P548 OIDs in Coded Data Types

This is a page of type Category:InM Closed Action Items.

P548 OIDs in Coded Data Types

Sponsoring Person

Joann Larson, Kaiser Permanente

Disposition

Accepted by INm __/mmm/0000 on motion by __/__ (00-00-00)

Justification

The US Healthcare Information Technology Standards Panel (HITSP) is encouraging the use of Object Identifiers (OIDs) to precisely identify the context of an identifier or coded value. Currently, the CWE and CNE data types allow for the transmission of the coding system but not for the OID. This proposal, based on discussion at the Vocab TC telcon on December 12, 2007, seeks to expand the definition of the Coding System components to allow the transmission of either the coding system code or an OID.

The HL7 OID registry has assigned an OID to be used for HL7 and user-defined v2 code tables. That OID is 2.16.840.1.113883.12.#### where "####" is to be replaced by the table number.

This is a revision of the original joint proposal 529 from Quest Diagnostics and Kaiser Permanente per findings of the Vocab committee on December 12, 2007.

Vocab Minutes: 529: OID component to Coded Data Types. Add a field to the CWE and CNE datatypes to carry the OID of the coding system and the alternate coding system; the third component should not be used (this is reserved for table 0396 entries). Ted asked about how the different fields can be kept in synch. Stan asked why add a new field instead of using the coding system field to hold an OID. We then had a discussion around multiple candidate key identifiers to the same concept, with examples from ISO3166, UCUM, and SNOMED, and why there is one OID for SNOMED-CT, but two table 396 entries. There was not agreed resolution to this, and it should probably be examined more closely by vocab in the future. Stan moves that vocab recommends that we reuse ‘name of coding system’ and ‘name of alternate coding system’ for both OIDs for coding systems and table 396 entries instead of adding two new fields to the datatyps. Joann seconds. Vote: 12/0/1, motion carries. Action – Joann will update the proposal to reflect this and bring it back next call.

Note that Quest firmly supports OIDs as separate components of the C*E data types. Quest will be prepared to counter the revised proposal with a return to the original proposal when this is discussed at the HL7 meeting in San Antonio.

