Author: Kevin Roy

We covered many details about interfacing architecture and data exchange in Chapter 2. All that said, your main challenges are not with the plumbing, or with the methods used to transport or route data. In fact, interface and integration engines handle this quite well.

Interface Engines Don’t Address The Real Issue

The real issue is with data formats, workflows, and meaning – and interface and integration engines don’t address these problems. It’s quite common for two or more departments (and by extension, the systems they use) within the same hospital or IDN to use different definitions and data structures to indicate the same information, such as “temporary patient.”

Consider another example. A physician adds a note “NA” (i.e., Not Applicable) to a patient’s chart indicating that information was never gathered about allergies to medications. Later on, another physician looks at the patient file, interprets the NA code as “No Allergies,” and orders an antibiotic drug. The patient dies from an allergic reaction. While this is an extreme case, it’s well within the realm of possibilities. This is why meaning – the semantics of data – is everything.

Here’s another scenario. A physician submits a pharmacy order for a pain relief medication not recognized by the system receiving the order. The order is dropped and the patient endures more pain for longer until the situation can be remedied.

Even the definition of a procedure can vary from one physician or clinician to the next. If a physician requests a complete blood workup on a patient but the lab technician omits some tests because she doesn’t consider them to be part of the order, the doctor will wonder when she will be receiving results for the outstanding tests. When they never show up, she’ll be forced to follow up with the lab, wasting valuable time for her and her patient.

Or consider something as simple as date-time data. If you don’t specify AM and PM in your scheduling application, you’re going to be constantly wasting time rescheduling appointments set for 8:30 at night when you mean 8:30 in the morning, for example. The same holds true when you don’t account for time zones, such as data in one system set for MST and the other set for CST.

Data and Information Challenges

The real challenge is at the information level. What information is needed by whom, when, and in what format? Once you have these answers, you need to validate that information being transferred is using the same semantics.

	Issue	Example
Data structure	The HL7® 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.	There might be a gap based on the maximum length of data elements. A field in one hospital system specifies a maximum length of 50 characters. The same field in the system under implementation is set at maximum length of 20.
Data tables	HL7® provides a recommended set of data values. These can be modified.	HL7® v2.6 “suggests” six different values for patient gender.
Data semantics	Good data semantics implies that the meaning or intent of the data is exchanged accurately – not simply the data value itself. It’s essential for HL7® interfaces to convey their interpretation of the HL7® standard in use.	Patient identification is the classic example. It is important to determine which fields are in use. Possibilities include: PID-2 Patient ID, PID-3 Patient Identification List, PID-18 Patient Account Number, PV1-19 Visit Number, or a combination thereof.
Z-segments	Z-segments are custom message segments. They are used when an application must convey information outside the scope of the HL7® standard. Development teams also resort to Z-segments to work around technical limitations.	By definition, all Z-segments result in gaps. If Z-segments aren’t mapped accurately, critical information can be lost.

 

The bottom line is that it’s critical to understand the data, the source systems involved, and how each system handles data semantics. Here are some tips and questions to help you get at this information.

6 Questions to Help Your Team Understand Healthcare Data

1. Understand the message/interface specification provided by your vendor. “We are HL7 2.4” is not enough. Ask the vendor to provide details about messages, segments, fields, the need for z-segments, etc. Also find out how they handle data semantics. In other words, what does the data mean? What is it used for? By extension, understand workflow-related information, event timing, vocabulary definitions, and who will use the information and how. The examples we listed above (lab results, two meanings of NA) speak to this.

2. Understand the type of message that will be generated based on the event (e.g., a patient admission, patient visit, cancelling a transfer, sending a partial lab result). Understand what data is provided with the event, including the various code sets. Watch this video for a 4-minute overview of an HL7^® message:

https://blog.interfaceware.com/understanding-hl7-messages/

3. How do the code sets and content evolve over time, and who handles the updates and how?

4. Where does the data go? Is there a need to protect sensitive data?

5. How does the new system manage errors? What happens to messages that aren’t understood by the destination system? What happens to rejected messages? We all agree that in a perfect world no piece of information and no messages would be dropped, but the reality is it that it can and will happen. How would users and the overall workflow be impacted in such a situation? How can you mitigate the risk?

6. How do you handle workflow changes? If it’s a matter of adapting the interface, how is this handled, how much time does it take, what does it cost, and who pays? You want to avoid Frozen Interface Syndrome, which occurs when you are trying to implement a new interface and need all participants to switch over at the same time but can’t get their cooperation. Worse yet is Interface Black Box Syndrome, when you lack full visibility into all the work that has gone into interface development handled by a third party, making it nearly impossible to upgrade, tweak, and manage the interface without spending lots of money and time.

