Interoperability is a big discussion in health care, with new regulations requiring interoperability for patient data. Most approaches follow the typical RESTful API approach that has become the standard method for data exchange. Yet Health Level Seven (HL7), with its new Fast Healthcare Interoperability Resources (FHIR) standard for the electronic transfer of health data, is leading to a rash of implementations that, to date, are not solving core interoperability issues.
Data is still insecure, users can’t govern their own health records, and the need for multiple APIs for different participants with different rights (human and machine) in the network is adding unneeded expenditures to an already burdened healthcare system. The way out is not to add more middleware, but to upgrade the basic tools of interoperability in a way that finally brings healthcare technology into the 21st century.
A Timely Policy
Doctors, hospitals, pharmacists, insurance providers, outpatient treatment centers, labs and billing companies are just a few of the parties that comprise the overcomplicated U.S. healthcare system.
In digitizing medical files, as required by the 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act, providers have adopted whatever solution was most convenient. This has led to the mess of interoperability issues that HL7 seeks to remedy with FHIR.
Existing Electronic Medical Records (EMR) systems do not easily share data. Best case, patients have to sign off to share data with two incompatible systems. Worst case, information must be turned into a physical CD or document to follow the patient between providers. Data security is also notoriously poor. Hackers prioritized the healthcare sector as their main target in 2019; breach costs exceeded $17.7 billion.
The New Infrastructure Rush
When common formats, by way of FHIR and HL7, provided standards and solutions to empower global health data interoperability, the industry erupted into a flurry of activity. Thousands of healthcare databases are now being draped in virtual construction tarps and surrounded by digital scaffolding.
Building a new, interoperable data ontology for the entire healthcare system is a massive undertaking. For one, 80% of hospital data is managed using the cryptic, machine-language HL7 Version 2. Most of the rest uses the inefficient, dated XML data format. HL7 FHIR promotes the use of more modern data syntaxes, like JSON and RDF (Turtle).
Secondly, databases have no notion of the new FHIR schema. Armies of developers must build frameworks and middleware to facilitate interoperability. This is why Big Tech incumbents including Google Cloud Healthcare, Amazon AWS and Microsoft for Healthcare are jumping into the fray with their own solutions.
The outcome, once HL7’s 22 resources are fully normative, will be seamless information sharing, electronic notifications, and collaboration between every player in the giant web of patients, providers, labs, and middlemen. But it will come at a steep cost in the current traditionally RESTful API-based manner that is being broadly pursued.
The Problem with APIs
The new scaffolding is expensive, takes data control away from patients, and is not inherently secure. The number of unique APIs required to support the access, rights and disparate user base in the healthcare network are the reason.
Interoperability requires a common syntax and “language” to enable databases to talk to each other. The average traditional API costs up to $30,000 to build, plus half that cost to manage annually. That is not to mention the cost to integrate and secure each API. A small healthcare organization with only 10 APIs faces costs of $450,000 annually for basic API services.
When you consider that most big healthcare organizations will need to connect thousands of APIs, HL7’s interoperability schema really is the best way forward. The traditional API tooling to manage the interoperability of the well-framed data structures, however, is the problem.
Moreover, the patient, the rightful owner of their own health record, still doesn’t have the ability to govern their own data. Because change only happens in the database itself, the manager of the database, not the patient, controls the data within.
In the best case, this puts an additional burden on patients to give explicit permission every time health records move between providers. In the worst case, a provider sees an entire medical history without a patient’s consent–your podiatrist seeing your psychiatric records, for example.
Finally, each API enables one data store to talk to the next, opening opportunities for bad actors to make changes to databases from the outside. The firewalls that protect databases and networks are penetrable, and user profiles are sometimes created outside of the database itself, making it possible to expose, steal and change data from outside the database.
In that light, HL7 is paving the wrong road with good intentions. But there is another way.
Semantic Standards and Blockchain to the Rescue
If you eliminate data APIs, secure interoperability, with data governance fully in the hands of the patient, becomes possible. Healthcare data silos will be replaced with a dynamic, trusted and shared data network with privacy and security directly baked in. The solution involves adding semantic standards for full interoperability, blockchain for data governance and data-centric security.
Semantic standards, such as RDF formatting and SPARQL queries, let users quickly and easily gain answers from multiple databases and other data stores at once. Relational databases, the ones currently in use in healthcare, are all formatted differently, and need API middleware to talk to one another. Accurate answers are not guaranteed. Semantic standards, on the other hand, create a common language between all databases. Instead of untangling the mismatched definitions and formatting inevitable with relational databases, doctors’ offices, for example, could easily pull in pertinent patient records, insurance coverage, and the latest research on diseases.
Patients, for their part, would use blockchain to regain control of their data. Patients would be able to turn on aspects of their data to specific caregivers, instead of relinquishing control to database business managers, as is currently the case. Your podiatrist, in other words, will not be able to see your psychiatric records unless you choose to share them.
The data ledger, which lives on the blockchain, will contain instructions as to who can update (writer new records on) the ledger, who can read it, and who can make changes. All changes are controlled by private-key encryption that is in the hands of the patient; only those with authorization can see select histories of health data (or, as in the case of an ER doctor, entire histories, with permission).
Data security is controlled in the data layer itself, instead of through middleware such as a firewall. Data can be shared without API, thanks to those semantic standards, and data are natively embedded with security in the blockchain. Compliance, governance, security and data management all become easier. Data cannot be stolen or manipulated by an outside party, the way it commonly is by healthcare hackers today.
The interoperability conundrum, in other words, is solved. Fewer APIs means fewer security vulnerabilities; a common, semantic standard eliminates confusion and minimizes mistakes. Blockchain puts patients in control of who sees what parts of their health records. Eliminating the need for API middleware also saves tens of thousands of dollars, at a minimum.
About Brian Platz
Brian is the Co-CEO and Co-Chairman of Fluree, PBC, a decentralized app platform that aims to remodel how business applications are built. Before establishing Fluree, Brian was the co-founder of SilkRoad technology which expanded to over 2,000 customers and 500 employees in 12 international offices.
