Simplifying the interface challenge in healthcare

Healthcare software provider or medical device manufacturer’s approach to healthcare integration

Providers, application software developers, and medical device vendors are all faced with the demand of providing electronic interfaces at unprecedented rates.

While there are many different approaches and tools used to solve the healthcare integration challenge, the options primarily are reduced to:

  1. Implementing point-to-point interfaces
  2. Developing an integration engine (sometimes referred to as a communications subsystem)
  3. Partnering with an integration engine vendor

No matter what the approach, a vendor’s application, at a minimum, likely will need to integrate to several different healthcare applications including the following:

  • HISHospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends AD... More  Hospital Information System
  • RISRadiology Information System (RIS) is the main application in an imaging center or radiology departm... More  Radiology Information System
  • LISLaboratory Information System (LIS) is an information system that receives, processes, and stores in... More  Laboratory Information System
  • EMR  Electronic Medical Record
  • EHR  Electronic Healthcare Record
  • ED  Emergency Department Application
  • Rx  Pharmacy System

Determining the most effective approach for healthcare integration has a long term impact on an organization’s development, client support, and client implementation functions. Defining the requirements is an important first step to evaluating the options.

Healthcare integration overview

To facilitate communication between two healthcare applications, a modest interface includes:

  • An export endpoint for the sending application
  • An import endpoint for the receiving application
  • A method of moving data between the two endpoints
  • A method for handling the queuing messages
  • A method for logging the flow of messages

Illustrated in Figure 1 is a simple, sample interface between an HISHospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends AD... More system and a lab. The blue box represents the export endpoint for the HISHospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends AD... More system and the yellow box represents the import endpoint for the lab system.

Sample Interface Between HIS System and Lab

HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More is the most widely used standard to facilitate the communication between two or more clinical applications. The prime benefit of HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More is that it simplifies the implementation of interfaces and reduces the need for custom interfaces. Since it’s inception in the late 1980’s, HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More has evolved as a very flexible standard with a documented framework for negotiation between applications. The inherent flexibility defined in the HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More Standard will make the use of an integration technology solution attractive and, most times, a necessity.

Taking this example a step further, illustrated in Figure 2 is the same HISHospital Information System (HIS) is the main system in a hospital used by most caregivers. Sends AD... More and LISLaboratory Information System (LIS) is an information system that receives, processes, and stores in... More systems but with the added capability in both applications to import and export data.

HIS and LIS System with Added Capability to Import and Export

Logic tells us that each healthcare application must grant access to accept and send patient data and have rules of what it will accept and what it will send.

Frequently, the access grant will be hard-and-fast rules rather than flexible ones that provide easy methods for exchanging data. Most application developers focus their efforts on the design and objectives of their own application rather than straightforward ways to interface with other vendors. Consequently, healthcare applications will contain data unique to their approach, making it challenging to exchange data and gain access to accurate specifications. The unique data elements are handled as Z segments in HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More.

While there is not a true “black box” that can easily provide for the data exchange between disparate applications, there are tools that ensure minimal dependence on other vendors. A healthcare integration engine brings adaptability and flexibility to the game.

An integration engine can transform or map the data to the receiving application’s requirements while the message is in transit so that it can be accepted by the receiving application. Many times, interim tables are also created to allow flexibility in the way data is mapped by the engine.

Some rudimentary engines may have tools for assisting with issues like Z segments. More advanced integration engines also will provide the ability to analyze test messages so that interfaces may be built without access to updated specifications.

The use of an integration engine in this manner dramatically reduces the dependency on multiple vendors to make changes in the format of messages they send or receive. While most engines provide the capability of handling all HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More versions, having the means to convert from one HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More version to another is essential, especially if the other system requires it.

Alternative options are sometimes used when interfacing to healthcare applications that do not grant access. These options can include:

  • Interacting directly with the application’s database
  • Using screen-scraping tools to read the tables

Sometimes, these may be the only viable options when access to an application is not granted by the application vendor. However, using these options can create data integrity issues and should, therefore, be used with caution. Moreover, the use of screen-scraping tools is usually tedious and is often more difficult to maintain as changes are made in either application.

Healthcare integration requirements

With this overview, a healthcare interface solution should meet the following minimum requirements:

First in, first out (FIFO)

The exchange of clinical data must be real time, and in FIFO order. This means that the first HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More message received will also be the first HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More message delivered.

Flexibility to address varying requirements

Since HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More is essentially a framework for negotiation, the interface solution must be flexible to deal with HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More V2.3.1, V2.4, V2.5, etc. and send one message in the differing versions to multiple applications. Part of the flexibility is working with the uniqueness of each application. Within HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More, Z segments are one way to handle the important data elements that one application may need and another may not. Flexibility is essential.

External application and provider integration

Unlike the simple diagram on the previous page, real-world integration takes place between multiple applications in multiple locations. Healthcare interface traffic can be intense so a strong traffic director in the middle is extremely important. The intensity comes from the flexibility defined in how HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More is deployed in various healthcare applications. Providers (e.g., clinics, labs, and imaging centers) often direct how they want HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More used in their organization.

However, there is a clear distinction from being in the middle directing healthcare traffic and being “stuck” in the middle. When the capability exists to modify and direct message traffic, the application can adapt rather than wait on others to modify their application. If the traffic director capability does not exist, then being stuck in the middle will translate into delayed and costly implementations, application modifications, etc.

