This unit explains the terms that let real projects adapt the shared
FHIR foundation to a particular setting.
After this unit, you should be able to:
explain what the letters in FHIR stand for;
describe the 80/20 principle without treating it as a fixed quota;
distinguish a base resource, profile, extension, and implementation
guide; and
recognize common ways of exchanging FHIR information without
memorizing a fixed number of paradigms.
Start with FHIR is a standard, then continue through the
pages in order.
Subsections of 📁 4. Adapting and exchanging FHIR
Chapter 8
📖 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.
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.
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
Resources are predefined data structures for focused healthcare and
administrative concepts. Examples include:
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.
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.
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.
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.
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.