Interoperability : a problem or a solution in healthcare? Maybe it’s both
Complicated but necessary, interoperability is one of the biggest issues facing the industry today.
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.
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.
But who really owns your record?
Maybe you have thought about this or maybe you have not. However, another challenge here is ownership of your medical record — have you ever really stopped to ask yourself who owns your patient data?
According to the graphic above, you can see by state who actually owns patient records. As it stands today, technically, the only state where you own your record is New Hampshire!
If we’re going to make interoperability work, we also must put the patient in the center and allow the patient to be the center of sharing and caring for that information. This has been an ongoing challenge that many have tried to solve — including Google and Microsoft. Unfortunately, it’s also not an easy problem to solve and one of the bigger drivers is that we as consumers aren’t asking for this — yet.
You might be wondering how this is relevant to interoperability. To put it very simply, if you don’t have control of over your record, how can you help make the change? Demand creates change, and in order to create demand we must have some sort of ownership over what it is we are demanding.
The future of interoperability
Healthcare may still be struggling when it comes to resolving interoperability; however, the industry is at least having way more discussions about the topic. Taking into consideration population health, the push to develop a greater patient experience, health systems and the industry as a whole, it’s clear we’ll have to start looking at more ways to solve this issue.
The biggest advice I can leave you with is to play an active role in your own health by keeping a copy of your own health records. And ask questions; ask for more information from your provider.
There is a lot of change coming with the advent of perhaps replacing Obamacare and also what the industry decides to do as a whole to meet population health demands.
I believe interoperability is here — just not perhaps in the way that we are expecting it. We can in fact share records, we can transfer records, we canalso push and pull records — what we can’t do is keep them in sync, we can’t build anything on top of it, the data is sometimes good quality and sometimes not so good quality, sometimes the data is free form and sometimes its not.
So perhaps we are asking the wrong questions to solve the right answer. I call it data liquidity — in order to have data flow freely we must have data liquidity.
The driving force of data liquidity becomes demand, today the reality is most demand isn’t coming in yet, or perhaps not enough to make this a big focus, but it is coming, and when it comes then it will be solved.
The question that remains is: Will we make the challenge of interoperability more complex, or will we simplify it and are we asking the right question?