BlogPosts/Health Care Integration using HL7 and a Swiss Army Knife
  • Share:
Image Description

Series: General Blogs (Not part of a series)

Health Care Integration using HL7 and a Swiss Army Knife

Healthcare systems interoperability can be complex and difficult terrain.  Often, a tool that allows you to solve many different types of problems effectively is referred to as a Swiss Army Knife.  A Swiss Army Knife is considered a safe bet when you must brave the elements in difficult terrain. 

At Nexus Point S.I., we deliver with rapid deployment, cloud and on premises health integration capabilities based on HL7, NCPDP, X12, XML, Flat file, CSV and batch for any partner in the health care ecosystem, small or large.

A while back, I was working with a hospital customer, on a data integration project.  The goal was to improve control of existing health care HL7 message processing in a way that would allow them to lower the cost of future expansion and ongoing maintenance. The hospital wanted to have more control of the processing HL7 messages as they passed between their Hospital Information System (HIS) and other internal hospital systems.  They also wanted to have the same level of control to and from external partners like billing vendors and peer hospitals.   

They needed to be able to:

  1. Control message routing.
  2. Modify the messages according to business and interoperability requirements.
  3. Generate additional messages and message types from the original messages to share the generated data with appropriate operational systems and partners. 

The hospital needed to accomplish this without affecting their existing data flow and processes.  I presented them with a straightforward and standards-based approach using ConnectMate Interface Engine. 

ConnectMate Engine is our proprietary technology that has been used in production by hospitals, pharmacy benefit managers and health document processing OEM partners for more than 10 years.

In the first phase of this and many initiatives, the goal is to interpose or create bridges between the existing interfaces.  We sometimes described them as just that, "Bridge Interfaces" to give a visualizable label.  Once the Bridge Interfaces are in place, they are used to create additional pipelines/pathways and rules to facilitate current and emerging information business requirements.  

The goal here was to keep everything flowing as per normal while staging for reuse of existing data feed to multiple purposes, such as sending to newly added internal systems or downstream ecosystem partners. 

There were 4 important outcomes that were highly valued by the hospital customer.

  1. After the implementation and training, key IT hospital staff had a better understanding of their interoperability ecosystem.
  2. With cost prevention in mind, the trained IT staff could better visualize, plan, and if desired, even build new interfaces and pipelines.
  3. They could maintain the existing pipelines without having to always rely on the HIS vendor or downstream partners to decide the architecture.
  4. They could avoid or at least lower their reliance on the HIS vender to do all internal and external integrations. This allowed the hospital to have more control in lowering ongoing costs to maintain current and future information pipelines.  

The Implementation

To implement the solution in the most flexible way possible, I followed these simple steps:

  1. Deployed a preconfigured VM with ConnectMate Engine, in their environment (On-Premises).  (ConnectMate Engine VM can also deploy in the cloud)
  2. I created a process flow with:
    1. A Listening connection that mimicked their hospital management system.
    2. A Client connection to the hospital system that I was mimicking.
    3. A route to send all traffic from the new Listening Connection into the hospital system.
    4. This created what we can call bridge, pass-through or gateway interfaces.
  3. I then connected the original source of the information to the new listening connection.  At this point we could see and interact with all messages traveling through the new pass-through.
  4. I then created processing logic in the listening connection to read and make decisions based on what was in each incoming message.  This way I could send the messages to other processes without changing the original message flow.

"This article was originally published by Vince Yoder on 4/3/2017. It was slightly update by the Nexus Point Media Team in Jan 2024."


  • Share:

Once the bridge/pass-through interfaces were implemented, the customer then wanted to create new HL7 messages based on the types now coming through the pipeline.  For some use cases, the customer needed to add additional segments that were important for the downstream systems as part of the normal data stream.

For this part, we simply:

  • Added source code to find a specific value in the incoming messages.  If the value existed, we routed the message to a specific processing connection.
  • On the processing connection, we added code to find a specific element in the message and based on the value of that element, we created new message segments.
  • We then sent the new message(s) to the new downstream systems. 

These are capabilities that the hospital could not control internally before.  They came to us because they recognized that they could implement our solution internally and realize ongoing cost savings for every next interoperability requirement.  This was because of the inherent reuse capability with optimized and controlled pipelines management in-house.

We followed the same steps for several other new internal processes and helped the customer improve their overall service delivery to patients.

 Once we had completed the project, while discussing the solution in a post implementation meeting, an architect with the Hospital Information System vendor stated that “Vince was able to come in with his ConnectMate Swiss Army Knife, and in record-time, solve every interface problem we ran into”.   During the project, Vince never had to say no, but instead, “We can do that and how soon do you need it”.

 ConnectMate is so powerful and flexible that I really haven’t found a health care data integration problem that we could not help a customer solve.  Now we have new capabilities like Micro Services and HL7 FHIR entering the scene, and we are already proving that we can solve problems with those practices as well.

Save

Save

"This article was originally published by Vince Yoder on 4/3/2017. It was slightly update by the Nexus Point Media Team in Jan 2024."

 CM Management Center

(Responsive Web and Mobile Management Desk - User Interface)

ConnectMate Engine may be the most cost effective and performant solution for you. It works equally well for RCM & billing providers, Lab service providers, clinics, insurance companies, ACOs and any other organization that needs to rapidly deploy integrations based on HL7, NCPDP, X12, XML, Flat file, CSV or batch operations. 

As one of our clients once said, “Get ConnectMate and Get Going!”

Save

Save

  • Share:

Vince Yoder

Mr Vince Yoder is the former Director of Health Care Integration Nexus Point Systems Integration, LLC Health Care Division.  He was Certified ConnectMate Architect and Engineer with more than 10 years experience on the platform. Vince was hands on daily with our hospital integration projects involving HL7 and NCPDP based solutions.  Vince was responsible for architecture, engineering of integration solutions.  He was also responsible for developer training for clients, our independent integration contractors and internal team members.  Vince served his country in the U.S. Army specializing in missle systems and mainframe computers. Vince had 11 years experience as a Hospital IT Department Manager responsible for network security and administration as well as systems integration.  He also periodically taugh IT courses at the area community college system.  We thank him for is service to our Country and to our Clients.  Thank You Vince.  We all miss you.