IHE ITI Technical Framework
  • IHE IT Infrastructure (ITI) Technical Framework, Volume
    Revision 20.0, August 4, 2023 – Final Text
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the Volume 1 Table of Contents.

Appendix B: Definition of Unique Ids

Many IHE Profiles rely on the globally unique identification of persistent objects. It is the responsibility of the creating actor (or its delegate) to assign a globally-unique identifier to an object before the object is submitted or, is available for retrieval. This allows other actors to retrieve the same object at different points in time and to obtain the same semantics for its presented content.

This appendix describes how unique identifiers shall be created. The requirements specified in this appendix are derived from the common practices and definitions of OIDs in ISO 8824, HL7® V3 and CDA® and UIDs in DICOM®. They guarantee uniqueness across multiple countries, sites, vendors, and equipment.

HL7 is the registered trademark of Health Level Seven International and the use does not constitute endorsement by HL7.

CDA is the registered trademark of Health Level Seven International and the use does not constitute endorsement by HL7.

DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information.

B.1 Requirements for UIDs

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 a Document Sharing transaction shall be extensions of registered values as defined by ISO 9834-3 to ensure global uniqueness. These requirements result in the following structure for unique Ids.

B.2 Structure of a UID

Each UID is composed of two parts, an <org root> and a <suffix> separated by a “period”. Therefore: UID = <org root>.<suffix>

The <org root> portion of the UID uniquely identifies an organization, (e.g., manufacturer, research organization, hospital, 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 UIDs created by that organization. Unlike the <org root>, which may be common for UIDs in an organization, the <suffix> shall take different unique values between different UIDs that identify different objects. The <org root> is used only for uniqueness and not for any other purpose.

Although a specific implementation may choose some particular structure for its generated UIDs, it should never assume that a UID carries any semantics. 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 UIDs (including extracting the root) may jeopardize the ability to inter-operate as implementations evolve.

B.3 UID encoding rules

The UID encoding rules are defined as follows:

  • Each component of a UID is a number and shall consist of one or more digits. The first digit of each component shall not be zero unless the component is a single digit.

Note:   Registration authorities may distribute components with non-significant leading zeroes. The leading zeroes should be ignored when being encoded (i.e., “00029” would be encoded “29”).

  • Each component numeric value shall be encoded using the characters 0-9 of the Basic G0 Set of the International Reference Version of ISO 646:1990. This particular encoding is the same as the UTF-8 encoding for these characters in UNICODE.
  • Components shall be separated by the character "." (2EH).
  • UIDs shall not exceed 64 total characters, including the digits of each component, and separators between components.

B.4 How to obtain a UID registration root?

Organizations that define UIDs are responsible for properly registering their UIDs (at least obtain a registered <Org Root>) as defined for OSI Object Identifiers (ISO 9834-3). The organization defining the UID shall accept the responsibility of ensuring its uniqueness. IHE will not register UIDs or issue registered organization roots. There are a large number of means to obtain an organization root free or for a reasonable fee.

A useful resource that is often used by the DICOM community lists many ways to obtain a registered UID Root for a small fee or even for free, anywhere in the world.

http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration

The manner in which the suffix of a UID is defined is not constrained by any IHE Integration Profile. Only the guarantee of its uniqueness by the defining organization is required by IHE.

B.5 Example of a UID

This example presents a particular choice made by a specific organization in defining its suffix to guarantee uniqueness. A variant is discussed.

   "1.2.840.xxxxx.4076078054086.11059664469.235212"

    (root)     (suffix)

>In this example, the root is:

   1     Identifies ISO

   2     Identifies ANSI Member Body

   840     Country code of a specific Member Body (U.S. for ANSI)

   xxxxx     Identifies a specific Organization (provided by ANSI)

In this example the remaining components of the suffix relate to the identification of a specific instance:

   4076078054086   802.3 MAC Address (004 076 078 054 086)

   11059664469     Time system was booted (July 31, 2033 10:14:29)

   235212    Monotonically increasing sequence number

In this example, the organization has chosen these components to guarantee uniqueness. Other organizations may choose an entirely different series of components to uniquely identify its objects.

Because of the flexibility allowed in creating UIDs, implementations should not depend on any assumed structure of UIDs and should not attempt to parse UIDs to extract the semantics of some of its components.

B.6 Representing UUIDs as OIDs

The standards ITU X.667 and ISO 9834-8 define a particular OID root for the UUIDs, and define the translation between these two formats. The top node 2.25 is assigned for all UUIDs. This means that the UUID that can be written as urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 (using hexadecimal notation) is also 2.25.329800735698586629295641978511506172918 (using dotted decimal notation). It can also be encoded using the ASN.1 rules in a binary form internally within X.509 Certificates and some LDAP messages. All of these are the same OID. The reverse is not true. Not all OIDs can be represented as UUIDs. UUIDs are a subset of the OIDs.

This relationship is one way to obtain OIDs in situations where an OID is needed. It is not necessary to use the 2.25 root. An OID assigning authority might take advantage of the UUID generation mechanisms to assign new OIDs within its own root domain. These OIDs would not be UUIDs, but they would be valid OIDs.