📁 2. FHIR basics for non-developers

Unit not ready

Note

This learning unit is not 100% finished yet. Thank you for your understanding.

For someone who is not a developer, HL7^® FHIR^®¹ might seem very complicated. In additon, most introductions to HL7^® FHIR^®¹ as well as the official documentation itself use terms that you might not yet be familiar with, like:

We will cover these concepts here. Read on to understand on which core technical basis HL7^® FHIR^®¹ is built.

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎ ↩︎ ↩︎

Chapter 2

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

Machine Readability

Do we still need structured data with Large Language Models?

Even with the advancements in artificial intelligence that can read texts, having pre-structured data remains a significant advantage. With data in a standardized, structured format, a computer knows exactly how to process the information it receives. If information needs to be extracted from text first, ambiguities can arise, leading to errors or missing important details. Current large language models may produce different results across multiple attempts to extract data from the same text, which should be avoided at all costs. Structured, machine-readable data is reliable and ensures consistent results, making standardized data formats essential for health data exchange.

Artificial intelligence can indeed be a valuable tool in the process of packaging information into these standardized formats. In general, healthcare practitioners are trained to think and document in a highly structured manner, so even a letter from a physician presented as plain text is likely to be far more organized and formalized than a random piece of text.

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

Interoperability¹ means that different systems, software, or devices can communicate and work together effectively by understanding and using each other’s data correctly. In healthcare, this means ensuring that all the tools, technologies, and systems can seamlessly share information, such as patient records or medical measurements, without misunderstandings or errors. Interoperability is crucial because it helps healthcare providers access accurate information quickly, make better decisions, and provide safer, more efficient patient care.

Example 1: Fahrenheit vs. Celsius

A lack of interoperability can lead to significant problems, even with something as simple as temperature measurement. For example, in the United States, body temperature is measured in Fahrenheit, where a normal reading is 98.6°F. However, in Europe, body temperature is measured in Celsius, and a normal reading is 37°C. A misunderstanding between these two scales can lead to serious errors, as 98.6°C or 37°F would indicate a situation incompatible with life. Without standardized systems, such basic discrepancies can cause confusion and potentially dangerous outcomes in medical care.

Example 2: Microsoft Office vs. Libre Office Impress

Another situation you have probably experienced is this: imagine you create a presentation in Microsoft PowerPoint and want to share it with a colleague who uses an open-source software like LibreOffice Impress. If Microsoft PowerPoint and LibreOffice Impress don’t fully support each other’s features, issues can arise: the formatting might be off, animations may not work as intended, or some elements might be missing altogether. This lack of compatibility can lead to miscommunication and extra work to fix the presentation. Ensuring systems can talk to each other correctly is essential to avoid these errors and keep the content consistent.

Developers of healthcare standards aim to ensure that different systems work well together, and are interoperable¹. This is essential for seamless integration and communication across various healthcare platforms.

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:

X-Ray Comic 1

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.

You can read more about interoperability here ↩︎ ↩︎

Chapter 3

📖 The creation of FHIR in 2011

HL7^® FHIR^®¹^,² 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 that is dedicated to improving interoperability in healthcare. HL7^® HL7^® FHIR^®¹ is already used by many organizations and its usage has significantly grown in the last few years, just recently spreading to Europe³.

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^®¹ 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.

But HL7^®¹ 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.

Do you remember how Youtube looked on 2011?

Screenshot taken from Webdesignmuseum.org

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎ ↩︎ ↩︎ ↩︎
Link to official HL7® FHIR® Documentation ↩︎
See the link section in this chapter for more information about european FHIR-initiatives. ↩︎

Chapter 3

📖 The scope of FHIR

