📖 The problem FHIR wants to solve

To fully utilize computers in healthcare, information must be in a digital format that machines can process automatically, without human intervention. This requires using standardized formats that are structured for machine readability.

Making data machine-readable is crucial for automating processes, analyzing data, and enabling efficient data exchange between different systems.

Interoperability is the ability of different systems, software, or devices to exchange information and use it with a shared understanding. In healthcare, the goal is for authorized people and systems to use information such as patient records or measurements safely and consistently, even when different software is involved. A standard such as FHIR supports that goal, but it cannot eliminate misunderstandings or errors by itself.

Developers of healthcare standards aim to make different systems more interoperable. The standard provides a shared foundation; real integration also depends on agreed meaning, workflow, security, governance, testing, and reliable software.

Consider a patient in a hospital who requires a chest X-ray. Think about all the steps in which information must be generated and/or exchanged. Think about your own experiences in healthcare: how were these steps performed? Here is a suggestion of what the key steps at which clinical information is created or exchanged may be:

1. The physician documents the X-ray request, patient details, and clinical notes.
2. The request is sent to the radiology department.
3. Radiology schedules the procedure and informs the physician and patient.
4. The patient undergoes the X-ray.
5. The radiology team processes the images and prepares a report.
6. The images and report are sent back to the requesting physician.
7. The physician reviews the results, records the findings, and decides on the next steps.

Nowadays, dedicated computer systems and software are used to perform this kind of information exchange between departments and to store data for documentation.

An average-size hospital has a complex digital infrastructure to coordinate all the different bits and pieces, from encounters to procedures and the communication between different departments.

From your own experience, you might have seen how things can go wrong when exchanging medical information between practitioners, departments or encounters. Oftentimes, errors arise when different players use different systems that are not fully compatible with each other.

📖 The creation of FHIR in 2011

HL7^® FHIR^®1,2 is a healthcare standard that helps to exchange clinical information in a consistent format. It is one of many standards created and maintained by HL7^®. HL7® is a not-for-profit organization dedicated to improving interoperability in healthcare. FHIR is now used in many regional, national, and international healthcare projects.

The creation of FHIR in 2011 in its historical context

timeline
title 2011: the birth of HL7 FHIR (and the iPad 2)
1998 : SOAP is introduced
: Launch of Google
2000 : Roy Fielding publishes dissertation about REST
: CDA Release 1.0
: dot.com bubble burst
2005 : CDA Release 2.0
: Launch of Youtube
2011 : HL7<sup>®</sup> FHIR<sup>®</sup>[^FHIR] development starts under leadership of Graham Grieve
: iPad 2 release
: Samsung Galaxy II release
2017 : HL7<sup>®</sup> FHIR<sup>®</sup>[^FHIR] STU3 Release
2018 : HL7<sup>®</sup> FHIR<sup>®</sup>[^FHIR] R4 Release
2023 : HL7<sup>®</sup> FHIR<sup>®</sup>[^FHIR] R5 Release

HL7^® FHIR^®1 is relatively new: It was created by Graham Grieve in 2011. At that time, there already existed multiple successful standards, like CDA (Clinical document architecture) and HL7® version 2.

The HL7 community wanted to create a new standard that would use state-of-the-art technology and be accessible for developers and healthcare practitioners alike. Another important goal was to handle use cases that arose from the growing popularity of mobile devices.

2011 was also the year of the release of the iPad 2 and the Samsung Galaxy II.

Screenshot taken from Webdesignmuseum.org

📖 The scope of FHIR

HL7^® FHIR^®1 (Fast Healthcare Interoperability Resources) has a broad scope that covers various areas of healthcare, from clinical care to administrative tasks, and even extends to research use cases. It is designed to support the exchange of data in many contexts, such as sharing patient records, managing appointments and billing, or conducting clinical studies. This flexibility makes HL7^® FHIR^®1 relevant to a wide range of healthcare information-exchange use cases.

