What is HL7 programming? (Part 1 of 3)

What is HL7 programming? (Part 1 of 3)

Hi,

I know what the HIT gurus are thinking about this topic's title. But really, I do have to listen to this question quite frequently.

Not only do I receive this inquiry from the folks that are trying to get involved in healthcare IT for the first time, but for many years I have also heard of it from recruiters and head hunters, "Are you an HL7 programmer too?", is typical in their screenings. Of course, hesitantly I answer "yes!", or risk losing the opportunity to further discuss what might end up being a lucrative contract or a nice career job.

"HL7 programming" is a misnomer. HL7 is not a programming languange, like C# or Java are. HL7 in itself is not a standard either. HL7 is a standard developing organization (SDO).

HL7, the organization, has published several standards, among them:

• HL7 Version 2.x series (currently they list only versions 2.3 through 2.6),
• HL7 Version 3.0,
• Clinical Context Management (CCOW),
• Arden Syntax,
• Clinical Document Architecture (CDA),

HL7 Version 2.x series are the most popular of their standards. They have been adopted by an overwhelming number of healthcare delivery organizations in such a way that some reputable studies estimate the adoption rate in the US is over 90%. HL7 Version 2.x series are often referred to collectively as an interface messaging standard since they do consist of a specification formed by a myriad of well-structured and well-organized field delimited messages. The messages are defined by abstract templates which aid in their implementation. This messaging standard which was first released in 1987 under version 1.0 has evolved significantly but it initiated much before other popular industry formats such as, XML, ever existed, or were widely known as they are today. The latest release from the version 2.x series was HL7 Version 2.6 which was approved as an ANSI standard October, 2007.

HL7 Version 3.0 is based on the HL7 Reference Information Model (HL7 RIM) which is much more complex and it is also based on XML. It uses the RIM and an object-oriented methodology to create messages.

This version has had a difficult time being adopted in the United States. Europe, having a smaller Healthcare IT infrastructure than the US, has been able to adapt to it with much more ease. In my opinion it was a smart decision not to move forward with Version 3.0 since it was defined much before the XML standard evolved and there are many "lessons learned". We also have mature "use cases" and "best practices" acquired from other industries and that we weren't quite aware of years before. Version 3.0 should undergoe scrutiny and reinvented, maybe by creating Version 4.0, which should be simpler so that it can be easily adopted and implemented. Until this happens I doubt that it will gain significant momentum.

I have architected, developed, and encountered many implementations of HL7 Version 3.0. Somehow they remind me of the early days of DICOM implementations in which each vendor had a very different interpretation of the DICOM standard. Some of these DICOM implementations continue to be a cause of difficulties when integrating equipment from different vendors. Many healthcare delivery organizations decided to go in the direction of "Single Vendor" solutions due to the complexity involved in integrating heterogeneous environments.

To be continued (Part 1 of 3) ...

The EHR Guy