Answers to these questions will help you understand the source and target systems. This is important for new product implementations (like EHRs and EMRs). Once you’ve nailed down these details, you need to pinpoint the gaps with the receiving system(s) so you can bridge them with an interface.

Here are some questions you’ll need to ask of the vendor and your internal teams about the receiving system(s).

5 Questions for HIT Vendors and Internal Interfacing Teams

1. Map out the message process or workflow. For instance, if your interface transfers data from a remote application via FTP, what is the flow? Do messages start in one application, get routed to an engine, then another engine, and then finally reach the destination system?

2. Map out the business impacts of the interface. If you make changes to a patient charge interface, what is the business impact? What if you choose not to implement the interface? For example, will it result in more manual data entry for a clinician?

3. What information does the destination system need? Where in the message structure is the information found?

4. Is the vocabulary used in the destination system different from that used in the source system?

5. Is all of this information documented? If not, how will the vendor keep you updated on changes? This is an especially important question to ask vendors, since they simply won’t be as responsive two years down the road as they were during implementation and go-live.

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

In Chapter 1 of the HL7^® Survival Guide, we covered what it takes to exchange data. To help you make the most suitable choice among interfacing approaches, we’ve laid out the pros and cons of each approach or set of capabilities.

	Advantages	Trade-Offs
Point-to-Point	Get up and running quickly if you have a few systems only. Small system volume makes it easier to work with Works well and is cost-effective for fewer than five healthcare information/clinical systems as infrastructure investment in minimal and complexity is reduced. Easier to get going quickly when you’re starting from scratch No need for technical resources; vendors can set up interfaces	Harder to grow/evolve over time because systems are tightly coupled together and any change to one might impacts all others Doesn’t scale well since there will be N(N-1) interfaces in ecosystem (e.g., 5 systems – 5(5-1) = 20 interfaces) Inflexible – systems must understand other systems’ expected data structure and semantics Limited monitoring capabilities Costs can grow rapidly if you rely on vendor to change or add new interfaces
	Advantages	Trade-Offs
Interfacing Capabilities	Mediates transport protocols between systems Scales elegantly to reduce number of interfaces required (N + 1) Centralizes and facilitates monitoring of message flows and interfaces Systems are loosely coupled, enabling you to add new interfaces and modify existing ones without impacting other systems Provides tools and infrastructure so interface adapts to different HL7® message and data formats Reduces interface costs by using single application capabilities across all applications Reduces dependency on multiple vendors for changes to message format	Steep learning curve – need to be well versed in a specific vendor’s technology to develop interfaces Vendor lock in can mean additional costs for integration engine infrastructure, as well as costly interface engine technology conversion that involves large projects impacting several systems
	Advantages	Trade-Offs
Integration Capabilities	Includes workflow management features that enable the interface to respond as clinical workflows evolve and that offer a more flexible migration path for systems and ecosystems Provides a single point for system integration to ensure consistent management Built to scale	More complex and expensive than smaller-scale interface engine due to shortage of skilled analysts and need for extensive training Expensive software licenses Need to create a dedicated team (if you don’t already have one)

 

Vendors of Integration Engines and Technologies

To help you get a jump-start on your research, we’ve listed some of the major interface engine providers below. Each of these providers addresses different needs: while some are best suited to small hospitals, others scale to support multiple locations and stakeholders, such as for an 80-hospital IDN. Still other engine vendors focus on interfacing with EMR solutions (for example, Summit and Iatric are fairly Meditech focused).

Check out the relevant vendors below, and evaluate other players in the market. Use the grid above to figure out the questions you should ask based on your organization’s needs.

• Cerner Open Engine
• Cloverleaf
• Corepoint Health
• Ensemble
• Iatric EasyConnect
• Interfaceware Iguana
• McKesson Pathways
• Microsoft BizTalk
• Mirth Connect / NextGen Connect
• Oracle Fusion
• Oracle JCAPS/ICAN/e*Gate/DataGate
• Rhapsody
• Siemens OpenLink
• Summit Exchange

Note: This is a partial list. We welcome your suggestions for other vendors you feel should be added.

Engine Vendor Performance Rankings and Market Share

• For vendor performance rankings, see the KLAS Research website.
• For a current view of the HL7^® interface market within healthcare, see the 2018 HL7 Interface Engine Rating survey results published by Core Health Technologies.

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

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

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