# HL7 OID Policy and Guidelines

## Purpose

This document attempts to describe HL7's policies around OIDs, as well
as provide guidance to implementers on appropriate usage of OIDs, UUIDs
and related artifacts within version 3 instances.

At the moment, this document is a straw-man. Numerous 'normative'
statements are made regarding SHALL, SHOULD, MAY, etc. These statements
are initial positions suggested by the author. All content within this
document is subject to discussion and modification and should not be
treated as official HL7 policy until endorsed by the HL7 Vocabulary and
INM committees.

In some cases, this paper assumes the availability of new capabilities,
such as additional metadata in the OID registry, presence of an OID
registration list server, etc. If this policy paper is agreed, those
additional capabilities will need to be implemented.

## Background

### OIDs

OIDs are a hierarchical identification scheme designed to ensure that
identifiers are globally unique. The scheme is an ISO standard and is
used in a wide variety of industries. OID identifiers consist of a
series of integers separated by decimals. Each string of numbers prior
to a decimal represents the 'assigning authority' for the integer
following the decimal. If the rules defined by ISO are appropriately
followed, there is **no** chance that the same OID will be issued to
more than one object. If an OID is known, then it is also known exactly
what object the OID corresponds to.

Any person or organization can be issued an OID by an OID registrar.
Once issued, that OID is permanently and irrevocably assigned to
identify that person or organization. The person or organization can
then issue additional OIDs beneath their particular node.

![](media/image1.png){width="5.997222222222222in"
height="4.749305555555556in"}

For example, in the above diagram, the internet has the OID "1.3.6.1".
It in turn is the assigning authority for the node "mgmt" which has the
OID "1.3.6.1.2".

Note that the hierarchy implicit in an OID does not represent a
"meaning" for the OID, merely a way of ensuring that the identifiers
issued are unique.

### What are UUIDs

UUID stands for Universal Unique Identifier. A synonym is GUID (Globally
Unique Identifier). UUIDs are 32-byte hex numbers constructed by an
algorithm based on system information, time information and randomness
which ensures that the identifiers are unique. They tend to be displayed
like this: "[{guid {19809563-2181-11D6-834A-00B0D06C03A6}}]{.mark}".
With a total of 340 trillion trillion trillion possible values, the
probability of issuing a duplicate UUID is infinitesimally small.

## HL7 OID and UUID Usage

OIDs are HL7's preferred mechanism for identification of instances and
concepts in version 3 instances. They are used in two places:

1.  They MAY be used as the *root* property when conveying an identifier
    using the II datatype

2.  They SHALL be used as the *codeSystem* property when conveying a
    code using the CD, CE and CV datatypes

In addition to OIDs, the II.root property MAY instead be populated with
a UUID or an HL7-defined string.[^1]

In addition to their appearance in HL7 messages, HL7 also uses OIDs for
internal tracking purposes, including the identification of HL7
artifacts in registries and for uniquely referencing artifacts such as
value sets.

## Principles for identification in HL7

### Unique reference

The primary purpose of the II and various CD-derived datatypes is to
allow unique reference to a particular instance or concept.

In the original HL7 v2 world, many identifiers and codes were "local".
They worked well when exchanging information within the narrow world of
the hospital for which they were configured, but ran into problems when
communication became necessary between other hospitals, other regiouns
or even other jurisdictions. Communication across these boundaries
frequently required custom mapping rules checking sending facility,
sending application or other fields to come up with a 'true' unique
identifier.

In v3, the design of the II and CD datatypes is intended to ensure that
unique globally identification can be achieved within the confines of
the datatype itself. This means that if an application sees two values
of an II or CD-derived datatype and they have the same values (same
*root* and *extension* for II, or same *codeSystem* and *code* for CD),
that means they refer to exactly the same instance or concept. This is
true regardless of whether the instances were created by different
applications created by different software firms and operating in
different jurisdictions or even countries.

To put it another way, no complaint application anywhere in the world
will ever create an II or CD-derived element with the same value as
another II or CD-derived element that does not have exactly the same
meaning. The problems of duplicate patient identifiers from distinct
systems referring to different patients or duplicate local observation
codes referring to different observation types should not occur in v3.

This is achieved by the use of OIDs, UUIDs or HL7-defined unique
identification strings to ensure that there is no danger of two
independent applications ever accidentally creating the same identifier
for distinct objects.

### Non-duplicate reference

One of the challenges with OIDs and UUIDs is that there is nothing to
prevent every application under the sun from assigning its own unique
identifier to the same artifact. Every hospital in the U.S. could
theoretically construct their own OID for the concept of "U.S. social
security number". While there would be no issue with duplicate
identifiers referring to different people (solved by the global
uniqueness of the identifiers), there would still be a problem with
sharing information between systems. Applications would not be able to
successfully match person records by id because the *root* properties of
each of the ids would be different.

To mitigate this problem, HL7 agreed to construct and maintain an OID
"registry" of all common identifiers intended for use in HL7 v3
instances. HL7 policy is that only one OID may be recorded as the
'preferred' OID for that concept. HL7 v3 compliant systems SHALL use the
preferred OID when constructing v3 instances. HL7 takes responsibility
for ensuring that only one OID for a given concept is registered.

This approach ensures that every organization that captures the concept
"U.S. Social security number" uses the same OID root for that
identifier, regardless of what jurisdiction (or even country) the
application is operating in.

