HL7 OID Registry Frequently Asked Questions

I already have an OID, does HL7 have to assign a new one?

No. There are two separate operations, the creation of an OID under the HL7 root, and the registration of an OID. When you select “Internal” on the form data entry page, HL7 will create an OID under the HL7 root and register it. If you select “External” on that page, you must enter the literal numeric form (dots and numbers) of the OID you already have, which will then be registered.

I have no idea what Type I should select for my OID

HL7 has created a Type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for; this type has nothing to do with ISO standards, or any intrinsic meaning or form of the OID itself. It is only a convenience for the users of this Registry.

The following Types have been defined for use in the HL7 OID Registry:

• Type 1

HL7 registered internal objects (other than published documents and organizational bodies)

Type 1 OIDs are only used for certain internal administrative functions at this time.

• Type 2

HL7 organizational bodies and groups

Type 2 OIDs are only used to identify an HL7 Group, such as a Working Group, or an International Council Member of HL7, such as HL7 Australia.

• Type 3

External group functioning as a Registration Authority

Type 3 OIDs are used for organizations that wish to create their own trees of OIDs for their use. If you will be assigning OIDs yourself under the OID that you are applying for, then you should select Type 3. This effectively delegates Registration Authority to your organization for all OIDs under this new Type 3 OID. No one else anywhere will create OIDs under your new root. Every OID created ‘under’ this new root will be considered by HL7 to be an ‘external’ OID, since you will have created it external to the HL7 OID Registry OID assignment software. These may be requested or registered by anyone.

• Type 4

Registered externally maintained identifier systems and namespaces

Type 4 OIDs are used for namespaces for identifiers that are public, and used widely, such as health card numbers, ID numbers assigned by jurisdictional authorities, etc. This is also used for any namespaces you may manage with your own defined OIDs under your own root, such as Medical Record Numbers or Accession Numbers, for example. This type of OID is typically used in the root of the version 3 datatype Instance Identifier.

• Type 5

HL7 Internal Code Systems

Type 5 OIDs are used only for HL7 created and maintained Coding Systems, that have been approved through the HL7 V3 Harmonization process. This type is assigned only by the group that applies decisions from the harmonization processes to the HL7 databases. These OIDs are typically used in the codSystem property of an HL7 Version 3 coded datatype.

• Type 6

Registered external coding systems

Type 6 is assigned to those OIDs that identify a Coding System or terminology that is created, published, and maintained by any organization outside of HL7. At this time, only an HL7 cochair or OID administrator can assign Type 6 to any OID. This type of OID is typically used in the codeSystem property of an HL7 Version 3 coded datatype.

• Type 7

HL7 published documents

Type 7 OIDs are used solely for HL7 published artifacts, and are assigned only by members of the HL7 publishing group. This includes standards, tutorial slides, implementation guides, databases, published RIM graphic billboards, etc.

• Type 8

HL7 OID registered documentation products and artifacts

Type 8 is currently not used.

• Type 9

HL7 Registered conformance profiles

Type 9 is used to indicate HL7 Conformance Profiles, published in the HL7 Profile Registry.

• Type 10

HL7 Registered Templates

Type 10 OIDs identify published Templates. These are created and registered by the Templates Workgroup, or by HL7 Workgroups that define and publish templates as part of their balloted standards.

• Type 11

HL7 defined and registered Value Sets

Type 11 OIDs identify Value Sets that have been created and published by HL7, and have been approved through the HL7 Harmonization processes only. These are used in HL7 Version 3 Model Binding and Context Binding mechanisms, and can only be assigned by members of the group that applies the HL7 Harmonization process approvals to the HL7 databases.

• Type 12

HL7 Version 2.x tables

Type 12 indicates that an OID identifies explicitly an HL7 Version 2.x Table, as published in the HL7 Version 2 series of standards. These exist to help facilitate development of translation capabilities between Version 2.x and Version 3/CDA interfaces.

• Type 13

Externally authored and curated Value Sets

Type 13 OIDs identify Value Sets that have been created, published, and are maintained by organizations outside of HL7. They may be registered by anyone, and are generally used in Hl7 Version 3 Model Binding and Context Binding mechanisms.

• Type 14

Assignment Ontology node

Type 14 OIDs may be used by any Registration Authority to indicate a structural ‘branch’ in the tree that they create under their own root, where the node is not any particular type of OID, the types will be below this node. Normally any node that is not a leaf is a registration authority, but some find that adding levels in the structure of the OIDs they create as Registration Authorities make the administration of the tree a bit easier. Each of the nodes in the HL7 tree that is the root of each of the Types is actually a Type 14 OID.

• Type 15

Small code sets externally defined

