FHIRFast Healthcare Interoperability Resources
In short
FHIR is the HL7 International standard that organises health data into reusable pieces called resources (patient, observation, medication), which different systems read and write the same way. Resources are exchanged mainly through web APIs, like the ones modern apps use. Regulations and national networks in countries such as the US, Brazil and India rely on it today.
- Type
- Standard
- Steward
- HL7 International
- Current version
- R5 (5.0.0)
- Reviewed
- October 25, 2026
Explanation
What it is
FHIR (Fast Healthcare Interoperability Resources) is an HL7 International standard that models health data as resources: small, well-defined units such as Patient, Observation, Condition or MedicationRequest. Every resource shares a common structure, is represented in JSON or XML and is identified by a URL.
How it is exchanged
The standard describes several exchange methods that can be combined:
- REST API: read, search, create and update resources over HTTP.
- Documents: a Bundle headed by a Composition that travels as a unit, as in the IPS.
- Messaging: Bundles sent from one system to another.
- Services and operations, such as $expand or $validate-code for terminologies.
- Subscriptions, to notify another system when something changes.
FHIR is rarely used "as is". Countries and communities publish implementation guides with profiles that constrain and extend resources for a specific use case, such as the IPS or national guides.
Versions
| Release | Number | Year | Status |
|---|---|---|---|
| R4 | 4.0.1 | 2019 | First with normative content |
| R4B | 4.3.0 | 2022 | Trial use |
| R5 | 5.0.0 | 2023 | Current published version |
| R6 | 6.0.0 (draft) | — | Under ballot at HL7; the second full ballot came out in July 2026 |
As of October 2026, R5 is the current published version; even so, guides such as the IPS, Brazil's RNDS guide and India's ABDM guide are built on R4.
Common misconceptions
- "Having FHIR" does not guarantee interoperability. Two FHIR servers that share neither an implementation guide nor terminologies will not understand each other.
- FHIR alone is not enough to authorize app access. That is what SMART App Launch is for: it builds on OAuth 2.0, and ONC (formerly ASTP/ONC) certification requires it in the US.
- Releases are not interchangeable: an R4 client cannot read R5 without conversion.
- FHIR does not instantly replace HL7 v2 or CDA. They coexist, and in 2025 HL7 published an official guide for mapping v2 messages to FHIR.
Usage examples
In the US, ONC (formerly ASTP/ONC) certification criterion § 170.315(g)(10) requires a FHIR API with US Core profiles and SMART App Launch authorization.
The CMS Blue Button 2.0 API uses FHIR to deliver Medicare claims data to the apps a beneficiary authorizes.
Brazil's RNDS publishes its profiles in a FHIR R4 (4.0.1) guide; its first exchange was the notification of SARS-CoV-2 test results.
In India, NRCeS publishes the FHIR R4 guide for ABDM, the National Health Authority's program, with profiles for prescriptions, discharge summaries and diagnostic reports.
The HL7 IPS is a FHIR R4 guide: a server generates it on demand with the $summary operation.
A laboratory publishes its results as Observation resources grouped in a DiagnosticReport so the medical record can query them.
Relation to other terms
Relies on4
- LOINCStrong
The base specification's vital signs profile requires those data to be represented with LOINC codes.
- SNOMED CTStrong
The base specification uses SNOMED CT value sets mainly as example bindings; it is widely used in national guides and in the IPS.
- Value setStrong
Almost all FHIR elements with a coded data type are bound to a value set with a binding strength.
- UCUMMedium
Quantity recommends UCUM units; the Age, Duration, Distance and Count types require UCUM only when the unit system is given.
Depend on this one12
- IHE MHDRequired
MHD is defined on FHIR R4: its transactions use resources such as DocumentReference and List.
- IPSRequired
The HL7 guide defines the IPS as a FHIR R4 document; HL7 publishes a CDA R2 representation as the alternative.
- SMART App LaunchRequired
SMART authorizes access to FHIR servers and expresses permissions in terms of FHIR resource types.
- Consent managementMedium
FHIR offers the Consent resource and the IHE PCF profile builds on it; there are also non-FHIR implementations, such as IHE BPPC.
- DPI-HMedium
The report cites HL7 FHIR as an example of a messaging standard for the interoperability layer.
- HIEMedium
An HIE can expose FHIR APIs (OpenHIE accepts FHIR transactions as an alternative), but the concept does not depend on any one standard.
- IHEMedium
IHE's newer profiles, such as MHD, PIXm, PDQm or IUA, are defined on FHIR or REST APIs.
- IHE ATNAMedium
Only when RESTful ATNA is used, which records and queries audit events as FHIR AuditEvent resources.
- MPI / EMPIMedium
PIXm, PDQm and PMIR offer the same functions on FHIR; an MPI can work without FHIR.
- OpenHIEMedium
Some workflows, such as registering a patient, offer FHIR transactions as an alternative to those based on HL7 v2.
- TEFCAMedium
TEFCA has a standard operating procedure for facilitated FHIR exchange, which coexists with document-based exchange.
- Terminology serverMedium
FHIR defines a standard terminology service interface, but a terminology server can offer other interfaces.
Sources
- HL7 FHIR — Directory of published versionshl7.org
- HL7 FHIR — Exchange modulehl7.org
- HL7 Version 2 to FHIR Implementation Guidehl7.org
- ONC — § 170.315(g)(10) Standardized API for patient and population serviceshealthit.gov
- CMS — Blue Button 2.0 API documentationbluebutton.cms.gov
- Ministério da Saúde — RNDS, guia de implementação FHIRrnds-fhir.saude.gov.br
- Ministério da Saúde — Guia da RNDS: introduçãornds-guia.saude.gov.br
- NRCeS — FHIR Implementation Guide for ABDMnrces.in
- HL7 — International Patient Summary Implementation Guidehl7.org
- Federal Register — HHS Statement of Organization: Office of the National Coordinator for Health IT (91 FR 16204, 1 April 2026)federalregister.gov