📖 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.