## Guidance for identifiers

There is some flexibility in how identifiers are conveyed in v3, as the
use of the *extension* property is optional and the root may be
populated with a choice of OID, UUID (GUID) or HL7-defined string.
Effectively this allows for 6 distinct combinations. This section
provides guidance for which style of identifier SHOULD be used by HL7
applications.

There are three primary categories of identifiers: Common public
identifiers, Local public identifiers and Private identifiers.

### Common public identifiers

These are real-world identifiers which are known by humans (providers,
patients, etc.) and which are frequently used in an environment outside
of a direct business relationship with the issuer of the identifier. For
example, social security number, drivers license number, physician
license number, jurisdictional patient identifier, etc.

Because these identifiers are known by and used by humans, the
*extension* property SHALL be used to convey the human-recognizable
portion. This ensures that the portion typically recognizable by users
is separate from the "namespace" portion contained in the root. This use
of 'extension' should occur for these human-recognizable identifier
types even if the identifier is a pure numeric that technically could be
appended to the end of a namespace OID.

To ensure globally unique identification, the root portion of the
identifier SHALL be used to define the namespace of the identifier. The
differentiating characteristic of Common public identifiers is that the
person capturing the identifier into an electronic system will rarely
have a means of directly communicating with the issuing authority to
determine the appropriate value for the root. For example, a user in
California who needs to record an Alberta driver's license will rarely
be able to contact the Alberta Department of Transportation to discover
the appropriate root. Furthermore, the Alberta Department of
Transportation may have little awareness of v3 messaging and might not
even know what the appropriate root would be.

As a result, HL7 maintains a registry of appropriate roots for every
type of Common public identifier. To determine the appropriate root, an
HL7 system merely needs to consult its local cached copy of this
registry. Because the only root types accepted by the HL7 registry are
OIDs, this means that the root portion of a Common public identifier
SHALL be an OID.

### Local public identifiers

Similar to Common public identifiers, Local public identifiers are also
used in human-to-human communication. As a result, the *extension*
property SHOULD be used to transmit the human-readable portion of the
identifier, even when the identifier has a numeric format that would
allow it to be appended as part of the OID root.

The primary difference between Local and Common public identifiers is
that Local identifiers are almost exclusively captured by systems that
have a direct business relationship with the originating system.
Examples include local patient identifiers, order numbers, encounter
numbers, etc. Any system which requires that one of these identifiers be
entered by a user will already have a business relationship with the
system which originated the identifier, and thus should know the
appropriate value for the *root* property of the identifier.

Because the roots will be known by the system capturing these
identifiers, no central registry is required. The roots for Local public
identifiers SHOULD NOT be submitted for inclusion in the HL7 OID
Registry. Because they will not be registered, the identifiers are free
to be UUIDs or OIDs. If OIDs are used, they SHOULD generally be based on
the OID of the organization or application responsible for issuing and
ensuring the uniqueness of the identifier.

### Private identifiers

Private identifiers includes all those identifiers necessary for the
smooth operation of automated systems, but which generally are not used
by clinicians, patients or other humans involved in healthcare. Examples
include message identifiers, event identifiers, query identifiers,
application identifiers, and sometimes facility and organization
identifiers.

Because these identifiers are not intended for human consumption, human
readability is not a concern. The complete identifier MAY be sent in the
*root* property, completely omitting the *extension*. I.e. The
identifier may consist of a bare UUID or OID.

Also, because these identifiers will **only** be used between systems
which have existing business relationships, there is no need for a
central registry. Thus, OIDs used as the root (or even as the entire)
identifier SHOULD NOT be included in the HL7 OID registry.

### Identifier use summary

  ----------------------- ----------------------- -----------------------
  **Identifier Type**     **Root**                **Extension**

  Common public           SHALL be an OID and     SHALL be populated
                          SHALL be registered     

  Local public            SHALL be an OID or UUID SHOULD be populated
                          and SHOULD NOT be       
                          registered              

  Private                 SHALL be an OID or UUID MAY be populated
                          and SHOULD NOT be       
                          registered              
  ----------------------- ----------------------- -----------------------

### What constitutes a distinct assigning authority?

As described above, most identifiers consist of both a *root*, which
represents the assigning authority for an identifier and an *extension*
which is the actual real-world identifier.

The "assigning authority" is **not** the organization, nor the facility
responsible for issuing the identifier. Rather, the assigning authority
is a unique 'namespace' or sequence of identifiers. Basically, the
assigning authority can be though of as a small database that tracks
what numbers have already been issued and which ensures that the next
identifier issued does not collide with any previous identifier. It is
possible that multiple applications (even from different facilities) may
access that same database when issuing identifiers. If that is the case
there SHALL only be a single assigning authority (and thus a single OID
or UUID).

On the other hand, it's quite possible for one application to issue
identifiers from multiple independent pools of numbers. Each independent
pool would be its own assigning authority with its own OID or UUID root.

It is common for identification systems to evolve and change as
organizations merge, split and re-purpose. To ensure unique,
non-duplicate reference, the following criteria should be followed when
deciding whether to issue a new OID.

