Regardless of the HL7® version you choose to for interfacing, the first step is to define your healthcare integration strategy – will you use a point-to-point architecture? Do you need an interface engine? What integration capabilities do you need? Your choice will impact the scoping of your project, so it’s critical to nail down your strategy from the get-go. The key takeaway? Integrating several systems will require more extensive mapping and configuration than simple point-to-point architectures.
Interfaces Enable Data Exchange – But Require Development Effort
Even systems that are 100% HL7-compliant may not be able to exchange data because each one can use a variety of standard and custom message formats. These are the data exchange gaps that must be bridged through an interface, which can translate and manipulate the data. You can handle this manipulation by hand-coding changes to the messages in a point-to-point interface, or by using a central Interface engine application. Even then, HL7® interfaces always require some degree of customization.
Point-to-Point Interfaces
Hospitals, physician practices, and other healthcare provider organizations typically use several different computer systems for everything from billing and electronic medical records, to labs and pharmacy management. These systems need to exchange data with each other. The simplest way to do it is to establish a point-to-point interface, which is a connection between any two systems that enables the needed communication. Point-to-point interfaces are designed to send data from system A to another system B through a custom link (i.e., the interface) between the two. Because each system recognizes the other’s data format and interface specification (i.e., language and grammar), they understand each other.
It’s worth noting the number of interfaces needed to connect the ecosystem when using point-to-point interfaces. For example, if a system needs to exchange ADT data with three other systems, three interfaces need to be built. In the worst case scenario, for an ecosystem featuring N system – all collaborating together and initiating information exchange – you would end up with (N-1)*N interfaces. For three systems, that’s up to 6 interfaces; for six systems, up to 30. This is discussed in more detail in chapter 2.
Interface and Integration Engines
An interface engine or integration engine is middleware built specifically to connect systems. The engine eliminates the need for individual connections between systems, and orchestrates the message workflow, transforms message formats as needed, and guarantees message delivery. Integration engines go one step further than interface engines and simplify system interoperability by enabling workflow (not simply message) orchestration.
What’s the Difference between an Interface Engine and an Integration Engine?
While interface and integration engines are not exactly the same, they’re very similar and can be difficult to distinguish from one another. The real difference is in the range of functionality and capabilities supported by each. In fact, they provide different levels of support for an organization’s level of maturity when it comes to HL7®, from zero interoperability and integration (standalone hospital information systems, for instance) through to full interoperability.
Another way to look at interfacing and integration needs is by comparing trade-offs between cost and complexity. Point-to-point interfaces are sufficient to get you going or for getting your feet wet. After all, they don’t require a major time or financial investment. However, as soon as need more than a handful of interfaces, complexity and costs increase exponentially (see diagram below). That’s when it becomes more cost-effective to start working with an engine. Again, you may find you simply need a plain-vanilla interface engine. But if your data exchange needs are more complex (i.e., dependent on clinical workflows, involving multiple systems and/or multiple locations), you probably want to consider a more sophisticated integration engine. While you won’t get away from complexity with interface and integration engines, you will find they are more cost-effective for dealing with more complex environments.
Transporting an HL7® Message
HL7® suggests message structure but doesn’t specify how to transport those messages. It’s the role of integration engines to translate, mediate, orchestrate, and route messages. Each interface uses the transport mechanism making the most sense based on system requirements and limitations, whether LLP, TCP sockets, FTP, Web services, or email, to name a few.
Each system will use its favorite transport protocol/data exchange protocol. That’s why you need a translator to transport the message in a format each system will understand. You can build the translator into a point-to-point interface. Or, if you’re using an interface/integration engine, make sure it includes a translator (most engines do).
Fortunately, interface and integration engines handle message transformation between systems. In other words, they can pick up a message in a certain format and create a new message in a new format while retaining the same meaning across both messages.
However, interface and integration engines stand apart in how they move data. While a typical interface engine moves information from point A to point B using a hub-and-spoke model, an integration engine taps into business workflows to transfer information. In other words, compared to an interface engine, an integration engine provides more flexibility and control/visibility over data semantics.
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
