FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for representing healthcare data as typed JSON or XML "resources" and exchanging them over a REST API. If you can call a web API, you can read a Patient, write an Observation or search for lab results on any FHIR server. This guide explains HL7 FHIR for developers: the resource model, the API, the versions, profiles, terminologies, SMART on FHIR, and where FHIR fits in Europe.

Key takeaways

FHIR models healthcare data as roughly 145 resource types in R4, such as Patient, Observation and Encounter, linked by references.
Every FHIR server exposes the same REST pattern: GET /Patient/123, POST /Observation, GET /Observation?patient=123.
R4 (4.0.1) is still the version most production systems use; R5 (5.0.0) is the current published release, and R6 is in ballot as of October 2026.
Profiles and implementation guides (US Core, the International Patient Summary, German base profiles) constrain FHIR for a country or use case.
Codes come from terminologies like LOINC, SNOMED CT and UCUM, not free text.
SMART on FHIR adds OAuth 2.0 based authorization and app launch on top of the API.

What is FHIR, in one paragraph

FHIR is a specification published by HL7 International. The first draft standard for trial use (DSTU1) appeared in September 2014, and the specification has gone through several releases since. FHIR takes ideas from earlier HL7 standards (v2 messaging and the CDA document format) and rebuilds them with web-native tools: resources with stable URLs, JSON as a first-class format, HTTP verbs for operations, and OAuth for security. The result is a standard a typical web or mobile developer can pick up in an afternoon, while still being expressive enough for hospitals, labs and payers.

If you are coming from HL7 v2, read our comparison of FHIR vs HL7 v2 after this one.

Resources: the building blocks

A resource is a typed object with a defined set of elements. Think of it as a class in your application, except the class is defined once, internationally, so other systems understand it too. The FHIR R4 resource list covers clinical concepts (Condition, Observation, MedicationRequest), administration (Patient, Practitioner, Organization, Encounter), workflow (Task, Appointment, CarePlan) and infrastructure (Bundle, CapabilityStatement, OperationOutcome).

Every resource shares a few common parts:

resourceType names the type, for example "Patient".
id is the logical id the server assigns.
meta holds the version id, last-updated time, profiles and tags.
extension lets you add data the base resource does not define, without breaking other systems.

Elements use primitive types (string, decimal, dateTime) and complex types (HumanName, Address, CodeableConcept, Quantity). For a practical walk-through with example JSON, the FHIR Basics guide in the Ovok docs covers resources, references, codeable concepts, identifiers and ValueSets.

References link resources together

Healthcare data is a graph. An Observation points to the Patient it is about; a DiagnosticReport points to several Observations; a MedicationRequest points to a Patient and a Practitioner. FHIR expresses each link as a Reference, such as {"reference": "Patient/123"}. It works much like a foreign key, but it can also point to a resource on another server or to an external identifier.

Identifiers are not ids

A resource id is local to one server. An identifier is a business identifier issued by some authority: a hospital medical record number, a national insurance number, a device serial. Each identifier has a system (a URI naming the issuer) and a value. Keeping the two apart is one of the first things that saves FHIR newcomers from duplicate-record bugs.

The FHIR REST API

FHIR defines a uniform RESTful API. Relative to a server's base URL, the core interactions are:

Read: GET [base]/Patient/123
Version read: GET [base]/Patient/123/_history/2
Create: POST [base]/Patient
Update: PUT [base]/Patient/123
Patch: PATCH [base]/Patient/123
Delete: DELETE [base]/Patient/123
Search: GET [base]/Observation?patient=123&code=http://loinc.org|8867-4
History: GET [base]/Patient/123/_history
Capabilities: GET [base]/metadata

On top of these, FHIR has Bundles for sending many operations at once (as a batch or an all-or-nothing transaction), named operations such as $everything or $lastn, and Subscriptions for change notifications. Errors come back as an OperationOutcome resource with a severity, a code and a human-readable diagnostic.

Search deserves its own article, and it has one: our practical FHIR API and search guide covers search parameters, modifiers, chaining, _include, paging, transactions and conditional writes with concrete HTTP examples.