1.  If the responsible organization for assigning authority changes, the
    OID or UUID for that assigning authority SHALL NOT change. This is
    true even if the OID may be part of a hierarchy that belonged to the
    old organization and which does not belong to the new organization.
    The pool of numbers has not changed, and thus there is no technical
    reason to change the OID. The interoperability and implementation
    effort with changing the OID far outweighs any political sensitivity
    that may exist about using an OID that is part of the hierarchy of
    another application.

2.  If the purpose of an identifier changes, a new OID SHALL NOT be
    issued. For example if a pool of identifiers originally intended to
    refer to registered nurses within a jurisdiction expands to include
    all nurses, or even all healthcare providers, while still drawing on
    the same pool of number, the OID would not change. However, the
    metadata associated with the identifier in the HL7 registry should
    be updated. Again, the intention is to eliminate any unnecessary
    migrations for implementers and to ensure that identical identifiers
    continue to match.

> Note: It is not possible for the purpose of an assigning authority to
> narrow. Once an identifier has been issued by an assigning authority,
> it remains issued forever. Thus an assigning authority for all
> provider identifiers which has issued at least one non-nursing
> identifier could never be subsequently constrained to be only a
> "nursing identifier" assigning authority.

3.  If the pool of numbers changes such that an identifier previously
    issued might be re-issued to a new item, a new root OID or UUID
    SHALL be issued. This is necessary to ensure that the principle of
    identifier uniqueness is maintained. Applications SHOULD ensure that
    all previously issued identifiers are always referenced with the
    original OID or UUID and all newly issued identifiers use the new
    OID or UUID

### Caveats around identifiers

There are several rules around the compliant use of HL7 identifiers:

1.  Compliant applications SHALL NOT, under any circumstances or over
    any period of time, issue the same identifier to a different object.
    I.e. Identifier re-use is prohibited. If it becomes necessary for a
    series of identifiers to wrap (because of screen or storage
    constraints), a new root OID or UUID must be used. This holds even
    if the original identifier has been out of use for 50 years. (You
    never know whether some historical tracking system is still making
    use of that identifier.)

2.  Once a root has been tied to an identifier assigning authority, it
    SHALL NOT be reassigned. I.e. An OID or UUID that has been tied to a
    particular pool of identifiers must always refer to that same pool
    of identifiers.

3.  Applications SHALL NOT attempt to infer the purpose of an OID by
    tracing the hierarchy of an OID. OID hierarchy does not necessarily
    reflect current responsibility for an identifier. Also, the
    'purpose' of a particular identifier namespace may evolve over time.
    Any semantics associated with an identifier which needs to be
    communicated between applications should be exchanged using separate
    attributes, such as Role.code, Act.code, etc.

4.  OIDs used for identifiers which have extensions SHOULD NOT be the
    parent for any other OID as code systems can't really be an
    assigning authority for other concepts.

5.  Where the underlying specification allows multiple identifier
    repetitions or code translations and where additional non-preferred
    OIDs exist for an identifier or code, conformant applications MAY
    send additional repetitions or translations which use the
    non-preferred OID as the root or code system provided that it also
    has a repetition or translation which uses the preferred OID. This
    approach may be used by conformant applications who wish to
    communicate with a non-conformant application which requires the use
    of non-HL7-registered OIDs for Common identifiers or code systems.

6.  The *extension* property should only be used for real-world
    identifiers intended for human display. While technically it allows
    any sort of string, an *extension* SHALL NOT contain either an OID
    or a UUID. To do so would be to defeat the purpose of having an
    extension at all.

7.  OID registrations SHALL include any special guidance on the capture
    of identifiers. In the absence of specific guidance in the
    description, the assumption shall be all upper-case with no
    intervening spaces or punctuation. (Compliant applications are free
    to introduce spaces or punctuation or spacing to aid in display, but
    must omit them when transmitting and must not rely on their presence
    in received instances.) Leading zeros (if any) should be retained.
    Consistency of formatting is essential to ensure that comparisons
    work correctly, and also to avoid the possibility of duplicate
    identifiers in a case where "1.A1" and "1A.1" are both distinct
    identifiers (and therefore punctuation is significant).

8.  In cases where matching is performed on an object which has multiple
    identifiers, a match is achieved if **any** of the identifiers has
    an exact match.

9.  Identifiers with a single root SHALL only be issued by a single
    assigning authority. In cases where identifiers are sometimes taken
    from a common source and in other circumstances issued locally, the
    identifiers shall either have distinct roots or shall all use the
    local root (provided the local issuer is certain there will never be
    a duplicate.)

10. In some cases, committees, or more commonly affiliates or
    implementers may constrain the set of identifier roots that may be
    used for an identifier, for example requiring the use of a national
    health identifier for a patient id. Such constraints may be asserted
    through the use of constraint box assertions in the RMIM design.

11. When persisting information from an HL7 v3 instance, applications
    SHOULD persist both the *root* and *extension*. If this is not done,
    the application will be unable to perform complete matching on the
    identifier and will also be unable to transmit the complete
    identifier on subsequent communications.

Even with rules 1 and 2 above, it must be acknowledged that healthcare
operates in the real world. Errors do occasionally happen. Some
identification schemes are not well designed and may accidentally issue
duplicate identifiers. Others re-use identifiers at non-predictable
intervals. Where it is not possible or practical to assign a new root
each time the identifiers are re-used, errors may occur. Applications
which transmit such faulty identifiers are still considered compliant,
**provided that** they are not responsible for the creation of the
duplicate identifier themselves. HL7 applications which themselves
produce duplicate identifiers are non-compliant.

