[Insight-developers] [Fwd: Your UID prefix from Medical Conne ctions]

Miller, James V (Research) millerjv at crd.ge.com
Thu Jan 6 09:43:29 EST 2005


Stephen,

As Dr. Clunie suggested, we should give ITK a subspace to this UID.  That
way ISC will have room to grow if necessary.

ISC_UID will be what you just received.
ITK_UID = ISC_UID.1. 

Note that whis makes ITK's root UID 29 characters long. We'll
have to dig through the standard to see what the length 
restriction on a UID is.  It may be limited to 64 characters. In which case
we'll have space in our UID subspace for 11^36 unique items which can be
images, series, studies, contours, etc., (36 suffix characters which can be
0-9 and "."). 

(We delegate a subrange to each of the prime organizations in ISC but I am
not sure that there is any reason to do that yet.)

For the suffix, we should use a combination of a device
serial number (MAC address, etc.) and a datestamp plus perhaps a random
number, perhaps hashed to keep it within the 64 bytes
that DICOM allots for UIDs. We need to provide an algorithm in ITK for
generating a unique suffix of a specified size. This 
will eliminate the need for a user to ever supply a suffix.

As for how to use the root uid, I would encoded it in a header
file.  Then I would suggest that we extend the DICOM writers such they will
use the ITK_UID by default but allow an application to supply an alternative
root id.  This may be
hard to do because different root id's may be of different lengths but a
complete UID has a size limit.  So our suffix generation routine would have
to be written to generate suffices of various sizes.

As Dr. Clunie pointed out, nobody cares what the UIDs are as long as they
are unique.  So it may not be worth it to extend
the writers to take an application supplied root uid.

Once we have a routine to generate suffices uniquely, then we
need to setup the writer to know when to generate a UID.  Dr. 
Clunie pointed out that the output of an algorithm could reuse
the Study UID from the input dataset but cannot reuse the Series UID or any
of the Instance UIDs.




-----Original Message-----
From: Stephen R. Aylward [mailto:aylward at unc.edu]
Sent: Wednesday, January 05, 2005 5:55 PM
To: Insight-developers (E-mail)
Subject: [Insight-developers] [Fwd: Your UID prefix from Medical
Connections]


Wow - they're fast....the ISC's UID is given below...

As Dr. Clunie said, we are obligated to make sure each suffix is 
unique...or I may go to jail or spend an extra year in purgatory 
or...hmmm, they're kind of unspecific on it...and guessing about how 
some dicom databases operate, it probably is quite important.

To make suffixes unique...are some machine's random number generators 
tied to GMT?   If not, perhaps a long random number appended to GMT at a 
resolution of a 1/100th of a second is a good suffix.

Assuming that we don't want to get into trying to manage/delegate 
sub-ranges of suffixes, I don't think we should make it easy for the 
user to modify a suffix since they might succumb to the impression that 
if they use 1234 then they would certainly not conflict with anyone else...

Stephen

-------- Original Message --------
Subject: Your UID prefix from Medical Connections
Date: Wed, 5 Jan 2005 22:38:10 -0000
From: Dave Harvey <dave at medicalconnections.co.uk>
To: <aylward at unc.edu>

Dear Stephen R. Aylward,

I have pleasure in enclosing your UID prefix as promised.  It is:

1.2.826.0.1.3680043.2.1125.

You are hereby granted full permission to use this UID prefix as your own
subject only to the following minimal conditions:

1) You agree to operate a policy to ensure that UIDs subordinate to this
prefix cannot be duplicated.

2) You may sub-delegate ranges using your prefix, providing this is either
on a not-for-profit basis, or as part of another product.
      i.e. you may not sell numbering space itself

I hope that this facility is useful to you, but you have any questions,
please ask.

Yours sincerely

David Harvey
Medical Connections



-- 
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab.rad.unc.edu
aylward at unc.edu
(919) 966-9695
_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers


More information about the Insight-developers mailing list