A key aspect of HL7^® FHIR^®1’s development is the involvement of medical experts who define these resources. These experts determine the essential clinical, administrative, and research information to be standardized, ensuring it is relevant and useful in real-world healthcare settings. By focusing on both the content and structure of the data, HL7^® FHIR^®1 provides a framework that supports interoperability. Implementations still need shared terminology, validation, governance, and clinical review to preserve accuracy and meaning in a real workflow.

FHIR is—and is not

FHIR is a standard for representing and exchanging healthcare information. It provides common data structures, rules, and exchange approaches.

FHIR is not an electronic health record, app, database, user interface, workflow, or clinical guideline. It also does not make a deployment secure or legally compliant by itself. Those responsibilities belong to the complete technical and organizational implementation.

📖 The client-server model

One of the key design choices in HL7^® FHIR^®1 was to use familiar web technologies. The web commonly uses a client-server model.

Imagine ordering in a restaurant. You are the client because you make a request. The restaurant is the server-side service that receives the request, prepares the result, and sends a response. A waiter may carry the request and response, but the waiter and kitchen do not need to be mapped to separate kinds of “server” in the analogy.

On the internet, a client such as an app sends a request to a server, which provides information or performs an allowed action. The server then returns a response.

For example, a clinical app could ask a FHIR server for the Patient resource with logical id 123. The app is the client. The FHIR server checks the request and can return the resource, report that it was not found, or reject a request that is not permitted.

The client-server model explains the roles in the conversation. HTTP and a FHIR API provide more detailed rules for the request and response.

📖 HTTP, REST and SOAP

The client-server model explains who asks and who responds. The systems also need shared rules for how to send a request and a response.

HTTP: the web protocol

HTTP is the protocol commonly used for communication on the web. It defines request methods such as GET and POST and describes how a server returns a response and status code.

In a FHIR RESTful API, a client might send an HTTP GET request for Patient/123. The server can respond with the Patient resource in JSON or XML, or with an error response when the request cannot be completed.

REST: an architectural style

REST (Representational State Transfer) is an architectural style, not a protocol. A RESTful API applies REST principles while commonly using HTTP as its protocol.

FHIR defines a RESTful API with standard interactions for its resource model, including create, read, update, delete, and search. This is a widely used way to exchange FHIR resources, but it is not the only one. FHIR also supports documents, messaging, subscriptions, operations, and other exchange patterns.

SOAP: optional historical context

SOAP is an XML-based messaging protocol used by many web services, especially in enterprise systems. It did not create or formalize all client-server communication on the web. SOAP can be combined with separate WS-* specifications for features such as message-level security and reliable messaging.

For this beginner course, the main point is simply that SOAP and REST are different approaches. FHIR can be used in service-oriented architectures, while its RESTful API is the most familiar starting point for many implementations.

Security comes from the complete implementation

Neither REST nor SOAP makes a system secure automatically. A production FHIR service normally needs several layers of protection, including:

• HTTPS to encrypt data in transit;
• authentication to establish who or what is connecting;
• authorization to decide what that identity may do;
• input validation, logging, monitoring, and auditing; and
• organizational controls that meet the applicable privacy and security requirements.

OAuth 2.0 is commonly used as part of an authorization solution, but it does not replace the other controls.

Useful links

FHIR RESTful API

Roy Fielding’s dissertation introducing REST

W3C SOAP specification

📖 JSON and XML

Structured data is organized according to defined fields and rules so software can store, search, and process it. In healthcare, examples include vital signs, diagnoses, medications, laboratory results, and allergies. A structure makes consistent exchange easier, but it does not guarantee that the entered data is complete or correct.

The main building blocks in HL7^® FHIR^®1 are called resources. A resource can be represented in formats such as JSON or XML.

JSON and XML are widely used beyond healthcare. FHIR uses familiar formats so systems can represent the same resource content in more than one machine-readable form.

