For system analysts and interface developers, testing and managing HL7 interface connections is a large part of day-to-day responsibilities. Therefore, knowing and understanding the nature of HL7 messages and its structure is helpful in optimizing the time and money invested in the interfacing process. Senior implementations consultant at Corepoint Health, Alex Lin, identifies his top three suggestions that everyone should know about working with HL7 standards:
A standard is not a rule, only a suggestion.
HL7 is a standard. By definition, a “standard” is, “a basis for comparison; a reference point against which other things can be evaluated.” A standard in computer software is often referenced when discussing software interoperability.
Because HL7 messages are a standard, there are no defined repercussions for any healthcare organization who decides to not abide by that standard. Instead, that healthcare organization, and those who interface to it, is inconvenienced by the time and money it costs to customize an interface to accommodate the non-standard messaging type.
With the help of an interface engine, communicating with vendors using different versions of HL7 or other messaging standards and formats (XML, CSV, X12, etc.) will be much easier than trying to build an interface manually.
The HL7 version you use is flexible.
When deciding which version of HL7 to use for your messaging needs, there are a few things to keep in mind. First of all, two-thirds of the industry currently uses HL7 v2.3 and v2.3.1. It’s not surprising, then, that HL7 v2.3.1 is the HL7 standards version most cited within the Final Rules issued for Meaningful Use and Standards.
Secondly, HL7 v2.x versions are backwards compatible. This means that if you have v2.3 and you need to interface with a v2.1, your version will be able to accommodate the differences. However, if you have v2.3 and you need to interface with someone using v2.5, they will have to accommodate your version.
Again, with the help of an interface engine, translating between different versions is simpler and time and money will ultimately be saved in the long run.
Each 2.x version is more customized and backwards compatible.
Each new version of HL7 adds more specific and customized messaging standards for communication with specialty organizations, such as a blood bank. In each new version, some message and data types are deprecated, elaborated and replaced with new ones. Additionally, some of the newer 2.x versions simply offer new message and data types.
The XML-based HL7 v3 is not backwards compatible with the 2.x versions of the standard, so existing v2 interfaces would not be able to communicate with interfaces using v3 without considerable modification.
Knowing and understanding the nature of HL7, its history, structure and relationship to the industry is helpful for any analyst or developer working with HL7 interfaces.
What other characteristics of HL7 do you find to be helpful to understand when working with HL7?
