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