Type 15 OIDs are used to identify small code lists or sets that are defined and maintained by organizations outside of HL7. Where Value Sets are built upon underlying coding systems, short code lists are often ad-hoc values that are used in various applications, that are not components of a particular terminology or coding system. This type of OID may be used in the codeSystem property of a version 3 coded datatype.

• Type 17

Non-specified type

Type 17 OIDs are for any other type of object that does not fall into one of the other Type categories.

• Type 19

HL7 Examples

Type 19 OIDs are used for published examples; it is a truly meaningless identifier, as it is not to be used for any actual entities. This is the only kind of OID that may not be a unique identifier, i.e. it may refer to more than one object if it appears in different publications or slides. Type 19 OIDs are used ONLY in published examples in documents and slide presentations, and should NEVER appear in any implementation or any HL7 model instance.

What does the radio button selection ‘Internal’ vs. ‘External’ mean?

When you choose ‘Internal’, an OID will be assigned under the HL7 branches, with the numeric value of the OID generated by the website software automatically. When you choose ‘External’, you must enter the numeric format of an OID you already have (assigned by a Registration Authority other than HL7) into the form field just below.

What is the limit on length of an OID?

There is no limit to the length of an ISO OID. Some standards, such as DICOM, have declared an arbitrary length limit of 64 characters, so if you wish to use the OID you are registering in such a standard, you should try to conform to those other restrictions. HL7 does not put any restriction on the length of an OID, but the website software cannot accept an ‘External’ OID longer than 128 characters at this time.

Is there a limit to the size of the integers in each clause of the OID?

No. ISO has no limit to the size of the number. Practical considerations for software implementations have generally led some to recommend that the numbers not exceed (2**32)-1, which is the largest 32 bit unsigned integer in most computer languages. HL7 does not enforce any such limitation, but if you create an OID with very large integers in it, be aware that some system may not be able to process it properly.

What is the Symbolic Name?

The Symbolic Name in the HL7 OID registry is intended to be a relatively short human-readable name for the OID, since the integer values are not as human readable. It is used as the ISO Secondary Identifier Value for the OID, and should be unique among the direct descendants of its parent OID (non-uniqueness is strongly discouraged in the ISO X.660 standard clause 6.2.6). In addition, the name must conform to the ISO Secondary Identifier naming rules for arcs on the OID tree, as defined in the ISO OID standards X.660:

"An arc may (but need not) also have associated with it one or more secondary values that are identifiers that are human-readable values. The identifiers of an arc are required to commence with a lowercase letter, and to contain only letters, digits, and hyphens. The last character shall not be a hyphen, nor shall there be two consecutive hyphens in the name (see ITU-T Rec. X.680 | ISO/IEC 8824-1, 11.3)."

The symbolic name may be used in the “NameAndNumberForm” representation of an OID as per ITU-T Rec X.680, as the RH name, with the integer in parentheses following. Note that this syntax is not supported in the HL7 OID registry, nor in the HL7 datatypes that have components that carry OIDs.

Why can’t I use one of the other legal ISO representations for an OID?

HL7 has limited resources for tool development and maintenance, and so supports only the numeric form of an OID node entry in the Registry.

How should I structure the OIDs that I assign underneath my root?

You may structure the tree any way that you wish. Most people select an ontology that is convenient for them to maintain and publish in their organizations. As long as the OID identifiers are unique, and uniquely identify the object they are associated with, any structure is legal. HL7 has an informative document in ballot that includes some example structures in its appendices. This OID document may be found on the WorkGroup webpage for Structured Documents.

I have an OID for a coding system. Can I assign OIDs under that node for other objects related to my coding system?

It is not illegal to do so, but we strongly discourage doing this. ISO recommends that the OID for an object always be a leaf, and an nodes that are ‘above’ the leaf either correspond to a Registration Authority, or are administrative organizational branches – they do not identify objects. HL7 recommends against doing this.

Can I use my root OID to identify my organization?

If your organization will be the Registration Authority for OIDs under that node, then you may do so. But if a different organization takes over that role at some time in the future, then the identification may be ambiguous. By ISO standards, an OID that is not a leaf or intermediary branch identifies a Registration Authority. The full definition of this is defined in ISO standard 9834-1 clause 3.6.8:

registration authority: An entity such as an organization, a standard or an automated facility that performs registration of one or more types of objects (see also International Registration Authority). NOTE – For this Recommendation | International Standard, the above definition of registration authority extends the term to cover registration by organizations acting at international, regional and national levels and by other means. For clarity, the term International Registration Authority is used in this Recommendation | International Standard to refer to an organization performing registration at the international level.

For instance, if your organization subcontracts its OID administration function to another organization, then your Type 3 OID will actually identify the contracted organization, rather than the original organization. If it is performed by some automated software package, then the root will identify the software system, not your organization. For this reason, we recommend that your create an OID for specifically your organization under the ‘root’ OID that you get from HL7.