Minimum UID length.
I've been maintaining a DICOM read/write library which supports
manipulating uncompressed DICOM files inline. This is more efficient
because 99% of my work involves only touching the image data.
The only other field I have to touch is the SOP instance UID.
I've written a routine to generate UIDs which are of the same length
as the current UID. The problem is that I cannot generate UIDs of
length less than 19 chars without loosing uniqueness. I've designed
my library so that it will 'wait' for a unique ID to prohibit the user
generating a large number of IDs which may be non-unique.
Is there a general trend that 99% of all DICOM software uses UIDs
which are more than 19 chars?
Re: Minimum UID length.
You should take care that you aren't being to terse in your UIDs or you
may find yourself bitten but laws of unintentend consequences. Yes,
UIDs tend to have a lot of repetitive information and only vary in the
last dozen or so characters of a near 64 byte value, but the fixed
portion of the UID can be used to establish that it isn't a "rogue" UID
generator. In my humble opion this violates the DICOM standard which
indicates UIDs are opaque and their internal values can't be
interpreted for anything other than uniqueness. However, a little while
back, a developer wrote in indicating a GE system was refusing his
system's images citing "invalid UID". The rationale GE provided for
rejecting his UID was the preamble/root of his UIDs did not included a
hierarchy of registration authorities as is shown in DICOM Part 5,
Annex C. In particular this paragraph:
For privately registered identifiers, NEMA will not act as registration
authority. Related organizations shall obtain their proper registration
as defined for OSI Object Identifiers by ISO 9834-3 to ensure global
uniqueness. National Standards Organizations representing a number of
countries (e.g., UK, France, Japan, USA, etc.) for the International
Standards Organization act as a registration authority by delegation
from ISO, as defined by ISO 9834-3.
The guidance in Annex C goes on to suggest a framework in which a
developer can ensure uniqueness across multiple instances of their
product, time, and different entities (eg. study, series, instance,
FOR, etc) for which UIDs have to be generated. This particular
developer said "Fine I've got my own scheme for ensuring the uniqueness
of my values. I don't need that hierarchical scheme based on a root
registration authority and a licensed extension number from the
GE on the other hand said. "We don't know you from Adam. If you don't
use UIDs based on a registered authority, we don't have to accept your
objects in our system". There are valid arguments on both sides. Bad
UIDs cost PACS vendors and others lots of tech support time when weird
things happen in their system from non-unique UIDs which have been
assumed to be unqiue. Non-unique UIDs can still happen with registered
root values but in theory it shows you've gone the extra design mile
and are establishment enough to get your own root value.
So, while you can save significant database storage a few bytes at time
with short UIDs. You can find yourself in a situation of your system
not working with one of the big players if you've cut too many corners
shaving down the UIDs. 19 characters sounds pretty lean if you ever
want to grow that system beyond a single instance.
Re: Minimum UID length.
I agree with Eric, but want to add my $0.02:
Part 5 Annex C is "Informative", whereas Part 5 Section 9, which is
"Although a specific implementation may choose some particular
structure for its generated UIDs, it should never assume that a UID
carries any semantics. Thus, a UID shall not be "parsed" to find a
particular value or component."
Besides, there are at least two legal hierarchies for ANSI-issued
object identifiers: 1.2.840.xxxxxx and 2.16.840.xxxxxx, who is to say
that the OID tree won't sprout new branches in the future?