HL7® interfacing – you can’t live without it but that doesn’t mean you have to suffer as you work to connect the systems that make your environment hum along. This guide will help you get a firm grasp on all the challenges, standards, and choices you need to make along the way, whether you’re developing interfaces on your own or working with a third party.
Why You Need the HL7® Survival Guide
Whether you’re an analyst or manager in a hospital or healthcare provider organization, HL7® interfacing is likely top of mind. After all, it’s what makes it possible for you to connect the diverse range of systems throughout your environment for the electronic sharing and retrieval of health information.
While the HL7® standard provides guidance on organizing data, you are likely trying to unravel many misconceptions about HL7® interfacing. To complicate matters, you’re up against multiple interoperability issues due to Meaningful Use requirements, forcing data integration among numerous systems.
It’s no small task keeping pace with all the HL7® standard developments, issues, and best practices. In fact, you’re not alone if you find yourself overwhelmed and tackling interfacing initiatives from a trial-and-error perspective. According to Frost and Sullivan, healthcare organizations spend $1 billion per year addressing system interoperability issues.
We developed this guide to help you take back control and simplify your daily professional life. Keep it handy as you’re working on HL7® interfacing and you’ll find that it eliminates many mind-numbing tasks so you can focus on the essential ones. At the same time, we welcome your feedback for improving this guide, as we plan to evolve it over time.
HL7® Defined
HL7® is a language that enables the standard, consistent, and uniform exchange and processing of health-related information between the various systems found in hospitals and healthcare provider organizations. Watch this video for a 3-minute overview of how HL7® works:
Whether they work for healthcare providers and hospitals or state and federal government agencies, many people who don’t deal directly with HL7® think it’s limited to clinical information systems, including those associated with radiology, labs, and more. But HL7® data is also used in systems used to manage billing, finances, and any number of other information systems within healthcare. In fact, the codes used to designate a range of healthcare-related information are in part governed by HL7®, and are embedded in HL7® messages.
HL7® Version 2 or 3?
Though HL7® version 3.0 was unveiled years ago, most implementations are done using HL7® version 2.3 or 2.4 as the base standard. The few implementations we’ve seen using version 3 have been limited to government agencies, including Canada Health Infoway and the US FDA. In fact, adoption is so low for version 3.0 that many call it a failure. Version 3 is not backward compatible with version 2, works within a completely different data structure, and requires different tools, technical skills, and implementation strategies. To avoid a steep learning curve, we recommend using HL7® version 2. Plus, Meaningful Use Stage 2 specifies HL7® v2.5.1 for lab data.
3 Main Challenges with HL7®
All that said, it’s healthy to approach an HL7® interfacing project with a clear idea of what you’re up against. Here are three main challenges we routinely see.
1. Customizable HL7® Format
The HL7® v.2 standard specifies a data structure based on trigger events, segments, fields, and data types. The recommended structure must account for complex clinical workflows and data representations, so the standard allows for extensive customization even when product specifications exist. As a result of the many variances and adaptations of the HL7® standard, there’s no truly standard way that systems are implemented and data is handled. In other words, plug and play is not part of the vocabulary.
2. Configurable and Customizable HL7® Data Tables and Code Sets
The HL7® standard provides a recommended set of data values for transactions. But they can be customized – and in fact, should be customized or configured under certain circumstances. Again, this means that data can be handled differently in each system. Some translation and data mapping would need to occur during data exchange so each system send/receive data it can understand.
3. HL7® Data Semantics
Good data semantics implies that the meaning or intent of the data – not simply the data value itself – is exchanged accurately. It’s essential for HL7® interfaces to convey their interpretation of the HL7® standard in use – or confusion will ensue. It’s the difference between NA standing for “Not Applicable” or “No Allergies”.
Your Feedback Welcome
We’ll be publishing chapters from the HL7® Survival Guide over the upcoming weeks and months. See a topic that needs more detail? Have a different perspective on interfacing and interoperability? Tell us in the comments!
Read More in the HL7® Survival Guide
Introduction
Chapter 1: How to Integrate and Exchange Healthcare Data
Chapter 2: Pros and Cons of Interfacing Capabilities
Chapter 3: The Heart of the Matter: Data Formats, Workflows, and Meaning
Chapter 4: How to Work with Vendors and Developing Your EHR Strategy
Chapter 5: Vendors, Consultants, and HL7® Interface Specifications
Chapter 6: Interfacing Artifacts: HL7® Conformance Profiles or Interface Specifications
Chapter 7: Interfacing Artifacts: Gap Analysis
Chapter 8: Interfacing Artifacts: Test Scenarios and Test Systems
Chapter 9: Interfacing Artifacts: Message Samples and Test Messages
Chapter 10: Process and Workflow
Chapter 11: Maintenance, Troubleshooting, and Monitoring
Chapter 12: Definitions
Chapter 13: Contributors and Resources