FHIR versions: R4, R4B, R5 and R6

Version choice matters because resources and search parameters change between releases, and servers usually support one version per endpoint. According to the official FHIR version history, as of October 2026:

R4 (4.0.1), published December 2018, mixes normative and trial-use content. It is the version most production servers, national profiles and certification programmes target today.
R4B (4.3.0), published May 2022, is an interim release between R4 and R5. Few projects target it directly.
R5 (5.0.0), published March 2023, is the current published version. It reworked Subscriptions (topic-based) and many workflow resources.
R6 is in development. HL7's package list shows several R6 ballots, the latest dated July 2026. Do not build on ballot versions for production.

Practical advice: unless a partner or regulation requires R5, start on R4. Most implementation guides you will need to conform to, including US Core and the German base profiles, are R4-based. Ovok's FHIR API is R4 (4.0.1), which you can confirm on the CapabilityStatement route.

Profiles and implementation guides

Base FHIR is deliberately loose: most elements are optional and most codes are examples. Real exchange needs tighter rules. That is what profiles do. A profile (a StructureDefinition) constrains a resource: this element is required, that code must come from this ValueSet, this extension is allowed. Profiles, ValueSets, examples and narrative get bundled into an implementation guide (IG).

IGs you are likely to meet:

US Core defines the minimum FHIR profiles for US health IT and is the baseline most US systems build on. The current release is US Core STU9 (9.0.0), published May 2026.
International Patient Summary (IPS) specifies a minimal, specialty-agnostic patient summary for cross-border care. IPS STU2 was published in 2025, with a 2.0.1 update in June 2026.
HL7 Europe European Patient Summary aims to define a European standard for the Patient Summary and to prepare the ground for the European EHR exchange format. Its 1.0.0 ballot was published in June 2026 and states that it was validated for consistency with EHDS requirements.
German base profiles (Basisprofile DE) from HL7 Deutschland define German identifiers (such as the 10-digit health insurance number, KVID) and code systems. See ig.fhir.de.
ISiK (Informationstechnische Systeme in Krankenhäusern) is gematik's FHIR interface specification for German hospital systems, released in modules and stages. The specification lives on gematik's GitHub.
MII core data set (Kerndatensatz) is the set of FHIR profiles that the German Medical Informatics Initiative uses for exchanging data across university hospitals. See the MII implementation guides.

When a partner says "we speak FHIR", the next question should always be "which version and which profiles?"

Terminologies: LOINC, SNOMED CT and UCUM

FHIR moves the structure; terminologies carry the meaning. Coded elements use a CodeableConcept, which holds one or more codings, each with a system URI, a code and an optional display.

