FHIR explained: a common language for healthcare data

FHIR stands for Fast Healthcare Interoperability Resources. It is a standard published by HL7 for representing and exchanging healthcare information electronically.

That sentence is accurate, but it does not yet explain why FHIR exists. The useful starting point is the problem it tries to solve: healthcare systems often need the same information, but they do not naturally describe or exchange it in the same way.

A hospital may know a person by a medical-record number. A laboratory may identify the same person through an order. A patient-facing app may only have an authorization token and a FHIR endpoint. Even when all three systems agree that they are talking about a patient, they still need shared rules for the shape and meaning of the data.

FHIR supplies those rules.

A shared model, not a shared database

FHIR defines reusable data models called resources. A resource represents a recognizable healthcare or administrative concept:

• Patient describes demographic and administrative information about a person receiving care.
• Practitioner represents a person involved in providing care.
• Observation represents a measurement or assertion, such as a heart rate or laboratory result.
• Condition represents a clinical condition, problem, or diagnosis.
• MedicationRequest represents an order or request for medication.
• Appointment represents a planned meeting that may result in care.

Each resource has a documented structure, data types, constraints, and links to the terminology that gives coded values their meaning. The FHIR resource index groups the available resource types by purpose.

FHIR does not require every participating system to use the same internal database. A hospital can keep its existing clinical data model, while a pharmacy can keep a model designed around dispensing. Each system maps the information it shares to and from FHIR at its boundary.

This distinction matters. FHIR standardizes the contract between systems; it does not dictate every implementation detail behind that contract.

Resources are the building blocks

FHIR is designed around small, composable units instead of one enormous healthcare record. A useful exchange usually combines multiple resources.

For example, a laboratory result might involve:

Patient <- Observation -> Encounter
                  |
                  v
             Practitioner

The Observation carries the result and references the patient it belongs to. It may also reference the encounter in which it was collected and the practitioner responsible for it.

The next article in this track examines that resource structure in detail. For now, the important point is that resources can stand on their own and connect through explicit references.

FHIR is more than a REST API

FHIR is often introduced through HTTP endpoints such as:

GET /fhir/Patient/123
GET /fhir/Observation?patient=123&category=laboratory
POST /fhir/Appointment

The FHIR RESTful API defines common interactions for reading, searching, creating, updating, and deleting resources. This fits web and mobile development well, which is one reason FHIR feels approachable to software teams.

REST is only one exchange style. The specification also supports:

• Documents, where a Composition and its referenced content are packaged as a persistent clinical document.
• Messaging, where a Bundle represents an event and its supporting resources.
• Transactions and batches, where several operations travel together in one Bundle.
• Subscriptions, where a system can be notified when matching events occur.
• Bulk exchange, defined by implementation guides for exporting data sets rather than fetching resources one at a time.

The exchange pattern should follow the use case. A mobile application reading current allergies has different needs from a hospital sending a discharge document or an analytics platform importing a population-level export.

Where FHIR is applicable

FHIR is a good fit when independently built systems need a stable, documented healthcare-data contract. Common examples include:

Patient access

A patient-authorized application can read information such as medications, allergies, results, and appointments from a healthcare provider. FHIR describes the data; an authorization profile such as SMART App Launch defines how the application obtains access.

Clinical integration

An electronic health record can exchange orders and results with laboratories, imaging systems, referral platforms, or decision-support services.

Provider and payer workflows

Organizations can use FHIR-based implementation guides for prior authorization, coverage discovery, claims-related workflows, and exchange of clinical information.

Public health and research

FHIR can carry case reports, questionnaires, research definitions, and standardized data extracts when the relevant implementation guide supports the use case.

Internal platform APIs

An organization can expose a consistent FHIR boundary over several older systems. Consumers integrate with the shared contract instead of learning each source system independently.

FHIR can also be the wrong level of abstraction. A tightly coupled service with no healthcare semantics may be better served by a smaller purpose-built API. Adopting FHIR only for familiar HTTP conventions adds complexity without gaining interoperability.

The base standard is intentionally broad

The base Patient resource must serve many jurisdictions and workflows. A concrete project usually needs narrower rules:

• Which elements are mandatory?
• Which identifier systems are accepted?
• Which code systems and value sets should be used?
• Which search parameters must a server support?
• Which extensions are permitted?

FHIR answers these questions through profiles and implementation guides. A profile constrains or extends a base resource for a specific context. An implementation guide brings profiles, terminology, examples, and behavioral expectations together for a defined use case.

Two systems can both claim to support FHIR and still fail to interoperate if they implement different versions or incompatible profiles. Real interoperability requires agreement on the base version and the applicable implementation guide.

What FHIR does not solve by itself

FHIR is not a complete integration strategy.

It does not automatically:

• match patient identities across organizations;
• guarantee that source data is complete or clinically correct;
• choose the right terminology for a local workflow;
• define every authorization policy;
• secure a deployment simply because its payloads are valid FHIR;
• remove the need for consent, audit, governance, and operational monitoring.

The FHIR security guidance is explicit that FHIR is not itself a security protocol. Production systems still need transport security, authentication, authorization, auditing, and privacy controls appropriate to the data.

R4, R4B, and R5

FHIR is released in named versions. You will commonly encounter:

• R4 (4.0.1), which contains the first normative parts of the standard.
• R4B (4.3.0), an intermediate release focused on selected changes.
• R5 (5.0.0), the current published specification.

Many foundational ideas are stable across them: resources have types and identities, elements have cardinalities and data types, references connect resources, and profiles state additional conformance rules. Individual resources and elements can still differ, so an implementation must declare and respect the version it uses. HL7 maintains version-management guidance and comparison material for this reason.

The examples in this track focus on concepts shared by R4 and R5. When building against a real endpoint, use the exact specification and implementation guide named by that endpoint.

A practical mental model

Think of FHIR as four cooperating layers:

1. Resources define the reusable healthcare data shapes.
2. Terminology gives coded information a shared meaning.
3. Profiles and implementation guides narrow the standard to a use case.
4. Exchange mechanisms move the resulting resources between systems.

If you start with the use case, identify the relevant implementation guide, and then inspect the required resources, FHIR becomes much less intimidating. The next step is to open one of those resources and learn how its pieces fit together.