"Private" UIDs

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
pgimeno
Posts: 9
Joined: Tue, 2023-02-07, 08:24

"Private" UIDs

#1 Post by pgimeno »

I need to generate a UID for a use that, as of this writing, is not contemplated by DCMTK (in particular, an Irradiation Event UID for an X-Ray Radiation Dose SR).

The version I have of DCMTK contemplates the following UID prefixes based on the site's UID root:

Code: Select all

/// UID root for study instance UIDs
#define SITE_STUDY_UID_ROOT                     SITE_UID_ROOT ".1.2"

/// UID root for series instance UIDs
#define SITE_SERIES_UID_ROOT                    SITE_UID_ROOT ".1.3"

/// UID root for SOP instance UIDs
#define SITE_INSTANCE_UID_ROOT                  SITE_UID_ROOT ".1.4"
Is there a UID prefix that I can use, that is guaranteed to not collide with DCMTK's future UID prefix allocations?

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: "Private" UIDs

#2 Post by J. Riesmeier »

As far as the DCMTK-specific UID prefixes are concerned, there is a Feature Request in our issue tracker that refers to this topic: https://support.dcmtk.org/redmine/issues/656 - However, there was no decision yet on how to actually implement it.

Since you were asking for "private" UIDs, wouldn't it make sense to use your own "organization root" (see DICOM PS3.5 Chapter 9)? This would transfer the decision on how to sub-divide the "UID namespace" to you. Of course, you could also use a UUID for this purpose. Some DCMTK users will probably just use dcmGenerateUniqueIdentifier() with the SITE_INSTANCE_UID_ROOT prefix, which is also the default for this function. See also comment in above referenced issue #656.

pgimeno
Posts: 9
Joined: Tue, 2023-02-07, 08:24

Re: "Private" UIDs

#3 Post by pgimeno »

J. Riesmeier wrote: Wed, 2023-05-03, 10:21 As far as the DCMTK-specific UID prefixes are concerned, there is a Feature Request in our issue tracker that refers to this topic: https://support.dcmtk.org/redmine/issues/656 - However, there was no decision yet on how to actually implement it.
Thanks for pointing me to that issue.

J. Riesmeier wrote: Wed, 2023-05-03, 10:21 Since you were asking for "private" UIDs, wouldn't it make sense to use your own "organization root" (see DICOM PS3.5 Chapter 9)? This would transfer the decision on how to sub-divide the "UID namespace" to you.
We have redefined SITE_UID_ROOT, but we are using the prefixes defined by the library and derived from it. What bothers me is the possibility that a future upgrade of the library defines UID prefixes that collide with the ones we have defined.

Currently I have defined this:

#define PRIV_SITE_IRRADIATION_EVENT_UID_ROOT SITE_UID_ROOT ".2.1"

Which will be fine if DCMTK promises to never use a prefix that ends in .2.x, but will otherwise put us at risk of a future collision. That's what I meant by "private". And if it promises to never use a prefix that ends in anything other than .1.x, all the better, as all prefixes that end in .2.x or above would be available for private purposes.

Note that, while SITE_UID_ROOT can (and is encouraged to) be redefined by the application, no such provision is given for the three aforementioned definitions.

J. Riesmeier wrote: Wed, 2023-05-03, 10:21 Of course, you could also use a UUID for this purpose.
Yes I could, but that would lose the categorization of the UIDs that lets one tell what kind of UID it is just by looking at its prefix, which is a desirable property.

J. Riesmeier wrote: Wed, 2023-05-03, 10:21 Some DCMTK users will probably just use dcmGenerateUniqueIdentifier() with the SITE_INSTANCE_UID_ROOT prefix, which is also the default for this function. See also comment in above referenced issue #656.
The problem again is the loss of categorization. Irradiation events are not SOP instances as the suffix suggests. Just like you would not create a study UID with, say, a SITE_SERIES_UID_ROOT, I'd like each UID category to be separated from the others. I know that's more of an aesthetic issue than a practical one, but it strikes me as less professional to have a separate study/series prefix and use the SOP instance prefix as a catch-all for everything else.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: "Private" UIDs

#4 Post by J. Riesmeier »

I can understand your points and will discuss with the other DCMTK team members whether we want to define a sub-prefix (based on SITE_UID_ROOT) that is reserved for application-specific / private usage.
However, I don't think that we will use ".2" for these type of UIDs, and also don't think that we should limit the DCMTK-specific use to ".1". Instead I would propose to use ".9" as a suffix to SITE_UID_ROOT for the before-mentioned "private" usage.

pgimeno
Posts: 9
Joined: Tue, 2023-02-07, 08:24

Re: "Private" UIDs

#5 Post by pgimeno »

Thanks. The application is still in development so we will change it to .9 per your suggestion.

pgimeno
Posts: 9
Joined: Tue, 2023-02-07, 08:24

Re: "Private" UIDs

#6 Post by pgimeno »

After checking the sources, I think there is a more serious problem. The library makes use of SITE_*_UID_ROOT in a number of places. This means that those who are using a precompiled version of the library, but redefining SITE_UID_ROOT, like we are doing, can potentially end up with a mix of their own root (in UIDs that they will generate themselves) and the default OFFIS root (in UIDs that the library generates internally).

So, the user needs to take care not to use anything that generates UIDs internally, for example DSRDocument::updateAttributes with updateAll = true and an empty UID tag, or any of the various functions that call DcmIODUtil::createUID.

These should be changed to dynamic, probably through global variables, so that an application can initialize the library with the desired root and trust that it will be used in all UIDs generated by the library, rather than having to recompile different versions of the library each with its own root for different projects, and needing to have one customized copy for each project.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: "Private" UIDs

#7 Post by J. Riesmeier »

I don't think that we should replace the #defines with global variables. In my opinion, global variables are usually the worst solution. Also, I don't think that anyone who has its own organization root (UID prefix) will use precompiled binaries/libraries. At least, in my estimation, this is rather rarely the case.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: "Private" UIDs

#8 Post by J. Riesmeier »

Instead I would propose to use ".9" as a suffix to SITE_UID_ROOT for the before-mentioned "private" usage.
Today, I discussed this with the team. We will make sure that the ".9" UIDs will never be used/generated by the DCMTK. An appropriate comment will be added to "dcuid.h".

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 1 guest