## Guidance for code systems

With HL7 code systems, there is no choice as to the type of mechanism
used to identify the code system. All code systems SHALL be identified
using an OID.

As with identifiers, there is a need for consistent identification of
the same code system using the same OID. As a result, HL7 also maintains
a registry of 'approved' code systems, ensuring that only one OID exists
for a given code system. As with identifiers, there are different
classifications of code systems, specifically: Common code systems and
Local code systems.

### Common Code Systems

Common code systems include all code systems intended for use where the
organization responsible for the creation and maintenance of the code
system is not always either the creator/sender or consumer/receiver of
the data instance. Examples include such code systems as LOINC, SNOMED,
NDC codes, etc. It also includes code systems created by government
agencies intended for use in communications between partners other than
the government agency itself.

All common code systems SHALL be registered with HL7 to ensure that all
applications use the same OID for the same code system.

Also, if the intention is to use the code system as part of the
definition of a value set to be bound to a domain or referenced in a
template or a profile, the code system SHALL be treated as a Common code
system and registered.[^2]

### Local Code Systems

Local code systems are those which are only used in communication by or
with the organization responsible for creating that code system.
Examples include internal lab test codes, internal location codes, etc.

Local code systems SHOULD NOT be registered with HL7 because there is
minimal danger of multiple OIDs being used for the same code system and
because HL7 wants to keep it's registry as simple and easy to search as
possible. If the scope of use of a Local code system expands beyond the
organization which maintains the code system, it has become a Common
code system, and should then be registered (using the OID already in use
locally).

### What constitutes a distinct code system?

Like identifiers, code systems also evolve. New codes may be added. Old
codes may be deprecated. To a certain extent, the semantics associated
with a code shifts subtly with ever addition and deprecation because the
available choices of a user selecting from that code system have
altered.

For the purpose of HL7 communication however, a code system shall be
deemed to remain the same provided that the general semantic meaning of
all codes within that code system remain the same. Small clarifications
or shifts in definition are acceptable. Wholesale redefinition (even if
redefinition of a long-deprecated code) are not acceptable. Where the
meaning of even a single code has changed, a new code system OID SHOULD
be issued.

### Caveats around code systems

1.  The use of a code system should not indicate that the complete set
    of codes within that code system was considered by the person
    performing data-entry.

2.  OIDs used for code systems SHOULD NOT be the parent for any other
    OID as code systems can't really be an assigning authority for other
    concepts.

3.  The registration of a code system with HL7 does NOT convey any
    licensing or usage privileges for the code system. Implementers who
    choose to use a code system in v3 instances must comply with any
    usage or licensing restrictions associated with that code system.

4.  Codes for a code system SHALL only be issued by a single responsible
    organization. In cases where codes are sometimes taken from a Common
    code system and in other circumstances issued locally, the codes
    SHALL have distinct roots.

## OID registration

There are two distinct processes HL7 performs with its OID registry. The
first is the issuing of OIDs beneath its own hierarchy for members (and
occasionally for non-members) who require OIDs for HL7 v3 communication.
The second is the 'registration' of OIDs (be they issued by HL7 or by
another issuing authority) as approved for use in HL7 v3 messages.

The rules around who can request and/or register an OID as well as the
metadata captured during the registration vary depending on what type of
OID is being dealt with. The specific rules and meta-data collected are
as follows:[^3]

### All OID issuance and registration requests

The following pieces of information are captured for every registration
request:

+-----------------+----------------------------------------------------+
| Request Type    | Mandatory                                          |
|                 |                                                    |
|                 | Indicates the type of registration being requested |
+-----------------+----------------------------------------------------+
| Realm           | Mandatory                                          |
|                 |                                                    |
|                 | Indicates the realm with whom the concept being    |
|                 | registered is primarily associated. Note that this |
|                 | does not mean that the registered concept can only |
|                 | be used by that realm, merely that the realm will  |
|                 | be most qualified to check for duplicates and      |
|                 | process registration.                              |
+-----------------+----------------------------------------------------+
| Equivalent OIDs | Optional                                           |
|                 |                                                    |
|                 | Indicates additional OIDs which exist for this     |
|                 | concept and may be in use somewhere.[^4]           |
+-----------------+----------------------------------------------------+
| Requesting      | Mandatory                                          |
| person          |                                                    |
| information     | Indicates who is submitting the request. If a      |
|                 | member, this should be automatically populated     |
|                 | (though overrideable) by the OID registry from the |
|                 | membership database                                |
+-----------------+----------------------------------------------------+
| Name            | Mandatory                                          |
|                 |                                                    |
|                 | Indicates who is submitting the request            |
+-----------------+----------------------------------------------------+
| E-mail          | Mandatory                                          |
|                 |                                                    |
|                 | Means of contacting requesting person              |
+-----------------+----------------------------------------------------+
| Phone number    | Optional                                           |
|                 |                                                    |
|                 | Means of contacting requesting person              |
+-----------------+----------------------------------------------------+

The primary purpose of this information is to allow the HL7 registration
agent to contact the requester with any questions about the request, as
well as to allow HL7 to communicate the result of the request (in
circumstances where human intervention is required in processing the
request).

### Code Systems

