What is FHIR?
FHIR is the common label on many health APIs. This page covers what the standard is, why U.S. rules point at it, and what that means when an app reads a person's data with their permission.
Arun Verma, co-founder of Triangle · 2026-10-19
This is not clinical evidence and not medical advice. It does not replace your care team. Discuss anything here with your clinician before you act on it.
What is FHIR?
FHIR is a standard for exchanging health care information electronically, published by HL7. The letters stand for Fast Healthcare Interoperability Resources. HL7 describes it as a next-generation standards framework built from modular pieces called resources, aimed at implementers who write software that moves health data. It is designed to sit alongside older HL7 standards rather than replace every workflow overnight. HL7 says FHIR can work on its own or in partnership with widely used standards such as HL7 Version 2 and CDA.
What is a FHIR resource?
A resource is the basic building block. HL7 says all exchangeable content is defined as a resource, and every resource shares a common way to define and represent it, a common set of metadata, and a human-readable part. Examples sit in modules such as administration (Patient, Practitioner, Organization), clinical content, medications, and diagnostics (Observation and reports). Resources can be combined through references for a specific use case, and StructureDefinitions can constrain how a given implementation uses them.
How does FHIR move data over the web?
Most implementations use a RESTful API over ordinary web requests. For each resource type, FHIR defines the same set of interactions, including read, search, create, update, and delete, so a client can work with resources in a granular way. Servers choose which interactions and resource types they support, and they publish a Capability Statement that says what is available. Payloads commonly use JSON or XML. The formal FHIR MIME types are application/fhir+json and application/fhir+xml. HL7's summary also lists OAuth among the web standards FHIR builds on. HL7 notes that you do not have to use REST to make use of resources; messaging and documents are other exchange styles in the specification.
Why do U.S. patient-access rules talk about FHIR?
Because certified health IT is expected to expose standardized APIs that apps can use without special effort. In the May 2020 Cures Act final rule, ONC adopted a new certification criterion, the standardized API for patient and population services at 45 CFR 170.315(g)(10), added it to the updated 2015 Edition Base EHR definition, and required the Health Level 7 FHIR standard Release 4 for that criterion. That criterion focuses on API-enabled read services for a single patient and for multiple patients. The same rule package is the policy hook that pushed FHIR APIs into everyday certified EHR products patients and developers encounter.
What did the CMS Patient Access API rule require?
CMS's Interoperability and Patient Access final rule (CMS-9115-F), published May 1, 2020, required certain payers to implement and maintain a standards-based Patient Access API. The impacted payers include Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally-facilitated Exchanges. That API had to meet the technical standards HHS finalized at 45 CFR 170.215, which then included HL7 FHIR Release 4.0.1. Through the API, payers must permit third-party applications to retrieve specified data with the approval and at the direction of a current enrollee. At a minimum, that includes adjudicated claims, encounters with capitated providers, and clinical data including laboratory results when the payer maintains them.
What is SMART on FHIR?
SMART App Launch is an HL7 implementation guide that defines OAuth 2.0 patterns so a client app can authorize, authenticate, and connect to a FHIR-based data system. In one line: it is how many apps get permissioned access to a FHIR server, including launch from inside an EHR or as a standalone app. SMART uses scopes to name the access permissions delegated to the app, drawn from FHIR interactions and resource types. An app might receive a narrow read scope for one resource type rather than open-ended access to everything on the server.
What does FHIR mean for an app working with a person's data?
FHIR gives you a shared shape for the data and a web-style way to request it, but permission still sits with the person and with whatever the server actually exposes. CMS's Patient Access API path is explicit that third-party apps retrieve data with the enrollee's approval and direction. SMART scopes further limit which resource types and interactions the token allows. A fair question for any integration is which Capability Statement endpoints and scopes are in scope, and what happens when a hospital or payer only publishes a subset of resource types. Servers are allowed to support only some interactions. FHIR is an exchange standard, not a promise that every record from every site will appear in one call.
What should developers not assume about FHIR APIs?
A common mistake is assuming every system speaks the same release, profile, or set of resources. ONC's certified API criterion aligned industry around FHIR Release 4 for that certification path, while the published HL7 specification continues to evolve across releases, so clients still need to check version and Capability Statement details. Another is treating any FHIR read endpoint as if it also granted write access, bulk export, or clinical decision support. Those are separate capabilities. And no source says a FHIR connection by itself replaces the person's say over who may see their information; authorization and scopes are part of how modern FHIR app launch is designed. You could ask which launch pattern the server supports, standalone or EHR launch, before wiring a client.
Sources
- HL7 FHIR R5 Index (Welcome to FHIR): HL7's FHIR home page states that FHIR is a standard for health care data exchange, published by HL7.
- HL7 FHIR R5 Overview (§2.1.15): HL7's FHIR Overview introduces FHIR (Fast Healthcare Interoperability Resources) as a standard for exchanging healthcare information electronically.
- HL7 FHIR R5 Summary: Introducing HL7 FHIR (§2.1.20): HL7's Introducing HL7 FHIR summary page expands the name as Fast Healthcare Interoperability Resources and calls FHIR a next generation standards framework created by HL7, built from modular components called Resources.
- HL7 FHIR R5 Overview (§2.1.15.1 Background): HL7's Overview says FHIR can be used as a stand-alone data exchange standard and can also be used in partnership with existing widely used standards, and points to comparing FHIR with HL7 V2, HL7 v3, and CDA.
- HL7 FHIR R5 Overview (§2.1.15.2 Components): HL7's Overview says the basic building block in FHIR is a Resource, that all exchangeable content is defined as a resource, and that resources share a common way to define and represent them, a common set of metadata, and a human readable part.
- HL7 FHIR R5 Overview (§2.1.15.4 The Specification): HL7's Overview lists specification modules including Administration (patients, practitioners, organizations), Clinical, Medications, and Diagnostics (Observations, Diagnostic reports).
- HL7 FHIR R5 Overview (§2.1.15.3.1 Approach to information modeling): HL7's Overview says specific use cases are usually implemented by combining resources through resource references, and that StructureDefinition resources provide additional rules that constrain optionality, cardinality, terminology bindings, datatypes and extensions.
- HL7 FHIR R5 RESTful API (§3.2.0 Http): HL7's RESTful API page describes FHIR as a RESTful specification and says that for each resource type the same set of interactions are defined, including read, search, create, update, and delete.
- HL7 FHIR R5 RESTful API (§3.2.0 Http): HL7's RESTful API page says servers can choose which interactions are made available and which resource types they support, and that servers SHALL provide a Capability Statement that specifies which interactions and resources are supported.
- HL7 FHIR R5 RESTful API (§3.2.0.1.10 Content Types and encodings): HL7's RESTful API page states that the formal MIME-type for FHIR resources is application/fhir+xml or application/fhir+json.
- HL7 FHIR R5 Overview (§2.1.15.4 The Specification): HL7's Overview notes that you do not have to use REST to make use of resources.
- HL7 FHIR R5 Summary: Introducing HL7 FHIR (§2.1.20.1 Why FHIR is better): HL7's Introducing HL7 FHIR summary lists a strong foundation in web standards including XML, JSON, HTTP, and OAuth, and support for RESTful architectures as well as exchange using messages or documents.
- Federal Register: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642, May 1, 2020): ONC's 21st Century Cures Act final rule (85 FR 25642, May 1, 2020) states that the final rule establishes API requirements, including for patients' access to their health information without special effort.
- Federal Register: 21st Century Cures Act final rule (85 FR 25642) — standardized API for patient and population services: ONC's Cures Act final rule says it adopted a new API certification criterion in 45 CFR 170.315(g)(10), the standardized API for patient and population services, added it to the updated 2015 Edition Base EHR definition, and that the criterion requires the use of the HL7 FHIR standard Release 4.
- Federal Register: 21st Century Cures Act final rule (85 FR 25642) — g(10) focus on single- and multiple-patient API services: ONC's Cures Act final rule says the standardized API for patient and population services criterion focuses on API-enabled services for which a single patient's data is the focus and services for which multiple patients' data are the focus, and advances interoperability of API-enabled read services for single and multiple patients.
- CMS: Interoperability and Patient Access Final Rule (CMS-9115-F) overview page: CMS's Interoperability and Patient Access final rule (CMS-9115-F) summary states CMS published the rule on May 1, 2020, and that it required or encouraged payers regulated under MA, Medicaid, CHIP, and QHP issuers on the FFEs to implement APIs to improve electronic exchange of health care data.
- CMS-9115-F Interoperability and Patient Access final rule PDF (Patient Access API / 45 CFR 170.215): CMS-9115-F finalizes that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs must implement and maintain a standards-based Patient Access API meeting technical standards at 45 CFR 170.215, then including HL7 FHIR Release 4.0.1.
- CMS-9115-F Interoperability and Patient Access final rule PDF (Patient Access API data classes): CMS-9115-F finalizes that through the Patient Access API, payers must permit third-party applications to retrieve, with the approval and at the direction of a current enrollee, specified data, and that at a minimum the API must make available adjudicated claims, encounters with capitated providers, and clinical data including laboratory results when maintained by the impacted payer.
- HL7 SMART App Launch IG v2.2.0 Overview: The HL7 SMART App Launch Overview states that the implementation guide describes foundational patterns based on OAuth 2.0 for client applications to authorize, authenticate, and integrate with FHIR-based data systems.
- HL7 SMART App Launch IG v2.2.0: App Launch and Authorization: The HL7 SMART App Launch Framework page says the framework connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system, including patient apps that launch standalone or from a portal.
- HL7 SMART App Launch IG v2.2.0 Overview (Scopes for Limiting Access): The HL7 SMART App Launch Overview says SMART uses scopes to define specific access permissions delegated to a client application, drawing on FHIR API definitions for interactions, resource types, and search parameters.
- HL7 FHIR R5 Overview (§2.1.15.6 Finding Additional Information): HL7's Overview says the FHIR specification is targeted to the implementation community — those who will actually write the software that uses the specification.
Start your 7-day free trialtilde is made by Triangle. 7-day free trial, then $9 a month. Cancel anytime.