Traditional RESTful APIs Will Not Solve Healthcare’s Biggest Interoperability Problems

Traditional RESTful APIs Will Not Solve Healthcare's Biggest Interoperability Problems
Brian Platz, Co-CEO and Co-Chairman of Fluree

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.


CIO: 3 Rules for Meeting ONC/CMS Interoperability, While Improving Cybersecurity

Healthcare data security has been a growing concern for CIOs for the last year or so, as hackers are increasingly targeting health information. Now, with a global pandemic forcing a shift to telemedicine and remote work, and new rules from the ONC and CMS introducing more regulatory burden, healthcare CIOs have more to manage than ever. Fortunately, it is possible to roll out new capabilities while simultaneously improving cybersecurity by following these three rules:

Rule 1: Think Like an Attacker

The coronavirus pandemic has forced healthcare providers everywhere to roll out new capabilities, processes, and workflows, such as telemedicine systems and new patient check-in procedures. These measures are being taken in addition to the necessary work being done to comply with the new mandates from ONC and CMS regarding patient data accessibility. Though these changes need to be implemented quickly, it’s important to follow cybersecurity best practices to avoid providing new openings for attackers. 

When a hacker sees new systems and processes being implemented, they are thinking about:

– What software is being introduced? Are there known vulnerabilities or frequently unpatched exploits associated with it?

– How are new endpoints being added and are they secure?

– Since the new ONC and CMS rules require publicly exposed FHIR APIs, how can those be attacked? Are there social engineering exploits that can provide a way around security?

– Are there ways to perpetrate identity fraud if a patient does not need to be physically present to receive healthcare?

This approach should lead to a cybersecurity plan that puts measures in place for each identified risk. By thinking like the adversary, it is possible to identify and lock down the possible attack vectors. 

Rule 2: Minimize the Attack Surface

Every way into an organization’s network needs to be secured, monitored, and maintained. The best way to make this process as efficient and fool-proof as possible is to minimize the number of ways into the network. 

This is especially difficult in light of the ONC and CMS rules, which require that clinical systems must share data through publicly available FHIR APIs. At first, this seems like a mandate to radically expand the organization’s attack surface. Indeed, this is precisely what happens if the straightforward approach of exposing every clinical system through public APIs is followed. 

A different approach, which provides the same capabilities and compliance with the rules, would be to route all API traffic through a central hub. Attaching all the clinical systems to a single point of API access provides a number of benefits:

– Most importantly, compliance is achieved while minimizing the new attack vectors.

– All traffic between clinical systems and the outside world can be monitored from a single place.

– The API hub can act as a façade that makes legacy systems compliant with the new rules, even if those systems lack native FHIR API capabilities.

The API hub need not be an expensive new component of the network architecture. Most healthcare organizations are already using a clinical integration engine to move HL7, XML, and DICOM traffic among their internal systems. The same technology can serve as an API hub. This is especially effective if a new instance of the integration engine is placed in an isolated part of the network without full access to other systems. 

Rule 3: Have an Expert Review the Defenses

Even for healthcare organizations with cybersecurity experts on staff, it can be worthwhile to bring in a cybersecurity consultant to cross-check new implementations. Novel threats are constantly shifting and emerging, making it nearly impossible for internal IT staff to keep up with the looming threats of ransomware hacks, while also adequately carrying out the day-to-day responsibilities of their jobs. For that reason, it makes sense to bring in a professional who focuses exclusively on security. It is also often useful to have an independent review from someone who is looking at the implementation from an outsider’s perspective. Independent consultants can provide the necessary guidance, risk assessments, and other security support, to set healthcare organizations up for success and operate more securely. 

Expanding an organization’s IT capabilities often means more exposure to risk, especially when implementations are subject to time constraints. However, given the value and importance of the data that’s being generated, transmitted, and stored, it is imperative not to let cybersecurity fall out of focus. By following best practices around design, implementation, and testing healthcare organizations can rise to meet the current challenges of the pandemic, address the mandates of the interoperability rules, and simultaneously improve data security measures. 


About Scott Galbari, Chief Technology Officer