HL7 will only issue OIDs for code systems being submitted as "Common"
code systems. Local code systems should base their OIDs on their local
organization or application OID. HL7 will however register code systems
with OIDs not derived from the HL7 hierarchy.

Code system registrations will be accepted from both members and
non-members. While it is preferred that requests for registration be
received from the organization responsible for the coding system, HL7
will also accept registrations from anyone that is expecting to use the
code system in v3 instances or who is acting on behalf of such a person
or organization. In other words, registration of code systems is not
restricted to the organization which maintains the code system. This is
done because in many cases the organization responsible for the code
system will have little interest or even awareness of their code systems
applicability for HL7 version 3.

When registering a code system, the following information will be
captured:[^5]

+-----------------+----------------------------------------------------+
| Code system     | Mandatory                                          |
| name            |                                                    |
|                 | This must be unique within the complete list of    |
|                 | HL7 code systems, and should therefore be quite    |
|                 | precise. For example, "Canadian Pharmacy Services  |
|                 | Billing Codes" is a good name. "Billing Codes" is  |
|                 | not.                                               |
|                 |                                                    |
|                 | This is also the default label that should be      |
|                 | displayed for and/or communicated in the           |
|                 | *codeSystemName* property.                         |
|                 |                                                    |
|                 | Where multiple versions of the Code System exist   |
|                 | having different definitions for the same code     |
|                 | (and thus requiring separate code system           |
|                 | registrations), the name should include the        |
|                 | version id.                                        |
+-----------------+----------------------------------------------------+
| Description     | Highly desired                                     |
|                 |                                                    |
|                 | A 1-4 line description of the purpose of and type  |
|                 | o content found within the code system. May        |
|                 | include effective date, summary of licensing       |
|                 | restrictions, etc.                                 |
+-----------------+----------------------------------------------------+
| OID             | Optional                                           |
|                 |                                                    |
|                 | This is the existing OID associated with the code  |
|                 | system which is to be registered. If not           |
|                 | specified, then HL7 will issue an OID              |
+-----------------+----------------------------------------------------+
| Maintenance     | Mandatory                                          |
| Organization    |                                                    |
| name            | This is the organization responsible for the       |
|                 | ongoing maintenance of the code system             |
+-----------------+----------------------------------------------------+
| Code System     | At least one of the following 4 items must be      |
| information     | populated (listed in order of preference). These   |
|                 | items describe how access to the code system can   |
|                 | be achieved.                                       |
+-----------------+----------------------------------------------------+
| URL             | Website or FTP from which details about the codes  |
|                 | within the code system can be retrieved. (This MAY |
|                 | require payment, registration, etc.)               |
+-----------------+----------------------------------------------------+
| E-mail          | Contact for getting access to the code system      |
+-----------------+----------------------------------------------------+
| Phone number    | Contact for getting access to the code system.     |
|                 | Phone numbers should be fully specified (e.g.      |
|                 | +1-123-456-7890) and include any necessary         |
|                 | extensions.                                        |
+-----------------+----------------------------------------------------+
| Mailing address | Contact for getting access to the code system      |
+-----------------+----------------------------------------------------+
| Registration    | Mandatory                                          |
| contact name or |                                                    |
| role            | The name or role name of the person(s) who can     |
|                 | respond to questions about the OID registration,   |
|                 | such as confirming or updating Code System         |
|                 | information, code system names, etc.               |
|                 |                                                    |
|                 | Note: This may occasionally be the same as the     |
|                 | name of the registering person                     |
+-----------------+----------------------------------------------------+
| Registration    | At least one of the following must be specified    |
| contact         | (listed in order of preference)                    |
| information     |                                                    |
+-----------------+----------------------------------------------------+
| E-mail          | Contact for confirming OID registration metadata   |
|                 | and changes                                        |
+-----------------+----------------------------------------------------+
| Phone number    | Contact for confirming OID registration metadata   |
|                 | and changes. Phone numbers should be fully         |
|                 | specified (e.g. +1-123-456-7890) and include any   |
|                 | necessary extensions.                              |
+-----------------+----------------------------------------------------+
| Mailing address | Contact for confirming OID registration metadata   |
|                 | and changes                                        |
+-----------------+----------------------------------------------------+

### Common public identifier roots

HL7 will only issue OIDs for code systems being submitted as "Common"
public identifiers. Local and private identifiers should base their
roots on their local organization or application OID or use a UUID. HL7
will however register identifier roots with OIDs not derived from the
HL7 hierarchy.

Identifier root registrations will be accepted from both members and
non-members. While it is preferred that requests for registration be
received from the organization responsible for the identification
mechanism, HL7 will also accept registrations from anyone that is
expecting to use the identification system in v3 instances or who is
acting on behalf of such a person or organization. In other words,
registration of identifier roots is not restricted to the organization
which maintains the identifiers. This is done because in many cases the
organization responsible for the identification system will have little
interest or even awareness of their identifiers applicability for HL7
version 3.

When registering a code system, the following information will be
captured:

