Why Your Health System Won't Share Your Data
/
Application Programming Interfaces (APIs) to move data between systems have been around for nearly 20 years. A small engineering team can build even the most complex interfaces in days, and every tech-enabled company relies on thousands of them for internal and external system communication every second. However, in healthcare, we liken this concept to curing cancer with regard to complexity. We need to get out of this bubble. Interoperability and data integration is not a hard problem to solve - it has been solved millions of times over in other industries. The challenge, instead, is developing a persuasive business case that doesn’t harm the competitive advantage of providers.
Incumbents Lose When Sharing Data
Traditional fee-for-service health systems justifiably are concerned about sharing their patient data. While they will often indicate security as their primary concern (which it should be), the real elephant in the room is that interoperability will lead to significant revenue loss and cost incursion. Concentrating your health information within a provider system creates “stickiness” in that you will prefer to receive your treatment within the network. Additionally, investing in these programs to open up data access can be incredibly expensive. Asking health systems to share data is like asking you to pay me money to kick you in the face. It just doesn’t make sense.
Increasing public pressure has led some systems to open up slivers of their data assets for sharing with external parties, but these efforts have primarily been for show. Instead, what is far more common is the need for providers to fax paper copies of small pieces of your health record to other care facilities following days (weeks? months? years?) of bureaucratic nonsense. Providers are basically saying “we are happy to share information, if you are willing to fight us for it.”
With that said, if I was running one of these fee-for-service providers, I would be doing exactly the same thing. This is freely admitting to putting profits above patients, but these are businesses that die without the proper figures on the bottom line. In an industry that rewards patient and service volume over management of patient health, data sharing is a nonstarter - it will not happen without overarching government mandates (which are unlikely to occur due to the massive provider lobby).
But there is a solution …
The Business Model for Interoperability
The business model of delivering healthcare in the US is broken - as I alluded to in other posts (Hospitals Kill, Physician Burnout). But, we can fix this by moving to a model that rewards caregivers for keeping populations healthy rather than just treating them when they are sick. Yup, I am talking about value-based care, and primarily global capitation models. When systems make money when their patients stay out of the hospital or keep their blood pressure low, they are far more likely to share data with other systems that can support that mission.
In a value-based business, if I am a health system that charges astronomical prices for treatment to cover my massive fixed costs, then I certainly want you to go somewhere else to be treated for those non-complex cases (assuming parity of quality). By sharing your data with these other entities, I am removing the “stickiness” factor mentioned above while also ensuring better quality care at the treating facility. Both your interests as a patient, and my interests as a business are aligned.
The Tech Behind Interoperability
Every time I hear about the release of another standard or another committee investigating a new standard, I lose another clump of hair (mainly because I am ripping it out). Ask my friends, I am undoubtedly balder than a few years ago. We have standards already; and, while none are perfect, they are good enough for our purposes. No standard is fully comprehensive or applicable to every use case, but let’s stop letting perfect be the enemy of good.
The process of integrating information across systems (EHRs, Claims Systems, etc.), is fairly straightforward:
Source (Provider) Builds APIs: The provider builds APIs into its data architecture that enables authorized third parties to access that information. While this seems arduous now, it likely becomes a non-issue in the long term. If providers demand these features, tech vendors will build them into their products and minimal lift will be required from the provider.
Builds the Pipes: Similar to #1, this is the development of APIs for reading data from other sources. Also similar to #1, tech vendors will build these into their tools automatically should providers demand them.
Data / Concept Mapping: Data is mapped from its structure in the data architecture of source system 1 into a chosen standard. In today’s HL7 world where every provider uses the segments differently, this would be a huge pain in the rear. That is because HL7 is a guideline - it is in no way a comprehensive standard (as compared to FHIR). With a FHIR back-end, the mapping of concepts becomes much more straightforward, albeit tedious. (FHIR is just an example, but one of the best in existence today)
Patient Matching: When sharing information, we want to be sure that Person A at one provider is the same as Person B at another. I will freely admit that this is a challenging problem, but there has been so much published on this concept that errors are becoming much less frequent (The Sequoia Project).
Use the Data: Once data is in stored in a common format, you can literally do whatever you want with it. It really is that easy.
As mentioned above, once providers demonstrate a true willingness to pay for interoperability, technology vendors will build these features directly into their products. But, because the willingness to pay is currently minimal, it does not make business sense for these features to be developed. As patients, we can help encourage this shift to value-based care by choosing physicians that operate within these VBC business models more often. It needs to become fiscally difficult for incumbents to avoid switching to this system. Then, and only then, will data interoperability be possible.