As Chief Technology Officer for Lyniate, Scott leads the development and delivery of all products and services. Scott has been in the healthcare IT domain for the past twenty years and has experience in developing and delivering imaging, workflow, nursing, interoperability, and patient flow solutions to customers in all geographies. He was most recently the General Manager for multiple businesses within McKesson and Change Healthcare and started his career as a software developer.

About Drew Ivan, Chief Product & Strategy Officer

Drew’s focus is on how to operationalize and productize integration technologies, patterns, and best practices. His experience includes over 20 years in health IT, working with a wide spectrum of customers, including public HIEs, IDNs, payers, life sciences companies, and software vendors, with the goal of improving outcomes and reducing costs by aggregating and analyzing clinical, claims, and cost data.


Regence, MultiCare Health System to Deploy HL7 Da Vinci Member Attribution List for Value-Based Care Arrangements

Regence, MultiCare Health System to Deploy HL7 Da Vinci Member Attribution List for Value-Based Care Arrangements

What You Should Know:

– Regence and MultiCare ink first-in-the-nation value-based
care partnership to deliver improved health outcomes at lower costs.


Health insurance provider Regence
and MultiCare Health System,
an independent accountable
care organization (ACO)
have partnered to deploy a first-in-the-nation value-based model
that delivers better health outcomes to members at lower costs while
simplifying administration for health care providers. Regence serves
approximately 3.1 million members through Regence BlueShield of Idaho, Regence
BlueCross BlueShield of Oregon, Regence BlueCross BlueShield of Utah and
Regence BlueShield (select counties in Washington). The new approach between
Regence and MultiCare Connected Care—the Accountable Care Organization that is
a wholly owned subsidiary of MultiCare Health System—marks a milestone in the
evolution of value-based partnerships between insurance payers and providers.

Da Vinci Member Attribution List Standard for Value-Based
Arrangements

The partnership will leverage utilized a soon to be
published HL7® FHIR® (Fast Healthcare Interoperability Resources) Standard
“Da Vinci Member Attribution List” which was developed by the HL7® Da Vinci Project for
value-based arrangements.  This national standard provides an
interoperable method to share member attribution data assisting in reducing the
burden on provider organizations managing patient data and allowing providers
to spend more time with patients. The Regence and MultiCare partnership establish
a foundation for the development of future population data interoperability
applications, such as the exchange of data for measuring care quality and
outcomes.

Why It Matters

Value-based arrangements result in improved outcomes, lower
costs and fewer care gaps for health plan members, and higher patient and
provider satisfaction. Providers are eligible to earn financial incentives by
meeting established targets for patient outcomes, costs and satisfaction
scores.

By creating efficiencies and security in delivering patient data to providers more frequently, it allows provider organizations to spend less time acquiring the data and more time with the patient.” said Melanie Matthews, president of MultiCare Connected Care. “It frees up providers to do the work of population health and helps us embrace our mission of partnering for a healing and healthy future.”

Microsoft Deploys COVID-19 Vaccine Management Platform

Microsoft Deploys COVID-19 Vaccine Management Platform

What You Should Know:

– Microsoft launches a COVID-19 vaccine management platform with partners Accenture and Avanade, EY, and Mazik Global to help government and healthcare customers provide fair and equitable vaccine distribution, administration, and monitoring of vaccine delivery. 

– Microsoft Consulting Services (MCS) has deployed
over 230 emergency COVID-19 response missions globally since the pandemic began
in March, including recent engagements to ensure the equitable, secure and
efficient distribution of the COVID-19 vaccine.


With COVID-19 vaccines soon to be available, Microsoft
announced it has launched a COVID-19 vaccine management platform together with
industry partners Accenture, Avandae, EY, and Mazik Global. The COVID-19
vaccine management solutions will enable registration capabilities for patients
and providers, phased scheduling for vaccinations, streamlined reporting, and
management dashboarding with analytics and forecasting.

These offerings are helping public health agencies and
healthcare providers to deliver the COVID-19 vaccine to individuals in an
efficient, equitable and safe manner. The underlying technologies and approach
have been tested and deployed with prior COVID-19 use cases, including contact
tracing, COVID-19 testing, and return to work and return to school programs.

To date, Microsoft
Consulting Services (MCS)
 has deployed over 230 emergency COVID-19
