EMR/EHR’s and HL7: Part One – General Overview

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

MSH|^~\&|LABSYSTEM|HAPPILANDLAB|OUREHR|HAPPILANDHEALTH|200905210930||ORU^R01^ORU_R01|CTRL-9876|P|2.4 CR
PID|||010-11-1111||Marion^Maid^E^^^^L|Wench|19720520|F|||256 Sherwood Forest Dr.^^Baton
Rouge^LA^70809||(555)555-1212|(555)555-1234||||AC010111111||76-B4335^LA^20070520 CR
OBR|1|948642^LABSYSTEM|917363^HAPPILANDLAB|1554-5^GLUCOSE|||200502150730|||||||||020-22-2222^
Hood^Robin^^^^MD^^Sherwood Health Associates|||||||||F|||||||030-33-3333&
Hood&Friar&&&&MD CR
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.

About the author

John Lynn

John Lynn is the Founder of HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

6 Comments

  • Standards like HL7 and DICOM essentially offer a framework for the exchange of data. What subset of the standard one uses, or: what dialect one speaks, depends on local variations in workflow.

    If all health care providers exchanged the exact same information at the exact same point in time, one would be able to define a very precise and rigorous standard. If healthcare providers (and physicians) don’t agree when and how things should be exchanged, by necessity, one will have a flexible standard with dialects. This is not just true for HL7, but for most standards in this area, including DICOM. Image workflows are pretty standardized, but yet again one sometimes needs a communication engine to translate between one variation and another one.

    The main point of the post is that one should use standards like HL7 to exchange data in a ‘standaridzed’ fashion between applications, and that realistically one should use a communication engine to deal with the ‘dialects’ issue.

    Or one could standardize all the organizanal workflows and force the physicians to always capture and exchange the exact same set of data, but that is unlikely to go donw well with the organization. It’s much easier to deal with the dialects and do a bit of translation in the middle.

  • Rene — Whenever I can, I absolutely encourage the middle data broker, or HL7 engine. You are absolutely right — if a requirement is based on a workflow, it has a high chance of failure. HL7 can be a serious boost, but it can be a detriment if not fully thought out. I’m simply trying to make the process easier to understand. Thanks so much for the comment.

    Dave — I might have met you. I took Neotool’s HL7 training in Dallas one year a few years back. Great material — and thanks for the great information! In my last post in the series I plan to list some of the resources, and these are great!!!

  • Great overview…one warning though from personal experience…there can still be proprietary data even within HL7 compliant systems. The data is not proprietary but the map that defines what the data fields are can be proprietary and therefor make two systems completely unable to talk to each other. I had that in converting from one HL7 compliant EMR to another so that one vendor had to create a custom export of the data so as not to divulge the secrets of their data table to the other vendor. It was a painful and drawn out process.

Click here to post a comment
   

Categories