Draft HL7 OID Policy

1. HL7 OID Policy and Guidelines 1.1. 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.

1.2. Background

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

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.

1.2.2. 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}}”. With a total of 340 trillion trillion trillion possible values, the probability of issuing a duplicate UUID is infinitesimally small.

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

1.4. Principles for identification in HL7

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

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

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

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

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

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

1.5.4. Identifier use summary Identifier Type Root Extension Common public SHALL be an OID and SHALL be registered SHALL be populated Local public SHALL be an OID or UUID and SHOULD NOT be registered SHOULD be populated Private SHALL be an OID or UUID and SHOULD NOT be registered MAY be populated

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

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

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

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

1.6.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).

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

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

1.7. 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:

1.7.1. 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. Requesting person information Mandatory 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).

1.7.2. 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: Code system name Mandatory 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 Organization name Mandatory This is the organization responsible for the ongoing maintenance of the code system Code System information At least one of the following 4 items must be 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 contact name or role Mandatory 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 contact information At least one of the following must be specified (listed in order of preference) 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

1.7.3. 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 assigning authority Mandatory 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 Organization name Mandatory This is the organization responsible for issuing and resolving identifiers issued under the identifier root. Code System information At least one of the following 4 items must be 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 contact name or role Mandatory – same as for code system Registration contact information Same as for code system At least one of the contact mechanisms must be specified (listed in order of preference)

1.7.4. 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 name Mandatory 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 Name Optional 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 contact name or role Mandatory – same as for code system Registration contact information Same as for code system 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.

1.7.5. 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. There should be no child OIDs created for value set, template or profile OIDs.

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

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

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

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

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

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

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

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

1.11. Issue resolutions

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

1.11.2. 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” which indicates that partial data is available, but not sufficient information for the underlying purpose of the datatype.

Appendix A – Sample registration form letter

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