HL7 OID Registry Frequently Asked Questions

Does HL7 register or assign OIDs for free?

HL7 charges a fee of $500 for each OID registration (this fee is non-refundable).

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.

Can you update the information in the registry for me if it changes later?

No. HL7 does not update information in the registry for registered entries. The confirmation email when you register an OID has an OID Key value; DO NOT LOSE THIS KEY. It is used to edit the OID information if it changes in the future (such as if a contact person leaves the company and someone else is assigned that role). The button/link to edit the OID data is on the lower left of the OID main page screen.

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.

Somebody told me I need an OID for my Organization. What do I do?

Some of the HL7 published standards, and some implementation guides that are being published by HL7 and by others, recommend using an OID to identify an Organization. Most Organizations in Healthcare IT already have common public identifiers (Provider IDs, CLIA numbers, TINs, etc.) and there are already OIDs that indicate these namespaces for use in the v3 datatype 'II' (Instance Identifier) to identify organizations; this is done by using the OID for the namespace in the II.root and the identification number in the II.extension. If you desire an OID to separately identify the Organization, one may be obtained using the HL7 OID Registry. If the Organization plans to assign OIDs under its new OID for various namespaces, code systems, sub-organizations, or for other related purposes, then a Type 3 OID should be requested. If there are no plans to assign OIDs of your own under the new OID, then request an OID type 17 (which can also be used for any random purpose). For further discussion on OID types, see below.

I'm working with eMeasures and the MAT and it says I need an OID, can you help?

OIDs, used as organizational and/or object identifiers, are required for an organization or user to create measures in the Measure Authoring Tool (MAT). Users of measures who are not developing their own measures do not need to use the MAT and they do not need to obtain OIDs. Registering for an OID or a MAT account are not requirements for CMS’ EHR Incentive Programs. If you need an OID for the MAT, you should select a Type 3 from the dropdown on the registry; this assigns the OID to your organization to create sub-OIDs, which the MAT uses for the objects it creates for eMeasures.

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 ITU-T 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.

ISO rules require that the Symbolic Name (secondary identifier) be unique only immediately under a particular node, but HL7 requires that the Symbolic Name also be unique among OIDs of the same OID Type. Note that when an OID is rejected for registration, or retired from use, its symbolic name may be reused for a different OID of the same type, or under the same parent node.

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.

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.

Under the HL7 root OID 2.16.840.1.113883, the following Types have been defined for use in the HL7 OID Registry:

• Type 1

HL7 registered internal objects (other than organizational bodies)

Type 1 OIDs are used for certain internal administrative functions, and to identify released and published Standards. This includes Version 3 International Releases, Normative Editions, V2.x Standards releases, CDA releases, etc. This is almost never used at this time.

• Type 2

HL7 organizational bodies and groups

Type 2 OIDs (eg 2.16.840.1.113883.2.xx) are only used to identify an HL7 Group, such as a Working Group, or an International Affiliate of HL7, such as HL7 Australia. These are created only when a new organizational body is recognized by HL7 International Headquarters.

For example, the OID allocated to HL7 Australia is 2.16.840.1.113883.2.3. Based on this root, HL7 Australia allocates and maintains OIDs for organizations in its jurisdiction in the HL7 Australia OID Registry.

• Type 3

External (not HL7) 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, and may be requested or registered by anyone. 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, and you agree to follow the rules on OID creation and maintenance specified in the ISO 9834 series of standards on OID governance for those you will create. No one else anywhere will create OIDs under your new root, all OIDs under it are your responsibility solely. 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, and if you wish to register any that you create under your new root, you will have to register them as 'external' in this registry.

Note that a Type 3 OID identifies an organizational entity, not a particular piece of hardware machinery. It does not have to be a corporation, it could be as small as a single development group building interface software for an NHIN Connect project, for instance. This entity is the one functioning as the Registration Authority, not necessarily the business organization, or a sender/receiver of messages or documents. Type 3 OIDs should not be used to identify objects in addition to the organizational entity responsible for creating new OIDs under it.

