Finally, healthcare is ready for apps.
Until now, apps for both patients and providers have been held back by a lack of a “common language” for connecting with electronic health record (EHR) systems. That has changed with the arrival of FHIR (Fast Healthcare Interoperability Resources), the new standard that defines how EHRs can share data with outside apps. FHIR is expected to go live in health systems across the U.S. in 2017.
FHIR, which stands for Fast Healthcare Interoperability Resources, is part of the Health Level 7 (HL7) ANSI standard for electronic health information exchange.
FHIR provides a way for healthcare apps to communicate with EHRs using a format (RESTful webservices) that is already widely understood and used in the web-application industry.
With FHIR, developers can create apps for patients to manage their prescriptions, or for medical providers to monitor test results for their patients. FHIR provides a standard way of delivering these kinds of medical records to an app without developers needing to worry about the specific format a given EHR uses for its data, because the data is sent the same way regardless of the EHR.
FHIR enables apps to have access to a richer set of health data, while saving the cost and effort of developers having to write code for every different health system. This means better access to medical data for both providers and patients, as well as improved secure sharing of health records between healthcare providers.
FHIR provides access to a rich set of patient information – but it depends on the EHR
FHIR supports many dozens of types of patient and health data, ranging from broad information, like patient demographic data and previously assessed conditions, to more detailed information like individual diagnostic results and medication orders.
While FHIR provides the “bucket” for these types of data to go into for an app to use, it is ultimately the job of the EHR to actually fill those buckets with the actual patient data. The important question, then, is: “Out of all of the types of medical records that FHIR supports, what records will my EHR actually provide through its FHIR solution?”
Epic, one of the largest EHR providers, has promised significant FHIR support – although its early preview comes with some limitations. According to the Open Epic website, Epic’s integration works with version 2 of FHIR (called “DSTU2”). Of the DSTU2 specification, Epic supports retrieving data for most of the top-level records like “patient”, “observation”, “procedure”, “medication”, etc. Epic does not yet officially support uploading data back to the EHR through FHIR, although that is normally a standard feature of FHIR.
A few types of data, like “schedule” and “appointment” records, are only supported in Epic’s testing environments for now. Other less-common types of data, like a “nutrition order,” do not appear to be supported at all.
Those interested in learning what data is actually supported with a particular EHR’s FHIR integration can look at the actual FHIR specification and compare that to what is supported by the EHR, e.g. at the Open Epic FHIR standard support page.
(Another approach for comparing specifications is called Crucible, an interesting tool which shows the real-time coverage of the FHIR specification for various EHRs.)
The bottom line for creators of FHIR-ready apps, then, is that not all EHRs – or their FHIR integrations – are created equally. App makers will need to check with their EHR providers to determine exactly what data that specific EHR will make available through FHIR.
A “SMART” platform for running apps within the EHR
While the point of FHIR is to allow apps to access medical data from outside the EHR, medical providers will typically want to launch the app from inside the EHR, which is their software starting point while providing medical care. So, how can providers access these external FHIR-ready apps from within their EHR (and how can they avoid having to log into multiple services?)e
Harvard’s SMART app platform (Substitutable Medical Apps, Reusable Technologies) dovetails with FHIR to define standards for how 3rd-party apps should work from within an EHR, such as how an app may be launched, how to know which EHR user is interacting with the app, and which patient’s data should be loaded.
Used together, the solution has come to be known as SMART on FHIR.
Getting SMART on FHIR into gear by 2017
Federal regulators have accelerated the adoption of SMART on FHIR by setting a deadline: the HITECH Act’s “meaningful use” program gives incentives to EHR vendors and healthcare providers to adopt SMART on FHIR by 2017, to “enable the development of new functionalities to build bridges across systems and provide increased data access.”
Motivated by the 2017 deadline, leading healthcare organizations and EHR vendors formed a group called the Healthcare Services Platform Consortium (HSPC) to continue the momentum of the SMART and FHIR standards. HSPC offers development tools based on SMART on FHIR. The group plans to create an open marketplace featuring the industry’s first vendor-neutral Healthcare App Store.
The SMART on FHIR standards and HSPC developer tools reduce the costs and risks of developing healthcare apps, while the HSPC App Store is poised to serve as a central marketplace that will allow innovative apps to be distributed to healthcare providers using any EHR.
Together, these new standards promise exciting benefits to the healthcare ecosystem.
For more details and background:
- The U.S. Office of the National Coordinator for Health Information Technology’s (ONC) Office of Science & Technology (OST) Health Information Exchange group (HIE) is the regulatory agency responsible for translating Stage 2 Meaningful Use data exchange requirements into specific interoperability standards.
- Centers for Medicare and Medicaid Services (CMS) EHR Incentive Programs