PMCCPMCCPMCC

Search tips
Search criteria 

Advanced

 
Logo of digimagwww.springer.comThis JournalToc AlertsSubmit OnlineOpen Choice
 
J Digit Imaging. 2009 February; 22(1): 11–14.
Published online 2007 September 25. doi:  10.1007/s10278-007-9079-7
PMCID: PMC3043668

Using Java to Generate Globally Unique Identifiers for DICOM Objects

Abstract

Digital imaging and communication in medicine (DICOM) specifies that all DICOM objects have globally unique identifiers (UIDs). Creating these UIDs can be a difficult task due to the variety of techniques in use and the requirement to ensure global uniqueness. We present a simple technique of combining a root organization identifier, assigned descriptive identifiers, and JAVA generated unique identifiers to construct DICOM compliant UIDs.

Key words: Digital imaging and communications in medicine (DICOM), structured reporting, digital imaging

BACKGROUND

Digital imaging and communication in medicine (DICOM) is the industry standard for biomedical imaging.1,2 It specifies a standard digital image format, structure, and interchange protocol for biomedical images and radiology structured reports, both of which are DICOM objects. Included in the standard is the requirement that all DICOM objects have globally unique identifiers (UIDs).3 (pp 54–55) Some UIDs are defined in the DICOM standard documentation and registered by the National Electrical Manufacturers Association (NEMA).4 (pp 86–98) Often, these NEMA UIDs are used to enumerate value option lists for specific elements in DICOM objects, such as Service-Object Pair (SOP) Classes.5 (pp 31–34)

Other UIDs are privately defined and registered by vendors, manufacturers and institutions. Private UIDs include Study Instance UIDs, Series Instance UIDs and SOP Instance UIDs.3 (p 55) The Study Instance UID and Series Instance UID identify the study and series, respectively, within which the object is a member.6 (pp 77–78) The SOP Instance UID is unique to each object.6 (pp 79–80) Global uniqueness requires that DICOM-generating applications (i.e., any application that creates DICOM objects, including modalities and PACS) guarantee that the private UIDs will not ever become replicated internal or external to the institution.3 (pp 54)

We first encountered the necessity of generating appropriate, private UIDs when developing an application that generates DICOM structured reports (SR).7 A DICOM SR is used to encode, transmit, and store imaging diagnostic information in a standard DICOM report.8 This manuscript presents a technique of modifying the results of the Java UID class to create DICOM-compliant UIDs that are globally unique.

METHODS

Components of the DICOM UID

According to the DICOM documentation, each UID, including private UIDs, are made up of two root components: org root and suffix [UID = “<org root>.<suffix>”]. Both root components are, in turn, made up of subcomponents. All subcomponents in the UID are separated by a period (‘.’). The entire UID can consist of only numbers, with no leading zeros in any subcomponent. In addition, the UID is limited to 64 characters (i.e., a 64-byte string).3 (pp 54–55)

The org root ensures external uniqueness of the DICOM UID, while the suffix ensures internal uniqueness. The org root, including its subcomponents, is assigned to an organization, institution, or vendor and can be obtained from a number of sources. A list of sources has been compiled by Dr. David Clunie.9 We registered for our org root via the Internet Assigned Numbers Authority (IANA).10

The suffix is also made up of multiple subcomponents because it is the organization’s responsibility to ensure uniqueness of every UID generated. We divided our suffix into two primary subcomponents: descriptive which describes the local application, object type, and UID type of the UID and uniqueness which guarantees internal distinctiveness. The descriptive subcomponent is made up of application ID, object type ID and UID type ID [<descriptive> = “<application id>.<object type id>.<UID type id>”]. The uniqueness sub-component is made up of unique, time and count [<uniqueness > = “< unique >.< time >.< count >”]. Finally, we append the UID type ID to the end of the suffix [<suffix> = “<descriptive>.<uniqueness>.<UID type id>”] (Fig. 1). Our application only generates two types of DICOM objects, both of which are types of DICOM SRs. However, these principles are applicable to more complex DICOM-generating applications.

Fig 1
The DICOM UID is composed of the org root and suffix. The suffix, in turn, is composed of the descriptive and uniqueness. Finally, the UID type ID is appended to the end of the suffix.

The Descriptive IDs

The descriptive subcomponent uses a set of incrementally assigned IDs. It is made up of application ID, object type ID, and UID type ID [<descriptive> = “<application id>.<object type id>.<UID type id>”].

The Application ID

The application ID is a unique number within the organization assigned to a specific application or application function. We recommend that there be a single person or small group with the responsibility of managing private UIDs within the organization. Therefore, all application IDs should be registered with this person/group and recorded. This will ensure locally unique application IDs. For example, assume a specific application for generating DICOM SR objects is assigned the ID “11”, then, each UID being created for any object generated from that application will use “11” as its application ID.

The Object Type ID

We assign each object type its own number. This number is the object type ID and is used for all instances of the object type across all applications within the organization. For example, if the Basic SR object is assigned, the ID “24”, then “24” would be used as the object type ID every time any application within the organization generates a DICOM object of Basic SR type.

The UID Type ID

Similar to the object type ID, we assign each UID type its own number. This number is the UID type ID and is used for all instances of the UID type across all applications within the organization. For example, assume we assign Study Instance UID the ID “2”, Series Instance UID the ID “3”, and SOP Instance UID the ID “4”. Every time a Study Instance UID is generated, for any object type for any application within the organization, “2” is used as the UID type ID, and so forth.