+-----------------+----------------------------------------------------+
| Identifier      | Mandatory                                          |
| assigning       |                                                    |
| authority       | This must be unique within the complete list of    |
|                 | HL7 identifier assigning authorities, and should   |
|                 | therefore be quite precise. For example, "Alberta  |
|                 | Canada College of Physicians and Surgeons License  |
|                 | number, 1983 on" is a good name. "Physician        |
|                 | License Number" is not.                            |
|                 |                                                    |
|                 | This is also the default label that should be      |
|                 | displayed for and/or communicated in the           |
|                 | *assigningAuthorityName* property.                 |
|                 |                                                    |
|                 | Where an assigning authority has reused            |
|                 | identifiers (and thus requires separate identifier |
|                 | root registrations), the name should include the   |
|                 | date on which the current set of identifiers       |
|                 | became effective.                                  |
+-----------------+----------------------------------------------------+
| Description     | Highly desired                                     |
|                 |                                                    |
|                 | Additional descriptive information about how the   |
|                 | identifier is used, time-period validity, format   |
|                 | in which identifier should be captured (e.g. use   |
|                 | of punctuation, capitalization), etc.              |
+-----------------+----------------------------------------------------+
| OID             | Optional                                           |
|                 |                                                    |
|                 | This is the existing OID associated with the       |
|                 | identifier root which is to be registered. If not  |
|                 | specified, then HL7 will issue an OID              |
+-----------------+----------------------------------------------------+
| Maintenance     | Mandatory                                          |
| Organization    |                                                    |
| name            | This is the organization responsible for issuing   |
|                 | and resolving identifiers issued under the         |
|                 | identifier root.                                   |
+-----------------+----------------------------------------------------+
| Code System     | At least one of the following 4 items must be      |
| information     | populated (listed in order of preference). These   |
|                 | items describe how access to or lookup of the      |
|                 | identifier can be achieved.                        |
+-----------------+----------------------------------------------------+
| URL             | Website or FTP from which details about            |
|                 | identifiers within the identifier root can be      |
|                 | retrieved. (This MAY require registration, etc.)   |
+-----------------+----------------------------------------------------+
| E-mail          | Contact for getting access to identifiers          |
|                 | registered under the root                          |
+-----------------+----------------------------------------------------+
| Phone number    | Contact for getting access to identifiers          |
|                 | registered under the root. Phone numbers should be |
|                 | fully specified (e.g. +1-123-456-7890) and include |
|                 | any necessary extensions.                          |
+-----------------+----------------------------------------------------+
| Mailing address | Contact for getting access to identifiers          |
|                 | registered under the root                          |
+-----------------+----------------------------------------------------+
| Registration    | Mandatory -- same as for code system               |
| contact name or |                                                    |
| role            |                                                    |
+-----------------+----------------------------------------------------+
| Registration    | Same as for code system                            |
| contact         |                                                    |
| information     | At least one of the contact mechanisms must be     |
|                 | specified (listed in order of preference)          |
+-----------------+----------------------------------------------------+

### Organizations

HL7 will issue OIDs to any member organizations as well as to
non-members who require an identifier to implement v3 standards.
(Registration is highly encouraged for any organization using v3 ).
This services is provided as a convenience for HL7 members and
implementers. Use of an OID within the HL7 OID hierarchy is not
necessary to use HL7 v3 and organizations are welcome to use OIDs issued
by any registrar.

HL7 does not "register" OIDs in the sense that it registers identifier
roots and code systems. Implementers are free to use OIDs that have not
been submitted to HL7. Also, HL7 will not check for duplicate OIDs for
organizations. It is the responsibility of each organization to be
consistent in the OID(s) it uses in v3 instances.

+-----------------+----------------------------------------------------+
| Organization    | Mandatory                                          |
| name            |                                                    |
|                 | The name of the organization being registered.     |
|                 | This SHOULD be a descriptive name that is unique   |
|                 | within the list of organizations registered under  |
|                 | the HL7 root                                       |
+-----------------+----------------------------------------------------+
| Unique String   | Optional                                           |
| Name            |                                                    |
|                 | If present, must be unique within the list of all  |
|                 | HL7-registered organizations.                      |
|                 |                                                    |
|                 | This is the name used for uniquely identifying     |
|                 | "Local" HL7 artifacts created by the organization. |
+-----------------+----------------------------------------------------+
| Registration    | Mandatory -- same as for code system               |
| contact name or |                                                    |
| role            |                                                    |
+-----------------+----------------------------------------------------+
| Registration    | Same as for code system                            |
| contact         |                                                    |
| information     | At least one of the contact mechanisms must be     |
|                 | specified (listed in order of preference)          |
|                 |                                                    |
|                 | NOTE: The submitter MUST be associated with the    |
|                 | organization being registered.                     |
+-----------------+----------------------------------------------------+

Organizations issued an OID by HL7 take full responsibility for all
sub-arches beneath that OID. They may create child OIDs for facilities,
departments, local identifiers, local code systems and any other objects
they feel useful.

### Vocabulary Value sets, Templates & Profiles

HL7 also issues OIDs when registering vocabulary value sets, templates
and conformance profiles. These OIDs cannot be directly registered into
the registry. Instead, the desired value set, template or profile must
be submitted via the specific registration tool for that type of
artifact. OIDs will be issued, as necessary, when the registration is
processed. The data captured will be similar to that captured for
identifiers and code systems.[^6]

There should be no child OIDs created for value set, template or profile
OIDs.

### HL7 objects, v2 tables, affiliates, publications

