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

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:

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 that is dedicated to improving interoperability in healthcare. HL7^® HL7^® FHIR^®1 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

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.

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

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 while maintaining the accuracy and meaning of healthcare information.

📖 Client Server Model

One of the key decisions that led to HL7^® FHIR^®1’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.

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

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^®1 and was the key to the success of HL7^® FHIR^®1, but it is not the only possible exchange paradigm. In this learning unit, you will learn about alternative options.

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

📖 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^®1 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^®1.

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²

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

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

Congratulations!

Now you have a basic understanding of what HL7^® FHIR^®1 is and how it works. In the next Section, you will learn about some more about the fundamental principles that HL7^® FHIR^®1 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^®1.

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

📖 FHIR is a standard

FHIR is a standard.

FHIR (Fast Healthcare Interoperability Resources) is a healthcare standard.

A standard is a set of guidelines or specifications designed for a particular field or industry. The goal of a standard is to ensure information consistency and compatibility between different healthcare systems and applications.

Everyday examples for standards are:

• the ISO codes for currencies like U.S. Dollar (USD), Euro (EUR), Japanese Yen (JPY).

• Standard Time zones (UTC - Coordinated Universal Time)

• standardized closing sizes (XS, S, L, M, XL, XXL).

Using a standard means to follow a common framework to achieve predictable and reliable outcomes: Standardized clothing sizes help consumers find the right fit across different brands. ISO codes for currencies ensure consistency and accuracy in international financial transactions. Finally, standard time zones based on Coordinated Universal Time (UTC) synchronize clocks and schedules worldwide, which is essential for smooth global communication and travel.

FHIR standardizes healthcare data formats to ensure seamless and accurate information exchange between different systems.

With FHIR, accessing a patient record ensures that the data is consistent and reliable. When you send data to another healthcare provider using FHIR, you can trust that they will receive the same information, with no alterations or loss.

FHIR meets several typical key criteria for standards in the IT context:

• 1. Consensus based development
• 2. Technical specifications
• 3. Seamless data exchange
• 4. Flexibility and Scalability
• 5. Quality and Compliance

1. Consensus based development

