Chapter 9

๐Ÿ“– What does FHIR stand for?

FHIR stands for Fast Healthcare Interoperability Resources. The name summarizes the standard’s original design goals and its central data model.

Fast to implement

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.

You will learn more in What are resources?.