• 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 Version 3 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 codeSystem 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 document artifacts

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

• Type 8

Deprecated

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. Note that these are NOT identifiers of code systems, they identify publishing artifacts. Note also that many HL7 Version 2.x tables have no codes at all, and resemble Concept Domains (but are not the same), others resemble Value Sets. Note that these are NOT code system OIDs.

• 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 or owner-specified type

Type 17 OIDs are for any other type of object that does not fall into one of the other Type categories, and may be used whenever something specific to a particular user or registration authority is needed.

• Type 18

HL7 Version 2.x Coding Systems

Type 18 OIDs are specifically for those coding systems that are defined as such in the family of HL7 Version 2.x standards. These may only be created by HL7 cochairs.

• 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.

• Type 21

V2.x Table-based HL7 Value Sets

Type 21 OIDs are assigned to Value Sets created specifically for published bindings in the HL7 Version 2.x standards. These are value sets that include all codes of the code systems that contain the defined codes in the published standard (type 18 code systems). They may only created by v2.x Standards editors.

How do I assign my own OIDs?

If you are already an ISO OID Registration Authority, you can assign any OIDs you wish, and register them (as 'external') in the HL7 OID Registry. If you are not, you may become one by requesting a Type 3 OID from HL7 (see above), which delegates Registration Authority for all OIDs under that new one to you.

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.

HL7 has a number of resources that may be helpful in determining how to structure your own assignments for OIDs under the root that you have been given. For more information, see http://www.hl7.org/implement/standards/product_brief.cfm?product_id=210

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 any nodes that are ‘above’ the leaf either correspond to a Registration Authority, or are administrative organizational branches – they should not identify objects. HL7 recommends against using the same OID for both a branch in the tree and to identify a specific coding system (or other type of object).

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.

What are the standards that define OIDs?

ISO and ITU have published standards that define OIDs, the OID tree, and the policies and procedures for Registration Authorities. These are primarily contained in the ISO 9834 series of standards, parts 1-8, and the ISO 8824 series of standards. Most of the same content is covered in the ITU standards series X.660, X.680, and X.690. Several of these standards are under active revision at this time. HL7 Structured Documents is also working on a balloted informative document to help understand how to use OIDs in CDA.

The Contact Person has left the company. How do I update the information in the OID Registry entry for my OID?

On the main OID Registry screen on the lower left you will see an area to 'Edit' your OID. You must enter the OID and the OID Key that was emailed when you registered the OID. Then you can update most of the fields of information on the OID entry, such as Contact Person, Responsible Body, Description, etc.

I cannot find the OID Key - it seems to have been lost. How can I edit my OID entry?

Contact hq@hl7.org and someone will work with you to locate your OID key.

Why is the status of my OID still 'Pending'?

HL7 manually reviews every OID registry entry before approving them. This review attempts to ensure that the registration is not a duplicate, i.e. no OID is currently registered for the same object, and that the information in the entry is complete and comprehensible. As this is a volunteer activity, it may be quite some time before a particular entry is reviewed and set to 'Complete'. OID registration requests are almost never rejected - when it is still 'Pending' you can almost always feel free to use the OID. Rejections occur if the entry duplicates a pre-existing registration. Rejections may occur if the entry is spam, or some kind of test or garbage entry. Occasionally, someone will register an OID for an object that is maintained and published by a third party; this may result in an inquiry during the review process, since this might cause a future duplication or problem if the object publisher wishes to register an OID for their own object which they may have received from some other Registration Authority. Preference is given to those registering OIDs for objects they are responsible for.

What type should I select for the Responsible Body?

Due to the large number of OID registered, HL7 has implemented some filtering for the types of organizations responsible for the OID entries and the objects that the OID identifies. This will be used for more advanced searching functions as they are developed. The types that HL7 has defined for now are:

• Academic

Academic or educational institution

• Govt Body

Government office, ministry, department, or other organization

• HL7 Body