HL7^® FHIR^®¹ (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^®¹ suitable for a wide range of healthcare applications.

A key aspect of HL7^® FHIR^®¹’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^®¹ provides a framework that supports interoperability while maintaining the accuracy and meaning of healthcare information.

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎ ↩︎ ↩︎ ↩︎

Chapter 4

📖 Client Server Model

One of the key decisions that led to HL7^® FHIR^®¹’s success was to use modern web technologies. The modern web is largely based on a client-server-model.

The client-server model is like the interaction between you and a waiter at a restaurant. You - the client - ask the waiter - the server - for food - data or services. The waiter takes your order to the kitchen - the server processes your request - and brings the food back to you - the server sends data back.

In the internet world, your computer or phone - the client - sends requests to servers, which are computers that provide information or services, like websites or apps.

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎

Chapter 5

📖 REST and SOAP

The client-server model alone is not sufficient for the internet to function effectively. Instead, it requires a precise specification of the steps involved in the communication process between clients and servers. This is done via dedicated protocols that ensure security and correctness.

SOAP

SOAP (Simple Object Access Protocol) was the initial protocol that formalized the client-server interaction for the web in 1998. It was widely used in the early 2000s for web services and data exchange.

SOAP is complex and secure, with strict rules, and is often used in situations where high security and reliability are necessary, like banking.

Deep dive to SOAP

Deep dive to SOAP (Simple Object Access Protocol)

SOAP is a protocol that provides a standard way for computers to exchange information over a network, especially when reliability and security are critical.

SOAP messages are strictly formatted in XML, which defines the structure of the message and ensures that all parts of the communication are clearly defined. Every SOAP message has a specific structure: an envelope that contains the message, a header (for optional metadata), and a body (for the actual data).

SOAP can work over many lower-level network protocols, including HTTP, SMTP (for email), or even TCP. However, HTTP is the most common.

SOAP can be stateful or stateless. This means it can maintain a session across multiple requests (stateful) if needed, which can be important for complex transactions.

SOAP has built-in standards for security (like WS-Security) and error handling. For example, it can encrypt messages and support various authentication methods, making it more suitable for applications that handle sensitive data, such as financial transactions or health information.

It also has standards for things like message reliability and transaction management, which helps ensure that messages are delivered correctly and consistently, even if there are network problems.

SOAP is more reliable and formal due to its strict rules and built-in error handling. It is ideal for complex enterprise-level applications where ensuring every message is delivered and understood correctly is crucial.

It supports advanced security features and is often used in industries where data integrity and security are paramount, like finance, healthcare, and government.

REST

Over time, another more light-weight protocol gained popularity and became the preferred choice for FHIR: REST (Representational State Transfer), first published in 2000 in the dissertation of Roy Fielding.

In 2011, the REST architecture for interacting with the server and the server client model was just a decade old, but already very successful and outgrowing the old SOAP protocol.

REST was adapted as the main exchange mechanism in FHIR.

REST is the most widely used exchange mechanism in HL7^® FHIR^®¹ and was the key to the success of HL7^® FHIR^®¹, but it is not the only possible exchange paradigm. In this learning unit, you will learn about alternative options.

Deep dive to REST

REST (Representational State Transfer):

REST is an architectural style that defines a set of rules for creating web services (APIs). It allows different computer systems to talk to each other over the internet by using standard web protocols.

RESTful APIs use standard web methods like GET (to retrieve data), POST (to send new data), PUT (to update data), and DELETE (to remove data). These methods are part of the HTTP protocol, which is the same protocol used to browse websites.

REST is designed to be stateless, which means each request from a client (like a mobile app or a web browser) to the server is independent and does not rely on previous requests. This makes it scalable and easy to manage.

REST is flexible with data formats: it can use JSON (JavaScript Object Notation), XML (Extensible Markup Language), HTML, or even plain text. However, JSON is the most common because it is lightweight, easy to read, and works well with JavaScript, which is widely used in web development.

REST is easier to implement and use because it relies on the standard web protocols that developers are already familiar with.

It is more performance-efficient due to its stateless nature and the lightweight nature of JSON.

REST APIs are more adaptable and can quickly respond to changes, which makes them ideal for modern web services, mobile applications, and microservices.

Mataphorical Comparison of REST and SOAP

Sometimes REST and SOAP are compared like this: REST is like sending a quick, flexible text message - easy, fast, and adaptable. SOAP is like sending a formal letter - detailed, structured, and secure, but slower and more complex.

Basic technical Comparision of REST and SOAP

Feature	SOAP	REST
Formality and Structure:	SOAP is highly structured, with strict rules for how messages should be formatted and transmitted. This structure includes predefined standards for handling security, transactions, and messaging reliability. This makes SOAP heavier and more complex but also more reliable and secure for applications that require these features.	REST is more flexible and simpler. It does not have built-in standards for things like security or transactions, so developers have more freedom to implement solutions in ways that best fit their needs.
Data Format	SOAP only uses XML for message formatting, which adds to its complexity. XML is a verbose format, meaning it takes more time and resources to process than JSON.	REST can use multiple data formats (JSON, XML, HTML, etc.), but JSON is most common because it is faster to read, write, and transmit.
Use Cases:	SOAP is best for situations where there is a need for high security, guaranteed message delivery, and formal communication rules, such as in banking, insurance, or government applications.	REST is ideal for public APIs and web services where speed, simplicity, and flexibility are more important, such as social media platforms, weather apps, and e-commerce websites.

Why HL7^® FHIR^® chooses REST despite SOAP’s security expertise

Despite SOAP’s built-in security features, REST has become the preferred choice for HL7^® FHIR^®, because it offers greater flexibility, scalability, and ease of integration with modern web technologies. REST can achieve high levels of security using standard web protocols like HTTPS[^https], along with robust authentication and authorization methods such as OAuth 2.0, making it suitable for handling sensitive data while providing a more lightweight and adaptable solution compared to SOAP.

What is https?

What is HTTPS?

HTTPS (HyperText Transfer Protocol Secure) encrypts data between your web browser and a website, ensuring that information is secure and protected from hackers. For REST APIs, HTTPS makes communication secure by encrypting requests and responses, protecting data from interception. This security enables REST to be used safely over the internet, even in scenarios where SOAP (Simple Object Access Protocol) was previously preferred for its security features

What is OAuth2?

OAuth 2.0 is a secure way for one app to access specific information or services from another app without needing your password; it works like a temporary, limited-use key that you can easily revoke anytime, keeping your main login details safe.

In summary, wile SOAP has built-in security features, RESTful APIs like those used in HL7^® FHIR^® maintain security through other means:

HTTPS for encrypted communication,
OAuth 2.0 and other modern authentication and authorization standards,
Digital signatures and data integrity checks,
Best practices and additional security layers implemented by organizations.

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎ ↩︎

Chapter 6

📖 JSON and XML

Structured data refers to any data that is organized in a specific format, making it easy to enter, store, search, and analyze. In healthcare, this could include patient information like vital signs, diagnoses, medications, lab results, or allergies. Structured data is typically presented in predefined formats like tables or fields that ensure consistency and accuracy.

The units of exchange in HL7^® FHIR^®¹ are called resources. Their content is organized data formats like JSON or XML.

XML and JSON are very popular in all industries, web, apps and so on. So, in 2011 it was decided to use these formats as the way to package the healthcare information that would be exchanged with HL7^® FHIR^®¹.

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.

Example for a Patient-resource in json and xml²

Example for patient resource instance.[^patientexample]

Choose Format:

Field	Details
Active	true
Deceased	false
Alt Names	- Peter James Chalmers (OFFICIAL) - Peter James Windsor (MAIDEN)
Contact Details	-unknown- (HOME) ph: (03) 5555 6473 (WORK) ph: (03) 3410 5613 (MOBILE) ph: (03) 5555 8834 (OLD) 534 Erewhon St, PeasantVille, Rainbow, Vic 3999 (HOME)
Next-of-Kin	Bénédicte du Marché (female) 534 Erewhon St, PleasantVille Vic 3999 (HOME) +33 (237) 998327
Valid Period	2012 –> (ongoing)
Links	Managing Organization: Organization/1 “Gastroenterology”

{
"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>

More about JSON and XML in this learning unit.

RDF Turtle

Turtle is a third format that is used, but it is way less popular than xml and json.

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎ ↩︎
↩︎

Chapter 7

📖 Summary

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

X-Ray Comic 2

$Figure illustrating usage of HL7 FHIR in a situation when a patient in a hospital shall receive an X-ray. 1. Request Documentation: The physician enters the X-ray request\ninto an EHR system using a HL7 FHIR ServiceRequest resource, including\npatient details and clinical notes. 2. Information Delivery: The request is automatically sent to the radiology department via a HL7 FHIR RESTful API, which retrieves and\nprocesses the ServiceRequest. 3. Scheduling: The radiology department schedules the procedure\nusing a HL7 FHIR Appointment resource and updates the system, notifying the\nphysician and patient. 4. Procedure Execution: The patient undergoes the X-ray, and the\nprocedure details are recorded in the system using a HL7 FHIR Procedure resource. 5. Results Preparation: The X-ray images are stored as ImagingStudy resources, and the report is generated as a DiagnosticReport resource. 6. Results Delivery: The HL7 FHIR RESTful API automatically sends the DiagnosticReport and associated ImagingStudy resources back to the\nphysician’s EHR. 7. Review and Decision: The physician reviews the results through\nthe EHR, which uses HL7 FHIR resources to present the data, and determines the next steps for patient care.\u200b$ $Figure illustrating usage of HL7 FHIR in a situation when a patient in a hospital shall receive an X-ray. 1. Request Documentation: The physician enters the X-ray request\ninto an EHR system using a HL7 FHIR ServiceRequest resource, including\npatient details and clinical notes. 2. Information Delivery: The request is automatically sent to the radiology department via a HL7 FHIR RESTful API, which retrieves and\nprocesses the ServiceRequest. 3. Scheduling: The radiology department schedules the procedure\nusing a HL7 FHIR Appointment resource and updates the system, notifying the\nphysician and patient. 4. Procedure Execution: The patient undergoes the X-ray, and the\nprocedure details are recorded in the system using a HL7 FHIR Procedure resource. 5. Results Preparation: The X-ray images are stored as ImagingStudy resources, and the report is generated as a DiagnosticReport resource. 6. Results Delivery: The HL7 FHIR RESTful API automatically sends the DiagnosticReport and associated ImagingStudy resources back to the\nphysician’s EHR. 7. Review and Decision: The physician reviews the results through\nthe EHR, which uses HL7 FHIR resources to present the data, and determines the next steps for patient care.\u200b$

Congratulations!

Now you have a basic understanding of what HL7^® FHIR^®¹ is and how it works. In the next Section, you will learn about some more about the fundamental principles that HL7^® FHIR^®¹ is built on. These include concepts like Resources, interoperability, the 80% rule, Profiling and Extensions. Having an idea about what these buzzwords mean will immensely help you in your further study of HL7^® FHIR^®¹.

HL7, FHIR and the FHIR [FLAME DESIGN] are the registered trademarks of Health Level Seven International and their use does not constitute endorsement by HL7. ↩︎ ↩︎ ↩︎ ↩︎

Chapter 9

📖 Useful links

Video: HL7^® FHIR^® facts for developers

HL7^® FHIR^® documentation

SOAP Protocol official documentation

W3 REST (Representational State Transfer) tutorial

Dissertation of Roy Fielding.

CDA documentation

Official HL7^® FHIR^® Introduction for clinicians

Official HL7^® FHIR^® Introduction for patients

Official HL7^® FHIR^® Introduction for architects

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.