Because everybody hates OIDs

Jul 16, 2011

In a recent post, John Halamka says:

For patient ID, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header.  This XML has nothing healthcare specific such as OIDsin it.

John H, like many other implementors, doesn’t like OIDs. John Moehrke took him to task:

OIDs are not healthcare specific and should not be frightening. Yes, they should never be shown to a human

John M’s response made me laugh - I regularly say that things about HL7 shouldn’t be shown to normal humans, and that’s a category I clearly don’t belong in. But shouldn’t be shown to any human? John M is right though - OIDs aren’t healthcare specific - OIDs is a standard defined jointly by ITU-T and ISO (source), and beloved of big system administrators. But HL7 is a pretty enthusiastic adopter (hence the mention on the wikipedia page here). However what John H is alluding to is that people don’t like OIDs. It’s a fact that I hear on a regular basis.

It’s not that people don’t understand what OIDs achieve (globally unique meaningless identifiers), it’s just that they don’t see that as an outcome that makes it worth putting up with OIDs for. And putting with OIDs is.. tiresome. For instance, here’s a few OIDs:

  • 2.16.840.1.113883.6.1
  • 2.16.840.1.113883.12
  • 1.2.36.9376069.11
  • 2.16.840.1.113883.6.96

One of these OIDs only means something to me, but the other three OIDs are probably the most commonly used HL7 OIDs in the world - but I reckon that very few people instinctively recognised them (the OIDs for LOINC, Snomed-CT, and HL7 v2 tables). (Obviously the DICOM OIDs for abstract and transfer syntax are the most widely used of all).

Why do we do make people use OIDs? Why, for these standard commonly used concepts? Is that we want to make it hard to do v3? Is there some value proposition for making people use OIDs for these fixed concepts. And it’s not like we need to. Where the base identifier type is defined, we define three types: UUID (like so: 8E485717-26F0-4F15-A1A8-DA163032EB7E), OID, and RUID, about which the standard says:

HL7 also reserves the right to assignRUIDs, such as mnemonic identifiers for code systems

An RUID is defined as:

A globally unique string defined exclusively by HL7. Identifiers in this scheme are only defined by balloted HL7 specifications. Local communities or systems must never use such reserved identifiers based on bilateral negotiations.

And HL7 has never actually gone and defined one of these. Why not? Thinking back on the few times we have talked about it, there’s two reasons:

  • We want people to get used to OIDs
  • We’re concerned about spending committee time on defining RUIDs.

Well, I think it’s high time we defined some, and let people use easy to use strings like “snomed-ct”, “loinc”, “v3-model”, “us.ssn” etc. It would make instances so much easier to work with. Anything we can do to make the instances easier to work with is not only a good thing, it’s a necessary thing (starting to become urgently necessary).

One of the intriguing aspects of defining RUIDs is that they are retrospectively active. In other words, if HL7 defines an RUID today, it can be used in any existing v3 instance, in particular, any CDA documents.That’s kind of cool - and also a bit dangerous for all the existing implementations out there that have almost certainly not added RUID support even though it’s part of the specification. So I think that if we went ahead and defined a set of RUIDs, we’d have to say that they can only be adopted by trading partner agreement.

Of course, defining RUIDs for the commonly used OIDs isn’t going to get rid of them completely. Nor is it going to make people completely happy. But we have to do something.

The other thing  that a set of carefully chosen RUIDs would do is re-introduce meaning to the identifiers. I’ve recently been spending a lot of time looking at converting v2 messages to CDA documents, and CDA badly needs meaningful identifiers. Defining RUIDs and letting the affiliates ballot their own RUIDs would go along to solving this problem. (of course, letting affiliates ballot and use their own RUIDs would make it impossible to share documents across different affiliates - but why worry about the closing the door after the horse has long bolted?)