FHIR is developed by HL7 (Health level 7 International: https://www.hl7.org/ ), a global authority on standards for electronic health data. The development process involves collaboration between a wide range of stakeholders, including healthcare providers, technology vendors and regulators.

A key role in this process is played HL7 Work groups (https://www.hl7.org/Special/committees/, https://hl7.org/fhir/resourcelist.html ), where experts from different areas come together and discuss, develop and refine aspects of FHIR that are relevant to their field of expertise. For example, the Patient care work group (https://www.hl7.org/Special/committees/patientcare/index.cfm ) is responsible for FHIR resources like AllergyIntolerance, Condition, CarePlan.

2. Technical specifications

FHIR provides a comprehensive set of technical specifications that describe how information can be exchanged between different systems. These specifications are all documented on the FHIR website.

3. Seamless data exchange

The ultimate goal of FHIR is to provide standardized formats and rules for data exchange such that on its way from one system to another, the health care data integrity is preserved and the information can easily be read by the recipient.

This is realized by providing a common framework and language for exchanging data. FHIR ensures that information can be shared across diverse platforms and applications like electronic healthcare records, devices, and hospital IT systems. This is realized by two core features:

1. Common standardized format: The structure and content of a given concept is defined in dedicated resources in a specified format.

2. Formalized rules on how to exchange information, for example via a Restful API.

4. Flexibility and Scalability

FHIR is designed to be adaptable and scalable. It supports a wide range of use cases, from simple data sharing to complex, large-scale integration projects. Scalability is particularly crucial for healthcare organizations, as it ensures that as their needs and operations expand, FHIR can continue to facilitate efficient and secure data exchange. Whether a small clinic or a large hospital network, FHIR’s scalability allows these institutions to maintain seamless interoperability as they grow, integrate new systems, and handle increasing volumes of patient data.

5. Quality and Compliance

FHIR includes guidelines and rules that ensure the quality, accuracy, and security of exchanging medical information. It helps organizations comply with regulatory requirements for data exchange and privacy, such as HIPAA¹ in the USA.

📖 The F.H.I.R. Acronym

FHIR stands for Fast Healthcare Interoperability Resources. From this acronym we get several more hints about its nature than just it being a standard, with all implications that come with that.

• Fast
• Healthcare
• Interoperability
• Resources

FHIR claims to be FAST

The meaning of FAST in this context is that FHIR is fast to implement.

To implement something refers to the process of putting a plan into effect. It involves taking the steps that are necessary to carry out the project in a practical, real-world setting.

FHIR is fast to implement because it uses modern web standards like Restful APIs, JSON and XML. Developers are already familiar with them because of they are widespread used all industries. Also, the docs are user friendly and focus on helping with implementation.

FHIR being fast can also apply to performance. The architecture of FHIR is built to handle high volumes of data and transactions, enabling swift access and retrieval of healthcare information.

FHIR is Healthcare-specific

FHIR is tailored for the healthcare industry.

Interoperability

The term interoperability appears to have originated within the context of the military and defense industry in the mid 20th century. It was used to describe the ability of different weapons systems, units or forces to work together effectively.

By the 1970s and 1980s, interoperability had become a common term in IT and telecommunications.

In healthcare, it means that doctors, nurses, hospitals, apps, pharmacies all can exchange and understand each other's medical records even if they use different types of computer systems. This helps everyone work together to improve healthcare for their patients.

In the introduction for non-developers we already mentioned some every-day examples for (missing) interoperability like different units for temperature and distance, or incompatibility of a Microsoft Office Presentation in Libre Office impress.

These everyday examples illustrate how lack of interoperability can lead to confusion and errors. But when it comes to more critical fields like aerospace, healthcare, or defense, the consequences of poor interoperability can be far more severe.

Resources

The central role of FHIR is played by resources. They are predefined data structures that represent different healthcare entities.

Examples are:

• Patient (https://hl7.org/fhir/patient.html )

• Condition (https://hl7.org/fhir/condition.html )

• Medication (https://hl7.org/fhir/medication.html )

• Practitioner (https://hl7.org/fhir/practitioner.html )

For each resource, specific properties are defined. For example, a patient has a name, an address, an identifier, a birthdate, a gender and other characteristics.

These properties are like fields in a form that can be filled with the patient’s data. But unlike a paper form, a patient resource provides more flexibility and mechanisms to check if the data is correct or missing. Moreover, it is readable and understandable by a computer.

All information that is exchanged is packaged in a FHIR resource.

Patient data, medication data, terminologies, even technical info like the capability statement of a server that says what it can offer, are resources.

You can imagine as separate paper forms for different aspects of health care.

You will learn more about Resources in this learning unit.

📖 FHIR's 80% rule

The 80% rule is a decisive strategic approach to handle the huge amount of diversity of healthcare data. Because of the sheer volume of different use cases and perspectives in the healthcare sector, it is hard to agree on data structures. FHIR resources that satisfy all participants for a nephrologist specialize on kidney transplantations, the exact time of birth of a patient will seem to be of no importance, while for the neonatologist it will be very relevant.

To capture the ethnicity of a patient is not important or even adequate in Germany, but of clinical relevance for the interpretation of certain lab parameters or risk factors in the US.

To include all possible properties for all resources would lead to very big constructs that would be hard to navigate. Therefore, the 80% rule states that only the 80% most important commonly agreed upon properties are included in the resource. Or put differently, a resource should be usable for 80% of. All use cases in all sub sectors of the healthcare industry. The remaining 20% of special use cases are not represented by the predefined resources.

Note:

The opposite approach would be to include all possible elements that any use case would ever need. This approach is followed the openEHR, an open standard for managing and sharing electronic health records (EHRs).

📖 Profiling

Profiling

The definition of resources in FHIR is not only about the content of a resource, but also about the structure and relationship of the elements.

The cardinality states how often. An element can appear in a resource and if it is mandatory and not.

Examples are 0..1 or 1..1 and so on.

Profiling is the action of adjusting a resource to your needs.

For example in your case, if in your case the birth date may be necessary, then you change 01211.

The result of profiling is an adjusted resource. We call it a profile.

Profiles are what is used in implementations. Resources are the definitions from the specification. Although some people don't make a clear distinction between the two terms.

Video: FHIR Profiling in 100 seconds.

📖 Extensibility

FHIR resources can be extended. As mentioned, the 80% rule limits their applicability to 80% of the most relevant use cases. To overcome this limitation. and to be able to use the resource for a use case of the remaining 20%, extensions can be added.

For example, in the US Core Specification, the Ethnicity extension is part of the patient resource. Extensions are resources on their own that can be added to a profile.

Video: FHIR Extensbility in 100 seconds.

📖 Exchange Paradigms

• RESTful API
• Messaging
• Documents
• Services
• Subscriptions
• Batch/Transaction
• Video: FHIR Exchange Paradigms in 100 seconds
• Useful links

The various possibilities of exchanging FHIR resources are referred to as the FHIR exchange paradigms. There are six (?) of them:

RESTful API (Representational State Transfer):

The most common exchange paradigm in FHIR is the FHIR RESTful API¹, where resources are accessed and manipulated using standard HTTP methods like GET, POST, PUT, DELETE, etc. Each resource has a unique URL, and operations are performed on these resources via HTTP requests. Supports searching, updating, and retrieving resources.

Messaging:

FHIR supports a message-based exchange paradigm where data is sent in the form of a message. Typically used for event-driven exchanges, such as sending alerts or notifications between systems. Messages contain a bundle of resources and are sent as a single transaction.

Documents:

FHIR documents are a static, narrative-driven bundle of resources that can be exchanged. These documents are used when a complete, self-contained package of information is needed, such as a discharge summary or a clinical report.

Unlike other paradigms, documents are meant to be read as a complete story and not interacted with piecemeal.

Services:

In this paradigm, FHIR can be used to define and invoke services. This includes clinical decision support services or other operations that are performed as a service call, with FHIR defining the request and response formats. Examples include operations like $validate, $lookup, or $expand.

Subscriptions:

FHIR supports a subscription model where clients can subscribe to certain events (like updates to a resource), and the server notifies them when these events occur. This is useful for real-time data updates, such as monitoring patient vitals or receiving updates when a patient’s status changes.

Batch/Transaction:

In this paradigm, multiple FHIR resources are bundled together and sent in a single HTTP request.

Batch

A group of independent operations that the server processesindividually.

Transaction

A group of operations that the server processes as a single atomic operation, where either all operations succeed, or none do.

You'll learn about the exchange paradigms in Chapter 9.

Video: FHIR Exchange Paradigms in 100 seconds.

Useful links

Official FHIR RESTful API Documentation

Official Messaging Documentation

Official Documents Documentation

Official Services Documentation

Official Subscriptions Documentation

📖 Resources at a glance