Getty Images
Breaking Down the Fast Healthcare Interoperability Resource (FHIR)
The Fast Healthcare Interoperability Resource (FHIR) standard aims to improve data exchange, but how does it work and how will it impact interoperability?
As health data interoperability becomes an increasingly pressing concern for providers, developers and vendors are paying a great deal more attention to the data standards that will enable seamless, on-demand information exchange.
The Fast Healthcare Interoperability Resource, commonly known as FHIR, quickly became one of the most popular protocols for joining together disparate systems and continues to hold great promise for developing an application-based approach to interoperability and health information exchange.
But what is FHIR, and how is it being used to further health data exchange?
In this primer, HealthITAnalytics breaks down the basics of one of the critical standards enabling efficient and secure interoperability.
WHAT IS FHIR?
The Fast Healthcare Interoperability Resource is a draft data standard developed and nurtured by HL7 International. FHIR was created with the complexity of healthcare data in mind and takes a modern, internet-based approach to connect different discrete elements.
"The philosophy behind FHIR is to build a base set of resources that, either by themselves or when combined, satisfy the majority of common use cases. FHIR resources aim to define the information contents and structure for the core information set that is shared by most implementations," HL7 states on its website.
Data elements, or "resources," each have a tag that acts as a unique identifier, just like the URL of a web page.
On the internet, users across the world can access the same URL and complete the same tasks using any standard browser running on any web-enabled device, whether it’s a smartphone, desktop, or tablet running a Windows, Apple, Android, or Linux operating system.
FHIR hopes to do the same thing: allow developers to build standardized "browser" applications that will enable access to data no matter what EHR "operating system" underpins the user's infrastructure.
The key to this is the resource. An FHIR resource can be an individual packet of information that includes metadata, text, or particular data elements but can also be bundled into collections that create clinical documents, similar to the Consolidated Clinical Document Architecture (C-CDA), but much more flexible.
"FHIR resources can be used to build documents that represent a composition: a set of coherent information that is a statement of healthcare information, particularly including clinical observations and services," HL7 states. "A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices."
By creating an accessible and standard URL for these information bundles instead of just passing individual documents back and forth between systems, several applications can point to the same version of the same data every time.
WHAT MAKES FHIR DIFFERENT FROM OTHER ATTEMPTS AT IMPROVING INTEROPERABILITY?
At the moment, most health information exchange and data interoperability is based on documents. Whether faxed, emailed, or sent electronically, providers typically have to choose a set of data to transmit and generate a message containing only that data.
While this approach does help organizations successfully communicate, it can be too limiting for meaningful care coordination, decision making, or data analytics.
For example, the C-CDA is a standardized document format that contains a great deal of critical information, but it is like a PDF — the data is relatively static, and it takes a special effort to extract the information and make it usable in any other format.
The exchange of these documents is valuable, as whole documents play a key role in clinical care.
While having complete information is important, document-based exchange doesn't allow a provider to delve into the context of the data received. Lab results, for example, may be a critical component of a patient’s care, but these alone do not tell that patient’s full story.
In this way, document exchange is important, but so is data-level exchange. Health information exchange (HIE) based on traditional C-CDA documents do not allow clinicians to access information at the data level.
Using standardized application programming interface (API) standards, FHIR allows developers to create apps that transcend this document-based environment. Applications can be plugged into a basic EHR operating system and feed information directly into the provider workflow, avoiding pitfalls of document-based exchange, which often requires providers to access data separately.
But FHIR APIs require health IT developers to publish FHIR endpoints in a standardized format, according to a 2022 blog post written by Office of the National Coordinator (ONC) officials. By developing the Lantern tool — which consumes public endpoint data, tests the accessibility of these endpoints, and then reports capability information to a public-facing dashboard — ONC worked with health IT stakeholders to form consensus around a standard format to publish FHIR endpoint lists.
HOW ARE VENDORS AND PROVIDERS USING IT?
A slew of providers, developers, and vendors have created tools that leverage the data standard. The use cases for the standard are nearly limitless and include some of the major challenges preventing healthcare organizations from increasing patient engagement, developing robust population health management programs, and diving into advanced, intelligent clinical decision support.
With enthusiastic support from the ONC and many of the most prominent commercial players in the industry, FHIR is seeing action in several different scenarios.
In 2021, the University of Pittsburgh Medical Center (UPMC) adopted FHIR to enhance interoperability and intraoperability across the organization, with a particular focus on connecting its ambulatory and hospital-based EHR systems.
HL7 and HL7 FHIR Accelerator CodeX also announced GenomeX last year, a foundational domain aimed at advancing genomic data interoperability, following a revelation from phase four of ONC’s Sync for Genes program showing that FHIR APIs can facilitate genomic data sharing.
This year, informaticists at Intermountain Health shared that they developed a FHIR-based platform designed to combine various algorithms, artificial intelligence (AI) apps, and other tools to bolster clinical decision support.
Hackathons, developer programs, and connect-a-thons are becoming popular ways to pick out the best and brightest ideas from the health IT community at large.
In 2022, CommonWell Health Alliance hosted one such connect-a-thon with 11 of its members. CommonWell has been leveraging FHIR for document-based exchange, but its most recent efforts are focused on developing the next generation of FHIR for discrete data exchange.
By pairing FHIR with the CommonWell Record Locator Service (RLS), stakeholders hope to enable providers to more easily locate FHIR resources – such as labs, allergy information, and medications – for their patients.
In the past, the ONC has also launched several FHIR-based app challenges, complete with hundreds of thousands of dollars in prize money.
FHIR also features heavily in the ONC's interoperability plans. Part of the information blocking provisions of the 21st Century Cures Act calls on medical providers and health IT developers to encourage patient data access using third-party apps and APIs that support the FHIR Release 5 standard.
WHAT DOES IT MEAN FOR PATIENTS AND PROVIDERS?
Why should patients and providers get excited about FHIR? Because it can make healthcare much more similar to the other internet-based experiences that consumers enjoy in other industries. It may also help make all those wearable devices and monitoring gadgets worthwhile from a clinical perspective.
The healthcare Internet of Things (IoT) is growing at a lightning pace, but so far, there have been few tools that can connect patient-generated health data (PGHD) with streamlined provider workflows.
FHIR presents an opportunity to connect the EHR with the millions of sources of PGHD, including wearables and other remote patient monitoring (RPM), while making that data easily accessible and actionable for providers.
Situation-specific apps built on a FHIR platform might be able to perform analytics on PGHD and present users with a summary of trends that are relevant to a particular aspect of chronic disease management or patient wellness.
Patients who see multiple providers in different health systems might no longer have to worry about having three or four patient portals from organizations using different EHRs. One single personal health record, which integrates data from different formats to deliver a comprehensive view of all medications, problems, and allergies, could link these disparate systems together to improve care coordination.
Providers may be able to customize their toolsets to meet the needs of their specialty or area of interest, pulling data from different research sources to bolster their clinical decision support capabilities or allowing them to send de-identified information to research registries focused on cultivating a precision medicine approach for the treatment of a rare cancer.
No matter the specific use cases, FHIR revolutionized how developers viewed the underlying technical infrastructure supporting patient care.
The standard is now widely used in mobile applications, cloud communications, EHR-based data sharing, and server communications across the healthcare industry.
Over the past ten years, the FHIR community has achieved success in several key areas, including the Argonaut Project that helped users of a leading platform aggregate and access personal health data on their mobile devices, and the HL7 DaVinci Project, which has helped payers and providers improve clinical quality, cost, and care management outcomes.
The promises of FHIR are many, and the support for the data standard is strong across the care continuum.
At the time of writing, HL7 officials are watching the healthcare market to help decide whether the next FHIR release will be a restricted branch development from Release 5 or a full new version.