JSON uses key-value pairs to represent data, which means it pairs a name (the key) with a piece of information (the value).

XML uses tags (special words enclosed in angle brackets, like <ingredient> or <step>) to label and describe different pieces of information.

A Patient resource in JSON and XML²

{
"resourceType" : "Patient",
"id" : "example",
"text" : {
  "status" : "generated",
  "identifier" : [{
    "use" : "usual",
    "type" : {
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
        "code" : "MR"
      }]
    },
  "system" : "urn:oid:1.2.36.146.595.217.0.1",
  "value" : "12345",
  "period" : {
    "start" : "2001-05-06"
    },
  "assigner" : {
    "display" : "Acme Healthcare"
  }
  }],
"active" : true,
"name" : [{
  "use" : "official",
  "family" : "Chalmers",
  "given" : ["Peter","James"]
  },
  {
    "use" : "usual",
    "given" : ["Jim"]
  },
  {
    "use" : "maiden",
    "family" : "Windsor",
    "given" : ["Peter",
    "James"],
    "period" : {
      "end" : "2002"
  }
}],
"telecom" : [{
"use" : "home"
},
{
"system" : "phone",
"value" : "(03) 5555 6473",
"use" : "work",
"rank" : 1
},
{
"system" : "phone",
"value" : "(03) 3410 5613",
"use" : "mobile",
"rank" : 2
},
{
"system" : "phone",
"value" : "(03) 5555 8834",
"use" : "old",
"period" : {
"end" : "2014"
}
}],
"gender" : "male",
"birthDate" : "1974-12-25",
"\_birthDate" : {
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/patient-birthTime",
"valueDateTime" : "1974-12-25T14:35:45-05:00"
}]
},
"deceasedBoolean" : false,
"address" : [{
"use" : "home",
"type" : "both",
"text" : "534 Erewhon St PeasantVille, Rainbow, Vic 3999",
"line" : ["534 Erewhon St"],
"city" : "PleasantVille",
"district" : "Rainbow",
"state" : "Vic",
"postalCode" : "3999",
"period" : {
"start" : "1974-12-25"
}
}],
"contact" : [{
"relationship" : [{
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0131",
"code" : "N"
}]
}],
"name" : {
"family" : "du Marché",
"\_family" : {
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/humanname-own-prefix",
"valueString" : "VV"
}]
},
"given" : ["Bénédicte"]
},
"telecom" : [{
"system" : "phone",
"value" : "+33 (237) 998327"
}],
"address" : {
"use" : "home",
"type" : "both",
"line" : ["534 Erewhon St"],
"city" : "PleasantVille",
"district" : "Rainbow",
"state" : "Vic",
"postalCode" : "3999",
"period" : {
"start" : "1974-12-25"
}
},
"gender" : "female",
"period" : {
"start" : "2012"
}
}],
"managingOrganization" : {
"reference" : "Organization/1"
}
}

<?xml version="1.0" encoding="UTF-8"?>

<Patient xmlns="http://hl7.org/fhir">
  <id value="example"/>
      <!--     MRN assigned by ACME healthcare on 6-May 2001     -->
