request for dicom org root for openmrs

Implementing
1

Dear all,

the radiology module is generating DICOM UIDs, specifically Study Instance UIDs.

For these UIDs to be DICOM compliant UIDs they have to be prefixed with an ‘org root’ portion of the UID which uniquely identifies an organization, (i.e., manufacturer, research organization, NEMA, etc.) see http://dicom.nema.org/dicom/2013/output/chtml/part05/chapter_9.html

Currently, the radiology module defines a default value, which is just used for development purposes. It is the duty of the implementer to change this global property once he configures the radiology module.

My question now is should OpenMRS apply for an UID, like for example here (and if so who should do so): https://www.medicalconnections.co.uk/Free_UID

so the ‘org root’ UID can be used it as a default value in the radiology module and also by other OpenMRS modules. This would ensure that DICOM UIDs generated by OpenMRS can be externally unique and furthermore take some burden off of implementers.

@judy @sunbiz please share your opinions and invite others who might be able to help on this topic

2 Likes
2

It would be preferable to have the org part of the UID to be implementation specific. I think if we use a common org UID across all OpenMRS implementations and, someone wants to get a study performed from one location which is using OpenMRS and wants to upload it in another location which is also using OpenMRS, there is a distant possibility of UID duplication.

3

you are totally right that is a possibility. although we could counteract that with an implementation specific UID component so the DICOM UID would be something like ‘org root’.‘implementation’.‘application’.‘uid type’.'unique part’

I am ok with leaving the default which I use during development (currently is “999.999.999”) and every implementer has to change it to a UID for his org.

By the way, who ever is interested, this is how I intend to implement the UID generation Using Java to Generate Globally Unique Identifiers for DICOM Objects

3 Likes
4

I think the problem with OpenMRS becoming an org root, is that OpenMRS does not produce those radiology images. OpenMRS is developer of the RIS, but not the organization that is generating the tool. It should be the implementation that should add that, or we should stick with the default.

1 Like
5

Just for the record: Every entity in the DICOM Data Model has a UID with the exception of the patient. DICOM Data Model: Patient -> Study -> Series -> Instance(Image)

The radiology module generates the UID for the Study, which will then be served by the PACS to the imaging modalities which in turn put this Study Instance UID into the image. So we do not produce images correct, but the UIDs end up in the images. So we have to make those UIDs according to DICOM.

But I am ok with it being the implementers duty to get a valid externally unique org root UID.

2 Likes
6

Just wanted to inform whoever is reading this topic, that I am changing the default Org Root UID in the radiology module to “2.25” since “999.999.999” isnt a valid UID based on the ASN.1 standard.

I wrote an interface DicomUidGenerator for generating a DICOM UID which we use for our DICOM Study Instance UID. I also wrote a default implementation UuidDicomUidGenerator which puts a UUID in decimal representation after the Org Root UID. See OID repository - 2.25 = {joint-iso-itu-t(2) uuid(25)} for more info where you can read that

UUIDs can in all cases be appended after the 2.25 arc without registration.

An implementation can then just configure its own Org Root UID and another DicomUidGenerator if they want to.