In addition to the above types of OIDs, HL7 also issues OIDs for
internal use for HL7 objects, version 2 tables, affiliates and
publications. These OIDs cannot be directly registered by HL7 members or
non-members. Creation of the OIDs is driven by HL7 processes creates the
underlying artifacts.[^7]

## Registration process

As discussed in \<ref\>, the primary purpose of OID registration is to
ensure that there is only one OID registered for a given concept. To
avoid duplication as much as possible, human intervention is necessary
to review registration requests. As a result, OID requests submitted to
the OID registry are first reviewed by an HL7 volunteer prior to the
registration being accepted.

For the issuing of organization OIDs, no registration occurs and thus no
human review is required.

Because of the potential large volume of registrations, as well as the
difficulty of identifying duplicates in jurisdiction with which a
volunteer is not familiar, review of registrations will be delegated to
the respective realm.

The process for registration consists of several steps:

1.  A registration request is submitted to the OID registry via web or
    XML submission.

2.  As part of the web submission process, the submitter is asked to
    confirm that they have read this document and that they believe
    their submission complies with the rules defined herein.

3.  The OID registry confirms compliance of the submission with HL7
    requirements (e.g. population of required elements, field-level
    validation, etc.)

4.  An HL7 volunteer from the appropriate realm will review the existing
    set of registered concepts checking for duplicates. If possible
    duplicates are detected, the volunteer will communicate with the
    submitter to confirm that none of the existing registrations
    correspond with the desired concept. Duplicate checking will
    basically consist of searching the OID registry for key-words from
    the proposed registration as well as synonyms. The search should
    cross all realms.

5.  If the concept is not already registered, a 'provisional'
    registration will be issued. (No OID will be assigned at this time.)

6.  If the requesting person differs from the "contact" person for the
    concept being registered, a standard form-letter (see Appendix X)
    will be sent to the identified "contact" person indicating HL7's
    intention to register their concept and asking for confirmation of
    the description and meta-data information

7.  At the same time, notice of the 'provisional' registration will be
    posted to an OID registration list server for review by anyone
    interested.

8.  If corrections are received from the "contact" person or from list
    servers are received, the provisional registration will be corrected
    and re-issued.

9.  Two weeks after the most recent provisional registration has been
    posted, the registration will become final and an OID will be issued
    (if an existing OID has not already been identified).

An additional step may occur if the request for registration comes from
an affiliate with a principle language other than English. To aid in
global use of the OID registry, affiliates may choose to maintain
translations of the name and description elements associated with an OID
into their local language.

## Revision process

From time to time, it may be necessary to update the metadata associated
with an existing OID registration.

Metadata for organizations may only be changed by the identified contact
for that organization, or by another member of that same organization
(after attempting to confirm the change with the "contact" for that
organization.).

For changes to other objects, the HL7 volunteer for the associated realm
will confirm that the requested changes fit within the allowed types of
changes. I.e. The responsible person for an organization must still be a
member of that organization; the description of a code system can't
change to a completely different description; etc.

Notifications of changes to code system and identifier root OIDs will be
broadcast to the OID registration list server.

## General guidelines

In addition to the specific guidelines relating to identifiers and code
systems described above, there are additional guidelines relating to
OIDs.

### Non-traceability

Compliant applications SHALL NOT attempt to infer meaning from an OID by
parsing the OID structure and making assumptions about the OID based on
the assigning authority.

### Care with generating UUIDs

UUIDs are effectively randomly-generated identifiers. Because of the
astronomically large namespace of potential identifiers, the probability
of duplicate identifiers is exceedingly small. However, this is only
true if the random generation approach is truly random, which is
actually quite hard to do for most computer languages. As a result,
great caution must be taken in generating UUIDs to ensure they are truly
unique. Where possible, specific application or operating system
function calls should be used to generate new UUIDs rather than relying
on custom development. Otherwise the "random space" actually generated
by the id creator could be considerably smaller (by 10s of orders of
magnitude) than the theoretical namespace. This is a particularly
challenging problem because it may not manifest during the 100s or 1000s
of identifiers created during testing, but could well manifest in a
production environment faced with creating 100s of thousands or millions
of identifiers.

### OID preference

In addition to the above problem, OIDs have a slight advantage over
UUIDs in that they **are** technically traceable. A human being, given
enough time, could slowly trace up the OID hierarchy by checking
websites, making phone-calls and writing letters to find the meaning of
an OID even if it is not registered. UUIDs can never be traced. As a
result, there is a preference within HL7 for using OIDs to capture any
identifier roots that have semantic value -- basically all Local public
identifiers.

Another slight advantage for OIDs is they tend to be easier for humans
to recognize which can simplify the process of manually examining
message instances when testing and debugging.

### v2 identifiers

While the use of globally unique identifiers are not required in version
2, they are supported by the v2 identifier types: HD, EI, CX and XCN.
Essentially the *root* component corresponds to the "Universal ID"
component or sub-component, where the following "Universal ID Type" is
constrained to 'GUID' or 'ISO' (OID). The *extension* component
corresponds to the "Entity Identifier" or "ID Number" portion of the
identifier. As a result, v2 applications can carry the same identifiers
communicated in v3.

## Issue resolutions

### What happens with duplicate OIDs?

