Posted by: Jenny Laurello
Data standards, HL7
Q&A on HL7 with Eliot Muir, president, iNTERFACEWARE
1. What do you see as the biggest challenges associated with HL7 integration?
HL7 standards are a set of loosely defined standards. Unlike some standards that enforce strict guidelines, HL7 standards were designed to find a quick solution to healthcare integration woes. As a result, there are many different versions and aspects of HL7 floating around and interfacing between disparate systems can be extremely difficult.
Additionally, various parts of the standard are ambiguous at best and include a significant amount of optionality. This leads to different vendors making their own interpretations. As a result, one of the main challenges of integration is simply being nimble enough to adapt to these various interpretations.
2. What are the key drivers for the adoption of and consistent use of HL7 standards?
HL7 standards are the most widely deployed standards across the healthcare industry. They have successfully eliminated the headache of custom interface programming on the part of both the sending and receiving application vendors. HL7 standards have been around long enough to be tried and tested for creating interfaces. They have helped the healthcare industry reduce costs by outlining best practices for processes such as collection of patient attributes or a standard set of interesting events.
3. What best practices should hospitals and healthcare providers adopt to ensure they meet healthcare standards such as HL7?
1) Do the simplest translation possible.
The shortest distance between any two points is a straight line. The same principle is true for integration. When integrating two systems, there’s much less risk of lost or mis-translated information if you keep the translation in the same language.
For instance, if you’re tasked with translating some text from Quebecois French to Parisian French, it doesn’t make any sense to translate it into English first. The same rule applies for HL7
Approximately, more than 90 percent of interfaces require transforming or translating one version of HL7 v2.x into a different version of HL7 v2.x. HL7 v3 is XML based and a complete rewrite of the standard. As a result, it is time-consuming and cumbersome to integrate systems by translating from HL7 v2.x into XML based systems and then back into a different dialect of HL7 v2.x. This should be avoided if the goal is for a cost-effective timely integration.
2) Use tools with good visibility into the transactions
Integration is always a moving target. Vendors make minor alterations to their products regularly. These changes often alter their interfaces in terms of what data they send/receive or how it’s formatted. When looking for an integration solution, it’s important to make sure there is clear visibility around the transactions. As you go live with your interface, it will save time and money if your support team can quickly look up all the transactions into and out of your system
3) Work from real data, not the standard.
Integration is a real-world problem, not a theoretical one. Many of the core systems at hospitals were built more than a decade ago. These systems are in place because they work and meet the operational needs of healthcare providers not because they strictly adhere to the standards. As discussed earlier, the shortest and the most accurate path to interoperability provides the most flexibility for optimal real world interfacing.
Some of the common descriptions for HL7 include: “HL7 is a non-standard, standard” or “HL7 is a great standard, everyone has one.” This has led to lenient adoption of the standard. Therefore, it is important to be flexible and be able to work with existing data and interfaces, rather than build specific interfaces that can only work with the standard.
4. What’s different about HL7 version 3? How can healthcare providers prepare for the updated standards?
HL7 Version 2 was developed with the goal of standardizing and reducing the costs of building interfaces in healthcare. To expedite the adoption of these standards and to increase the number of users, clinical interface specialists and vendors tried to incorporate data fields and interface frameworks already in use. As a result, Version 2 was a set of loosely defined standards built in an ad hoc fashion but easy to conform to. Version 3 (V3) on the other hand was developed with a more ambitious goal of attempting to make a complete data model framework to try and achieve consistency across the whole message set. Additionally, V3 is XML based and therefore each message is significantly larger by one or two orders of magnitude compared with V2.
We’re still very much at the early adopter phase for V3 standards. Other than at the government level there really has not been much penetration of V3 standards into clinical environments.
iNTERFACEWARE is a software provider committed to simplifying HL7 integration. More information about iNTERFACEWARE, can be found at: http://www.interfaceware.com/.