It is important to note that each application in the integration path has to have the ability to send and/ or receive data, ideally in an HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More format (although some integration solutions may be able to utilize CSV or flat-file formats).

Short implementation cycle

Implementation must be simple, taking a matter of days versus months. The workflow for interface configuration should be intuitive so that a developer does not have to be available to implement each application or site. Configuring an interface to meet the requirements of vendor specifications should be a simple activity in a project plan. Accordingly, the configuration process should be GUI driven and logical.

Scalable

The number of interfaces will grow over time. With more healthcare providers demanding electronic exchanges of patient data and the growing EMRElectronic Medical Record (EMR), as defined in Defining Key Health Information Technology Terms (The... More adoption, an interface solution must be able to grow with the demands of the market.

Different data formats

In addition to HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More, the interface solution should be able to handle other clinical standards including the Clinical Document Architecture (CDAClinical Document Architecture (CDA) HL7 CDA uses XML for encoding of the documents and breaks down ... More), Continuity of Care (CCRContinuity of Care Record (CCR) is an XML-based standard for the movement of “documents” between... More), and XML. EMRs are growing as a key driver in healthcare interfaces, so addressing the various clinical formats is critical to meet an application and provider’s interfacing requirements.

Ease of interface testing and maintenance

Delivering quality interfaces is crucial. Accordingly, several testing functions should be provided within the interface solution. Even the most rudimentary integration solutions should include HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More conformance checkingConformance checking or gap analysis for HL7 messages is a logical process used to determine whether... More (testing messages against a selected HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More version including modifications made), message unit testing, and communication testing. Equally important, providing documentation of the interfaces built and deployed is critical to managing the cost of support of each installation.

To emphasize a critical testing point, an interface solution should be able to scan messages coming from another application to determine their structure and HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More version, especially when specifications do not exist or are inaccurate.

Ease of monitoring and management

To keep customer support costs low, interface implementations should be easy to monitor and resolution tools for easy fixes should be readily available. This will enable customers to track the uptime of critical interfaces, resolve issues proactively, and quickly fix issues. The importance of keeping logs of messages sent will become very obvious when a message needs to be re-sent or a history of message exchanges needs to be reviewed. Tools that make searching through the logs easily will be quickly pay for themselves with the growing number of messages and interfaces being implemented.

Gaining independence from other healthcare vendors is an objective for most healthcare software providers or medical device manufacturers. In other words, healthcare vendors do not want the successful implementation of their application to rely on another vendor’s application. Independence is essential to implementing quickly and establishing a swift success record of your application’s benefits.

The key question is: how can a healthcare vendor quickly and easily deliver interfaces to different applications in a consistent, cost-effective manner? Outlined above are several key requirements to include in your selected approach to implement an interface strategy for your customers.

Evaluating the integration options

With the requirements outlined above, how do the integration options compare?

To review, the options are:

  1. Implementing point-to-point interfaces
  2. Developing an integration engine
  3. Partnering with an integration engine vendor

Two of the options include an interface engineAn interface engine can transform or map the data to the receiving application’s requirements whil... More, so a fundamental decision to make is building an interface engineAn interface engine can transform or map the data to the receiving application’s requirements whil... More versus partnering with an interface vendor. Nevertheless, it is useful to summarize the plus/minus of the point-to-point versus interface engineAn interface engine can transform or map the data to the receiving application’s requirements whil... More option given each requirement.

In almost all cases, given the requirements outlined above, would a point-to-point interfaceA point-to-point interface is one in which the receiving vendor provides a specification on what dat... More option be feasible. Building custom interfaces for each application for each client would be costly to implement, support, and maintain. The point-to-point approach in the environment described would not work effectively for a vendor.

The decision then is whether to build or buy. With the requirements needed in the market today and the changes occurring with the standards, a healthcare integration engine can be viewed as a separate application.

With that view, one must be able to answer each of the following questions in the affirmative in order to not consider partnering:

  • Does your organization have the development resources and skill sets to undertake a separate effort to build an interface engineAn interface engine can transform or map the data to the receiving application’s requirements whil... More application?
  • Can your organization afford the time to build a healthcare interface engineAn interface engine can transform or map the data to the receiving application’s requirements whil... More application to meet customer immediate demands?
  • Does your organization have the support capability to answer customer questions about HL7HL7 is a Standards Developing Organization accredited by the American National Standards Institute (... More, CDAClinical Document Architecture (CDA) HL7 CDA uses XML for encoding of the documents and breaks down ... More, CCRContinuity of Care Record (CCR) is an XML-based standard for the movement of “documents” between... More, and other standards?
  • Does your team have the experience and background to implement varying interface requirements in each client’s organization and to each of their external providers?

Features of a Point-to-Point Environment vs. an Integration Engine Environment

About Corepoint Health

Corepoint Health solutions deliver interoperabilityInteroperability refers to the ability of two or more systems or components to exchange information ... More for healthcare organizations and simplify the complexities of healthcare data through practical software applications, consulting and training.

Our innovative and proven software solutions leverage clinical data flow efficiently for a diverse group of healthcare entities including hospitals, imaging centers, laboratories, clinics and healthcare vendors. This next generation approach to healthcare data and streamlined workflow is where Corepoint Health specializes in helping customers discover the power of integration.

Download PDF

 Print Friendly