How Widely Adopted Is HL7?
August 30th, 2007 by Dave Shaver
(1 votes, average: 5 out of 5)
Loading ...Posted in HL7 Standards
HL7 is extensively adopted within the healthcare community. The HL7 standards has been under development since the late 1980s and represents the de facto method of moving clinical healthcare data. To clarify, the term “HL7″ can mean many different things based on who asks the question. However, when most people say “HL7″ they mean the “HL7 2.X messaging standard.” A much smaller number of people mean HL7 3.X, CCOW, EHR, CCD, CCR, CDA, etc.
If we use the common definition of HL7 (HL7 2.X), it is fair to say that most hospital-based clinical software applications support HL7. “Support” in this context means that they can send or receive a subset of the HL7 2.X messages. Specifically, a typical software application will use between five and twenty HL7 triggers (messages) out of a total set of 300 or so provided in the full standard. So, take “applications support HL7″ with a grain of salt in all cases.
If we expand the scope to “all healthcare software,” the adoption of HL7 drops off and becomes spotty based on the needs of the facility. For example, an EMR application running in a five physician office might use HL7 for lab results (ORU) but not for demographics (ADT), orders (ORM), or scheduling (SIU) messages at all.
HL7 2.X is an implementation-driven “standard.” This means it has been pieced together over the last 20 years and works “most of the time” for “most of the people.” It is fair to call it a “standard” in quotes because the implicit goal of HL7 is to reflect the specialization of clinical settings. As I teach in HL7 training class, clinical settings demand specialization of applications, data models, and work flows. The HL7 standards cannot fix this need for specialization and, therefore, HL7 is purposefully-flexible in many areas.
On the other hand, HL7 3.X is model-driven. From a practical standpoint, it means that some of the brightest minds in healthcare informatics have spent ten years developing a rather clever model for the representation of clinical data. Some argue the model is either too clever or not clever enough. Regardless, so far, the depth of adoption for HL7 3.X has not come close to HL7 2.X.
Specifically, within the United States, the use of HL7 3.X is painfully small if we measure use of 3.X by real production interfaces moving real “average” healthcare data in real “average” facilities.
In short, the industry is caught with a huge adoption problem on five fronts with respect to HL7 2.X / 3.X in general and “standard interfacing” in particular:
- There is no such thing as a “standard healthcare workflow” or “standard healthcare data model used to store real data in a real database.” If you spread the issue across different healthcare settings, the specialization so broad it is virtually impossible to standardize anything. If you take political or geographic settings into consideration, it is impossible to build one useful standard — even a very broad standard — that works just one way.
- In HL7 training class, I twist the meaning of Metcalfe’s law and apply it to standards. Specifically, the value of a standard like HL7 is proportional to the square of the number of users of the standard (n^2). This means that the value of an installed based (HL7 2.X) is much higher as more users adopt the installed standard. Regardless of clever factor, competing standards (in or out of the same family) have far less value.
- HL7 2.X is the workhorse that gets the job done while HL7 3.X is new, better, and — when compared with 2.X — very hard for the average user to understand. An unimplemented or under-implemented standard has little value — recall the(n^2) problem.
- Both HL7 2.X and 3.X were developed with a depth of complexity that meets acute care (hospital) requirements. This means that smaller, simpler environments have a complex “non-standard standard” to use even if they just want “a little interfacing.” Standards profiling helps resolve this issue.
- Often clinical software vendors consider integration functionality late in the product lifecycle and often do not consider it strategic to sales or deployments. This means that the depth of support for HL7 is sometimes shallow and the interfaces are fragile.
In summary, HL7 is very widely used within healthcare. Each interface is slightly-to-very different based on the trading partners and healthcare setting. HL7 can not totally standardize clinical data models or workflow because every facility is special or different in some boring or very critical way.
HL7 is the best standard we have in healthcare — best in the sense that many users move real messages between real applications every day. Ultimately, HL7 makes building interfaces vastly easier than using custom formats like a custom CSV, XML, or flat files.
Some of these topics are covered in more depth in a 14 page whitepaper entitled, The HL7 Evolution (PDF).
Last 5 posts by Dave Shaver
- Massachusetts Hospitals Must Have CPOE by 2012 and CCHIT-Certified EHRs by 2015 - August 13th, 2008
- HL7 Dates and Times - July 25th, 2008
- HL7 Time Zone Qualification - July 25th, 2008
- RHIOs vs. Peer-to-Peer Communications - July 11th, 2008
- Hospitals Allowed to Pay for EMR Interfaces and Not Violate Stark - June 3rd, 2008
I agree with the overall sentiment expressed by this post - as one who has been involved in HL7 v2.x/v3 implementations in various European countries things like “There is no such thing as a standard healthcare workflow” especially rings true, as does the need for standards profiling.
3.x was developed with a scope that’s even wider than just the acute hospital setting: it’s the provision of healthcare in general .. regardless of setting or geopolitical area.
Lots of profiling will be necessary. And in the US most of the v3 profiling seems to be done in the area of CDA (HL7 v3 documents): the CCD, X.12 claim attachments, VA/DoD discharge letter and SOAP note and the IHE CDA based documents. All of those have been implemented and are used in production today. IMHO the use of CDA will steadily increase in the US, next to a whole bunch of v2.x messages for the routine data exchanges in hospital settings.
-René
As is often the case, I agree with René. One addition: It should be easy for us HL7 geeks to understand that CDA is “just part of V3.X.” However, for most users of 2.X, CDA is something “new” and, to a large extent, solves a “different problem” than 2.X.
When typical US-based users ask about the status of 3.X, they are often talking about the areas where 2.X is widely used: Messsaging of ADT, ORM, ORU, SIU, etc. They want to know how an ADT^A01 is going to work in V3. Or how the trigger model from V2 maps into V3.
Some more technical types understand that the two standards are solving problems that are similar-yet-different. e.g., an HL7 2.X ORU can have a HL7 3.X CDA payload and this is “normal and typical”.
Ultimately I hope that the focus of the HL7 community will continue to be meeting the needs of real users with real problems. In general, as one of the HL7 geeks, I’d say we’re doing a pretty good job most weeks.
[…] HL7 V3 is still in the “early adopter” phase, there are now over 100 registered projects in progress […]
We still use HL7 2.3. Isn’t HL7 version 3 XML based? If so how much larger is it than a typical HL7 2.3 message? We used a mapping tool that is based on XML and it blew the size of the message up 10 times larger than regular HL7 2.3. This was a major problem and it maxed out CPU usage so we quit using it.
[…] These applications typically have “more-or-less 2.3″ interfaces and, broadly, those interfaces are “good enough” for most users. There is a comparatively small group that helps create new releases of HL7 or that […]
Hard to understand is not the same as hard to use. While building HL7 version 3 messages is mind-twistingly hard at times, implementing them isn’t.
Part of HL7’s problem is that V3 has not been marketed properly. Too much emphasis is put on the intangibles (i.e. RIM based, HMD) that you are lucky if your CIO understands, let alone values.
Why is there not a HL7 version 3 “for dummies”? HL7 sells a very nice v3 guide, but it doesn’t do much for the crowd that is much less interested on how the messages get built, rather than on “how do I stick XXX value into this message for YYY patient”.