HL7 Integration

The worldwide push for a centralized electronic health record and the explosion in the number of clinical applications are only two factors driving the need for a unified language between applications. Health Level 7 (HL7) happens to be a large part of the solution. Apps used by healthcare centers that have embraced the HL7 messaging standard can communicate with one another even when they speak different languages.

Every healthcare environment is radically different when it comes to payment structures, politics, data collected, business relationships, software systems, and database structures. Meaning, every hospital, imaging center,  clinical lab, acupuncture center, outpatient surgery center, and podiatrist’s office have unique requirements for interacting with patients and data. Now take into consideration the uniqueness of every healthcare setting in each country where care will have to be delivered. You'll end up with an enormous amount of unique requirements that are close when it comes to their needs but never exactly the same. It is in this disjointed playing field that HL7 attempts to establish a flexible, single, worldwide standard for the movement of clinical data. The evolution of HL7 has been improving workflow throughout the healthcare industry.

HL7's messaging standard is broad enough to accommodate both stand-alone diagnostic imaging centers and clinics and large-scale hospital networks. Also, HL7 is not a software application, to clear up a common misconception. The HL7 standard is a guide or a rule book with pages detailing interfacing information that sets a framework for negotiation in interfacing, giving analysts and programmers a starting point from which to begin their technical discussions.

Health Level 7 stands for the seven-layer International Standards Organization (ISO) Communications Model:

1. Physical: Connecting the object to the transmission media
2. Data Link: Between adjacent nodes, providing error control.
3. Network: Routing the information in the network
4. Transport: Providing end-to-end communication control
5. Session: Handling issues that are not communication problems
6. Presentation: Converting the information
7. Application: Providing various services to the applications

Whether a healthcare organization is upgrading present software or implementing a new one, Health Level Seven International (HL7) interfaces are typically considered. HL7 interfaces are needed to support data integration needs due to application interoperability. Properly implemented HL7 interfaces can enhance end-user workflow and reduce duplicative data entry. The way in which HL7 interfaces are implemented will dictate the success of a project, as with any new technology effort. So let’s get to it.

Plan the interface

While ADT (Admission, discharge, transfer) might be the most often discussed HL7 interface, there are other HL7 interfaces used in health care institutions. These other interfaces are deployed to share clinical, physician and financial data relative to visits and patients. Examples of these other interfaces are:

ORU – Observation results
DFT – Detailed financial transaction
ORM – Orders
MFN – Master files notification
MDM – Medical document management
SIU – Scheduling
BAR – Billing account record

HL7 Integration Options

A hospital or a typical clinical facility will have several HL7 enabled devices and applications. To increase the overall efficiency of the facility and reduce data entry time, these applications or devices need to communicate with each other.

There are two ways this can be accomplished:

1. POINT-TO-POINT: The simplest way to exchange data is to establish a point-to-point interface, wherein a connection between any two systems that enables the necessary communication is established. Point-to-point interfaces are built to send data from one system to another through a custom link or an interface between the two. As each system recognizes the other’s interface specification (i.e., language and grammar) and data format, they understand each other. However, it's worth noting the number of interfaces needed to connect the ecosystem when using point-to-point interfaces. For instance, if a system needs to exchange ADT data with 4 other systems, 4 interfaces have to be built. At times, for an ecosystem featuring X system, all initiating information exchange and collaborating together, one would end up with (X-1)*X interfaces.  For 4 systems, that’s up to 12 interfaces; for 6 systems, up to 30.
2. INTERFACE AND INTEGRATION ENGINES: An integration engine or an interface engine is middleware built to connect systems. This engine transforms message formats as needed, orchestrates the message workflow, guarantees message delivery and removes the need for individual connections between systems. Interface and integration engines are quite similar and can be hard to tell apart. The actual difference is in the range of capabilities and functionality supported by each. When it comes to HL7, they provide various levels of support for an organization’s level of maturity from zero integration (standalone hospital information systems, for instance) and zero interoperability through to full interoperability.

