[Insight-developers] DICOM UID generation

Wed Jan 5 17:40:44 EST 2005

Done.  Attached is the completed form.

I will let you know when I get the email containing the UID.

One thing - this is a "default UID" for ITK.   We need to make it easy
for people to change the default UID for ITK.   Can we make the UID by a
value of an advanced option in CMAKE?  Is that sufficiently permanent -
what if they clear the cache - they'll have to remember to re-type their
UID...or we could also store in a separate file in the binary
directory...a file that contains cmake variables that persist beyond the
"cache?"

Stephen

PS> A copy of ISC's UID request form is at 
http://caddlab.rad.unc.edu/Public/ISC-UIDApplication.jpg
I will add this to the InsightDocuments directory or any other place 
ya'll suggest.  It has a short blurb about us being allowed to 
sub-delegate for others to use...

> 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
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
> 
> 
> 
> ------------------------------------------------------------------------
> 

-- 
===========================================================
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