How do you make health databases talk? Use the ‘Health Level Seven’ (HL7) protocol.
How do you make them say something other than four letter words? A lot of study, smarts, and intuitive understanding, and nifty tools I outline here will be your best allies in that sense.
HL7 essentially describes a transfer protocol that is used between health care databases. Why would you care if you were implementing an EHR? Simple. I assure you your EHR does not run the radiology equipment, or the radiation oncology equipment, or the lab system, or the drug dispensing system, or the supplies system . . . In other words, I know that a majority of places have multiple systems in play out of operational necessity. HL7 attempts to give us a way to get around that, by creating a data standard that describes messaging ‘events,” and the body of that message. An HL7 (2.x) Message looks something like this
PID|||010-11-1111||Marion^Maid^E^^^^L|Wench|19720520|F|||256 Sherwood Forest Dr.^^Baton
Hood^Robin^^^^MD^^Sherwood Health Associates|||||||||F|||||||030-33-3333&
OBX|1|SN|1554-5^GLUCOSE^^^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^175|mg/dl|70_105|H|||F CR
I know. That looks like a bunch of gibberish, doesn’t it? But really, it’s not. I want to try and demistify a little about this message over the next few posts, and hopefully help you to understand what HL7 does, how it transmits data, and how you can make it work for you.
Often, people ask me the differences about HL7 standards. The standards have undergone enormous changes over the years, and you can always keep up with them at www.hl7.org. There are so many resources over at that site, and my main purpose is to give you an overview of what I find to be the most useful, and a general guide on how to use it.
First I want to explain a few things about HL7. Think of it like DICOM, only not really . . . you know, standard. Because, like almost everything in healthcare, a standard is just what you make of it. Think of HL7 more of being guidelines for where to put data in a message. While it seems rigid at first, the more you are exposed to the different vendors and their different capabilities as it relates to HL7, the more you will understand what I mean (instead of thinking I’m launching into an explanation of what the word ‘is’ is). HL7 itself has undergone several different versions, but most vendors I have seen are using version 2.x (that’s 2.anything), but version 3 has some pretty slick features, and utilizes XML to make it much more accessible. The first thing you want to do is make sure that the two systems you want to have a conversation will be using the same language.
If they can’t, don’t despair, because often people use an engine to sit between the source and the destination, and you can do all sorts of nifty transformations in those things. There are variety of platforms for this intermediary server, and an incomplete list can be found here on HL7’s site. The type of environment, be it eBiz, Ensemble, Interfaceware, Corepoint — that selection is going to be made based on how you are going to use your engine. Do you plan to use it for multiple interfaces? How many, really? What kind of functionality do you want it to have? Generally, I stay tool agnostic, because these choice are best left to organizations.
Just know that the engine will do one vital thing — it will change your interface process from one step to two. You will have one interface from source to engine (and thus one specification and one set of code) and another interface from engine to destination (thus a second specification for a second set of code). Often times, HL7 will also involve configuration of the source and destination systems on HL7 message handling.
The next part of this series will discuss HL7 event types in overview.