FHIR: shaping the future of health data exchange
HL7 FHIR® began with an open ended question: What would health data exchange look like if we started from scratch using modern approaches? To answer this question, HL7 turned to other industries for ideas. Recent interoperability successes pointed strongly to the use of RESTful based APIs.
HL7 FHIR combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. FHIR is based on modular components called “resources.” and these resources can be combined to solve clinical and administrative problems in a practical way. FHIR is still being developed by HL7, but the third Standard for Trial Use became available in 2017 and the first normative edition is planned for 2018.
The FHIR standard is based on the following simple five key points:
- Faster to learn and implement
- Lower cost
- Scales well from simple to complex
The impact of many of these key points will be seen throughout the following sections.
Comparison to existing standards
HL7 V2 is a well-established standard that works well within institutions to connect applications. However, it is a legacy standard with unique syntaxes, custom tools, and a hefty learning curve for those entering the healthcare IT industry. The design of the standard is also limiting to modern devices and apps that are trying to leverage available patient data. Privacy and security are also difficult to implement. These limitations have become a barrier to patient engagement and making patient data available in the most convenient formats.
HL7 V3 was meant to be the successor of HL7 V2. It leveraged modern standards technologies available at the time while being based on a reference model, but ended up being overly complex to implement with a steep learning curve. It also had no backwards compatibility with HL7 V2, which made switching to the new standard all the more complex given how embedded HL7 V2 is within the U.S. healthcare system.
HL7 CDA was incorporated into the Meaningful Use criteria, and thus has broad penetration in the United States. However, there remains many drawbacks with CDA that are being exposed by the requirements of Meaningful Use:
- Due to the same complexity as HL7 V3, the learning curve is still steep
- Interoperability beyond a human-to-human level is still challenging
- CDA documents do not fit well in many workflows
- Extensibility is difficult
HL7 is developing FHIR profiles for Consolidated CDA (C-CDA). There are also several projects looking at providing automated transformation between C-CDA and FHIR.
HL7 FHIR differentiates itself from past standards technologies by focusing on the following:
- Focus on those who are implementing the standard
- Ensure common scenarios are easily supported
- Leverage cross-industry web technologies
- Require human readability as base level of interoperability, same as CDA
- Make the standard freely available
- Deliver flexibility by supporting multiple paradigms and architectures
- Provide for modern governance of data
Focus on the implementers
HL7 FHIR was written with implementers as the target audience in mind. Of high importance was the use of reference implementations, which were incorporated into the design of FHIR from the beginning. Robust testing was deemed important as well for implementers, which led to the availability of public test servers.
Support for commonly used workflows
The content in the core specification is meant to cover the top 80% of use cases. This is similar to the focus of the HL7 V2 standard, only the extensions will be cleaner and easier. The idea is to focus on the real needs of the industry, but allow for all the special use cases as well. HL7 V3 was commonly criticized for trying to account for too many use cases in the core standard, thus leading to an overly complex standard that was difficult to achieve.
Embrace web technologies
The use of RESTful web services as an API has been on the rise over the last decade across all industries. RESTful web services is embraced by organizations such as Facebook, Twitter, and Amazon as their primary API. In addition, related technologies such as XML, JSON, and Oauth, are also common when dealing with encoding and authorization. These technologies have well supported tools and a large talent pool of IT resources. Thus, healthcare will not be locked in to unique industry standards, but can embrace what is used across all industries.
The concept of human readability being the minimum level of interoperability was introduced with the CDA standard. The idea is that if none of the structured data is able to be imported into the receiving system, the data could be viewed in a standard web browser. HL7 FHIR continues with this concept to ensure that human readability will always be an option.
Paradigms for packaging the payload
HL7 FHIR plans to support four interoperability paradigms, which are distinct ways of utilizing FHIR to best accommodate varying workflows. The four paradigms and when they might be used are:
- REST Small, light-weight exchanges with low coupling between systems
- Messages Communicate multiple resources in a single exchange
- Documents Focus is on persistence when data spans multiple resources
- Services Use a custom service when capabilities of other paradigms don’t fit requirement
Regardless of the paradigm, the content is still based on resources. The resources are just bundled into different data sets depending on the paradigm. The diagram below details some of the key differences among the paradigms.
Resources are small, logically discrete units of exchange. Resources define behavior and meaning, have a known identity and location, are the smallest possible unit of transaction, and provide meaningful data that is of interest to healthcare. The plan is to limit resources to about 150 in total. They are sometimes compared to an HL7 V2 segment.
The resources can be extended and adapted to provide a more manageable solution to the healthcare demand for optionality and customization.
Governance to maintain the privacy and security of patient data will be of utmost importance to the success of FHIR. FHIR includes modern capabilities that should allow policies to be constructed in a way that are protective but not constraining.
All exchange of production data is expected to be secured using TLS/SSL. Authentication can be achieved in a number of ways, but OAuth is recommended for web-centric use. FHIR defines a Security Label infrastructure to support access control management, and FHIR also defines provenance and security event resources suitable for tracking the origins, authorship, history, status and access of resources.
Where might HL7 FHIR be used?
HL7 FHIR has the capability to be used in a variety of workflows, from small mobile devices to large multi-facility hospital information systems. FHIR not only enables new workflows, such as those related to patient engagement, but also more traditional communications between applications.
Common workflows include:
- Traditional application-to-application interoperability within the four walls
- External connectivity
- HIEs / ACOs
- National exchanges
- Social web
- Mobile applications
- Home health devices
The timeline diagram in Image 4 depicts potential FHIR workflows.
- Initially, there will likely be a need for broker applications, such as an interface engine, to act as middleware between applications that still use traditional standards and those with the new FHIR-based standard.
- Patient engagement will be a major target for FHIR. Apps will be able to leverage the lightweight REST standard to provide patients timely data and alerts.
- FHIR will also be utilized as a link into patient data repositories, where applications all throughout the provider facility can gain access to patient data only when the patient shows up in their department.
The diagram in Image 5 expands on the third scenario in Image 4, patient data repository access.
Many departmental applications throughout the provider facility will query the FHIR database repository for the data they need, when they need it, allowing for very efficient data transfers and an accurate single source of truth for all data.
Advances in FHIR
The HL7 FHIR standard can be used for a variety of workflows, as illustrated in the previous section. However, the key step in enabling the FHIR technology is to have major vendors open up their clinical data in a FHIR repository so other applications can leverage it to solve creative workflow problems. In addition to having the data available, there is an emerging technology that would take this even one step further. The technology is called SMART, and it allows more robust functionality and creative usage of the data directly within the EHR itself. SMART on FHIR would embed third party functionality directly within the EHR application itself. In a nutshell, SMART enables third party plug-in apps to run natively inside any compliant EHR.
The SMART project started in 2010 with a fouryear, $15 million grant from the ONC. The idea was to build an app platform for healthcare allowing support apps to be chosen by clinicians. Each year at the HIMSS Interoperability Showcase, several vendors demonstrated the progress they are making by incorporating SMART. Since then app development has proliferated, and there are currently 44 apps available on the SMART web site. All the apps use the same underlying set of platform specifications. The SMART specs provide means for health care organizations or developers to access discrete clinical data—such as medications, problems, lab results, immunizations and patient demographics.
SMART opens up innovation in healthcare like has not been possible previously. If someone has a bright idea to enhance workflow and creates a SMART app, the healthcare provider doesn’t need to wait for an EHR vendor to adopt the idea. Assuming they have a SMART-compliant EHR, they can immediately take advantage of the bright idea through the use of the app.
The Argonaut Project
Argonaut is a supporting movement of FHIR in the U.S. led by volunteers. Individuals within HL7 were focused on keeping the FHIR project on target with its self-proclaimed deadlines for adoption. This focus was especially important considering the Open API requirements for Meaningful Use Stage 3. Several of the major EHR vendor organizations also wanted to do what they could to help push development and adoption in the U.S. So HL7, along with these vendor organizations, set out to do two things through the Argonaut Project: First, they funded the work to build a U.S. specific profile, and second they combine resources to help market and drive adoption of the standard.
The organizations are working with HL7 and the ONC to shed light on the best way to use FHIR in the U.S. considering there are some parts of FHIR that are very international in perspective. For instance, because there is no consistency around the world with how medication is encoded, FHIR doesn’t make any rules about how medication is encoded. But in the context of the U.S., RxNorm is the coding system used for medication. HL7 is working through many similar types of issues with the Argonaut members. This will hopefully help drive a cleaner more consistent standard for the U.S., along with a speedier adoption due to the buy-in of the larger vendor organizations that are participating.
Where does FHIR go from here?
The industry is waiting to embrace a standard that offers something better, but given the embedded nature of HL7 V2, the transition will not happen overnight. FHIR tries to fill the gaps that exist with the standards in use today, as has been discussed in this paper. While the healthcare market will decide whether FHIR survives, coexists, or replaces other products, the modern technologies that it is based on have already won over other industries.
Additionally, other standards organizations are jumping on board to support HL7 in the development of FHIR. One of those is IHE International, which plans to leverage FHIR across several profiles including: MHD (mobile XDS), PIXm/PDQm (patient identification), PCC (care coordination), mACM (alerting), and others