[Insight-developers] DICOM UID Generation + Mac address

Miller, James V (Research) millerjv at crd.ge.com
Tue Jan 18 08:17:15 EST 2005


It was suggested previously that we take the ITK root id and tack a 
".1" onto it to designate a subspace of the id space for ITK generated
DICOM.  This will allow the Insight Software Consortium to designate another
subspace of the id space (".2", etc) as needed to distinguish our DICOM
efforts.

So we want to send the prefix 

1.2.826.0.1.3680043.2.1125.1.

to the GDCM generation code.


The user should have the option of indicating whether series being written
is to be part of an existing study.  There are two use cases that I can see:

1. The output being generated is based upon an existing DICOM series
(input).
In this case, the user may want to have the output series be part of the
same
study as the input series.  In this case, the user will need to provide the
StudyUID from the input series.

2. The user is writing several outputs and want to have them put in the same

study.  In this case, the outputs do not necessarily have to be based on an
existing DICOM series.  Again, the user will have to provide a StudyUID. But
in
this case, the we need to provide a mechanism for the user to request a UID
from the DICOM writer.  This will allow the user to generate a StudyUID 
and pass that UID to several DICOM writers so that each result appears in
the 
same study.

I don't think you need to tack the image number onto the instance UID.  Are
you
concerned that the clock value will not have enough resolution to ensure a 
unique value for two adjacent images?

Along these lines, there shouldn't be a reason to tack any particular
suffix onto Study Instance UID, Series Instance UID, and Frame of Reference
UID. The UID's are not meant to be parsed.  So the only important thing
that the UID's are unique.  If the algorithm of MAC + Date + Time will
give a unique UID, then there is no need to use the additional UID space
to distinguish the type of UID.

Are you ensuring that the UID's do not exceed the size limit of a UID?

Finally, what about multitasking environments where two processes might
try to write a DICOM image (albeit a different image) at the same time?
Based on a MAC+DATE+TIME algorithm, two processes could generate the same
UID.  Should we encode the "process/task number" into the UID? (I guess 
this could be taken a step further where a single process has multiple
threads where each thread may write out an image (albeit a different image)
at the same time.  In this case, we would need to encode a "process + thread
number" into the UID.

Jim


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


_______________________________________________
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