Datatypes R2 Issue 66

Introduction

The current data types specification mandates that the "HL7 Preferred OID" be used for Identification Schemes if multiple alternative OIDs exist for an Identification Scheme. (see bolded text below).

This proposal seeks to remove the requirement (the bolded text below) and to work with the Conformance SIG to add conformance requirements related to the use of sepcific OIDs to a (balloted) conformance specification.

Motivation: during v3 implementation in NL and DE it was noted that the use of certain OID roots is sometimes mandated by a healthcare ministry, or a national healthcare initiative. This effectively means that any OIDs that HL7 may already have in its registry for this same identification scheme won't be used, and that all current/future interactions (in NL and DE) don't conform to the requirement as shown below.

Backwards compatibility: the proposed change would relax an existing constraint.

Current Specification (Abstract Data Types R1)

2.14.1:

"HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources.

Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used."

2.17.2:

"In the case where identifier schemes provide for multiple representations, HL7 shall make a ruling about which is the preferred form. HL7 shall document that ruling where that respective external identifier scheme is recognized. HL7 shall decide upon the preferred form based on criteria of practicality and common use. In absence of clear criteria of practicality and common use, the safest, most extensible, and least stylized (the least decorated) form shall be given preference."

Discussion

• IMO conformance related to the use of certain OID roots should be specified at the Realm level. Rene spronk 01:45, 31 August 2006 (CDT)

• All OIDs are equal, and although one can express a preference within HL7.org, an OIDs registry showing both the preferred and non-preferred equivalents seems to be more realistic than just mandating one OID. Rene spronk 01:49, 31 August 2006 (CDT)

• I am not sure that the current standard mandates ONLY one OID. It appears to me to simply mandate that at least HL7 OIDs be used. Nothing prevents a Jurisdiction from using both HL7 and the jurisdicitional OID (IMO). Leon Salvail 12:33, 31 August 2006 (PDT)
  • Leon, I don't know how you can use more than one. other than smacking the governments over the hand for having the temerity to define their own oid's, we don't really have much choice but to do as Rene suggests. Grahame Grieve 15:35, 04 Sept 2006 (AEST)

• Lloyd: I strongly oppose this change. If governments mandate the use of a non-conformant OID, then they end up with non-conformant implementation. The fundamental principle of one approved OID for interoperability purposes is a good one. If implementations must break this interoperability to satisfy government mandates, so be it. That doesn't mean we have to label them as compliant.
  • So noted. Given that all OIDs that identify an object are "equally valid" according to the ISO definition and should probably register all those OIDs, and designate one as being preferential, without disallowing the others. If a non-preferred one is used, then there is a mapping to the preferred one in the OIDs registry. Labeling all HL7 artefacts as used in a particular Realm as non-HL7-conformant just because they use a non-preferntial OID is not an option IMO. Rene spronk 22:40, 28 April 2007 (CDT)
    • Rene, please can you quote and cite chapter and verse where the ISO definition says that all OIDs that identify an object are "equally valid"? What does that even mean? I think it's unrealistic to require an OID registry. Not that it wouldn't be nice, but the OID system has no official registry mechanism and in the absence of such it cannot be part of the rules of dealing with OIDs. So, I am with Lloyd against that change. (G Schadow)
    • Well, could you quote chapter and verse where it states that this is NOT the case? The OID mechanism is there to help identify things. I don't expect the ISO standard to say anything about preferential OIDs, because all OIDs do what they are supposed to do: uniquely identify an object. Rene spronk 06:43, 4 June 2007 (CDT)

Status

Really, this issue is about how HL7 maintains the registry, and how OID clashes are resolved. The datatypes aspect of this is clear: HL7 policy with regard to OIDs must be followed, and any ois used that is not local to the implementation must be in the registry. So the content has been split into two parts, what is relevent to the datatypes, and the policy. For the first ballot cycle of R2, the policy is still found in document, but INM will be asking Vocab to find another home for the policy, perhaps in the HDF. Ballot comments are welcome.

Links

Back to Data Types R2 issues