Ask a patient to move their records from one health system to another and the request often turns into a fax number, a signed release form, and a multi-day wait. Ask two hospitals to share a single lab result electronically and the project can consume months of interface engineering. For decades, the technical bottleneck was not a lack of data — it was the absence of a common, machine-readable way to ask for it and get a consistent answer back. FHIR was built to close that gap, and its adoption has done more to reshape how health data moves than any single standard that came before it.

FHIR, short for Fast Healthcare Interoperability Resources and pronounced “fire,” is a specification maintained by Health Level Seven International (HL7) for representing and exchanging healthcare information electronically. It is not a single piece of software or a product any vendor sells. It is a shared blueprint — a set of rules that lets an electronic health record system, a lab system, a payer’s claims platform, and a patient’s phone app all describe a blood pressure reading, a medication order, or an allergy in the same structured way, and fetch it over the same kind of web connection every modern app already uses.

What Problem Was FHIR Actually Solving?

Before FHIR, the dominant data exchange standards in US healthcare were HL7 Version 2 (HL7v2), a messaging format dating to the 1980s, and the Clinical Document Architecture (CDA), an XML-based document standard introduced in the 2000s. Both moved enormous volumes of clinical data and both are still in wide use today. But both were built for a different technical era.

HL7v2 messages use a pipe-and-hat delimited text format that is flexible to the point of being loosely standardized — two vendors can both claim HL7v2 conformance and still require custom mapping to talk to each other. CDA documents are richly structured but document-centric: a discharge summary or continuity-of-care document is a whole package, not a single discrete data element a developer can query in isolation. Neither standard was designed around the REST-based, JSON-friendly patterns that had already become the default for building web and mobile applications everywhere outside healthcare.

HL7 began developing FHIR around 2011 under lead architect Graham Grieve, explicitly aiming to borrow patterns from contemporary web APIs — the same approach used by services like banking or e-commerce APIs — rather than healthcare-specific messaging conventions. The goal, according to HL7’s own documentation, was to let developers “focus on implementation” instead of spending months interpreting ambiguous specifications.

How Does FHIR Actually Work?

FHIR organizes healthcare information into “resources” — modular, discrete units of data that each represent a single concept. There is a resource for a Patient, a resource for an Observation (such as a lab result or vital sign), a resource for a Medication, a resource for a Condition, a resource for an Encounter, and dozens more, each with a defined set of fields, data types, and relationships to other resources. As of FHIR R4 there are roughly 145 resource types covering clinical, administrative, and financial data.

Resources travel over REST, not proprietary messaging

Instead of a custom messaging protocol, FHIR resources are exchanged using standard RESTful HTTP operations: GET to retrieve a resource, POST to create one, PUT to update one, DELETE to remove one. A developer can request a specific patient’s allergy list with an HTTP GET call the same way they would query any modern web API, and receive the answer formatted as JSON or XML (early versions also supported RDF). This is the detail that made FHIR approachable to a much broader pool of software developers — not just specialists trained in healthcare messaging formats.

Rather than bundling everything a system might need into one giant document, FHIR resources reference one another. An Observation resource for a blood glucose reading references the Patient resource it belongs to and the Encounter resource during which it was recorded, rather than repeating that demographic and visit information inline. This composability is what lets developers pull back only the specific pieces of information an application actually needs.

Profiles adapt the base standard to real-world use cases

The base FHIR specification defines resources generically enough to apply across many countries and use cases. Implementation guides — most notably the US Core Implementation Guide in the United States — constrain and extend those base resources into “profiles” that specify which fields are required, what value sets or code systems must be used, and how a resource should be populated for a particular jurisdiction or purpose. US Core profiles are what US-based certified health IT products are actually required to support.

What Are the Different FHIR Versions, and Why Does R4 Matter?

FHIR has gone through several major releases, and the version numbers matter because they map directly to what a given system is contractually or regulatorily required to support.

  • DSTU2 (Draft Standard for Trial Use 2, 2015) was the first version to see meaningful pilot adoption, including early SMART on FHIR implementations.
  • STU3 (Standard for Trial Use 3, 2017) expanded the resource catalog and refined the RESTful API but was still explicitly labeled “trial use,” meaning breaking changes between versions remained possible.
  • R4 (Release 4), published by HL7 in January 2019, was the first release in which core parts of the specification — the RESTful API, the XML and JSON data formats, and the base data types — passed a normative ballot. That “normative” designation is significant: it means those portions of FHIR are locked for backward compatibility going forward, giving vendors and health systems confidence to build production software against the standard rather than a moving target. Most FHIR resources in R4 remain in trial use even though the underlying framework is normative.
  • R5, published in 2023, added further resources and refinements, but R4 remains the version referenced by current US federal regulation as of this writing.