response missions globally since the pandemic began in March, including recent
engagements to ensure the equitable, secure and efficient distribution of the
COVID-19 vaccine. MCS has developed an offering, the Vaccination Registration
and Administration Solution (VRAS), which advances the capabilities of their
COVID-19 solution portfolio and enables compliant administration of resident
assessment, registration and phased scheduling for vaccine distribution. 

Key features of the solutions include:

– tracking and reporting of immunization progress through
secure data exchange that utilizes industry standards, such as Health Level
Seven (HL7), Fast Healthcare Interoperability Resources (FHIR) and open APIs.

– health providers and pharmacies can monitor and report on
the effectiveness of specific vaccine batches, and health administrators can
easily summarize the achievement of vaccine deployment goals in large
population groups

Partnership Offerings

Microsoft partners have leveraged the Microsoft cloud to
provide customers with additional offerings to support vaccine management.
These offerings also apply APIs, HL7 and FHIR to enable interoperability and
integration with existing systems of record, artificial intelligence to
generate accurate and geo-specific predictive analytics, and secure
communications using Microsoft Teams.

EY has partnered with Microsoft for the EY Vaccine
Management Solution to enable patient-provider engagement, supply chain
visibility, and Internet of Things (IoT) real-time monitoring of the vaccines.
Additionally, the EY Vaccine Analytics Solution is an integrated COVID-19 data
and analytics tool supporting stakeholders in understanding population and
geography-specific vaccine uptake.

Mazik Global has created the MazikCare Vaccine Flow that is built on Power Apps and utilizes
pre-built templates to implement scalable solutions to accelerate the mass
distribution of the COVID-19 vaccine. Providers will be able to seek out
specific populations based on at-risk criteria to prioritize distribution.
Patients can self-monitor and have peace of mind to head-off adverse reactions.

Redox Adds Data on Demand, Single Sign-On Access to Interoperability Platform

Redox Launches Rapid Deployment Telehealth Model for Providers to Go-Live in Less Than 2 Weeks

What You Should Know:

– Redox adds data on demand and single sign-on access
features to its cloud interoperability platform to help to simplify the process
of developing software for healthcare.

– Both new features are now available to all customers on
the Redox platform.

Redox
Inc.
, a Madison, WI-based interoperability platform for healthcare data
exchange, unveiled Data on Demand, which enables software developers to query
any electronic health
record (EHR)
or healthcare data source via the Redox API. Powered by a
FHIR-conformant data storage architecture, Data on Demand is pre-built
integration infrastructure designed to simplify and normalize the integration
experience and reduce the technical burden of consuming hundreds or thousands
of messages per day. In addition, the company has added Single Sign-on that allows applications using Redox to make
it easier for providers to launch their products from within their EHR in an
efficient manner. Both features are available to all customers on the Redox
platform. 

Data on Demand and Single Sign-on Simplify the Process of
Developing Software

Redox continues to expand the integration capabilities
healthcare software developers can access through a single API with these new
features:

Data on Demand converts traditional HL7 feeds into a
data store that application developers can query on demand. This provides a
consistent integration experience that works with both the push- and API-based
integrations provided by EHR companies. Regardless of how data is provided by
the EHR, Redox customers can more easily manage the volume of messages and
logic needed to update information, allowing them to focus on getting the data
that they want, when they want it. No other integration vendor can turn HL7
feeds into reusable queries.

Single Sign-On (SSO) allows customers to improve the
provider’s experience with their products by sharing login credentials and
pertinent patient or visit context along with patient data that they’ve
collected. This allows applications on the Redox network to securely connect to
other applications and share the login context for a user. Customers trust Redox
to verify that the SSO request is valid, and Redox normalizes and pulls the
information to launch the application.

“Redox continues to develop the robust integration
capabilities software developers need to navigate the fragmented world of data
exchange and interoperability in healthcare,” said Niko Skievaski, co-founder
and president, Redox. “The Redox API is transforming the way healthcare
organizations access and share data. Our company’s ultimate goal is to enable
the frictionless adoption of technology in healthcare, and we’re making great
strides as the interoperability standard and one-stop-shop for our customers.”