What Is FHIR and What Does It Actually Mean for Healthcare Organizations?

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is the HL7 International standard that defines how health data is structured and exchanged between software systems using modern web APIs, replacing decades of proprietary data formats and point-to-point integrations that made moving clinical information between organizations expensive and unreliable. For healthcare organizations, FHIR is now less of a technology choice and more of a regulatory requirement: federal rules from both ONC and CMS have made FHIR R4 the mandated standard for EHR certification, patient data access, prior authorization, and payer-to-payer data exchange, with compliance deadlines that extend through January 2027.

Understanding what FHIR is and what it actually requires of your organization is increasingly a prerequisite for healthcare IT strategy, vendor evaluation, and regulatory compliance planning.

What problem FHIR was designed to solve

Before FHIR, healthcare data exchange was built on a collection of standards that were designed for a world of proprietary systems and batch file transfers: HL7 v2, designed in 1987, sent pipe-delimited messages between systems that needed to be individually negotiated and mapped. CDA (Clinical Document Architecture) structured clinical documents but was designed for document exchange, not granular data queries. Every EHR vendor implemented these standards differently, which meant that "HL7 interface" was not an interoperability guarantee; it was the beginning of a customization project.

The result was a healthcare industry in which the same patient's data existed in dozens of disconnected systems, each using its own format, with exchange possible only through expensive custom interfaces or manual fax and print workflows. A hospital could not reliably query a patient's medication list from an outside pharmacy, a payer could not automatically receive a prior authorization decision from a health system, and a patient had essentially no practical way to download their own health record.

FHIR, developed by HL7 International starting in 2011, took a different approach. Rather than designing another document exchange protocol, it defined health data as discrete resources (Patient, Observation, Medication, Encounter, Claim, Practitioner, and hundreds of others) that could be accessed, created, updated, and deleted via standard REST API calls, the same type of API used by most modern software applications. The implication was significant: a developer who knew how to build a REST API could build against a FHIR endpoint without learning a proprietary healthcare protocol.

How FHIR works

FHIR organizes clinical and administrative data into resources, each representing a specific type of information. A Patient resource contains demographic data. An Observation resource contains a lab result, vital sign, or clinical measurement. A Condition resource describes a diagnosis. A MedicationRequest represents a prescription. A Claim represents a billing submission. Each resource has a defined structure, a set of required and optional fields, and a canonical URL that identifies it.

The technical layer is standard web technology. FHIR APIs use HTTP methods: GET to retrieve a resource, POST to create one, PUT to update one, DELETE to remove one. Resources are returned in JSON or XML. Authentication uses OAuth 2.0, the same protocol used by most consumer and enterprise software. A SMART on FHIR application, which is the open standard for FHIR-compatible clinical apps, can launch inside an EHR and access patient data using the same authorization flow a user would see logging into a web application.

What this means practically is that a health system with a FHIR R4-compliant EHR has an API endpoint that outside applications can query for patient data. A patient-facing app can retrieve someone's lab results. A payer can pull clinical data to support a prior authorization decision. A population health tool can aggregate observations across a patient population. A care coordination platform can read and write care plans. These are all possible without custom interfaces if the underlying system is FHIR-compliant and the authorization is properly configured.

FHIR R4, finalized in December 2018, is the current production standard. It is the version required by ONC certification criteria and CMS interoperability rules. FHIR R5, released in March 2023, introduced additional resources and refinements, particularly around patient engagement and care coordination, and major EHRs including Epic and Oracle Health began releasing R5-compatible sandbox environments in 2025. The practical guidance for production integrations as of 2026 is to build against R4 and plan for R4-to-R5 migration as the market matures over 2026 and 2027.

What federal regulations require of providers

The regulatory landscape for FHIR in healthcare involves two parallel tracks: one covering providers and EHR developers through ONC, and one covering payers through CMS. Both have binding compliance requirements.

