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.

Links

Back to Data Types R2 issues