FHIR (Fast Healthcare Interoperability Resources)

FHIR (Fast Healthcare Interoperability Resources) is an HL7 International standard for exchanging healthcare information using modular data units called resources and web-style application programming interfaces. It combines the structured information modelling of earlier HL7 standards with widely used web technologies — RESTful APIs, JSON and XML serialisation, and standard HTTP — to make health data easier to access and to build applications on.

Definition

FHIR is a standard that represents clinical and administrative data as discrete, self-contained resources — each with a defined structure and a stable identity — and exchanges them through a RESTful application programming interface over standard web protocols, so that systems and applications can read, write, and search health data in an interoperable way.

Scope

This entry covers the FHIR resource model, its RESTful exchange paradigm, profiling for local needs, and its relationship to earlier HL7 standards and to substitutable applications such as SMART on FHIR. It treats FHIR as a data-exchange standard and a methodological topic; it does not give implementation, security configuration, or procurement guidance.

Core questions

• What is a FHIR resource, and how do resources combine to represent a patient record?
• How does the RESTful API approach differ from HL7 v2 messaging?
• What are profiles and extensions, and why are they needed?
• How does FHIR enable substitutable applications such as SMART on FHIR?

Key concepts

• Resources (Patient, Observation, Encounter, MedicationRequest, etc.)
• RESTful API (create, read, update, delete, search)
• JSON and XML serialisation
• References and bundles
• Profiles and extensions
• Implementation guides
• SMART on FHIR substitutable applications

Mechanisms

FHIR models healthcare information as resources — modular units such as Patient, Observation, or MedicationRequest — each with a defined set of elements and a stable, addressable identity. Resources reference one another, and groups of resources can be assembled into bundles. Systems exchange them through a RESTful interface in which standard HTTP operations create, read, update, delete, and search resources, with data serialised as JSON or XML. Because individual deployments need local constraints, FHIR supports profiling: profiles and extensions tailor base resources to a jurisdiction or use case, and implementation guides package these for a community. This resource-and-API design also underpins substitutable applications, where an app authorised against a FHIR endpoint (the SMART on FHIR pattern) can run across conforming systems.

Clinical relevance

FHIR is increasingly the basis for patient-facing apps, clinical data access, and cross-organisation exchange, and it features in national interoperability policy. This entry describes how FHIR structures and exposes data; it is reference material about the standard and is not guidance for building, securing, or deploying any clinical system.

Evidence & guidelines

FHIR is a normative HL7 International standard, developed and balloted through HL7, with national and regional implementation guides constraining it for local use. Bender and Sartipi (2013) is an early technical description of the standard's RESTful design; Benson and Grieve's textbook gives a consolidated account of FHIR alongside HL7 and SNOMED CT, and Mandl and Kohane (2012) provide the policy rationale for the open, app-based architecture FHIR supports.

History

FHIR was initiated by HL7 around 2011-2012, led by Grahame Grieve, as a deliberately lighter-weight alternative to HL7 version 3 that reused mainstream web technologies. Early descriptions such as Bender and Sartipi (2013) framed it as an agile, RESTful approach, and the standard advanced through successive releases toward normative status during the 2010s, converging with policy arguments for open, substitutable health IT.

Debates

How well does FHIR achieve true semantic interoperability?

FHIR standardises structure and exchange well, but consistent meaning still depends on disciplined use of profiles and terminology bindings; variation in profiling across implementations can limit out-of-the-box semantic interoperability.

Key figures

• Grahame Grieve
• Duane Bender
• Kamran Sartipi
• Kenneth Mandl
• Isaac Kohane

Seminal works

• bender-sartipi-2013
• benson-grieve-2021

Frequently asked questions

How is FHIR different from HL7 v2 messaging?

HL7 v2 sends event-driven messages with delimited segments, whereas FHIR exposes discrete resources through a RESTful web API that systems can read, write, and search directly, using mainstream formats such as JSON over HTTP.

What does SMART on FHIR mean?

SMART on FHIR is a pattern in which an application authorises against a FHIR endpoint using open standards, so the same app can run across different systems that expose conforming FHIR APIs; it is one motivation for FHIR's resource-and-API design.