The ONC 21st Century Cures Act final rule established FHIR R4 as the required standard for certified health IT under the ONC Health IT Certification Program. EHRs that are certified under this program must expose patient data through FHIR R4 APIs, allowing patients to access their complete electronic health information at no cost using third-party applications of their choice. The rule also established information blocking regulations, which prohibit providers, health IT developers, and health information networks from practices that unreasonably restrict the access, exchange, or use of electronic health information. Providers found to have committed information blocking became subject to disincentives under a final rule that took effect July 31, 2024.

For hospital and health system IT leaders, this means that your EHR must be ONC-certified, and that EHR certification now implies a functioning FHIR R4 API. It also means that policies or technical configurations that restrict patient data access, even without explicit intent, can constitute information blocking under federal law.

The operational implications extend beyond certification. Once your EHR exposes a FHIR endpoint, you have decisions to make about what applications can connect to it, under what authorization rules, and how patient consent is managed. A FHIR API that is technically available but poorly governed creates both compliance risk and clinical risk if unauthorized applications can query patient data or if patient consent workflows are not designed appropriately.

What federal regulations require of payers

CMS-0057-F, the CMS Interoperability and Prior Authorization final rule published in February 2024, requires Medicare Advantage organizations, state Medicaid and CHIP agencies, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on Federally Facilitated Exchanges to implement four FHIR R4 APIs by January 1, 2027:

Patient Access API. Allows members to access their own claims, encounter data, and (as of the 2024 rule) prior authorization data through third-party applications of their choice. Payers are required to report annual metrics on Patient Access API usage to CMS beginning January 1, 2026.

Provider Access API. Allows in-network providers to query claims and clinical data for their patients directly through the payer's FHIR endpoint, with appropriate authorization. This is designed to give treating clinicians access to the longitudinal claims history that payers hold, which providers have historically been unable to access in real time.

Payer-to-Payer API. Requires payers to exchange member data when a patient transitions between health plans, allowing clinical and claims history to follow the member rather than starting fresh with each enrollment. Members can also request their data be exchanged at any time.

Prior Authorization API. Structured as a FHIR-based electronic process for prior authorization requests and responses, replacing fax and manual workflows. The rule sets specific response time requirements alongside the API requirement, codifying how quickly payers must respond to electronic prior authorization requests.

For health plans and managed care organizations, these four APIs represent a significant infrastructure build. The Salesforce Health Cloud for payers post covers the payer data model and how modern platforms are approaching CMS interoperability compliance in more detail.

FHIR and EHR integration: what actually changes

One of the most common points of confusion about FHIR is the gap between what the standard makes possible and what is operationally true in a given health system's environment. An EHR being "FHIR-compliant" does not mean every data exchange your organization needs will automatically work through FHIR. It means the EHR vendor has implemented FHIR APIs that meet ONC certification criteria for the data elements covered by those criteria.

The practical picture is more nuanced. Major EHRs, including Epic, Oracle Health (formerly Cerner), MEDITECH, and Athenahealth, have FHIR R4 implementations, but those implementations vary in scope, in which FHIR resources are supported, in how authorization is configured, and in what bulk data export capabilities are available. An EHR that supports FHIR patient access for patient-facing apps may not support the same FHIR endpoints for bulk data extraction to a data warehouse. An integration that works in one EHR's FHIR implementation may require different query logic in another.

For health system IT leaders, this means FHIR significantly reduces integration complexity compared to the HL7 v2 and custom interface world, but does not eliminate the integration work. The FHIR and EHR integration post covers the implementation realities in more detail, including where health systems commonly encounter complexity when moving from FHIR-in-theory to FHIR-in-production.

FHIR and clinical AI: why it matters for AI deployments

An underappreciated implication of FHIR for healthcare organizations deploying clinical AI is that FHIR is the data access layer that makes AI on clinical data operationally possible at scale. An AI system that needs to query patient histories, lab trends, medication lists, or clinical observations needs a structured, queryable data source. FHIR provides that source in a way that HL7 v2 messages and scanned clinical documents do not.