<identifier>
    <use value="usual"/>
    <type>
      <coding>
        <system value="http://terminology.hl7.org/CodeSystem/v2-0203"/>
        <code value="MR"/>
      </coding>
    </type>
    <system value="urn:oid:1.2.36.146.595.217.0.1"/>
    <value value="12345"/>
    <period>
      <start value="2001-05-06"/>
    </period>
    <assigner>
      <display value="Acme Healthcare"/>
    </assigner>
  </identifier>
  <active value="true"/>
      <!--     Peter James Chalmers, but called "Jim"     -->
  <name>
    <use value="official"/>
    <family value="Chalmers"/>
    <given value="Peter"/>
    <given value="James"/>
  </name>
  <name>
    <use value="usual"/>
    <given value="Jim"/>
  </name>
  <name>
        <!--    Maiden names apply for anyone whose name changes as a result of marriage - irrespective
     of gender    -->
    <use value="maiden"/>
    <family value="Windsor"/>
    <given value="Peter"/>
    <given value="James"/>
    <period>
      <end value="2002"/>
    </period>
  </name>
  <telecom>
    <use value="home"/>
        <!--     home communication details aren't known     -->
  </telecom>
  <telecom>
    <system value="phone"/>
    <value value="(03) 5555 6473"/>
    <use value="work"/>
    <rank value="1"/>
  </telecom>
  <telecom>
    <system value="phone"/>
    <value value="(03) 3410 5613"/>
    <use value="mobile"/>
    <rank value="2"/>
  </telecom>
  <telecom>
    <system value="phone"/>
    <value value="(03) 5555 8834"/>
    <use value="old"/>
    <period>
      <end value="2014"/>
    </period>
  </telecom>
      <!--     use FHIR code system for male / female     -->
  <gender value="male"/>
  <birthDate value="1974-12-25">
    <extension url="http://hl7.org/fhir/StructureDefinition/patient-birthTime">
      <valueDateTime value="1974-12-25T14:35:45-05:00"/>
    </extension>
  </birthDate>
  <deceasedBoolean value="false"/>
  <address>
    <use value="home"/>
    <type value="both"/>
    <text value="534 Erewhon St PeasantVille, Rainbow, Vic  3999"/>
    <line value="534 Erewhon St"/>
    <city value="PleasantVille"/>
    <district value="Rainbow"/>
    <state value="Vic"/>
    <postalCode value="3999"/>
    <period>
      <start value="1974-12-25"/>
    </period>
  </address>
  <contact>
    <relationship>
      <coding>
        <system value="http://terminology.hl7.org/CodeSystem/v2-0131"/>
        <code value="N"/>
      </coding>
    </relationship>
    <name>
      <family value="du Marché">
            <!--     the "du" part is a family name prefix (VV in iso 21090)     -->
        <extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-prefix">
          <valueString value="VV"/>
        </extension>
      </family>
      <given value="Bénédicte"/>
    </name>
    <telecom>
      <system value="phone"/>
      <value value="+33 (237) 998327"/>
    </telecom>
    <address>
      <use value="home"/>
      <type value="both"/>
      <line value="534 Erewhon St"/>
      <city value="PleasantVille"/>
      <district value="Rainbow"/>
      <state value="Vic"/>
      <postalCode value="3999"/>
      <period>
        <start value="1974-12-25"/>
      </period>
    </address>
    <gender value="female"/>
    <period>
          <!--     The contact relationship started in 2012     -->
      <start value="2012"/>
    </period>
  </contact>
  <managingOrganization>
    <reference value="Organization/1"/>
  </managingOrganization>
</Patient>

📖 Summary

Let’s look at our example from the beginning of this article, the patient needing an X-Ray. With HL7^® FHIR^®1, the steps could be carried out like this:

1. The physician records the request as a FHIR ServiceRequest in the EHR.
2. A FHIR RESTful API sends the request to radiology.
3. Radiology schedules an Appointment and the systems notify the physician and patient.
4. The completed X-ray is recorded as a Procedure.
5. The images are stored as an ImagingStudy and the report as a DiagnosticReport.
6. The report and its referenced images are returned to the physician’s EHR through the API.
7. The physician reviews the results and decides on the next steps.

Congratulations!

You now have a basic picture of the problem FHIR addresses and the web technologies it commonly uses. Next, learn how focused resources represent and connect the information in this X-ray story. The following unit then explains how profiles, extensions, implementation guides, and exchange approaches adapt that shared base for real projects.

📖 Useful links

Start here

HL7^® FHIR^® documentation

Official HL7^® FHIR^® Introduction for clinicians

Official HL7^® FHIR^® Introduction for patients

