Introduction to FHIR

FHIR® (Fast Healthcare Interoperability Resources) is synonymous with healthcare interoperability, and is rapidly being adoption by EHR vendors, developers, payers, and patient applications. FHIR (pronounced fire) is a standard for exchanging healthcare information electronically using modern web technologies. FHIR was developed by HL7, a Standards Development Organization (SDO), and was first published as a Draft Standard for Trial Use in 2014.

About FHIR File Format

FHIR® data can be represented as either JSON or XML, and consists of discrete data elements (called resources) and standard Application Programming Interfaces (APIs) to create, read, update, and delete (CRUD) those data elements. Resources are representations of content such as patients, procedures, medications, claims, and many other resource types.

Each resource is a building block that is assigned a unique identifier. APIs enable multiple stakeholders to reference the same underlying resource across health systems, payers, developers, and other systems. FHIR resources can be interpreted by any system, including patient mobile apps, EHRs (Electronic Health Records), and Claims Processing Systems.

About FHIR Regulations

FHIR® resources are open source and available to any developer, which allows for limitless connections to applications, providers, payers, and patients. FHIR is also Meaningful Stage 3 compliant, which is a federal mandate that drives all patients to have access to all of their electronic health records.

FHIR APIs are specifically required in certified Electronic Health Records (EHRs) by the February 2019 Notice of Proposed Rulemaking (NPRM) by ONC, and is the specified standard by which health plans will be required to make patient data available under the CMS Interoperability and Patient Access Proposed Rule, both of which will further accelerate FHIR adoption.

Advantages of FHIR

Since its inception, FHIR has made significant advancements in addressing one of the biggest challenges plaguing healthcare interoperability by enabling health IT developers to quickly and easily build applications to exchange data using modern web technologies they’re familiar with (such as HTML, JSON, XML, and OAuth), instead of esoteric, outdated clinical languages.

Comparison of FHIR, HL7, and CCDA

FHIR® is an improvement over HL7 and CCDA. HL7 Version 3 failed to gain widespread adoption because of its high complexity, lack of flexibility, and high effort to implementation, which required a deep level of expertise.

The main part of HL7 v3 that remains widely adopted today is the Clinical Document Architecture (CDA). CDA allows for metadata standardization and various clinical data points. CDA is only specific to clinical data. CCDA, is a consolidated form of CDA and is focused on the most essential and common healthcare data elements, which is closer aligned to FHIR.

FHIR, HL7, and CCDA are similar in terms of providing support to specific use cases, and providing validation tools and data standardization. FHIR, however, provides a multitude of FHIR resource, allows for an easier, faster, and cheaper way to build various applications, and encloses not only a document exchange format (HL7 v3 and CCDA), but also allows for the exchange of APIs, messages, resources, and various documents (such as doctor notes).

The modular FHIR approach is also more flexible for developing applications for patients and providers. The CDA approach was initially intended to provide a data dump of the full medical history of a patient. FHIR includes the $everything query, which enables you to get the full medical history for the specified patient.

Because FHIR breaks down data into smaller, discrete pieces, there is better uniformity than in CDA, which can be problematic for processing larger documents for patients with complex care histories.

For more information about the differences between FHIR and CDA, see FHIR® vs. CDA.

Users of FHIR

1upHealth is among many organizations and companies who are advocating for FHIR, including the US government, EHR vendors (such as Epic® and Cerner), Apple, Microsoft, Google, and many other. The are two main reasons for this:

  • FHIR is based on modern web technologies that software developers can easily use, without in-depth healthcare domain knowledge or familiarity with esoteric languages

  • Companies recognize the multitude of benefits and use cases for FHIR

FHIR Use Cases

FHIR is the future of data access. Before FHIR, integrating with health systems and sharing data was a difficult and extensive process. Developers had to build customized applications for each EHR to be able to read and write data. This takes a lot of human resources who must spend a large amount of time understanding unique integration requirements. Now, with FHIR, fast interoperability between various platforms can be completed quicker in a standardized manner, where the data is in a structured format.

With an increasing demand for interoperability, FHIR adoption has been spreading across various EHRs, including Cerner, Epic, and Veradigm, as well as businesses that have been modifying their models to accommodate the need for FHIR. With growing patient expectations to have an easy option to access their data, FHIR offers a future of effortless integration that has become normal in other industries.

FHIR Limitations

Migrations from HL7 to FHIR can be a lengthy process because of a lack of backward compatibility and standardization of health systems. For migrations to succeed, FHIR resources must be extended, which adds an extra layer of difficulty. Resources are built based on the 80/20 rule, containing data elements if 80% of the existing systems include them with extensions for the other 20%. Extensions are meant for specific use cases and don’t scale unless they have been shared and adopted through implementation guides.

History of FHIR

2011

In August 2011, Graham Grieve, known as the Father of FHIR, asserted that HL7 Version 3 had failed. Graham Grieve and a small team created a new standard for interoperability, Resources for Healthcare or RFH. The standard was later renamed to Fast Healthcare Interoperability Resources, otherwise known as FHIR.

2012

In March 2012, FHIR specification work was transferred to HL7 International, which allowed for free access and availability. FHIR went through several iterations before stakeholders reached consensus that it was ready.

2014

In December 2014, the Argonaut project emerged with the goal to accelerate OAuth and FHIR in health information exchange through FHIR implementation guides and profiles. On February 2014, HL7 published FHIR as a Draft Standard for Trial Use (DSTU), Release 1, which led to the October 2015 release of the Second Draft Standard for Trial Use (DSTU2).

2015

The Argonaut project was released May 2015, and consisted of EHR vendors (such as Epic, Cerner, and athenahealth), health systems (such as Mayo Clinic and Intermountain), and SMART at the Boston Children’s Hospital (BCH) Informatics Program led by Ken Mandl. The outcome of this would be to enable digital electronic health records and health information technology exchange for patients, providers, and payers.

2017

In March 2017, FHIR Release 3 was published as the first Standards for Trial Use (STU) release.

The key changes of this release included:

  • Improvements to the RESTful API framework

  • Added Financial Management and Terminology Services

  • Additional support for Clinical Quality Measures and Clinical Decision Support

  • Expanded use cases to encompass clinical workflows

  • Specified the format of how FHIR relates to Linked Data and an RDF format

2019
to
Present

In 2019, the following updates were made to FHIR:

  • FHIR Release 4 was released with the first Level 6 normative resources.

  • The FHIR Bulk Data specification was balloted by 1upHealth, and the initial reference implementation was developed by 1upHealth and Boston Children’s Hospital under a $1M HHS Leap grant.

  • FHIR adoption has been spreading across various EHRs, including Cerner, Epic, and Veradigm.

  • Businesses are modifying their models to accommodate FHIR

Impact of FHIR

FHIR is an HL7 standard that brings RESTful APIs and a common format for hundreds of clinical data models to healthcare. If you're new to FHIR, here's what you need to know:

  • For healthcare integrators, this means that traditional HL7 standard data formats and messages are going to transition to the FHIR formatted XML and JSON objects, with read and write functionality based on the GET, PUT, POST, DELETE functions used in web-based APIs.

  • For healthcare app developers, you can have atomic data access to individual items within resources such as the Patient demographics or Observations for lab results among many other resources.

  • For healthcare systems, you can build and run applications on this new API standard and produce richer products with data connected from external systems. FHIR is required under the new rules of Meaningful Use 3, so most EHR vendors will offer support as of 2018.

  • As a patient, you can get and share your medical data in more ways than ever before, including with apps that you use. FHIR® also means you'll have more choices of apps in the future.