The Uniqueness IDs

The uniqueness subcomponent of suffix is the set of IDs to guarantee the UIDs global uniqueness. It is made up of unique, time, and count [<uniqueness > = “< unique >.< time >.< count >”]. We use the java.rmi.server.UID class to generate these IDs. It is convenient for us to use Java given that our web application is written in Java Server Pages (JSP).

By calling the UID constructor, “UID uid = new UID()”, Java generates a uid object with three parts: (1) an intunique to the Virtual Machine (VM) where the UID was generated, (2) a long timestamp representing the time at which the VM was started or became “live”, and (3) a short thread-safe count. The count is necessary for UIDs generated where the unique and time are the same. When using the “toString()” method on the UID, a single string is returned with each part represented in hexadecimal and separated by a colon (“:”) (e.g., “d4ebd08:111ba8f4cc6:-7fff”). As DICOM UIDs require only numbers, we parse the string into three substrings and then use the “Integer.parseInt(unique)”, “Long.parseLong(time)”, and Integer.parseInt(count)” methods to convert each hexadecimal value to an integer value.

When the count is generated, it automatically starts at −8,000 (FFFFE0C0 in hexadecimal) and then counts upwards sequentially. So, we use the “0x000000FFFF & count” command to convert the signed integer to an unsigned integer. This command converts “FFFFE0C0” (in hexadecimal) to 32,768. The system counts upward from 32,768 to 65,535 sequentially, then resets to 0 and continues to count up to 32,767 sequentially. At this point, it resets the time part and restarts the count at 32,768. We assign the java-generated unique as the unique ID, time as the time ID, and count as the count ID and combine them together, separating each subcomponent by a “.” (e.g., “223264008.1175656025286.32769”).

RESULTS

The final UID equals “<org root>.<application id>.<object type id>.<UID type id>.<unique>.<time>.<count>.<UID type id>”. The technique described ensures global uniqueness in generating private UIDs using Java.

DISCUSSION

Although the purpose of the UID could be identified within the organization via the descriptive subcomponents of the suffix, we strongly caution against inferring semantic meaning from UIDs. Internally unique application, object and UID type identifiers aid in ensuring global uniqueness; however, semantic meaning should not be inferred from the UID itself. Rather, in the case of DICOM objects, the semantics are obtained from the objects contents directly (e.g., the DICOM header of an image).

It can be difficult to generate DICOM UIDs that comply with the length limitations while ensuring global uniqueness.11 By using the Java UID class, this is accomplished in a simple manner. Java is a convenient, standard programming language commonly used in both web and client-based health care applications today. The Java UID class provides a simple technique for calculating numbers that ensure global uniqueness. Simple modifications of the Java results are needed to make the numbers DICOM compliant. Finally, by combining the correct subcomponents, we generate a globally unique UID, which is DICOM complaint.

References

1. Bidgood WD, Jr, Horii SC, Prior FW, Syckle DE. Understanding and using DICOM, the data interchange standard for biomedical imaging. J Am Med Inform Assoc. 1997;4(3):199–212. [PMC free article] [PubMed]
2. NEMA. DICOM Part 1: Introduction and Overview. PS 3.1-2006. Available at: ftp://medical.nema.org/medical/dicom/2007/07_01pu.pdf. Accessed February 28, 2007.
3. NEMA. DICOM Part 5: Data Structures and Encoding. PS 3.5-2004. Available at: ftp://medical.nema.org/medical/dicom/2007/07_05pu.pdf. Accessed February 28, 2007.
4. NEMA. DICOM Part 6: Data Dictionary. PS 3.6-2007. Available at: ftp://medical.nema.org/medical/dicom/2007/07_06pu.pdf. Accessed February 28, 2007.
5. NEMA. DICOM Part 4: Service Class Specifications. PS 3.4-2007. Available at: ftp://medical.nema.org/medical/dicom/2007/07_04pu.pdf. Accessed February 28, 2007.
6. NEMA. DICOM Part 3: Information Object Definitions. PS 3.3-2004. Available at: ftp://medical.nema.org/medical/dicom/2007/07_03pu.pdf. Accessed February 28, 2007.
7. Kamauu AWC, DuVall SL, Liimatta A, Wiggins RH, 3rd, Avrin DE: Implementing the IHE Teaching File and Clinical Trial Export Profile to Develop a MIRC-Compliant Vendor-Neutral Export Selector That Uses RadLex Terminology. Presented at: Radiological Society of North America (RSNA), 2006; McCormick Place, Chicago, Illinois.
8. Noumeir R. Benefits of the DICOM Structured Report. J Digit Imaging. 2006;19(4):295–306. doi: 10.1007/s10278-006-0631-7. [PMC free article] [PubMed] [Cross Ref]
9. Clunie D. UID Registration. http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration. Accessed April 3, 2007.
10. IANA. Private Enterprise Number (PEN) Request Template. http://www.iana.org/cgi-bin/enterprise.pl. Accessed April 3, 2007.
11. DICOM News Group (UID root search). http://groups.google.com/group/comp.protocols.dicom/search?q=UID+root&start=0&scoring=d&. Accessed February 28, 2007.

Articles from Journal of Digital Imaging are provided here courtesy of Springer