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! 

Interoperability — a problem or a solution in healthcare? Maybe it’s both

Imagine that you, your doctor, your data and the clinic’s software are all connected and communicating in perfect harmony. That’s interoperability at its best. But interoperability is complicated. While it has the ability to streamline healthcare when functioning correctly, it remains one of the industry’s biggest hurdles to overcome. I’ll try to explain why.

What it is

If we want to get technical, however, interoperability is defined as “the ability of computer systems or software to exchange and make use of information.” There are two important parts here — 1) to exchange, and 2) to make use of.

Let’s look at the exchange part first. The issue of data exchanges is so paramount in certain industries, including healthcare, that there are actually boards and foundations created and dedicated fully to matters surrounding it, including the upholding of standards. But what’s fascinating about healthcare is that in this industry a consensus has yet to be reached regarding what those standards should be — and the standards that do exist can be left for interpretation of what can be implemented.

Why this matters to you

Let me put it in a way we can all relate to. Let’s say you get sick (hopefully that doesn’t happen to you) and have to go to the doctor. You fill out a lot of paperwork, then spend time in a room with the doctor and probably a computer, where he or she documents everything. And you don’t get a copy of any of the information, it just goes somewhere. Next, maybe you need to see a specialist as a follow-up to this visit. This second doctor asks you to fill out all the same information and report everything that happened at your last doctor’s appointment. So either you have to try to remember all the details, or perhaps they call your first doctor to get the information, which can take time.

Can you imagine if this were how ATMs worked? It would look something like this: You go to your bank and make a deposit. Then you go to an ATM to get money and it asks you to sign up for a bank account. Then a representative has to call your other bank to get verification before you can get your hands on your money — and you can consider yourself lucky if they can do it on the spot. Can you imagine doing this for every single ATM transaction?

Parents with chronically sick children have figured out the workaround to this. Maybe you’ve seen or even been one of those parents who resolves to carrying around a binder containing their child’s medical information. They’re trying to keep all the records organized and at the ready, so they can share them with doctors at a moment’s notice. How did it come to this? To answer that question, we must first look back.

The first medical records

In the beginning, there were manila folders. (Ah, the age before computers …) In some ways, that system was simpler than what we have today, but in other ways, it’s far more complicated, insecure, unsearchable and unusable.

Prior to 1900, there were actually no medical standards for keeping records about patients. And with the rise of hospitals and medical education in the second half of the 19th century, we began seeing official medical records as hospitals started keeping ledgers. By 1960 or so, computers were playing a role in the medical field, standardizing the storing and sharing of medical records.

What really changed things was U.S. Congress’ new Health Insurance Portability and Accountability Act (HIPAA) (1996), which required standards for electronic medical records (well, sort of). And of course, no one can forget Obamacare, which launched in 2010 and introduced new reporting requirements.

Great, so we have standards now, right? Well, not exactly. You see, those laws aren’t about standards, they’re about reporting.

The challenges

So we transitioned from manila folders to software. But all the software did was make the folders and information inside them electronic. I don’t want to downplay the value of these systems, however, the simple fact is that today that software is all about recording, reporting and billing. The next challenge will be to ensure the information is input in a way that is totally standardized and reliable.

That challenge involves more than just elements related to human error, including:

Software innovation: When you make a product you ultimately need to create a competitive edge; the way that was done 50 years ago is different than the way we would like to see it done today. It used to be OK to create things that ultimately created “black boxes” of sorts. Now I won’t say that was the intention of the software makers, just the time in history — after all, you were often the only player or one of a few players. However, today we are all about a sharing economy and working with each other — think Airbnb, Uber and Postmates.

Standards: There has been no adoption of any single standard — and most standards have variations in them and are left for interpretation of the user to do it as they see fit — the farthest and most standard two that are used and have consistency are HL7 and CCDA — unfortunately it requires more work than a simple login to get your records and each vendor has to integrate each interface (the way data is sent) separately.

No driving force: Unfortunately, the only driving force behind standardization today is the need to report information to the government which is used for cost efficiency and payments as well as in today’s world Population Health.

Consumers: We, as consumers, have yet to push the industry, mostly because we’re barely involved in our own health. This needs to change and is arguably the largest area of improvement we need to make.

Regulation: The regulations that have been put in place for information standardization include a “pass/fail” check when a software vendor is making the product — but no one follows up on the product during implementation. This often results in cases in which software is implemented at a hospital and it can pass the standards check, yet the functionality of it is not effective outside the four walls — for instance ask your doctor next time to send a “direct message” to another email, most have no idea how to do it or if their software can do it. Another area we need to focus on is ownership — more on this later in the article.