Official HL7^® FHIR^® Introduction for architects

Technical background

FHIR RESTful API

W3C SOAP specification

Dissertation of Roy Fielding

CDA documentation

Examples from Europe

European usage of HL7^® FHIR^®: European Health Data Space - EHDS aims to create a unified digital health infrastructure, using FHIR as a key standard.

German usage of HL7^® FHIR^®: Elektronische Patientenakte - Germany’s ePA project uses FHIR standards for nationwide EHR interoperability.

British usage of HL7^® FHIR^®: NHS Digital FHIR API Standards - The UK’s NHS Digital promotes FHIR through API standards for healthcare interoperability.

French usage of HL7^® FHIR^®: Mon Espace Santé - France’s health platform adopts FHIR for patient data sharing.

EU Cross-border exchange: InteropEHRate Project - An EU-funded project uses FHIR standards for cross-border health data exchange.

HL7 Europe: HL7 Europe Initiatives - HL7 Europe collaborates with governments to promote FHIR adoption.

📖 Resources at a glance

The central FHIR mental model

A FHIR resource is a standardized, machine-readable building block for one healthcare or administrative concept. Examples include:

• Patient for information about a person receiving care;
• Practitioner for a healthcare professional;
• ServiceRequest for a request such as an X-ray examination;
• Observation for a measurement or assessment;
• DiagnosticReport for a diagnostic report; and
• ImagingStudy for information about medical images.

FHIR is not one enormous patient record. It uses multiple focused resources that can be combined to tell a useful clinical story.

Resource type versus resource instance

A resource type is like a reusable form. It defines which elements can appear and what those elements mean. Patient is a resource type.

A resource instance is one completed version of that form. A Patient instance might contain the name, birth date, and identifiers for one particular person. Another person is represented by another Patient instance.

Every resource instance states its resourceType. It can also have:

• a logical id used by a server;
• human-readable narrative;
• common metadata; and
• elements specific to that resource type.

A business identifier, such as a hospital patient number, is not the same as the server’s logical id. Organizations may assign identifiers, while a FHIR server manages logical ids within its own system.

References connect the story

Resources remain small by referencing one another instead of copying the same information everywhere.

Consider an X-ray journey:

1. a Patient identifies the person receiving care;
2. a Practitioner requests an examination;
3. a ServiceRequest records the X-ray request and refers to the Patient;
4. an ImagingStudy describes the acquired images; and
5. a DiagnosticReport records the report and can refer to the Patient, request, and imaging study.

The exact resources and references depend on the workflow and the implementation guide, but the principle stays the same: each resource has a focused purpose, and references connect the pieces.

Bundles carry resources together

A Bundle is a FHIR resource that contains a collection of entries. Systems use different Bundle types for different purposes—for example, search results, documents, messages, batches, or transactions.

A Bundle is a transport or collection structure; it does not merge all of its entries into one giant resource. Each contained resource keeps its own type and meaning.

Check your understanding

1. What is the difference between the Patient resource type and one Patient instance?
2. Why does a DiagnosticReport refer to a Patient instead of copying all patient information into the report?
3. What does a Bundle add when several related resources need to travel together?

Useful links

Official FHIR resource list

FHIR resource formats

FHIR references

FHIR Bundle resource

📖 FHIR is a standard

A shared language for healthcare information

A standard is a published set of definitions and rules that people and organizations can use in the same way. Familiar examples include standard units of measurement, country codes, and date formats.

FHIR (Fast Healthcare Interoperability Resources) is a healthcare data standard published by HL7 International. It defines reusable data structures called resources, common data types and terminology patterns, and several ways to exchange the resulting information.

For example, two systems can use the Patient resource as a shared starting point for representing a person’s administrative and demographic information. That common structure reduces ambiguity and the amount of custom mapping needed between systems.

A standard supports interoperability; it does not guarantee it

FHIR gives implementers a common framework, but using FHIR does not by itself ensure that:

