UID's generated by DCMTK are DICOM-compliant ?

[Horst Balthasar]

We have to connect our device to the a PACS, that ask us for a example of a DICOM file. The answer from the PACS are the following:

Unfortunately, the example sent confirms our fears, which we explicitly mentioned in our email:

All 3 UIDs have the OrgRoot of the company Offis
=> therefore the example is not DICOM-compliant.

(Since the example was generated by "IMED MEDICAL GMBH" according to its DICOM header, the SeriesInstanceUID and SOPinstanceUID of
the example should have an OrgRoot from IMED MEDICAL and must not "misuse" the OrgRoot of the Offis company.
Since we know that the DICOM toolkits from Offis contain functions with which a manufacturer can either compile in their own OrgRoot
or alternatively set the toolkit so that it supports the variant of UIDs starting with 2.25. that is also permitted according to the DICOM
standard, there is no technical background that would explain why the manufacturer could not set this up correctly).

This means for your wish to connect the device to the PACS:
The use of third-party OrgRoots by a manufacturer when generating its image studies
can lead to the mixing of studies and, in the worst case, endanger patients.

Is that correct ? What can do ?

We use the UID generation as is in DCMTK with other PACS and it was not a problem to transfer the images.

Best regards,
Horst Balthasar

[J. Riesmeier]

I think I know this company. At least I had contact with a PACS company that claimed exactly the same thing. However, their statement is not correct (I even talked to the head of that company to clarify this). You can use the standard UID generation routine provided by the DCMTK, i.e. with the organizational root registered by OFFIS (which is not a company, by the way). The underlying algorithm makes great efforts to ensure that there are no conflicts with duplicate UID values.

But of course, it would not hurt if you would use your own UID prefix (registered organization root plus e.g. serial number of the device) or UUIDs. This is also what I usually recommend.

[Horst Balthasar]

Mr. Riesmeier,

thanks for her answer.

Best regards,
Horst Balthasar

[Horst Balthasar]

After we informed PACS IT about your reply, we received the following e-mail:

Unfortunately, it is not clear from this that OFFIS guarantees (!) that the UIDs generated by the DCMTK using the "organizational root" registered on OFFIS are unique worldwide.
However, the DICOM standard requires precisely this guarantee, as you can see from the two passages of the DICOM standard quoted below.
=>
Could you therefore ask OFFIS for clarification that OFFIS actually guarantees this uniqueness?

If OFFIS does not guarantee uniqueness, using the OFFIS org root in the DCMTK to generate the UIDs of your data would not be DICOM-compliant and you would have to pay for the UIDs generated by your device - as we have already mentioned.

Would it be possible to give us such a guarantee?

Nevertheless, we will apply for our own org root at DIN.

Best regards
Horst

[Marco Eichelberg]

OFFIS explicity permits the use of the UIDs generated by DCMTK under the OFFIS UID root by DCMTK users.
While we cannot accept any legal responsibility for the uniqueness of the UIDs, the UIDs are as unique as technically possible.
If the PACS vendor has reason to suspect otherwise, I would be happy to hear the reason why.
In any case, claiming that the UIDs generated by DCMTK are not DICOM compliant is utter nonsense.

[Horst Balthasar]

Thank you for your answer.

We have already installed countless DICOM connections with our device and never had any complaints about the UIDs.

That is why I was very surprised about the statements of the IT from the PACS manufacturer.

I just hope that the IT person from the PACS manufacturer is satisfied with your statement and that we can successfully complete the connection.

But it seems to me that the IT person from the PACS manufacturer is very resistant to advice ("beratungsresistent").

Perhaps I should ask whether the UID that we receive via the worklist is also unique and therefore DICOM-compliant.

Best regards and have a nice weekend
Horst

[J. Riesmeier]

Nevertheless, we will apply for our own org root at DIN.

Another option would be to apply for an "OID" (same concept as UID) at BfArM.