This learning unit is not 100% finished yet. Thank you for your understanding.
In this learning unit, you’ll explore the essential terms and concepts behind FHIR, which stands for Fast Healthcare Interoperability Resources — a vital standard in healthcare technology.
You’ll learn what interoperability means, why FHIR is considered “fast,” and how resources are key to its framework. We’ll also cover the 80% rule that shapes FHIR’s design, the concepts of profiling and extensibility for customization and flexibility, and the different exchange paradigms that facilitate data sharing.
By the end, you’ll be familiar with the core FHIR terms and ready to dive deeper into the world of healthcare interoperability. Let’s get started!
Subsections of 📁 3. Deciphering FHIR buzzwords
Chapter 8
📖 FHIR is a standard
Chapter not ready
Note
This chapter is not completely ready yet. Some information may be missing.
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.
FHIRstandardizes 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:
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.
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:
Common standardized format: The structure and content of a given
concept is defined in dedicated resources in a specified format.
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 HIPAA1 in the USA.
This chapter is not completely ready yet. Some information may be missing.
What is an acronym?
An acronym is a word formed by taking the initial letters of a series of words or phrases and combining them into a single term. The letters typically represent the key words in the phrase, and the resulting acronym is often easier to say or remember than the full phrase.
For example:
NASA: National Aeronautics and Space Administration
RADAR: Radio Detection and Ranging
LASER: Light Amplification by Stimulated Emission of Radiation
Acronyms are commonly used to simplify complex terms, making them more manageable in conversation and writing. They are particularly prevalent in technical fields, organizations, and government agencies.
Some acronyms become so widely used that they are recognized as words in their own right (like “laser or “scuba”), while others are used more as shorthand in specific contexts.
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.
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.
Incompatibility Examples
Real historical examples show that lacking interoperability, whether due to incompatible units, software errors, or outdated standards, can have dramatic and sometimes deadly consequences - expand the paragraph to learn more.
Interoperability issues can lead to serious and even catastrophic consequences. To illustrate the importance of consistent and standardized data across systems, here are five historical examples where a lack of interoperability resulted in major failures:
1. Mars Climate Orbiter
In 1999, NASA’s Mars Climate Orbiter was lost in space due to a simple unit conversion error. One team used metric units (newtons), while another used imperial units (pounds-force) for the spacecraft’s navigation software. The lack of standardization led to the spacecraft deviating from its intended path and burning up in Mars’ atmosphere. A failure to ensure data compatibility resulted in a $125 million mission loss.
2. Therac-25 Radiation Therapy Machine
The Therac-25 was a radiation therapy machine that, in the 1980s, caused severe radiation overdoses due to a software error. The lack of proper interoperability and communication between software modules led to malfunctions in the machine’s safety systems. This resulted in the machine delivering radiation doses hundreds of times higher than intended, causing serious injuries and deaths.
3. Airbus A400M
In 2015, an Airbus A400M military transport aircraft crashed during a test flight, killing four crew members. The accident was traced back to software configuration issues that caused the engines to shut down unexpectedly. Different teams used incompatible software formats that were not properly integrated, leading to a critical failure in the aircraft’s control systems.
4. Patriot Missile Failure in the 1991 Gulf War
During the 1991 Gulf War, a Patriot missile defense system failed to intercept a Scud missile, resulting in the deaths of 28 American soldiers. The failure was due to a software bug caused by a timing error that arose from incompatibility between the system’s internal clock and the actual passage of time. The system was off by 0.34 seconds, enough to miss the target by hundreds of meters.
5. Year 2000 Problem (Y2K Bug)
The Y2K bug was a computer flaw that resulted from the practice of using two-digit numbers to represent years (e.g., “99” for 1999). As the year 2000 approached, there were fears that systems would interpret “00” as 1900, causing widespread software failures. The issue highlighted the need for consistent data standards and proper planning for long-term interoperability in computer systems.
Resources
The central role of FHIR is played by resources. They are predefined data structures that
represent different healthcare entities.
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.
This chapter is not completely ready yet. Some information may be missing.
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).
Chapter 11
📖 Profiling
Chapter not ready
Note
This chapter is not completely ready yet. Some information may be missing.
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.
Chapter 12
📖 Extensibility
Chapter not ready
Note
This chapter is not completely ready yet. Some information may be missing.
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.
Chapter 13
📖 Exchange Paradigms
Chapter not ready
Note
This chapter is not completely ready yet. Some information may be missing.
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 API1, 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.
Video in Preparation
Note
This video is in preparation and will be available soon. thank you for your patience.