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.