invalid implementation uid?

[jsta...@qwest.net]

I installed a pacs system that uses the following implementation class
uid #: 65.112.112.68.73.67.79.77. Now for most dicom transfers I have
not had a problem untill just recently when I tried to connect with a
GE CT and the following happened:
I was able to C-ECHO from the pacs station to the CT but when we tried
to echo from the CT to the work station it failed. I also could query
the CT and bring up the patient list, of course it failed when we tried
to retreive the images. We then got the GE people involved and their
response was that the UID# was incorrect and that is why it failed. Now
it appears to me the number (uid#) is not of any ANSI standard but
should that be the cause of failure? Correct me if I am wrong but
doesn't C-ECHO protocol validate the UID# on both sides in both cases
(whether sending or receiving)?

Jim

[eric.g...@gmail.com]

Implementation class uid shouldn't have anything to do with whether
devices will transfer data unless one vendor has specifically
blackballed another vendor's DICOM software stack. The implementation
class UID is simply a unique identifier for a particular DICOM library
or a specific vendor. Many vendors don't bother to update their
implementation UIDs even when they update the DICOM implementation. I'd
say the vendor engineers involved in your incident saw a funky looking
UID that appears not to have been generated from an authorative source
root and used that as an excuse not to look further. Its entirely
possible they really do look parse the UID and attempt to extract
semantic information from the UID root value (which would be in
violation of the standard) but I doubt it.

The implementation class UID serves no purpose other than to uniquely
identify your DICOM software standard should not have any effect
whatsoever on the DICOM transfer. That said, GE CT scanners usually can
communicate with external systems when they are properly setup. I think
I recall that they are promiscous on C-Echo but required proper setup
in the IDNET setup in order to perform a C-STORE. I suggest you have
the GE engineer re-examine the IDNET configuration to make sure its
properly configured - for example make sure its set up to use the
public/standard versions of the image rather thatn the GE private SOP
classes (which is the default config)

You might also get a DICOM sniffer on the interchange to see what kinds
of messages are being exchanged in the lower lever protocol. With such
a sniffer you'd be able to see if the scanner is only proposing the
private SOP class (or sending the private SOP class) which one would
expect your PACS application to refuse.

[Harry Soloon]

In fact, a UID is not totally opaque, and that is an invalid UID. The
first component of a real UID must be 0, 1, or 2, indicating a root
authority of ITU, ISO, or Joint ITU-ISO. It is perfectly reasonable
for an application to verify that the UID is derivable from a root
authority; otherwise, all UIDs from the application are suspect. I
don't know what checks the particular receiving application makes, but
the fault here is clearly with the sending application which is making
up bogus UIDs.

- Harry Solomon

[eric.g...@gmail.com]

Hi Harry

Perhaps a collision here between different paragraphs of Part 5,
Section 9.

You are referring the paragraphs which state:

The UID identification scheme is based on the OSI Object Identification
(numeric form) as defined by the ISO 8824 standard. All Unique
Identifiers, used within the context of the DICOM Standard, are
registered values as defined by ISO 9834-3 to ensure global uniqueness.
The uses of such UIDs are defined in the various Parts of the DICOM
Standard.
Each UID is composed of two parts, an <org root> and a <suffix>:
UID = <org root>.<suffix>

The <org root> portion of the UID uniquely identifies an organization,
(i.e., manufacturer, research organization, NEMA, etc.), and is
composed of a number of numeric components as defined by ISO 8824. The
<suffix> portion of the UID is also composed of a number of numeric
components, and shall be unique within the scope of the <org root>.
This implies that the organization identified in the <org root> is
responsible for guaranteeing <suffix> uniqueness by providing
registration policies. These policies shall guarantee <suffix>
uniqueness for all UID's created by that organization. Unlike the <org
root>, which may be common for UID's in an organization, the <suffix>
shall take different unique values between different UID's that
identify different objects.

Whereas I am citing the paragraph

"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. Component definition (for the suffix) is
implementation specific and may change as long as uniqueness is
maintained. Parsing UID's may jeopardize the ability to inter-operate
as implementations evolve."

So the question is - Does an implementation have the "right" to parse a
UID to extract the <org root> identifier and semantically verify that
it does indeed correspond to an ISO registered organization? Can they
refuse to participate in DICOM communications if the org root is not
one registered with an ISO recognized root organization (or if the UID
value is not structured in the manner required by an ISO organization)?

Guess we have to delve into the specfics of what ISO 9834-3 actually
says about requirements to ensure uniqueness. I've seen UIDs in
non-DICOM applications (like the windows registry) which definitely do
not begin with 0, 1, or 2, including some which begin with a 65. I'd
guess the application implementor assumed their UID root used in
another implemention domain was applicable in the DICOM space.

My personal take is the paragraph preventing you from parsing the UID
value precludes GE from parsing the implementation UID in order to
validate the org root; and it prevents you from prejudging the
correctness of other UID values and application may generate. Instead
you have a burden of proof to show an application is generating
non-unique UID values in specfic instances --i.e. its the DICOM
equivalent of innocent until proven guilty. Thus, while the implementer
may in fact be using an invalid UID and is in violation of the
standard, a GE application would be equally in violation of the
standard for parsing the UID to discover this fact.