• the source data is complete or clinically correct;
• both systems use the same FHIR version, profile, or codes;
• the receiver interprets every element in the intended way;
• no information is altered or lost during a wider workflow;
• the deployment is secure; or
• the organization meets its legal and regulatory obligations.

Real interoperability also requires an agreed implementation guide, terminology, validation rules, mapping where needed, security controls, governance, testing, and reliable operations.

How FHIR is developed

FHIR is developed through HL7’s standards process with contributions from healthcare professionals, patients, implementers, vendors, researchers, public bodies, and other stakeholders. HL7 work groups are responsible for different parts of the specification.

The specification therefore provides a shared technical foundation. Each real project still has to agree which parts of that foundation it uses and how it will protect and govern the exchanged information.

Useful links

FHIR overview

FHIR architectural principles

HL7 work groups

📖 What does FHIR stand for?

FHIR stands for Fast Healthcare Interoperability Resources. The name summarizes the standard’s original design goals and its central data model.

• Fast
• Healthcare
• Interoperability
• Resources

Fast to implement

In this context, Fast refers mainly to making healthcare interoperability faster and simpler to implement than earlier approaches—not to a guarantee about system response time.

FHIR uses technologies familiar to many software teams, including HTTP, RESTful APIs, JSON, and XML. Familiar tools can reduce the amount of special-purpose technology an implementation team has to learn. Actual performance still depends on the system design, data, infrastructure, and workload.

Healthcare-specific

FHIR is designed for healthcare information. Its resource types cover clinical, administrative, financial, public-health, and research concepts.

Interoperability

In healthcare, interoperability means that people and systems can exchange information and use it with a shared understanding, even when they use different software. Technical exchange is only one layer; shared terminology, workflow agreements, governance, and human practice also matter.

In the introduction for non-developers, we saw everyday examples of failed interoperability, such as systems using different units or incompatible file formats. In healthcare, the consequences can be much more serious because the information supports care decisions.

Resources

Resources are predefined data structures for focused healthcare and administrative concepts. Examples include:

• Patient;
• Condition;
• Medication; and
• Practitioner.

You can imagine resource types as separate forms for different aspects of healthcare. A completed form is one resource instance. Resources can refer to one another, and a Bundle can carry several related resources together.

You will learn more in What are resources?.

📖 FHIR's 80/20 principle

Healthcare is too varied for one base data model to contain every detail needed by every country, specialty, organization, and project. FHIR therefore aims to provide a manageable common core that supports the requirements shared by many implementations.

This idea is often called FHIR’s 80/20 principle: focus the base specification on the relatively small set of requirements that covers a large share of common interoperability needs. It is a design principle, not a measured quota.

It does not mean that:

• every resource contains exactly 80% of all possible fields;
• only 80% of healthcare use cases can use FHIR; or
• the remaining requirements should be ignored.

FHIR handles context-specific requirements mainly through profiles and extensions. For example, Patient.birthDate is optional in the base Patient resource. A local profile can require it when a particular workflow needs every Patient record to include a birth date. When the base resource has no suitable element for a necessary concept, a governed extension can represent that information.

The result is a shared base that systems can recognize, together with explicit local rules for the details that differ between use cases.

Useful links

FHIR architectural principles

FHIR profiling

FHIR extensibility

📖 Profiling

From a base resource to agreed local rules

The FHIR specification defines base resources that can be used in many different settings. Real projects usually need more specific rules. For example, a hospital, national programme, or research network may need a particular element to be present or may restrict which codes can be used.

Profiling means defining those additional rules while staying within the boundaries of the base FHIR resource. The published set of rules is called a profile. Technically, a profile is published as a StructureDefinition resource.

A profile can, for example:

• make an optional element required;
• limit the allowed values or data types;
• specify which terminology or value set to use; and
• require or constrain a governed extension.

Cardinality: how often may an element appear?