Practically, this means that healthcare organizations whose EHRs are FHIR-compliant have a foundation for clinical AI that organizations still running on legacy data formats lack. A clinical decision support tool, a predictive risk model, an AI-assisted prior authorization review: each of these requires access to structured clinical data in a format the AI system can process. FHIR R4 resources are that format.

The governance implications follow from the data access. A FHIR endpoint that feeds an AI system creates obligations around what data the AI can access, how it is de-identified or restricted, how access is audited, and what happens when the AI makes an erroneous decision based on incomplete or incorrect FHIR data. The AI governance for healthcare post covers those obligations in the context of HIPAA and clinical risk management.

What FHIR does not solve

FHIR is a data exchange standard, not a data quality standard. It defines how data is structured and transmitted, not whether the data is accurate, complete, or consistently coded across systems. A FHIR resource for a patient's diagnosis will arrive in a standard format, but the diagnosis code will reflect whatever was entered in the source system, which may be out of date, incorrectly specified, or missing context. Data quality problems in the source EHR become data quality problems in any system consuming data through FHIR.

FHIR also does not resolve governance or consent complexity. Making patient data technically accessible through a FHIR API does not mean your organization has determined who can access that data, for what purposes, under what consent framework, and with what audit trail. The information blocking rules create a floor: you cannot block access to electronic health information without a recognized exception, but they do not design your access governance model for you. Organizations that launch FHIR APIs without accompanying governance programs create compliance exposure, not less.

Finally, FHIR does not replace the clinical and workflow integration work that follows data exchange. Retrieving a patient's medication list from an outside system through FHIR is the beginning of a clinical workflow question, not the end: what happens with that data, who reviews it, how it reconciles with the medication list in your EHR, and what happens if there are discrepancies are all clinical and operational decisions that the standard cannot make.

What healthcare organizations should be doing now

The FHIR compliance picture for most healthcare organizations in 2026 has two parts: understanding where your EHR already meets FHIR requirements through ONC certification, and actively planning for the use cases where FHIR creates opportunity or additional obligation.

For providers, the first question is whether your EHR's FHIR implementation is configured correctly for patient access, what applications have been authorized to connect, and whether your policies around information access are consistent with the information blocking regulations that took effect in 2024.

For payers, the January 2027 deadline for four FHIR APIs under CMS-0057-F is a concrete infrastructure requirement. Organizations that have not begun building or procuring FHIR API infrastructure (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization) are running behind a regulatory timeline that does not flex.

For organizations deploying AI in clinical workflows, the FHIR readiness question is part of the AI readiness question: whether the data the AI needs is accessible through FHIR endpoints, whether those endpoints are configured correctly, and whether the governance model for AI data access has been designed alongside the technical integration.

The healthcare AI adoption scorecard Tristella uses includes FHIR readiness and data access governance as part of the assessment for healthcare organizations evaluating their AI implementation readiness. For organizations that are still building their broader healthcare IT strategy, the healthcare IT services overview covers where FHIR readiness fits in the larger strategic picture.

How Tristella approaches FHIR readiness for healthcare organizations

Tristella's healthcare IT practice works with health systems, payers, and medtech organizations on the intersection of FHIR readiness, clinical AI governance, and platform implementation. For organizations deploying Salesforce Health Cloud, Agentforce, or clinical AI tools that depend on FHIR data access, we assess the current FHIR implementation against use-case requirements, identify configuration and governance gaps, and build toward a production-ready data access architecture.

FHIR compliance is not a one-time project. As ONC and CMS continue to extend FHIR requirements, and as the clinical AI use cases that depend on FHIR data access multiply, the governance and technical infrastructure around FHIR endpoints requires ongoing ownership.

Myra Salapare leads Tristella's healthcare IT strategy and clinical AI practice. Contact us to discuss your organization's FHIR readiness and what it means for your AI and interoperability strategy.

Related reading:

Sources: