What Is FHIR? How the HL7 FHIR Standard Works

FHIR (Fast Healthcare Interoperability Resources) is a standard for representing and exchanging healthcare information electronically. It is published by HL7 International, the same standards body behind HL7 v2 and CDA. Instead of large, monolithic messages or documents, FHIR breaks clinical and administrative data into small, well-defined building blocks called resources (Patient, Observation, Encounter, MedicationRequest and so on) and exposes them through a web API that any developer familiar with HTTP and JSON can read.

That combination of a precise healthcare data model with ordinary web technology is why FHIR spread quickly. A team that has built a REST API before can make its first FHIR request in minutes, yet the resource definitions carry decades of clinical modeling experience. If you are trying to understand how FHIR relates to older HL7 standards, read HL7 vs FHIR after this guide.

A resource is the smallest unit of exchange in FHIR that makes sense on its own. Each resource type has a defined set of elements, data types, cardinality rules and a stable identity: every instance has a logical id and can be addressed at a URL such as [base]/Patient/123. The base specification defines roughly 150 resource types, grouped into areas such as foundation, base (individuals, entities, workflow), clinical, financial and specialized.

Resources link to each other through references. An Observation points to its subject Patient, an Encounter points to the Location and Practitioner involved, and a MedicationRequest points to the requester. Following those references lets a client assemble a full clinical picture without the server needing to pre-package it. Our FHIR resources guide walks through the resource types you will meet most often.

{
  "resourceType": "Patient",
  "id": "example-123",
  "identifier": [
    { "system": "http://hospital.example.org/mrn", "value": "MRN-004512" }
  ],
  "name": [{ "family": "Rivera", "given": ["Ana"] }],
  "gender": "female",
  "birthDate": "1984-07-19"
}

Every resource can also carry a human-readable narrative (an XHTML summary in text), plus meta information such as version id, last-updated timestamp and the profiles it claims to conform to.

The most common way to use FHIR is its RESTful API. Resources live at predictable URLs and are manipulated with standard HTTP verbs. The specification defines a small set of interactions that every developer should know:

Beyond these, FHIR defines operations, invoked with a $ prefix, for behavior that does not fit simple CRUD: $everything on Patient, $validate, terminology operations such as $expand and $translate, and $export for bulk data. Servers declare which interactions, search parameters and operations they support in their CapabilityStatement, so a client can discover what is possible before sending real traffic. The FHIR API integration guide covers those mechanics in depth.

FHIR resources have three official serializations: JSON, XML and RDF (Turtle). JSON dominates modern API work; XML remains common where existing tooling expects it. Clients select a format with the Accept header (application/fhir+json or application/fhir+xml) or the _format parameter.

REST is not the only option. The same resources can travel in other ways:

• Documents: a Bundle of type document whose first entry is a Composition, used for signed, persistent clinical documents such as discharge summaries.
• Messaging: a Bundle of type message with a MessageHeader, for event-driven exchange similar in spirit to HL7 v2.
• Subscriptions: servers notify clients when relevant data changes. R5 redesigned this around subscription topics, and a backport implementation guide brings that model to R4.
• Bulk data: the FHIR Bulk Data Access IG defines $export, which produces newline-delimited JSON files for population-level analytics and payer use cases.

The base specification is intentionally broad so it can serve hospitals, labs, payers, public health and research worldwide. Almost every element is optional. That flexibility is useful, but two systems that are both "FHIR compliant" can still fail to understand each other. Profiles solve this.

A profile is a StructureDefinition that constrains a base resource for a particular use: making elements required, fixing code systems, limiting cardinality and marking which elements a system must support. Profiles, along with value sets, search parameter rules and narrative guidance, are packaged into an implementation guide (IG). In the United States, the US Core IG is the foundation that certified EHR APIs are tested against; other countries publish their own national base IGs, and domains such as payer exchange, oncology and public health have specialized IGs.

When the base model lacks something you need, FHIR provides extensions. Every resource and data type can carry extensions identified by a canonical URL that points to a definition. Extensions keep the core model small while letting local needs be represented in a computable, discoverable way. Elements marked modifierExtension change the meaning of the data and must be understood by the receiver, so they are used sparingly.

FHIR was first published as a draft standard in 2014 and has gone through several releases. Each release is a separate, versioned specification, and resources are not automatically compatible across releases.

Within each release, every resource carries a FHIR Maturity Model (FMM) level from 0 to 5, or a Normative status. Normative content is expected to change only in backward-compatible ways, which is why regulators and EHR vendors anchored on R4. For a detailed look at the differences, see FHIR R4 vs R5.

HL7 International maintains FHIR through an open, consensus-based process. Work groups made up of volunteers from providers, vendors, payers and governments propose changes, publish ballots and resolve comments. Anyone can read the specification for free at hl7.org/fhir and follow development builds, and an open-source reference server, HAPI FHIR, along with HL7's official validator, help implementers test their work.

Regulation has accelerated adoption. In the US, the 21st Century Cures Act and ONC's certification rules require certified EHRs to offer standardized FHIR APIs secured with SMART on FHIR, and CMS rules require many payers to expose FHIR APIs for patient access, provider access, payer-to-payer exchange and prior authorization. Other countries are building national FHIR profiles for health records exchange. The result is that FHIR is now the default choice for new healthcare APIs, even when HL7 v2 still carries much of the traffic inside hospitals.

If you are planning a project, the FHIR implementation playbook explains the steps, and the FHIR integration companies directory lists firms that do this work.