FHIR expresses the minimum and maximum number of occurrences as cardinality:

• 0..1 means zero or one occurrence, so the element is optional;
• 1..1 means exactly one occurrence, so the element is required; and
• 0..* means zero or more occurrences.

In the base Patient resource, birthDate has cardinality 0..1. If a local workflow cannot operate without a birth date, its Patient profile can change the minimum to one. The resulting cardinality is 1..1. The profile has not created a new kind of data; it has made the shared rule more specific for that use case.

Projects commonly publish related profiles, extensions, terminology rules, examples, and exchange requirements together in an implementation guide. Systems need to agree on that context; saying only that data “uses FHIR” is often not specific enough.

Useful links

Official FHIR profiling documentation

FHIR StructureDefinition

📖 Extensibility

FHIR base resources focus on information that is common across many healthcare settings. Sometimes an implementation needs to exchange an additional concept for which the base resource has no suitable element. FHIR can represent that concept with an extension.

An extension is not a resource on its own. It is a structured element that can appear at an allowed location inside a resource. The formal definition of an extension is published as a StructureDefinition resource and is identified by a canonical URL. That definition explains what the extension means, where it may be used, and what type of value it may contain.

This governance matters. A sender should not invent an unexplained field, and a receiver should not guess what an unfamiliar field means. When both systems use the same published extension definition, they can refer to the same meaning. A profile can then require the extension or place additional constraints on its use.

Extensions must not be used to change the meaning of an existing element. FHIR also has a stricter form called a modifierExtension for the exceptional case where the added information changes how the containing element or resource must be interpreted. Systems are not allowed to ignore modifier extensions they do not understand.

In short:

• the base resource supplies the common structure;
• an extension represents a governed additional concept;
• a profile states how the resource and its extensions must be used in a particular context; and
• an implementation guide brings those agreements together for a project or community.

Useful links

Official FHIR extensibility documentation

Defining extensions

📖 Common ways to exchange FHIR information

• RESTful API
• Messaging
• Documents
• Operations and services
• Subscriptions
• Batch and transaction
• Useful links

FHIR information can move between systems in several ways. These are often called exchange approaches or exchange paradigms. The categories overlap, and the specification evolves, so there is no fixed number that learners need to memorize.

RESTful API

The FHIR RESTful API is a common way for a client to create, read, update, search for, or delete resources on a FHIR server using HTTP. A stored resource instance is typically addressed by its resource type and logical id, for example Patient/123.

Not every resource in every exchange has its own resolvable server URL. Resources can also travel inside documents, messages, and other Bundles.

Messaging

FHIR messaging exchanges a message Bundle about an event, such as a notification that something happened. The receiving system processes the message according to the agreed message rules.

A message Bundle is not the same as a transaction Bundle. Messaging represents an event exchange; a transaction is a RESTful request that asks a server to process several operations atomically.

Documents

A FHIR document is a persistent, self-contained clinical statement assembled as a document Bundle. It is intended to be understood as a complete clinical document, such as a discharge summary, rather than as unrelated resources that happen to travel together.

Operations and services

FHIR also defines named operations for activities that do not fit a simple create, read, update, or delete interaction. Examples include validation and terminology operations. A project can use FHIR resources as the request and response data for a wider service as well.

Subscriptions

A client can create a subscription to ask for notifications when specified events occur. For example, a system might request a notification when a relevant resource changes. The exact notification channel and payload depend on the FHIR version and implementation guide.

Batch and transaction

Batch and transaction are RESTful interactions that send multiple requests together in one Bundle:

• a batch contains independent requests; each request succeeds or fails on its own; and
• a transaction is atomic: either every requested change succeeds, or the server rejects the transaction as a whole.

These are useful processing patterns, but they should not be confused with FHIR messaging.

Useful links

Exchanging with FHIR

FHIR RESTful API

FHIR messaging

FHIR documents

FHIR subscriptions