Considerations About HL7 Integration
On the provider side of healthcare integration, HL7 (particularly v2) is a critical message type to understand. While it is standardized and heavily used by various EHRs/EMRs, it’s used in slightly different ways. There are efforts to further standardize and normalize its use across the board (such as with v3/FHIR), many EHRs and EMRs continue to use 2.x messages. Common HL7 messages include admissions/transfer/discharge (ADT), scheduling (SIU), lab orders and results (ORU, ORM), and medical reports (MDM). Choosing the right HL7 or EDI Software platform can be challenging.
Some of the challenges of HL7 2.x messages include:
- The ability to add non-standard custom segments or additional data anywhere in the message (whether they are completely custom “Z Segments” or other segments that aren’t typically part of the message, such as IN1 segments in an ADT message to include additional insurance information).
- A myriad of parsing and manipulation libraries available
- Questions about whether to go with a specialized HL7 platform or a full-fledged integration platform
- The wide diversity of applications/systems/endpoints to integrate with
- The need to correlate and understand other healthcare data, such as CCD and X12 EDI
These points can be captured in two key issues: The HL7 standard and parsing, and Specialized solutions vs Integration platforms.
HL7 2.x and parsing
HL7 v2 messages look a little bit like EDI files: flat text files with delimited fields and segments. Unlike EDI, the delimiters are all contained within the first few characters of the message, and the segment terminator is specified by the standard as a carraige return (‘\r’). Typically, a ‘|’ is used as a field delimiter, a ‘^’ is used as a component (field part) separator, an ‘&’ is used as a sub-component separator, and a ‘\’ is used as an escape character.
HL7 messages can have repeating groups of segments, and it’s possible to have those groups nested within each other (i.e. a grouped section of segments that can repeat that itself contains a grouped section of segments that can’t repeat). In addition to that, the specification itself declares that parsers must be prepared to ignore unexpected segments that applications may insert, whether they be custom Z Segments or HL7 segments that are typically found in a different transaction. Some applications will put these segments at the end of the message to make the parser’s job a bit easier, but some will put them interspersed throughout the message.
Integration platforms, such as Microsoft BizTalk, MuleSoft AnyPoint, and Dell Boomi, offer support for HL7 parsing. There are also stand-alone HL7 parsing libraries available, such as the HAPI project for Java, a .NET port of that project called NHAPI, and HL7apy for Python. Some of these integrate with the HL7 XSD schemas developed by Sun and distributed by HL7.org, others use their own schemas. There are several potential pitfalls to be aware of with these options:
- The Sun schemas are very useful for doing things like XSD validation or XSLT based mapping (such as with the BizTalk mapper), but make heavy use of <xsd:any> tags. This means that validation may be more permissive than expected or than a destination system expects.
- Parsers offer varying levels of support for the Sun XSDs – HAPI supports encoding them, HL7apy doesn’t appear to. BizTalk supports them, but doesn’t support encoding or decoding from HL7 to XML in that format out of the box (it uses a different proprietary XML format to support those operations), however, Tallan offers a solution accelerator to implement this (more on that later).
- Most libraries can support MLLP in some way, shape or form. Integration platforms will offer full-fledged support for multiple protocols and advanced options regarding transport types and transformation support.
- Enterprise grade support – open source projects and communities will lend themselves more to developers and consultants doing your support work, whereas commercial solutions will lend themselves more to assurances from the vendor.
Specialized solutions vs. Integration Platforms
As with other healthcare data, there are specialized vendors who offer HL7 message translation solutions (sometimes built off of the open source libraries mentioned above). These solutions can be tempting – they tend to offer well-thought-out translators for HL7 application needs and may have some pre-built packages for various EHRs. At the same time, they can be a trap. Any specialized integration tool will end up falling short at some point (such as when you need to start integration EDI claims or payment advice messages, or when you have one vendor or system giving you a non-HL7 XML, JSON, or flat file message that need to be parsed and translated to HL7 or vice versa). They may or may not offer support outside of the MLLP and/or SFTP protocols, limiting options for delivery and retrieval as new systems come on board such as Web Services or delivery over HTTP/HTTPS.
Most crucially, it is essential to make use of canonical messaging patterns when dealing with HL7 integrations. New lab partners will expect your organization to be able to on-board within a couple weeks. A point to point integration for each new partner can easily lead to a mess of spaghetti code – while it may be easier up front, it will eventually become unmanageable and exponentially increase in risk as time goes on. Simple code changes become very challenging to deploy and track, and each new integration point requires starting from scratch. Integration platforms lend themselves well to these patterns, and leave control in the consumer’s hands. Use of canonical messaging patterns makes on-boarding new trading partners or applications faster, as you can know what to expect from your organization’s canonical format and implement the feed-specific translation in a way that doesn’t disrupt other feeds.
Finally, integration platforms free you from the whims of the specialized vendor. Large, well-established platform solutions like BizTalk, Mule, and Boomi aren’t going anywhere, and offer loads of opportunity for any integration or reporting need your organization will have – most critically, unlocking your valuable data for use in BI reports and custom correlations with other integration data.
One challenge that can come up with the platforms is that they may lack some of the niceties of an HL7-specific platform – for example, BizTalk has some gaps between its built-in support for HL7 and the Sun XML schemas that are more widely understood (but offers excellent support for EDI), whereas Mule (which uses HAPI internally) offers pretty good parsing capabilities and XML support, but the translation options are not quite as solidified as BizTalk at this point.
The Tallan Solution
Tallan addresses these shortcomings with the T-Connect EDI Software and HL7 Accelerator. Developed from similar principals to our EDI Accelerator products, the HL7 accelerator adds several important capabilities to integration platforms:
- Fast, powerful message parsing that is compliant with standards and situations seen “in the wild”
- Out of the box patterns and practices such as canonical messaging and dynamic routing capabilities
- Message persistence in relational tables for data mining and correlation
- Full capabilities and support of the backing integration platform, and full compatibility with the T-Connect EDI Software product for EDI processing
These capabilities help ensure you can unlock the full capabilities of your EMR/EHR systems in a maintainable, flexible environment that keeps the care providers in control of care.