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.