Regardless of the HL7 version you choose for interfacing, the first step is to define your healthcare integration strategy. Do you need an interface engine? Or will you use a point-to-point architecture?  What integration capabilities do you require? It’s crucial to nail down your strategy from the get-go as your choice will impact the scoping of your project. The main takeaway? Integrating several systems will demand more extensive mapping and configuration than simple point-to-point architectures.

Systems that are 100% HL7-compliant may still not be able to exchange data as each one could be using a range of custom and standard message formats. These data exchange gaps have to be bridged with the help of an interface, that can manipulate and translate the data. By using a central Interface engine application or by hand-coding changes to the messages in a point-to-point interface, you can take care of this manipulation. Even then, HL7 interfaces will require some degree of customization.

Comparing trade-offs between cost and complexity is another way to look at interfacing and integration needs. Point-to-point interfaces are sufficient for getting your feet wet or to get you going as they don’t require a significant financial investment or time. However, soon as you need more than a couple of interfaces, costs and complexity start increasing exponentially. That’s when it gets more cost-effective to work with an engine. You may find that all you need is a plain, simple interface engine. However, if your data exchange requirements are more complex, as in dependent on clinical workflows, involving multiple locations or multiple systems, you might want to look into a more sophisticated integration engine. While you might not get away with complexity using interface and integration engines, you will find them more cost-effective at dealing with complex environments.

HL7 Integration

Analyze your health system’s needs and build a customized interface solution that will meet your budget along with current and future needs rather than implementing the recent phase of your HL7 integration. A strong interface team with coordinated testing by subject matter experts can provide a successful outcome in HL7 implementation.

SCOPE
The first step when implementing HL7 interfaces should be figuring out the scope of the HL7 work effort. Take the time to identify the required interfaces and identify interfaces that are not part of the current project scope. The analyst then performs a gap analysis based on the new system to be implemented and the client’s current information system environment. The gap analysis guides the conformance profile which will define the interface. The vendor, the client, and any third parties sign off on who takes care of what once the gap analysis is complete. Scoping can prove to be a massive bottleneck in an implementation project when manually handled. Seek out automation avenues if you're trying to eliminate process waste.

BUILD THE INTERFACE
An interface programmer uses other documentation (such as database mapping) and the conformance profile to code and configure the interface.

SIMULATION TESTING
The analyst or programmer validates the interface against the sample, read simulated, messages. Under test conditions, once the interface can send and receive simulated messages successfully, it is shipped for integration testing to the client site. Before integration testing,  providers should ensure that vendors put the interface through its paces. Before you sign off on the implementation project approval ask to see sample test documentation. Proper simulation testing can steer clear of a whole lot of headaches during go-live and after.

UNIT AND INTEGRATED TESTING
Here is where application subject matter experts should really be involved. While interface analysts are usually good at working with the technical items relevant to an interface, they might not be data content experts. Unit testing walks through reviewing data for accuracy and validating specific feeds. Any problems the interface engineer didn't find during the initial gap analysis should be identified here. Integrated testing demands reviewing data as it flows through downstream and upstream systems through the HL7 interface solutions. Project sponsors are generally very familiar with the data and must be involved in validation steps.

CLIENT VALIDATION
Using pre-configured test data, an analyst at the client site validates the interface in a test system against specific clinical scenarios. During the validation stage, you want to avoid using production systems and protected patient information. Based on the project and provider IT culture, the scope of client validation can vary greatly. Companies that invest in thorough validation see payoffs with less downtime, smoother go-lives and lesser calls to their tech support teams down the road.

Conclusion

With the emergence of new HIPAA legislation and guidelines, and as more clinics and hospitals take into account the regional health information organization model, diagnostic imaging centers and laboratories continue to utilize new technologies into their workflow, EMRs improve, and HL7 will continue to be a critical component in the evolution of healthcare. Each updated version of HL7 incorporates new options and features that complicate the standard one. The best interface engine today must allow multiple connections to both internal and external applications for an easy data exchange.

HL7 interface development could seem like a technically complex project, but managing it needn't be hard. Successful HL7 interface implementation takes teamwork and must marry the skill sets of the data subject matter experts who have the background to assist with testing and the interface team. Consultants can add interface expertise along with helping decrease an organization's backlog of interface work.