As an integration engine support engineer, I frequently provide consulting services to interface analysts, programmers, and developers that are responsible for the planning, implementation, care and feeding of new HL7 interfaces. The range of technical prowess among the clients I assist is fairly broad. For example, on any moment of a typical day you may find me fielding questions on segment cardinality from a self-professed “HL7 neophyte”, while minutes later I may be on a call to review customized TCP/MLP message framing test results with a beleaguered multi-tasker. Thus, while some are very conversant with HL7 standards, and more importantly, the actual “as-built” specifications of their trading partner’s production environment—many are not.
One of the questions that almost always needs to be addressed during new interface planning, regardless of the experience level of the client, is which version of HL7 to use when we construct messages. A recent user-community poll indicated that a large majority of HL7 messages in production are a v2.3 or v2.3.1 variant. However, when a new interface is being built (to send order results to a client system, for example) should a sending reference lab, imaging center, or hospital use the most common, or the latest v2.x?
While it is true that the newer versions of the v2.x HL7 standard are backward-compatible, the process of identifying gaps in the specifications becomes simplified when both trading partners are operating off of the same blueprint. Similarly, one shouldn’t arbitrarily choose the most common v2.x of the standard to use as a base-line for their messages either—unless their interface engine is flexible enough to easily make and test changes to the message structure, they could end up with some extended development and potential headaches long after they thought their specifications were “complete”. So which course of action is the most prudent?
My recommendation, whether solicited or offered as free advice on best practices, is always the same— talk to your trading partners. They know best which version their application is ready to accept. If they have no preference, then your discussion should lead to an agreement on the version to be used, and will naturally lead to other discussions that will help smooth the way for a more swift and efficient implementation.
Related posts:
- HL7 Sample Messages – Always the Best Way to Go
- Poll Results: Which HL7 Version Do You Encounter the Most in Your Interfacing Projects?
- Getting Started with Your HL7 Interface
- What Is HL7 Version 3 or V3?
- HL7 Specifications Defined
