On HL7 V2, from Ira Kalet

(posted with permission)

You probably will recall my reluctance to say much about HL7 at the very interesting panel discussion at the AMIA meeting last Fall. It was largely because of my lack of familiarity with it. Recently, in an effort to write a section on HL7 and laboratory data for my book, I have delved a lot further into it. I now take issue with only one statement you made. You said you have no complaint about HL7 version 2.x; your objections were directed to HL7 V3 and the RIM. Now that I understand version 2.3.1 and have had some in depth discussion with Dave Chou, my local source of HL7 expertise, I must note that version 2 is a disaster as well.

Version 2 has the virtue that it does not have ontological pretensions, and only claims to be a message transmission protocol. It appears at first sight to have been well thought out, even having an appendix with BNF definitions for messages and segments. On closer inspection, these definitions are wimpy. The text says that they are not to be relied on, that variants not precisely described are allowed. Further, while the overall structure of a message is somewhat specified, the actual content uses a very incompletely specified vocabulary. This is rather like saying we agree to more or less use English grammar but we don't have a common dictionary. It is really true. Some HL7 implementations generate messages using a vocabulary that is unknown to the receiving systems. Sometimes there are synonyms, sometimes not. It is a lot like the differences between different dialects of English (British, Scottish, Bostonian, East Coast American, Southern, Texan, Australian, etc.). Humans handle this reasonably well, but it is a lot of work for a computer program to deal with it. The so-called HL7 interface engines apparently do a lot more than just relay messages, they actually (according to Dave) do translations of messages on the fly. Much work is expended to create these custom translations, so that implementing HL7 is much costlier than implementing DICOM. There are many more dialects of the data vocabulary than there are of English.

DICOM is truly plug and play - if a DICOM data source claims to be able to send certain classes of data and another claims to be able to receive it, all you do is put in the sending system the destination address of the receiving system, turn them on and you are done. If they don't work together one or both of them has violated the specification and should be fixed. Not so with HL7. The HL7 documentation admits as much.

It is interesting that this service of getting data from place to place is so important that people are willing to pay the price of implementing an undisciplined, unruly communication scheme, but they are unwilling to agree on a precise common language.

I needed to vent to someone, and I expect that you would be sympathetic.

Thanks,
Ira Kalet

PS: The success of DICOM is that while it has an "object model", the model is about the image data and not about the things radiologists see in the images (i.e disease processes, etc.). An image is an array of numbers, along with some other data that are also describable without resort to inconsistent meanings. Things like the settings on the Xray tube (voltage, current, energy) when the image was produced, the size in patient space of the pixels, whether contrast was used, the name of the patient being "imaged". I see no fundamental obstacles to taking the same concrete approach to laboratory data and all the other things that HL7 talks about. In all my conversations, it seems to come down to a resignation to live with and evolve what was done already. It reminds me of the joke: "Why did it take God only 6 days to create the entire universe?" Answer: "He didn't have to make it backward compatible with an installed base."

PPS: See now Ira Kalet, Order and Chaos in Medical Data Communication: DICOM and HL7

Interesting Post from HL7 Connection re HL7 V3

From the HL7 Connection blog:

"Has anyone successfully implemented version 3? In my spare time I have been reading everything I can find on best practices and potential pitfalls."
Posted 3 days ago #
leaf999Member

"Why? There is no viable business model. The vendors with current market share have been quite sucessful with v2 interfaces. There are no clear advantages. The v3 data model is not a model of the interface record but rather of an application database. Why would vendors abandon their proprietary advantages developed at significant expense in order to re-develop their product as a comomdity offering, particularly when there is limited, if any, consumer demand (at least in the US).

The only US vendor (if you can call them that since they have no application product that has been implemented in a sucessful domestic healthcare setting) is Oracle. Last time I looked their only sign-up was Quadramed - which has since abondoned the effort (or so I was told by one of their application develoment managers.

Right now, if I were starting fresh, I'd implement v2 using XML.

While I'm at it, where is the formal transition strategy for mixed v2 & v3 interface settings. In my thirty some years in the field I've learned that the transitions are a very big deal.
This issue has popped up at the technical steering committee meetings for well over half a decade with no progress seen, or am I wrong?

What made HL7 such a success was its proclivity for the practicle real world needs of healthcare organizations and vendors. Now we have the Europeans mucking up HL7 the way they did CEN TC251.

The English NHS project is several years behind schedule, over budget, and gaining a reputation for 'shooting the sled dog vendors in the head' (thats a direct quote from a the senior english Government offical) - and they have taken v3 and bastardized it to the point that it could not be considered a standard approach to application interfaces outside the NHS.

The proof comes when one learns that the HL7 Board tried several years ago to discontinue further iterative enhancements to v2 telling committee chairs (I was one)that they should abandon additional v2 development. This edict was later recinded. I would see this as a clear indication that it was the result of the healthcare community having their say.

In my humble opinion, after more than a decade of development, HL7v3 is stillborn. I'm very unhappy about the situation and I very much hope I'm wrong. Please show me the error of my thinking - believe me when I say I'd be delighted. Until then I'll continue to recommend the use of v2 interfaces using XML."