Saturday, November 26, 2016

Will FHIR save the day for healthcare data integration?

Can FHIR (Fast Healthcare Interoperability Resources) integration standards help us improve healthcare? Here are some questions that can inform your answer:
1.) Is external unfettered access to data in healthcare applications of value?
2.) Is it helpful to be able to integrate applications and harvest data faster than before?
3.) Does a published standard for data resources, messaging, data access, and standards-based application development enable better and faster solutions to problems?

Unfettered Access

Getting to data inside an EHR or other healthcare application today is a burdensome lift.  If we want to, for example, gather up data from a clinically integrated network on diabetic patients having an appointment in the last six months along with evidence of their blood sugar being in control, then we have three daunting choices:
1.) manually audit charts across a dozen or so EHRs in our network.
2.) get some sort of paper or electronic report from each EHR, if possible.
3.) pay in much time and money for custom integration or add-on packages from multiple vendors.

What we need is for all of that burden to vanish. I know what you're thinking though. Why not get everybody on the same EHR system? I'm ignoring your question because its like asking why democracy can't work faster.

That aside, the FHIR standard may tear this burden to shreds and vastly improve our ability to get to data with these features:
a) Access to FHIR "compliant" vendor systems are driven by a common understanding of data fields and resources thereby reducing the challenge of proprietary vendor databases and applications.  The vendors expose some or all of their resources (data fields, records, documents, etc) using common standards and terms that are accessible via web-programming languages.
b) Since there are published standards and a vast growing body of knowledge, both the development and the customer community are amassing an emerging economy in the FHIR solutions market that may beget increasing "compliance" by major EHR vendors. I put "compliance" in quotes because FHIR is not a mandate, it is an open-source revolution.  For evidence of the growth of this economic organism, I point you to:
CA Healthcare
Cerner
EPIC
SMART on FHIR
and a few more with varying levels of currency

Faster, better than before

When speaking about faster, I need to remind you about how much time it takes to integrate in healthcare today. It goes something like this:
Day 1: We want to get at some data.
Day 30: We have a quote back from one or more proprietary system vendor(s).
Day 45: (aggressive timeline), the purchase orders are signed.
Day 45 in some cases: we can't get to the data. Sorry.
Day 90 to 190 or so: (aggressive timeline), we have access to the data on an ongoing basis. Please submit purchase order if you want something changed.

In a world where we have a system or systems that published their FHIR-based resources, the timeline goes more like this, assuming you've already hired or aligned with an integrator who understands RESTful web-based standards (also see Fielding) and is at least oriented to healthcare application concepts:

Day 1: We want to get at some data.
Day 15: Confirmation of requirements and specifications.
Day 30: Testing and piloting
Day 45: Potential go-live

This is somewhat of an over-simplification, but what is most important about this interaction is that it removes the frustrating barriers encountered today that include:

1.) Data-blocking or delaying via cost barriers
2.) Outright data-blocking via proprietary design
3.) Vendor lock-in
4.) Lack of skilled resources due to proprietary design

Published standards and practices

The beauty of FHIR is that it allows for a body of documentation and cross-platform toolkits that can be used and applied by all kinds of smart and industrious application and integration developers. This eases the path to integration and faster application development by healthcare organizations because:

a.) There are published standards the FHIR-compliant vendors follow so that others can develop integrated applications with the vendors exposed elements.
b.) FHIR uses industry standard web-based practices that will make it easier to find cross-industry professionals who can develop and support products and solutions.  For an example of how this "liberates" the development environment, see the app gallery of the SMART platform.
c.) Various segments of the web-application industry can further develop and improve upon toolkits.  For example, see the HAPI FHIR community for Java developers and the FHIRbase community for cloud-based healthcare data storage.

What this should mean is that access to capable resources will improve for healthcare and that building an integrated application infrastructure should be quicker and less costly. As a personal side note, I can't tell you how much easier it would be to recruit for developers and integrators who can grow in a standards-based developer career as opposed to being shoe-horned into a proprietary application development paradigm that is so prevalent in the healthcare industry. Where do they go from there and why would they want to lock into such a shoebox?

So, Is everybody on board?

The short answer is, "No." Not everybody is on board.  Although Cerner has been at the forefront of the FHIR movement and EPIC is also making a play, other vendors are not as fast or publicly deep into it. Does this matter in a world where EPIC and Cerner might be writing the ticket for most of the market? This is another big question for another time.
You can find a bit more caution about this topic at http://thehealthcareblog.com/blog/2016/01/20/fhir-the-last-best-chance-to-achieve-interoperability/ , and one of the blog's links to Pallav Sharda's comment that the "restless, free-spirit" individuals at the heart of FHIR won't be able to organize as fast as the industry will with a different approach.  For example, Athenahealth has a published API (Application programming interface) that also uses web-based programming standards and reference documents but it is not adhering to all the FHIR documentation nor does it claim to.

So, maybe I've answered the questions from the top of this page. Will FHIR help us? You tell me.