What is HL7 FHIR? A Simple Overview of This Important Standard

FHIR (pronounced “fire”) is a free, vendor-neutral standard for exchanging electronic health records. It might sound like a simple concept. Considering the difficulty of health tech, that’s exactly the point!

Clinical documents like visit notes, test results and even insurance information can be encoded in a FHIR-compatible format. This data can be shared in whole or in part via FHIR-based APIs.

The FHIR standard has several advantages over previous interoperability efforts: 

• FHIR allows developers to process data with JSON, a modern standard.
• FHIR permits flexible, atomic data sharing instead of rigid formatting.
• FHIR’s regulatory and developer support are unmatched.
  

Before FHIR, health data exchange involved standardized record exports. Now, FHIR supports a modern network that allows true interplay between electronic health record systems (EHRs). FHIR makes it easier for patients to move their health data, and for organizations to use that data at scale.

It’s Fast Healthcare Interoperability Resources, and More

FHIR is an acronym for Fast Healthcare Interoperability Resources, which is a fitting name! Turns out FHIR involves all of those things. You might also see it called HL7 FHIR R4, HL7 v4, FHIR R4 or the HL7 FHIR standard.

Several things make FHIR special when it comes to healthcare APIs:

Resources (aka Atomic Data)

Resources are the fundamental building blocks of FHIR. All exchangeable content in the FHIR standard is contained in a resource. These lightweight JSON snippets can be created for every aspect of a patient encounter. 

Instead of sharing a patient’s fixed, bloated XML record with everyone who requests it, FHIR permits requests for targeted, relevant resources. 

Think of old standards as if someone handed you an entire file cabinet to read through. With FHIR, it’s as if they gave you an index card with the information you requested instead. It’s simply the preferred modern practice.

Common resource types include Observation for vital signs, or Encounter for a visit. Different resources can also combine to form new use cases or standardized document types.

All resources have metadata and a human-readable component. Each resource of the same type is formatted in the same way. 

Resources can refer to each other, and to a URL. Resources can stand on their own or be made to support event workflows. They can come with customizable permissions, many of which have been suggested by the FHIR community.

Taken together, resources begin to form a valuable store of healthcare information.

Interoperable, Bi-Directional RESTful APIs

The FHIR standard includes RESTful API protocols as well as data.

REST architecture is familiar to developers, as it’s the same architecture that underlies enterprise tools, the internet, and modern APIs. It means that familiar HTTP and OAuth protocols play a part in its use. Yes, health infrastructure has finally reached the cutting edge!

As a RESTful system, FHIR is far more straightforward than previous approaches to health data. It supports atomic data access, meaning that FHIR-based tools can allow access to specific parts of a health record. It’s a standard that encourages privacy and is generally easier to work with.

Fast and Simple Design

FHIR is focused on ease of developer use and adoption. FHIR empowers a more robust and flexible data model of the actual patient experiences and treatment plans than predecessors in the field.

FHIR was built with the Pareto principle, or 80/20 design, in mind. The idea is that 80% of common use cases will be covered by the FHIR standard. In turn, individual FHIR implementations will handle the other less common 20%.

This was partially in response to the HL7 v3 standard, which was released, and flopped, in 2005. It was too comprehensive to understand.

Thanks to its focus on human-readable data, FHIR resources can also be read by non-developers with minimal effort!

Support for Legacy Health Systems

FHIR can be expressed as XML, JSON or RDF. It’s possible for basic FHIR interfaces to be implemented in a day, for free, and with support from vendors from Apple to Epic. 

Your implementation of FHIR need not support all FHIR resources, but must support what your organization does.

The FHIR standard doesn’t bring a system into or out of HIPAA compliance, but it can be implemented in HIPAA-compliant networks.

FHIR Has Friends In High Places

Legally speaking, FHIR is an important part of health tech.

In the US, the federal government has thrown its weight behind FHIR. The 21st Century Cures Act directed two major agencies - ONC and CMS - to promote nationwide interoperability using FHIR APIs.

Consumer-directed apps and portals are increasingly reliant on FHIR data. FHIR compatibility is also mandatory for payors and providers alike. FHIR implementations make it considerably easier to comply with Cures Act anti-information blocking rules.

FHIR’s Huge Community

There’s an active, worldwide community around FHIR. We’ve watched this community develop in real time, after the first draft of an API-based health data exchange was initiated by Australian developer Grahame Grieve in 2012 under the name Resources for Healthcare.

FHIR’s development was then overseen by Health Level 7 (HL7), the standards development organization dedicated to digital health interoperability. It continues to evolve with the help of volunteers and HL7 working groups.

FHIR is popular with developers globally. The standard’s open source nature, robust documentation and culture of collaboration contributes to its appeal.

You can find FHIR penetration in countries with health systems at various stages of development. For example, FHIR sees significant use in Brazil, Australia, Europe, Canada and India.

FHIR vs. CCDA

C-CDA, or Consolidated Clinical Document Architecture, is the main alternative to FHIR for patient medical record exports.

C-CDA is an XML-exclusive markup standard, not a complete API. C-CDA exports a patient’s medical history in a way that is difficult to query, and is generally read-only. It defines how documents are encoded, and can be exported - but does not define how they should be transported.

Standardizing digital documents was a significant step to interoperability, and was celebrated by many in health tech. Lessons learned from C-CDA were incorporated into FHIR.

We’re Staying on FHIR

At Particle, we believe FHIR’s connective power will enable long-sought healthcare goals.

As you can see, FHIR is way, way more than a format for data export - it’s a modern API that can keep up with leading consumer apps. FHIR is an evolution of existing standards and a new architecture in its own right.

Health tech leaders are using FHIR to build solutions instead of slogging through mismatched data. Patients will be able to control and share their health data from wearables, labs, hospitals. Physicians will be more effective with a complete picture of your health. 

FHIR is already helping the health system reach interoperability and #destroythefaxmachine. ⚛️