[Insight-developers] DICOM UID generation

Wed Jan 5 17:14:35 EST 2005

Hi Jim

The problem with Dave Harvey's UID roots is that they are
quite long and waste quite a few of the precious 64 characters.

The IANA SNMP UIDs are much shorter.

Also, be sure that when you get a root, you subdivide the space
and assign someone to manage it. E.g. add a ".1" for your current
needs, anticipating that for a completely different project you
can use the same root plus ".2" or whatever later on.

E.g., you can actually use it for SNMP devices as intended should
it be necessary !

David

Miller, James V (Research) wrote:

> Thanks David.
> 
> Perhaps Stephen or Will should apply for a root id at
> http://www.medicalconnections.co.uk/html/free_uid.html
> on behalf of the Insight Software Consortium.
> 
> Jim	
> 
> 
> 
> -----Original Message-----
> From: David Clunie [mailto:dclunie at dclunie.com]
> Sent: Wednesday, January 05, 2005 4:46 PM
> To: Insight-developers (E-mail)
> Subject: Re: [Insight-developers] DICOM UID generation
> 
> 
> Hi Jim
> 
> Sending money to ANSI is a complete waste of money, since there are
> free UID roots available, and nobody cares where your root comes from
> as long as it is unique.
> 
> For other alternatives, see:
> 
> "http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration"
> 
> Your biggest problem though is not getting a root, it is making sure
> that every file generated by ITK anywhere no matter where and by whom
> it is installed is globally unique.
> 
> Typically this is done with something unique to the device on which it
> is installed, e.g. serial number, hostid, MAC address or similar, as
> well as any process or thread running on that device (e.g. process
> number). It is very hard to get this right in a multi-platform toolkit.
> The MAC address, process number, a date time stamp with high precision
> and a random number might be necessary. If it won't all fit into 64
> bytes, considering feeding everything (after the root) into some sort
> of cryptographic hash function.
> 
> The question also always arises as to whether it is safer to require the
> installer/user of a toolkit to acquire and install their own root rather
> than use the same one supplied to all users of the toolkit. In general
> it is extremely hard to guarantee that all instances of the toolkit
> compiled and installed anywhere on any platform will generate unique IDs.
> Conversely, it is hard to get users of toolkits to do the right thing.
> 
> Having accounted for that problem, another is to be sure that not only
> are all generated images assigned a unique SOP Instance UID, but that if
> they are part of the same (new) series, they must have a new unique Series
> Instance UID that is the same for all images in that Series. Same goes
> for the Study Instance UID, though you can add to an existing study, but
> not to an existing series unless you are the equipment that created that
> series in the first place. Same goes for Frame of Reference UID, which
> obviously needs a lot of attention in a registration toolkit !
> 
> Typical mistakes generating UIDs, by the way, are to exceed 64 bytes total,
> and to use leading zeroes in numeric components, both of which are illegal
> and cause significant problems downstream.
> 
> The formal rules are in PS 3.8 Annex F and PS 3.5 Section 6.1 and ISO 8824.
> 
> There are a few more comments of mine in the FAQ at:
> 
> "http://www.dclunie.com/medical-image-faq/html/part2.html#UID"
> 
> David
> 
> 
> Miller, James V (Research) wrote:
> 
> 
>>With the addition of GDCM to ITK, we can now write DICOM files.  However,
> 
> we
> 
>>have no mechanism for generating the UIDs that are needed within a DICOM
>>file. From what I can see, these UIDs are be thought of being composed of
> 
> a
> 
>>prefix and suffix.  The prefix is assigned to an organization by some
>>governing body.  The suffix is something unique that ITK (or GDCM) would
>>have to generate.  Usually the suffix is a combination of a device number,
>>device type (for ITK, perhaps a secondary capture device or an imaging
>>workstation), a datestamp, etc. The rules of DICOM indicate the suffix is
>>NOT TO BE PARSED to determine any information (for instance slice number).
>> 
>>The prefix is composed of a set of numbers that identify the organization,
>>the granting organization, and the country of origin.  For ITK, we could
>>have an organization number assigned by ANSI. Below is a link to ANSI site
>>on this matter.  ANSI will grant a numeric and/or an alphanumeric
>>identifier.  To write DICOM files, we need the numeric identifier.  The
> 
> cost
> 
>>for a numeric identifier is $1000. Is enough of the legal entity of the
>>Insight Software Consortium established that we could request a numeric
>>organization number from ANSI?
>> 
>>
> 
> http://www.ansi.org/other_services/registration_programs/reg_org.aspx?menuid
> 
>>=10
>>
> 
> <http://www.ansi.org/other_services/registration_programs/reg_org.aspx?menui
> 
>>d=10> 
>> 
>>There are some "free" alternatives for getting a unique organization
> 
> number.
> 
>>There are people who have organization numbers that are willing to grant a
>>subspace of their number to other organizations. There are also some
>>European organizations that may grant a unique organization number free of
>>charge.
>> 
>>Given that ITK was developed under NIH resources, I think we should go the
>>ANSI route to obtaining an organization number.
>> 
>>My understanding of the DICOM UID process is based on a few minutes of
>>google searches, so I may be off base.  If anyone knows anything in more
>>detail, please speak up.
>> 
>> 
>> 
>>
>>Jim Miller 
>>_____________________________________
>>Visualization & Computer Vision
>>GE Research
>>Bldg. KW, Room C218B
>>1 Research Circle, Schenectady NY 12309-1027
>>
>>millerjv at research.ge.com <mailto:millerjv at research.ge.com> 
>>
>>james.miller at research.ge.com
>>(518) 387-4005, Dial Comm: 8*833-4005, 
>>Cell: (518) 505-7065, Fax: (518) 387-6981 
> 
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> 
> 

-- 
Dr. David A. Clunie                         mailto:dclunie at radpharm.com
Chief Technology Officer (RadPharm)            http://www.radpharm.com/
Princeton Radiology Pharmaceutical Research          Phone 609-936-2600
103 Carnegie Center Drive #300A                        Fax 609-936-2601
Princeton NJ 08540                              http://www.dclunie.com/