[LOINC](https://loinc.org/) identifies observations and measurements: 8867-4 is heart rate, 8480-6 systolic blood pressure, 2345-7 glucose in serum or plasma. System URI: http://loinc.org.
[SNOMED CT](https://www.snomed.org/) covers clinical findings, procedures, body sites and much more. System URI: http://snomed.info/sct. Use requires a licence, which is free in member countries.
[UCUM](https://ucum.org/) defines machine-readable units: mm[Hg], /min, mg/dL. In a Quantity, set system to http://unitsofmeasure.org and put the UCUM expression in code.

National code systems sit next to these. German projects often need ICD-10-GM, OPS, ATC and PZN. A ValueSet narrows a code system to the codes valid for one use, and a terminology server can expand ValueSets and validate codes. Ovok exposes standard operations for this, such as expanding a ValueSet.

SMART on FHIR in one section

SMART App Launch is the HL7 implementation guide that standardises how apps authenticate against a FHIR server. It builds on OAuth 2.0 and OpenID Connect and adds:

a discovery document at [base]/.well-known/smart-configuration;
scopes that map to FHIR access, such as patient/Observation.rs (read and search the launch patient's Observations) or user/*.cruds;
EHR launch (the app opens inside a clinical system with context) and standalone launch;
backend services authorization with client_credentials and signed JWT client assertions.

The current release is SMART App Launch 2.2.0 (STU 2.2, April 2024). Ovok publishes its SMART configuration and OpenID discovery documents; the health and discovery page lists the supported grants, scopes and PKCE method.

FHIR in the EU: the European Health Data Space

The European Health Data Space (EHDS) regulation entered into force on 26 March 2025. According to the European Commission, the main obligations phase in over several years:

From March 2029, patient summaries and ePrescriptions/eDispensations should be exchangeable in all Member States, and most secondary-use rules start to apply.
From March 2031, medical images, lab results and hospital discharge reports follow.
Individuals get the right to access their health data in a standard European electronic health record exchange format (EEHRxF).

The Commission's EHDS page does not itself name FHIR. In practice, the HL7 Europe guides above (such as the European Patient Summary) are being developed to prepare for the exchange format, and national programmes like Germany's ISiK and MII already use FHIR R4. If you build a digital-health product for European customers, designing your data model around FHIR now keeps your options open later. For backend choices with EU hosting in mind, see our guide to the best digital health backend for European startups.

Where FHIR shows up in a digital-health product

Remote patient monitoring. Device readings become Observations with LOINC codes and UCUM units, linked to a Patient and a Device. See Ovok for remote patient monitoring and our RPM platform comparison.
Questionnaires and patient-reported outcomes. Questionnaire and QuestionnaireResponse resources, with Observations extracted from answers.
Care plans and tasks. CarePlan, Goal and Task model what should happen and who does it.
Real-time apps. Subscriptions notify your app when matching data changes; see real-time FHIR Subscriptions over WebSockets.
Integration with hospitals and labs. Partners increasingly expose FHIR APIs, which means less custom mapping per partner.

How to start with FHIR

Read the resource pages for Patient, Observation and Bundle in the R4 specification. Skim, do not memorise.
Get a FHIR server to play with. The Ovok Developer sandbox gives you a FHIR R4 API (REST and GraphQL) with Access Policies for multi-tenant projects; Ovok is hosted on AWS in Frankfurt.
Call GET [base]/metadata and look at the CapabilityStatement: which resources, interactions and search parameters the server supports.
Create a Patient, then an Observation referencing it, then search for it. Follow the Ovok project setup guide to get credentials.
Pick the profiles your market needs (US Core, Basisprofile DE, IPS) and validate against them early.
Lock down access before you load real data. Read the Access Policies docs first.

FAQ

What does FHIR stand for?

Fast Healthcare Interoperability Resources. It is pronounced "fire" and published by HL7 International.

Is FHIR a database?

No. FHIR is a data model and an API specification. A FHIR server stores resources however it likes internally, as long as it exposes the standard API and resource shapes.

Should I use FHIR R4 or R5?

For most new products in 2026, R4. National profiles, certification programmes and most partner systems are R4-based. Choose R5 only if a partner or a specific feature requires it.

Is FHIR only for hospitals?

No. FHIR is used by payers, labs, public health, research networks and digital-health startups. Its REST and JSON design makes it a natural fit for mobile and web apps.

Do I need to buy LOINC or SNOMED CT?

LOINC is free to use under its licence. SNOMED CT requires a licence, which SNOMED International member countries provide to their users at no charge. Check the terms for your country.

What is the difference between FHIR and SMART on FHIR?

FHIR defines data and the API. SMART on FHIR defines how apps get authorised to use that API, using OAuth 2.0, scopes and launch context.

Does the EHDS require FHIR?

The Commission's EHDS overview refers to a European electronic health record exchange format rather than naming FHIR. HL7 Europe's FHIR guides are being prepared for that format, so FHIR knowledge is a sound investment for EU products.

Conclusion

FHIR gives healthcare a shared vocabulary and a familiar web API. Learn resources and references, start on R4, pick your profiles and terminologies deliberately, and put authorization in place from day one. The quickest way to learn is to make real calls: create a free project in the Ovok Developer sandbox, keep the Ovok docs open, and check pricing or the Ovok offer for startups when you are ready to move to production.