FHIR R5 — Fast Healthcare Interoperability Resources

HL7's modern REST/JSON layer. Designed in 2012 to make healthcare data as easy to consume as a web API: atomic resources, open schemas, national profiles.

What is FHIR?

FHIR — pronounced "fire" — is an interoperability standard published by HL7 International that replaces HL7 v2's messaging philosophy and HL7 CDA's document approach with a resource philosophy: every concept of the healthcare domain (Patient, Observation, Encounter, MedicationRequest…) is represented as a typed structure, serialisable in JSON or XML, and exposed via a standard REST API.

The goal: make writing a healthcare client as straightforward as writing a GitHub or Stripe client. A developer who knows HTTP, JSON and OAuth 2 can consume a FHIR server without HL7 training. That accessibility drove rapid adoption: by 2026, Epic, Cerner / Oracle Health, Athenahealth, Allscripts, Apple Health, Google Cloud Healthcare API, AWS HealthLake and virtually every US EHR expose a FHIR R4 or R5 layer.

FHIR coexists with HL7 v2 rather than replacing it: real-time flows (ADT, ORU) often stay on v2, while patient APIs, interoperable portals and mobile apps consume FHIR.

Anatomy of a FHIR resource

A FHIR resource is a JSON (or XML) object with an explicit type, a technical id, fields typed against the StructureDefinition published by HL7, and — optionally — extensions. Here is the canonical Patient example published by HL7 on the reference page:

{
  "resourceType": "Patient",
  "id": "example",
  "identifier": [{
    "system": "urn:oid:1.2.36.146.595.217.0.1",
    "value": "12345"
  }],
  "active": true,
  "name": [{
    "use": "official",
    "family": "Chalmers",
    "given": ["Peter", "James"]
  }],
  "telecom": [{
    "system": "phone",
    "value": "(03) 5555 6473",
    "use": "work"
  }],
  "gender": "male",
  "birthDate": "1974-12-25",
  "address": [{
    "use": "home",
    "line": ["534 Erewhon St"],
    "city": "PleasantVille",
    "state": "Vic",
    "postalCode": "3999"
  }]
}

Three structuring principles:

• resourceType first — the discriminator that lets a generic client dispatch correctly.
• Data types — every field follows a FHIR type (string, boolean, code, HumanName, Address, Identifier, Reference, Coding, CodeableConcept, Period…). Semantic vocabularies (LOINC, SNOMED CT, ICD-10, RxNorm) travel through Coding / CodeableConcept.
• Extensions — for local needs, FHIR allows adding URL-typed extension[] entries. National profiles (US Core, FR Core, NL Core…) define their own extensions.

Versions

HL7 International has been publishing FHIR since 2012. Each major release supersedes the previous one after an overlap period, and production servers can expose several versions simultaneously.

Resource families

FHIR R5 publishes around 157 resources, grouped by clinical and technical themes. The most prominent:

The REST API

The core of FHIR is its REST API specification. Examples of typical endpoints on a conformant server:

• GET /Patient/{id} — read a Patient resource by its technical identifier.
• POST /Patient — create a Patient resource (the id is allocated by the server).
• PUT /Patient/{id} — update a Patient resource.
• GET /Patient?identifier=urn:oid:1.2.3|MRN12345 — search a resource by business identifier.
• GET /Patient/{id}/$everything — composite operation that returns all related resources.
• GET /metadata — return the server's CapabilityStatement (what it knows how to do).

Responses are always FHIR resources. When searching, the server returns a Bundle typed searchset that aggregates the matches. When operating on several resources at once (transaction, batch), the client POSTs a Bundle typed transaction at the server root.

Security almost universally uses OAuth 2 + OpenID Connect, framed by SMART on FHIR for third-party apps embedded in an EHR.

Implementation Guides

Raw FHIR is not immediately deployable: it must be constrained. Implementation Guides (IGs) do this by publishing profiles (a StructureDefinition that restricts a resource), ValueSets and extensions specific to a use case or country.

Comparison with HL7 v2

Further reading

Detailed FHIR resource pages on ediverse:

• Patient — the foundational demographic resource
• Bundle — transaction and search container

Related standards:

• HL7 v2.x — the clinical messaging backbone
• X12 transactions 270/271/278/834/835/837 — the HIPAA administrative layer

Official specifications:

• FHIR R5 — Specification (release of 26 March 2023, copyright HL7 International, CC-BY 4.0 on resources).
• FHIR R5 — Resource List to browse the 157 published resources.
• International Patient Summary (IPS) — cross-border IG.
• US Core Implementation Guide — ONC-mandated profile.
• SMART App Launch Framework — OAuth 2 / OpenID Connect authorisation layer for FHIR.
• FHIR Management Group — HL7 governance body.