A separate proposal (#520) has been submitted by Regenstrief regarding the extension of the C*E data types to include a third triplet. If that proposal is accepted, our proposal would apply to that third triplet (quintuplet) as well. Yet another proposal (#523) calls for making the Coding System components conditional and would be relevant to this proposal as well.

Background and Discussion

Email from Frank O to Vocab listservice July 30, 2007: I was told that all v2.x tables will use the following OID:

2.16.840.1.113883.12.####

where "####" is to be replaced by the table number.

Now I am in doubt, that this is sufficient. It requires, that all tables are backward compatible concerning their contents.

Let’s take table 0004 "administrative gender" as an example. From 2.3.1 to 2.4 to values have been added: A = ambiguous N = not applicable

According to my understanding this may result in changing the semantics for "U=unknown"! As a consequence, we have new contents for an old table. Therefore, this table must get a new OID.

Am I right?

What about adding an OID subtype for the HL7 version numbers within the OID tree?

'Response from Cecil Lynch July 30, 2007 Hi Frank,

The OID does not need to change because of a change to the table contents. It would be the same OID, just as SNOMED or LOINC do not get a new OID with a new version.

Cecil

Response from Ted Klein, July 30, 2007 Frank, Versions of objects, and contents of namespaces, identified by OIDs are not in general differentiated by the OID itself. In fact, a Code System is not the same code system (not merely a version change, but a different code system) if the meaning of a concept identifier changes; concepts may be added, retired, or superceded but not redefined, otherwise you have a different code system. Which would be identified by a different OID. Now unfortunately, there are some code systems in the world that 'behave badly' and redefine concepts between versions. These are dealt with in HL7 by having the version ID of the namespace along with its identifier. In the case of 2.x, there should be no changes to table contents (for HL7 tables) between version of the standard. In the CE datatypes, the version of the code system (for user tables) is explicit.

In the case you cite below, the 'version' of Administrative Gender' is either 2.3.1 or 2.4. And is it completely legal to add new concepts. Again, nothing must be carried in the OID identifier format; the version information deals with the content of the namespace, not the namespace itself. The OID identifies the namespace itself. The version is required to resolve the content of a namespace at a point in time.

Note that the v2.x tables are not in the same OID branch as Code Systems, since in many ways, these do not really behave exactly as code systems, so they are in an area that may be managed differently.

-Ted

Response from Frank Oemig, July 31, 2007 mmh, well, this sounds like we are assigning an OID to the table, but not to the contents. So we are not treating v2.x tables as code systems, right?

Snomed and LOINC are "versioned" tables. They are just adding contents. Therefore, their OID does not change. ICD-10, esp. in Germany, changes every year. Concepts (ICD codes) are added, deleted and/or redefined, so that it gets a new OID every time.

The cited table (0004) is one example of v2.x. There may be others as well.Ted, according to your explanation table 0004 changes the semantics of "U" from 2.3.1 to 2.4, because in 2.3.1 it also covers the meaning of "ambiguous" and "not applicable". Therefore, treating table 0004 as a code system would guide me to assign a new OID!

In 2.x we do not have a means to express the version beside MSH. CE does not have a component for the code system version. CWE and CNE does, but they are used rarely up to v2.5.

It would be good if we can introduce and use individual OIDs for tables with user-defined values. So if one creates site-specific tables, these should get local (?) OIDs allowing differentiation.

Do we have an example on how to use the OID referencing mechanism with v2.x using CE and CWE/CNE?

I am sorry, but I would like to treat tables the same way as code systems.

thanks

Frank

Response from Ted Klein, July 31, 2007 Frank, I would also like to treat the tables like code systems, but we cannot, because they sometimes behave like code systems, sometimes like value sets, and sometimes just like a spreadsheet of user-defined values. So - we cannot.

The OID indeed identifies the table itself, just like the identifier HL70263. The contents of the table depends upon what type of table it is (HL7, User, or HL7 and User) and some tables (such as table 0396) can change between versions of the HL7 standard. More importantly, some tables, such as table 0088 Procedure Code, behave exactly as a value set, meaning that it contains (code, codeSystem) entries. So again, we CANNOT treat the HL7 2.x tables as code systems because they are NOT. This is one of the things that was fixed (attempted to fix it) in version 3.

So - just like in version 3, if you want to know the version of a table, you need to look somewhere else besides the OID.

-Ted

Response from Lloyd McKenzie, August 1, 2007 Hi Ted, Frank,

I'm assuming that we don't redefine v2 table concepts in a way that's incompatible with existing concepts? (And I'm pretty sure that's true of ICD-10 as well, at least how we use it in Canada). Distinct code systems mean that codes may have radically distinct meanings. Versions of code systems mean that meaning may evolve somewhat, either through the addition or deprecation of codes or the refinement of definitions. In most cases, knowing the code system alone is sufficient. When necessary, you can send the version as well, specifically the date on which that particular version of the code system was published.

Lloyd

Response from Frank Oemig August 1, 2007 Lloyd,

this is out of question and we are in sync here. The question is whether we can use OIDs to identify table values. Right now, we are using "HL70004" to identify table 0004. Can we achieve the same by using an OID? Does the OID "2.16.840.1.113883.12.4" do the same job?

I know that for some tables we are referring to other codes systems already. E.g. for ICD or OPS. But does it work for HL7 defined tables?

Frank

Response from Ted Klein, August 1, 2007 Frank, There are three issues for doing this that I know of: 1. Many implementations do not allow sufficient length for the subcomponents of CE (and CWE and CNE) to hold the OID in the Code System component; 2. The OIDs are not in Table 0396 and some systems will flag an error if a Code System name is not in Table 0396 3. For IS and ID datatypes, the standard specifies the table number, and the change to make it alternatively use the OID needs to go through the ballot process (I would guess 2.7)

I don't know of any other reasons not to do this.

-Ted

Response from Frank Oemig August 1, 2007 Ted,

1. and 2. are good arguments. With 2.7 we will not have a maximum length any more - at least not in the way we have had it before. Therefore, introducing it in 2.7 seems reasonable.

Again, the idea is to guide the development process to the use of OIDs in preparation of V3. I guess, this helps.

Frank