Despite best efforts, there is always the possibility that more than one
OID will be successfully registered with HL7 for the same concept. Upon
recognition of this issue, an OID maintenance volunteer will send a
notification of the issue to the MnM, Vocab and OID registration lists.
The appropriate committee within the responsible realm (or the HL7
vocabulary committee for universal realm artifacts) will hold a meeting
to determine which of the existing OIDs will be considered the preferred
OID. The results of the decision will be posted to the three lists and
will also be included with subsequent HL7 v3 ballot and release
publications.

The remaining OID will then be deprecated, with an indication in the
metadata indicating the preferred OID. The deprecation reference will
also indicate an "effective release". This release should be two
releases (at least two years) after the current HL7 release. Until the
deprecation release is reached, compliant applications can continue to
use either OID, with the recognition that many applications will not
appropriately match identifiers having different OIDs.

Once the deprecation release has occurred, compliant applications are
expected to use the preferred OID. Systems which exclusively use the
deprecated OID will be considered non-compliant.

### What happens if a complete identifier or code is not known?

In some cases, there may be a use-case to capture an identifier for
which the root is not known or a code for which the code system is not
known. In rare circumstances, it might even be possible to have a code
where the code system is known but the code is not. This does not
provide sufficient information to allow exact matching. However, it does
provide some level of information, and can at least allow 'candidate'
matching.

To support this, the *nullFlavor* property should be set to
"incomplete"[^8] which indicates that partial data is available, but not
sufficient information for the underlying purpose of the datatype.

## Appendix A -- Sample registration form letter {#appendix-a-sample-registration-form-letter .unnumbered}

*Dear* \<whoever\>*,*

*This letter is to inform you that HL7 intends to register your \<name\>
\[code system / identifier system\] as one which can be used within the
suite of HL7 version 3 healthcare information communication standards.
As part of this process, HL7 has been* \[asked to issue a new
OID\]/\[asked to register the OID xxxx as the preferred OID for this
concept\]*.*

*Your contact information has been provided as the appropriate person to
confirm the information HL7 intends to register with the* \[code system
/ identifier system\] *as well as to confirm future changes to this
information. If you are not the correct person, could you please provide
the name and contact information of a more appropriate individual within
your organization.*

*Please note that by registering your concept, HL7 is not in any way
changing any licensing or other requirements your organization may have
for using your* \[code system / identifier system\]*. Registration
merely makes your* \[code system / identifier system\] *eligible for
consideration for use in HL7 v3 instances. Implementers will still need
to follow any licensing or other requirements your organization has in
place.*

*The registration information we have is as follows:*

\<put registration stuff here\>

*If any of this information is inaccurate, or if a different OID would
be more appropriate, we would appreciate any corrections you can
provide. If we have not heard from you by* \<insert today's date plus
two weeks\> *we will proceed with the registration as it stands.*

*Thank you for your assistance,*

\<Volunteer name here\>

*Health Level Seven* \[affiliate or Inc.\]

Also attach a 1-pager explaining who HL7 is and what we do, as well as a
1-pager explaining what OIDs are and what they're for.

## Appendix B -- Issues not addressed {#appendix-b-issues-not-addressed .unnumbered}

1.  Finding an appropriate way to clearly expose OIDs in tooling. Hoping
    this will be addressed by the move to LexGrid.

2.  Under what circumstances should AssigningAuthorityName be populated?
    My argument is only when creating instances for debugging.

3.  

[^1]: Officially, HL7 allows for an HL7-defined string to be used as the
    *root* for II instances. It is not presently clear how/if/why this
    would be used. If they are supported, "Common Public Identifiers"
    are the only type of identifier where they are appropriate because
    they require the identifier root to be registered.

    If the decision is to continue to support these "HL7-defined
    Strings" for identifiers, an additional column should be present in
    the OID registry to allow for the capture of a unique string instead
    of an OID. Care must be taken to ensure that only an OID or a string
    is registered, never both. Otherwise, a direct string-compare of
    *root* and *extension* will not be sufficient to determine
    identifier equivalence.

[^2]: In theory, this could make pretty much every code system 'common'.
    The alternative is to allow value sets to be created against "Local"
    code systems, but it's not clear how we would handle the
    cross-referencing.

[^3]: This metadata excludes the "Responsible body OID" and "Responsible
    body type" which are currently captured in the OID registry. It is
    not clear what the purpose/benefit of these pieces of information
    is. They certainly have not been collected consistently. If they are
    to be collected, then we should add this information into the
    metadata tables above, including an indication of whether the data
    is required or not, as well as guidance for population.

[^4]: This may need to be a complex object which captures both an OID
    and a description. However, it should **not** require the full set
    of metadata needed for official OIDs. (We'll never have metadata or
    update metadata about non-preferred OIDs.)

[^5]: It may be that additional metadata are useful/relevant for code
    systems. The following have been proposed. We need to decide if
    they're necessary/useful.

    Is post-coordination allowed/supported?

    Are concepts permanent? (how could they not be?)

    Is the terminology available for download?

    What is the url for access?

    What is the release schedule for updates?\"?

[^6]: Processes for registering these things need to be fleshed out.
    Will we use the NIST registry or something else? How will we allow
    registration of value sets while still ensuring appropriate
    cross-referencing with code systems, etc. This needs to be fleshed
    out further

[^7]: We also need to more formally define the processes by which HL7
    ensures that these OIDs are issued.

[^8]: If agreed, this would be a proposal for a new null flavor.