The list of billion-dollar companies turned healthcare disruptors in 2018 continues to grow. Alphabet recently joined the likes of Apple, Amazon, Berkshire Hathaway, JP Morgan Chase, and Walmart to target the largest sector of the economy. In a recent announcement, Alphabet’s subsidiary, Google, revealed initiatives in the electronic health record (EHR) space using the increasingly popular Fast Healthcare Interoperability Resource (FHIR). The team at Google AI revealed exciting progress with the release of an open-sourced FHIR-enabled protocol buffer culminating in a Nature publication on FHIR-enabled Deep Learning model for EHRs. This advancement in Health IT is commendable and provides a desperately needed shakeup in a notoriously challenging industry. Many thanks to Alvin Rajkomar MD, Eyal Oren Ph.D., Patrik Sundberg, and the rest of the team for their incredibly important work.
Now that a highly influential player like Google is involved in the FHIR ecosystem, let’s take a step back and consider the opportunities and challenges this presents to digital health initiatives and EHRs. To begin, we’ll explore the motivation behind FHIR, how it represents a promising path to interoperability, inherent obstacles, and finally our view on how Google can best facilitate the expanded use of FHIR in healthcare.
So what is FHIR?
FHIR is a framework for exchanging data electronically between health IT systems. The FHIR project started in late 2011 under the moniker “Resources for Healthcare” (RfH). The goal of RfH was to answer the question: “Given the opportunity to start over, how would we build a standard communication protocol for electronic health data?” The result was a combination of web-based authentication frameworks and object models that had already been successfully implemented in non-healthcare industries.
The development of FHIR coincided with the Meaningful Use 3 (MU3) guidelines imposed by the Centers for Medicare and Medicaid Services (CMS) in 2015. MU3 penalizes health institutions that do not give patients and their providers “API access” to health data. As a result, the majority of industry-leading electronic medical record (EMR) vendors have bolstered their data centers and incorporated web-based FHIR standards to accommodate MU3 guidelines and satisfy their customers. The envisaged result is more streamlined deployments of novel, integrated software applications to healthcare providers.
What does FHIR actually change?
While the promises of FHIR address the technological challenge, the main issues in health IT lie at the administrative and operational level. One aspect of health IT that FHIR does not solve is the continuous back-and-forth conversations required between developers at different organizations to complete an integration. This happens because each EMR implements the relatively novel FHIR standard with a slightly different flavor. Consequently, a third-party vendor cannot simply port its FHIR code from one EMR to the other.
To be fair, a capable developer can still successfully build their portion of an FHIR implementation within a couple weeks. However, the need for constant communication between developers and other idiosyncrasies related to the client’s EHR environment can drag even an FHIR implementation for months until “Go Live”. Contrast this with other software-based industries where API development and data sharing are mature. A beginner software developer can incorporate mapping capabilities, using a Google Maps API, into an application in mere hours without any additional input from Google engineers.
A Deep-dive Into Specialty Pharma
A specialty drug is a class of prescription medications used to treat complex, chronic or rare medical conditions. Although this classification was originally intended to define the treatment of rare, also termed “orphan” diseases, affecting fewer than 200,000 people in the US, more recently, specialty drugs have emerged as the cornerstone of treatment for chronic and complex diseases such as cancer, autoimmune conditions, diabetes, hepatitis C, and HIV/AIDS.
Are there really no existing data standards in healthcare?
Well established data standards have been adopted by nearly all EHRs. The most widely accepted is Health Level 7 (HL7), which allows for simple two-way communication between EHRs and third parties. HL7 is essentially a large corpus of knowledge-engineered flat files whose content differ based on clinical use case. The HL7 data standard has been developed and re-worked consistently for over 30 years. To that end, nearly every health institution and EMR has an architecture to handle it. That said, the common problems with HL7 are two-fold:
- There is no standard delivery mechanism for HL7 messages, therefore, VPN set-up, which can be prohibitively time-consuming, is often required.
- Each HL7 message may have upwards of 80 different fields that need populating, and any given message recipient may have a different way of handling each of these fields.
Both problems indicate that HL7 is not a turnkey approach to data exchange, which led to the development of FHIR.
The back-and-forth problem cannot be solved when it comes to the use of HL7 as an integration framework. No amount of upfront exchange of spec documents will prevent the inevitable discussions on exactly which values need to be present in specific fields in order to allow two systems to talk to each other. FHIR, once mature, should significantly reduce (or possibly eliminate!) these types of discussions as it uses a web-based object model. It is not out of the question to expect that, for simple use cases, health IT deployments could move towards the Google Maps API example mentioned above.
How to really put the “F” in FHIR
Faster integrations and re-usable technology reduce costs for all parties, allow nimble startups to innovate, and will hopefully solve one of the most important, yet least discussed needs in healthcare – the amount of time physicians are spending on documentation. One study showed that despite physicians spending up to 50 percent of their time documenting in EHRs, there is no consensus on its effect on patient outcomes. This increase in clerical work has contributed to burnout and a high suicide rate among physicians leading to an overall decrease in quality of care.
While FHIR is by no means a silver bullet, it can play a significant role in improving workflows and data quality with its read/write capabilities. We believe Google is in a position to not only utilize FHIR but to expand and improve it. With their technical expertise and scale, Google can work to facilitate the adoption of comprehensive FHIR standards at the EHR level. We hope that instead of just data mining, Google will start working with HL7 International to expand FHIR in an effort to leverage the promising impact of machine learning in healthcare.
Photo: goir, Getty Images
