[Insight-developers] DICOM UID Generation + Mac address

[David Clunie]

There are two issues here, one being uniqueness of UIDs and the
other being repeatability of UIDs for the same entity.

There is not necessarily a simple answer to this that provides a
general solution at the DICOM toolkit level, since one has to know
what the application is trying to do.

I.e., is it adding more images to an existing series, or more series
to an existing study and/or frame of reference ?

Typically what I do is either:

- prior to creating a new study, create a new Study Instance UID that
is unique, and use that for all instances of all series that I will
add to that study; same for series, same for frame of reference; this
requires the calling application to properly model studies, series and
instances, and maintain some state, rather than independently write
individual instances with no notion that they share anything in common;
this is without doubt the safest approach

- prior to creating anything, build a UID component that is unique,
and feed that 'stamp' value into subsequent study, series and instance
level UID generation routines that subdivide that space into separate
sub-spaces for each purpose, and use numeric values obtained from
such things as StudyID, Series Number and Instance Number - this is
a very dangerous approach in the general case, since none of those
attributes may be sufficient to disambiguate instances within the
set, and I only use it when I need an extremely deterministic approach
to generating UIDs for testing purposes, and I know that the necessary
disambiguating fields have reliable values (as you know, many vendors
leave series number and instance (image) number blank or always 1 or
similar, and study ID may be zeroed out for deidentification purposes);
also remember that adding something to an existing unique ID created
by someone else does not necessarily create a unique ID - one can only
add to one's own UIDs if one knows the value will not be repeated;
also remember that using other DICOM attributes from the header to
try to build UIDs is fundamentally flawed since no other attributes
or combinations of attributes are guaranteed to be unique, except
UIDs themselves, which are not extensible !

Regardless, one has to provide a mechanism such that all instances
intended for the same series get the same series instance UID, etc.
One obviously cannot depend on timing for that, nor even assume that
instances will come from a single thread.

David

PS. In another response someone mentioned MD5 hashes - these are generally
too long to encode as a UID component without exceeding 64 characters,
however, assuming that the hash values were evenly distributed throughout
the range of the hash, one could mask a certain number of bits to zero,
hence increasing the risk of collision but probably still keeping the
risk manageable, and produce a shorted decimal valued component as a
result. This might be a good way of taking lots of information and
collapsing it into a shorter decimal component, but would require
knowledge of the hash function characteristics that are beyond my ability
to analyze.

Lorensen, William E (Research) wrote:

> Mathieu,
> 
> There are issues with the UID generation.
> 
> I generated a new series from an old one with DicomSereisReadSeriesWrite.
> Then I imported the images into our Advantage Windows system. The series
> showed up as several studies with a varying number of images per study.
> Seems like some of the ids you are making unique should not be. The varying
> number probably has to do with clock resolution on the UID generator.
> 
> Bill
> 
> -----Original Message-----
> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> Sent: Monday, January 17, 2005 4:32 PM
> To: Insight Developers
> Subject: [Insight-developers] DICOM UID Generation + Mac address
> 
> 
> Hello,
> 
> 	Ok I think I am pretty much done with the DICOM stuff in ITK for the
> 
> release. I just want to double check with you it's alright.
> 
> 1. GDCM take also in account the "Serie Instance UID". Therefore even if 
> there are two seriies (same study) within the same dir, only one will be 
> picked.
> 
> 2. GDCM now uses the new ITK DICOM radical to generate the DICOM files. 
> So far I overrides:
> 
> [SOP Instance UID]
> [Media Stored SOP Instance UID]
> [Study Instance UID]
> [Series Instance UID]
> [Frame of Reference UID]
> 
> And the algorithm is:
> 
> uid = s1 + s2 + s3
> 
> s1 = 1.2.826.0.1.3680043.2.1125 // ITK radical
> 
> s2 = Mac address
> 
> s3 = Date + Time
> 
> 
> Then for "SOP Instance UID" I also append the image number. I did a 
> static int, and I increment it each time I write the image.
> 
> The only remaining -potential- problem is for Study Instance UID, Series 
> Instance UID and Frame of Reference UID. I am not sure what people 
> usally append to those strings. I'll investigate, meanwhile I just put a 
> different number for those 3. (any comments David?)
> 
> 
> The implementation for the Mac address gave me a lot of troubles, so 
> there is a chance it does not work on your plateform. So far I only 
> tested it on Linux, MacOSX, Sun Sparc and Win32.
> 
> Mathieu