Health Level Seven International committee, group, affiliate or other organization in HL7

• Payor

Insurance company, fiscal institution, or other payor for healthcare

• Prof Soc

Professional Society in any area of Healthcare

• Provider

Hospital, Care Network, Clinic, Physician Group, or any other type of Provider organization

• SDO

Standards Development Organization

• Vendor

Developer/Seller of HIT systems

• Exchange

Information Network for archival and dissemination of health information

What are these OID things used for in HL7?

OID are used for a number of purposes in HL7:

• Identifier Namespaces

In HL7 Version 3 and CDA, the datatype II (Instance Identifier) is used to identify specific individual objects referred to in models. This datatype has a property, II.root, which defines a unique namespace for the identification. OIDs are often used in this root property to indicate a collection of identifiers each of which uniquely identifies a specific object; the identifier itself is contained in the II.extension property of the datatype. Some HL7 users have defined an OID to be a globally unique identifier of a specific individual object; in this case, the II.root is the entire identifier and there is no II.extension value. More commonly, the II.extension identifies the object. For instance, there may be an OID in II.root that indicates a certain type of Health Card that carries a number, and the number itself is in II.extension.

In HL7 version 2 standards, the HD (hierarchical descriptor) contains two components 'Universal ID' and 'Universal ID Type'. When the 'Universal ID Type' is set to "ISO", then the 'Universal ID' contains an OID, which is used to identify the object that the HD is associated with (HD is used in many fields as well as other datatypes in HL7 Version 2 standards).

• Terminology Identification

In HL7 Version 3 and CDA, the datatype CD (and most of the coded specializations of CD) carry a property of CD.codeSystem to identify the terminology that a particular code is drawn from. The HL7 Version 3 datatype CD.codeSystem property must be an OID. Each code system that is identified in HL7 model instances of this type is identified with an OID, which must be registered in the HL7 OID Registry in order for vocabulary Conformance Claims to be published specifying the use of this terminology.

In the most recent HL7 Version 2.7 standard, OIDs are included in the CWE and CNE datatypes as components also identifying a terminology or coding system. This greatly facilitates translation between interoperating v2 and v3 systems.

• Value Sets

When Value Sets are bound to coded attributes or datatype properties in HL7 V3 type models (including CDA), they are identified by an OID and optionally a name. These bindings, which make use of Value Set Assertions, are part of vocabulary Conformance Claims.

In the most recent HL7 Version 2.7 standard, OIDs are included in the CWE and CNE datatypes as components also identifying value sets used in the field. This greatly facilitates translation between interoperating v2 and v3 systems.

• Conformance Profiles

Version 2.x Registered Conformance Profiles are assigned an OID when they are registered. This OID is used in the MSH-21 field in later versions of the HL7 v2 standards.

• Templates

Version 3 Templates are identified with an OID.

Are the email addresses distributed?

The HL7 OID Registry serves as a publication mechanism for OID-identified objects where the OID is carried in HL7 models. The email address of the submitter is not output when the content of the registry is downloaded, but the email addresses of the contact person and responsible body are. This is intentional, as part of the reason for publicizing this information is so that the responsible body and/or the contact person can be contacted. The email address of the submitter will only be shown when the OID entry is individually accessed or edited.

Links to HL7 Affiliate OID Registries

HL7 International creates OIDs for organizations in its role as a Registration Authority. Each of these organizations may, in turn, delegate assignment of new OIDs under it to other registration authorities that work under its auspices and so on down the line. Eventually, one of these authorities assigns a unique (to it) number that corresponds to a leaf node on the tree. The leaf may represent a registration authority (in which case the OID identifies the authority), or an instance of an object. A registration authority owns the namespace consisting of its sub-tree. (Refer www.hl7.org/oid Introduction to the HL7 Object Identifier (OID) Registry)

One type of organizations that HL7 International creates OIDs for are the HL7 International Affiliates, who in turn allocate and manage OIDs for their Territory:

• HL7 Australia OID Registry