Time: Standards such as HL7 often require that a team work together to map that data. So imagine having five people multiplied by 100 applications to connect — you would need 500 people to pull this off. And since that isn’t realistic, these projects take time and run in a waterfall effect (meaning one after the other).

The evolution of solutions

There have been many solutions proposed to address this issue and all of them have succeeded in some ways and yet also failed to make a greater impact. The good news is, we need these trials and errors in order to discover what works for healthcare. Some of the more well-known solutions are:

Direct: A protocol that allows the exchange of “secure” information. Think of it like encrypted email with a file in it that’s in a standard format (although, again, “standard” here is left for interpretation). The idea is that the direct message sends a CCDA.

CCDA: A file format that has to have a particular structure, and usually does, however each interface can have some things that are non standard or inconsistent depending on what each vendor sends in the CCDA.

HIE: A health information exchange into which data is added and then transformed so that it’s uniform; an HIA is used to share data across a particular population or given region.

FHIR: A protocol that wraps an existing standard (right now that’s HL7 ) into a more modern standard REST API so that developers can build applications that help you access and use your data. FHIR has the potential to solve at least the data sharing and access for patients — however there is a question of ownership (see Ownership later in article) AND the fact that a machine technically can’t access your records according to laws.

Interfaces: There are standard interfaces like ADT, CCDA and HL7 that can share data, however, each feed again is unique, is time-consuming to connect and is left for interpretation.

We’re sharing data!

Now all this being said, I want to make sure everyone understands we’re actually sharing data, quite a bit actually. In fact, Epic — one of the world’s largest EMR software providers — is often blamed with not being able to share data or work well with others and yet Epic shares a lot of data and even displays it on their website loud and clear for everyone to see.

There are also many efforts to put together a common HIE and other data repositories . Some companies’ visions for this are about a shared society of information and others are about a common HIE being the single source of truth.

What does all of this mean?

Times change but we haven’t changed the way things work — this is why I argue it’s not about disruption, it’s about transformation. Just like we invest in personal growth, so must industries invest in the growth of their companies. What got us here in healthcare will not get us to the next step in healthcare and to get there we must create a more unified way of sharing information that is fast, secure and reliable.

In my view, the answer to this will require multiple different forces to work together in order to move this forward and make a change:

Vendors/Developers: First, vendors of products in healthcare must start working with new standards and adopting new technologies to integrate and work with data rather than conforming to the old ways of working.

Government: The government must set guidelines to help companies ensure they reach this goal, for instance, with Meaningful Use 2 we saw the requirement for APIs, which is a more modern way to connect data.

Health Systems: Rather than focusing on making sure just reporting gets done, it’s our job in healthcare to work to start pushing innovation and building systems that are built to scale for the new healthcare era.

Consumers: We play a big role here — we need to ask questions, ask for our data and be more involved in our health. They can’t ignore us, as we are ultimately the end user.

Agreement: What I mean by this is that we don’t all agree on words, for instance if you ask someone what population health means or interoperability means you will get different answers. If you were to ask a bank what it means to transfer funds every single one would have the same answer.

The last hurdle: the product life cycle

All right, so say we figure all of this out — we can just launch it, right? Well, kind of.

Unfortunately, most companies have a long product life cycle, which means that we could see it take 1 year just to get developed and another 2 to 3 years before all their clients are on the particular version that allows for this.

This then puts pressure on vendors to reduce their product life cycle and provide more frequent updates. Compare that to Facebook, Google or Uber and that number shrinks to every 2 weeks on average.

A word on the next evolution of Obamacare

I won’t get into all the specifics here — there’s only one thing I want to highlight: If/when and how Obamacare gets replaced, there are a few things we can count on that are positive impacts on our society, which is that almost all the bills I’ve read have a few positive similarities.

State borders: They would like to see that your medical coverage is not tied to a state or employer but rather tied to you (this is how it works in Germany as well). Your insurance can stay with you and be “portable.”

High deductible plans: We’ll continue to see the use of this and this means we have to be more careful of what we do and how we spend.

Now why are these two relevant? For starters, if we start removing state borders then we also must allow data sharing to work much better, faster and more instant, or at least allow the patient to be the center of care.

The second part about high deductible plans is also vital as it means we need to — as consumers — get more involved in our health, which will drive care and lower costs for both us and the system.