Instance Indentifiers (II)

Instance identifiers provide globally-unique keys for various data items in an HL7-enabled system. Various data objects have instance identifiers. For example: people have health card numbers, drivers licenses, passport numbers, organization-specific patient ids, and internal database keys.

High-level Identifier Types

At the high level, there are two ways of creating a unique "instance identifier":

  1. use an algorithm such the Universally Unique Identifier (UUID); or
  2. let each system generate its own identifier, which is then qualified with a second part that is unique to the system and type of thing being identified.

HL7 supports both of these types of identifiers. An example of the first type might look like this:

<id root="1ee83ff1-08ab-4fe7-b573-ea777e9bad51"/>

In this case, the "root" of the identifier specifies a UUID, which uniquely identifies the thing. Because UUIDs are complicated (they're long, difficult to remember, and not very interesting), this approach is generally only used for "uninteresting" cases. A good example is message ids. When a system sends a message, it must provide a unique message id. Generally, people don't care what these ids are (they're only interesting for trouble-shooting purposes), so a uniquely-generated UUID works well for this purpose.

An example of the second type of identifier might look like this:

<id extension="51" root=""/>

In this case, the locally-unique part of the identifier is the "extension". This might represent a local prescription number, or client identifier. The locally-unique extension is qualified with another number -- called an OID -- that indicates that it is a prescription number assigned by System X.

Understanding OIDs

OIDs are fairly carefully managed by both HL7 and COSIRA. Typically, an organization receives a base OID, and the organization can further specify related OIDs.

For example, Intelliware has been assigned the following OID:

Intelliware can define additional OIDs derived from this base OID, and use those OIDs to qualify different types of locally-unique ids. For example, we've derived the OID,, to use for identifiers created by the TL7 application. Further, we use the OID,, to qualify Professional Service Identifiers that exist in our application.

Thus, if a system sends a message to TL7 to record a professional service in a client's e-health record, TL7 will generate a sequential number (the "extension" part of the id) and qualify that sequential number with OID, (the "root" part of the id). If we store a professional service, the id might be represented like this:

<id extension="51" root=""/>

The next professional service that we store would probably have the following identifier:

<id extension="52" root=""/>

Specialization Types


<id root="2.16.840.1.113883.19.335.72.7" extension="R092377" use="BUS"/>



This is a relatively rare identifier type. It is represented solely with an OID. It is intended to be used for cases where a limited number of (well-known) identifiers are used. The most common example is the <profileId> section of the HL7 transport wrapper. The profileId specifies a conformance profile that the message conforms to. Each jurisdiction supports a limited number of profile ids, and all systems that communicate with that jurisdiction should know those profile ids.

<id root="2.16.840.1.113883.19.335.15.8885.21197"/>

It's interesting to note that, as of MR 2009, profile id stopped being represented as an II.OID.


<id root="2.16.840.1.113883.4.20" extension="123567890" displayable="true"/>



<id root="64AC5370-D851-2D2F-2A18-78FBB73BFED9"/>



<id root="64AC5370-D851-2D2F-2A18-78FBB73BFED9" use="VER"/>

Specialization Types and Attributes

The following table summarizes which attributes need to be used with which specialization type.

Specialization Types and Versions

The following table summarizes which types are used in which versions of the CHI releases.

Note: Some of the Data Types Specification documents for early releases (such as, for example, the Data Types document released with the V01R04.3 of the CeRx standard) are pretty vague about precise definitions of II types. Other deliverables in the release, such as the MIFs, refer to several specialization types such as II.TOKEN, even though those types aren't discussed in the Data Types document.

2.0-SNAPSHOT build 44073 (2013-10-21 14:54:29)