That regulatory anchoring is a large part of why FHIR moved from a promising specification to the de facto exchange format across the US health IT industry within about a decade of its creation.

How Did SMART on FHIR Extend the Standard?

FHIR defines how clinical data is structured and retrieved, but it does not by itself define how an outside application proves it is allowed to ask for that data. That gap is filled by SMART on FHIR (Substitutable Medical Applications, Reusable Technologies), a specification that layers standard OAuth 2.0 and OpenID Connect authorization on top of FHIR’s data model.

SMART on FHIR is what allows a patient-facing app — for example, a smartphone app that lets a patient view their own lab results — to authenticate with an electronic health record’s patient portal, receive explicit, scoped permission to access a defined slice of that patient’s data, and then pull it using standard FHIR calls, without the app developer ever needing direct access to the underlying EHR database or a proprietary integration contract with that EHR vendor. The same authorization pattern also supports apps launched from inside a clinician’s EHR workflow, with the EHR passing context such as which patient and encounter are currently open.

Because SMART on FHIR combines an open data standard (FHIR) with an open authorization standard (OAuth 2.0), it became the technical foundation that let a single app be built once and connect to many different EHR vendors’ systems, rather than requiring a custom integration for each one.

What Role Did Federal Regulation Play?

FHIR’s adoption curve changed sharply once it became a regulatory requirement rather than an optional best practice. The Office of the National Coordinator for Health Information Technology (ONC), under authority granted by the 21st Century Cures Act, finalized a rule in 2020 requiring that certified health IT products expose a standardized, publicly published FHIR-based API. That certification criterion, numbered § 170.315(g)(10) in the ONC Health IT Certification Program, specifically requires the use of HL7 FHIR Release 4 together with the US Core Implementation Guide and SMART App Launch for authorization.

In practical terms, this rule is why a certified EHR sold in the United States today must offer patients and authorized third-party applications a standardized FHIR API to retrieve health records, rather than leaving each vendor free to expose data through a proprietary interface or none at all. The US Core Implementation Guide is versioned separately from the base FHIR specification and is periodically updated to track the United States Core Data for Interoperability (USCDI), the federally defined data set that specifies which clinical data classes — such as problems, medications, lab results, and clinical notes — must be exchangeable at all. USCDI defines what data must move; US Core defines, in FHIR terms, how it is structured when it does.

The combined effect is a regulatory stack — Cures Act rule, USCDI data classes, US Core profiles, FHIR R4, SMART App Launch — that took what began as a voluntary technical specification and turned it into the backbone of federally mandated health data access in the United States.

Where Does FHIR Fall Short?

FHIR is widely adopted, but it has not eliminated interoperability friction. Implementation guides still leave room for local variation, and two systems can both be “FHIR compliant” while implementing different optional fields or code systems, requiring reconciliation work not unlike the mapping projects HL7v2 required. Bulk data exchange for large populations, complex clinical workflows such as prior authorization, and semantic consistency across terminologies remain active areas of specification work rather than solved problems. FHIR also has not fully displaced HL7v2, which continues to carry the bulk of real-time clinical messaging — such as lab and admission-discharge-transfer feeds — inside many hospital environments, and CDA-based documents such as the Continuity of Care Document remain common for certain document-exchange use cases. FHIR is best understood as the current, dominant layer in a stack of coexisting standards rather than a wholesale replacement for everything that came before it.

Frequently Asked Questions

What does FHIR stand for?

FHIR stands for Fast Healthcare Interoperability Resources. It is a specification developed and maintained by HL7 International for exchanging healthcare data electronically using modern web technologies, including RESTful APIs and JSON or XML data formats, organized around modular units of data called resources.

Is FHIR required by law in the United States?

Yes, in a specific sense. The ONC Cures Act Final Rule requires health IT products certified under the ONC Health IT Certification Program to expose a FHIR R4-based API using the US Core Implementation Guide and SMART App Launch, making FHIR support a certification requirement rather than a purely optional standard.

What is the difference between FHIR and SMART on FHIR?

FHIR defines how clinical data is structured, packaged into resources, and retrieved through a RESTful API. SMART on FHIR adds a standardized authorization layer, based on OAuth 2.0, on top of FHIR so that outside applications can securely request and receive permission-scoped access to a patient’s data.

Does FHIR replace HL7v2 and CDA?

Not entirely. FHIR has become the primary standard for new API-based data exchange and is required under current US certification rules, but HL7v2 still carries much real-time clinical messaging inside hospitals, and CDA-based documents remain in use for certain document-exchange scenarios. The three standards currently coexist across the industry.

What is a FHIR resource?

A resource is the basic unit of data in FHIR — a structured representation of a single healthcare concept, such as a Patient, Observation, Medication, or Condition. Resources reference one another rather than duplicating data, and FHIR R4 defines roughly 145 distinct resource types.