Which Integration Method Is Right For You?

Integration

In healthcare it seems we are always talking about the latest type of connection you can use HL7, FHIR, ADT and the list goes on; what is even more comical is it changes based on who you are talking to Provider? Payer? Patient?

It feels like the fix for integration has been to create a new type of integration standard. However it is not all about these times of connectors or integrations, we can actually reduce down all this into 3 main areas to focus on.

PointToPoint

Point-to-Point

These type of integrations are usually direct interfaces, like HL7, FHIR or ADT, that connect one system to the next. Information flows one way to share information and it is up to the Target system to decide what to do with it.

Point-to-Point is the most common type of integration in healthcare. You work with your vendors to establish a standard you will use, like HL7, and then make sure your schemas match and then test it.

This method leaves it up to each system to interact with any other systems to handle issues like EMPI or data flow or transformation. 

Major hurdles with this integration type is each integration requires its own project timeline and you have to maintain each, we see our clients have 5k+ connections by the time we get start working with them.

On the plus side they are much easier to setup than most any other integration and require the least amount of software and/or license fees.

IntegrationEngine

Health Information Exchange/Integration Engine

These types of integrations use Point-to-Point to move data to an Integration Engine that then forwards it to a target system. This is good for keeping a copy of the information, it is still up to the target system to decide what to do but in this case you can also handle a Point-to-Point reply from the target back to the Integration Engine and back to the Source.

Integration Engines are the second most popular and the most prevalent mostly thanks to the rise of Clinically Integrated Networks and ACOs as well as Population Health. However most of these systems are heavily under utilized and most clients report costs going up to maintain them as well as the team required.

This type of integration can automate the workflows required to talk to all your other solutions such as EMPI and data transformation. 

Major hurdles with this integration is the team you will have to deploy and license it also does not eliminate the Point-to-Point connections.

On the plus side you get all you’re data is sitting in one place, its stale in the sense its one way and often transformed so it can work with a data viewer, however being in one place is great to be able to manage Population Health metrics and sharing data.

Platform

Near Real-Time Bi-Directional Platform

This type of integration is the most robust it offers you a reliable way to manage data moving back and forth from a Source to multiple Targets and back, it can also handle all your Integration Engine needs.

Unlike its counterparts this requires a platform that is able to handle data back and forth and also keep the data current and not stale, meaning minimal transformations or at least real-time transformations so you always have a copy of the live data.

The major difference of a platform is that it encompass multiple other solutions to bring everything holistically into one place.  So instead of having an EMPI, Integration Engine, HIE, API platform and so on a platform handles all this for you in one single place. 

Major hurdles for this is usually cost and time to get up and running.

On the plus side most of the solutions in this space are fully managed by a vendor, cloud based, and once they are setup it is much easier to add connections and integrations by simply having your vendor follow a schema you have set in place for them.

What is right for you?

Rather than solving a need multiple times over and over it is time to re-evaluate your data integration strategy and see which option is best for you. Picking the best option will help you scale at a much more rapid pace than your competition.

And what is right for you is not right for all health systems, we still have clients that see the most value from Point-to-Point integrations. It really comes down to your needs and when is the right time to deploy it those needs.

There is also cost and scale challenges with each solution as well as implementation time. The first step to figuring out which option is right for you is to consider your current needs and your needs in the next 5 years, from there you can find the solution that fits both the needs and the budget.

Looking for a free evaluation of your integration strategy as well as which options are best for you? We are happy to help, and even if we are not the best option we will recommend one that is! 

Why Care Gaps Are Really Data Gaps

Gap

In healthcare you will often hear, or see in the news, talks about care gaps. Care gaps is used to describe when a link in the chain along the journey is not connected. Think of care gaps as a way to address a particular path/journey/experience in the same manner every time.

Addressing journey experiences is very important for systems and providers as it provides patients with a better experience overall, reduces risks and increases the success of each visit.

CareGaps

White spaces

Care gaps live in white spaces, spaces that need to be addressed to resolve a particular initiative that is usually unique to addressing the unique population that provider/system serves. This is an important part, because you can’t have the same care gaps for every hospital be the same, although there are guides and standards people follow as a starting point most often you will see systems really take a unique approach to it which is important for them to stay innovative.

Strategic initiatives look at resolving these challenges at a high level; for example lets say a patient visits a doctor and then he is referred to a specialist and instead of making appointment on the spot the patient has to call a different number make an appointment. Then once the patient gets there the doctor does not have their information, this is a big care gap.

In this area is where care gaps work to solve the white spaces and they do this using workflows that can be followed consistently over and over again.

Workflows

Workflows go hand in hand with care gaps. Care gaps identify the challenge we need to address and workflows is how we address those challenges. So if we were to take a look at it the flow goes from strategic initiatives to care gap identification to workflows.

Once workflows are identified then operations can begin executing those workflows and then we can measure the output of those and repeat the process or adjust until we find the right formula that provides consistent results

DataGaps

Data Gaps not Care Gaps

When thinking of addressing care gaps what is always absent is the data gap. We have a larger data gap problem than a care gap problem. If we take our example of a basic referral for instance and ask the question is why is it missing? There are a few reasons that could be:

  • Provider is not inside the 4 walls of the system OR
  • Provider is using their own EMR system OR
  • Provider is completely independent and even in another location/state

When you dig into all care gaps you will find it is often, if not always, a data gap issue that needs to be addressed – and any care gap or workflow built to work around this often ends in less than desired outcome.

It’s time to look at data gaps to inform care gaps

When working through the customer journey or doing an experience map, it is vital that we use data gaps that we have to inform those care gaps rather than the other way around. Unfortunately we often come at it only from a care gap perspective leaving our IT team scrambling to identify where data gaps exist and how to fill them.

Often this results in workarounds that cause more work for providers than is needed. Instead we really should start looking at data gaps to help inform these care gaps, in fact if we look at our data gaps we can identify large gaps that we have and by solving those we would be informing care gaps about which gaps can be addressed and which are the biggest whitespace to fill.

This is where a platform comes in, platforms help you resolve data gaps quickly or at least offer a path to a solution quickly that does not require you to have to build out a team or projects with every single new identified data gap.

Do We Really Need APIs In Healthcare?

When I talk to CEOs and CIOs often the first question I get is what are APIs and followed almost immediately by why do I need them? Perhaps, as I have come to learn, the root of the question is do I really need it? I mean after all we do have HL7 so why APIs and how are they different.

WHAT IS AN API?

For clarity sake lets all get on the same page about APIs. For starters API stands for Application Programming Interface(s). Better way of thinking of APIs is to think of power sockets. Around the world as you travel you find different sockets depending on which country you are in. To use those sockets you buy an “adapter” that converts your plug, for whatever gadget you have, to that countries specified plug. This is exactly what an API does. It allows an application that has one type of socket to use an adapter (API) that then connects to the other type of socket you need to connect to.

WAIT THIS SOUNDS LIKE HL7!

In many ways HL7 is a great, sort of, API that we have in healthcare that is taken largely for granted. However it is really important to note that a lot of the challenges of HL7 are really due in part to how the software provider configured HL7 and due to the complexity of HL7 there are many deployments of it.

Before I go any further though I would like to point out that APIs have the same challenge as HL7. There is no ultimate governing body and we have to rely on developers. Yes, there is, a widely accepted specification format for displaying such as JSON however how it comes out and how it is deployed is NOT standard.

Retrospectively HL7 has more of a standard than APIs as it forces a set of guidelines for how data should be displayed and more specific how data should be displayed in healthcare.

WAIT BUT WE NEED STANDARDS

Absolutely. Maybe. Perhaps.

The answer to this question is just as tough as figuring out how to solve it. The challenge with any standard is restriction of how something flows; thus why we get specifications. However then the challenge is in how its implemented across the industry.

What I would like you to consider is that instead of focusing on standards we focus on specifications that lay a general guideline and then use the least complex method to get that data in and out.

APIS WILL SOLVE EVERYTHING THEN?

No.

The first step is to shift away from talking about “interoperability” and start talking about data liquidity. After we refocus and redefine our approach and accomplish that we can then put APIs on top to help people access the data faster and help build great experiences.

However the greatest challenge lies beyond data liquidity, the merger of the experience, consumer and the clinical workflow.