What is FHIR? A Beginner's Guide

Did you know that over 75% of digital health companies connecting to multiple Electronic Health Records are already using FHIR?

FHIR stands for Fast Healthcare Interoperability Resources.

It is pronounced "fire" 🔥.

FHIR is a healthcare standard that enables the uniform exchange of health information between different systems. FHIR can be used to solve real-world clinical and administrative problems at a fraction of the cost of existing alternatives. Today, FHIR is arguably the fastest-growing healthcare standard in the world.

However, most people who are new to healthcare IT still struggle to understand what FHIR is and where to begin. In this article, we'll break down 5 essential FHIR concepts you need to understand.

1. FHIR resources are the smallest unit of exchange

All healthcare data can be represented in categories like Patient, Encounter, Observation, Insurance Claims, etc. In FHIR, each of these categories forms a "resource." Resources act as the smallest unit of exchangeable information.

FHIR Resources can be thought of as the "atoms" of health information exchange.

These resources are formally defined on the HL7 FHIR specification website. These FHIR resources can be grouped in many ways.

FHIR resources are constantly evolving with the needs of healthcare. A practical way to group FHIR resources is by maturity level. The ones at the top under Level 5, marked "N" for "Normative," are resources that have been vetted for use over a long period of time and are mature enough that there won't be many (breaking) changes.

The ones with a lower maturity level are relatively new to FHIR and may undergo significant changes with newer versions of FHIR.

As a beginner, you should usually try to use the more mature FHIR resources and steer clear of the newer ones whenever possible.

Let's now look at how a FHIR Resource is actually defined by taking the Patient resource as an example.

The Patient resource represents the patient in a healthcare context. You can read more about how this resource is supposed to be used and what exactly it means in the scope and usage section.

Once you've read through the basic use cases and scope of the FHIR Patient resource, you'll land on this "Structure" view that looks somewhat like a tree.

This explains the different fields that actually define a Patient resource. Let's briefly explore how to read the FHIR structure view.

In the next section, let's look at how to read this structured view of a FHIR resource.

Tip: For the more technical readers, a JSON example of the Patient resource might be a handy companion. If you're just starting out and don't understand what JSON means, take a look at this introduction to JSON article first.

2. FHIR data elements define the structure of a FHIR resource

In the tree view, you can see that the patient resource has fields like identifier, active, and name. These are the Data Elements that define what data points are to be captured as part of the Patient resource.

These data elements are listed for each resource, and a detailed view can be found in the Detailed Descriptions tab.

The Element Id tells you what this data point will be called in the final resource, and the Definition, Short Display, and Note explain how the field is supposed to be used.

We'll look at Type and Cardinality in more detail.

FHIR Data Types

Each data element has a Type. For example, the identifier is of the Identifier type, and clicking on the link takes you to the definition of what this type means.

Some types are simple (or primitive) like active, which is a boolean (true or false), while others like identifier and name have another nested structure within and are complex.

For example, the identifier type looks like this:

Now, this also has other complex types like CodeableConcept and Period. But I promise you, if you follow the type rabbit hole enough, you'll end up with only primitive types like string, URL, boolean, etc.

All of these primitive types are defined on the FHIR Data Types page.

A JSON representation of identifier would look something like this:

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

Now that we know how an identifier is supposed to look, we need to know how many times it should appear.

Cardinality

Cardinality noun. The number of elements in a set.

The "Card." field stands for Cardinality and represents the minimum and maximum times a particular data element can appear using the notation minimum..maximum. A maximum value of * means "as many times as needed" or ∞.

For example, the active field has a cardinality of 0..1. This means it is an optional field and can appear a maximum of only once. The identifier field has a cardinality of 0..*, where 0 represents that the field is optional and * represents infinity.

If this were being represented in JSON, identifier would appear as an array:

{
    "resourceType": "Patient",
    "identifier": [
        { identifier 1 },
        { identifier 2 }
    ]
}

There are a few more things to understand about FHIR data elements, like terminology bindings and constraints, but we'll cover that in another article.

For now, this is all you need to know about FHIR Data Elements. You now understand what a particular FHIR resource is supposed to look like.

If you want to get your hands dirty and actually create your first FHIR resource, follow along with the video below.

Although FHIR Resources define a good amount of common data points, they can't immediately be used in practice. To illustrate this, the following is a completely valid FHIR Patient resource according to the specification we just looked at:

{
    "resourceType": "Patient"
}

Note: The resourceType field always shows up in any resource, and it's always the name of the FHIR resource. So a FHIR Patient resource will implicitly need to have a resourceType of "Patient" at all times.

Hard to believe, right?

This happens due to the optional cardinality of most of the elements in the international FHIR specification. This is intentional. It keeps the international or "base" version of the FHIR standard extendable to as many use cases as possible.

3. FHIR profiles localize FHIR resources to specific use cases

While the FHIR resource still remains the minimum unit of exchange, in practice, the resources defined by the international FHIR specification need to be constrained further for local use—usually within a nation, an organization, or for a particular use case.

FHIR Profiles provide a formal way for implementers to constrain and extend the base specification of a resource.

Let's look at the same Patient resource we saw earlier, but as profiled by the US Core FHIR Profile. This is the version of the Patient resource that is to be used for the exchange of information within the United States as regulated by the ONC (recently renamed to ASTP).

The FHIR differential table above just shows what's different in the US Core FHIR patient compared to the base FHIR resource definition.

You'll notice a few things immediately:

1. There are extra fields like race and ethnicity that were not present in the base FHIR resource.
2. The cardinality of the identifier is now 1..*. The identifier element for a patient is not optional anymore. It is mandatory.
3. You'll notice the "S" square in red. This stands for "must support," and it basically means systems should be ready to handle this information.

Before we explore what extensions are, let's answer this common question that's probably on your mind.

What is the difference between Must Support and Mandatory?

The Must Support Elements, indicated by a red "S" in FHIR specifications, tell that systems must be able to process and handle these elements. It is not required to always have a value.

Mandatory Elements are usually indicated by a cardinality of 1..1 or 1..* and must always be present in the resource. It cannot be omitted from the resource structure.

Extensions add new data elements to the resource

We also see other data points that were not present in the base FHIR resource, like race, ethnicity, birthSex, and more. These are called extensions.

Extensions are a way to add new elements to a resource without changing its core definition. They allow for flexibility and customization of FHIR resources to meet specific needs or requirements that aren't covered by the standard elements.

Here's how extensions work:

1. They have a defined URL that identifies the extension.
2. They can contain any datatype allowed in FHIR.
3. They can be simple or complex, containing multiple sub-extensions.

For example, an extension for patient race might look like this in JSON:

{
  "resourceType": "Patient",
  "extension": [
    {
      "url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race",
      "extension": [
        {
          "url": "ombCategory",
          "valueCoding": {
            "system": "urn:oid:2.16.840.1.113883.6.238",
            "code": "2054-5",
            "display": "Black or African American"
          }
        },
        {
          "url": "text",
          "valueString": "Black or African American"
        }
      ]
    }
  ],
  // ... other Patient elements ...
}

If you want to dive deeper and learn about how to create your own FHIR Profiles, take a look at this video.

Now you have an idea of what a profiled FHIR resource should look like. How does one actually exchange this data with other systems?

Up next, we'll look at that with FHIR Exchange Paradigms.

4. FHIR paradigms define how FHIR resources are exchanged

FHIR paradigms define how the resources should be exchanged and consumed by different systems. There are many ways to do this. However, the most widely adopted paradigms are RESTful, Documents, and Messaging.

FHIR RESTful APIs

FHIR RESTful APIs provide a standardized way to interact with FHIR resources over HTTP. This paradigm follows REST principles, making it familiar to many developers and easy to implement.

Key aspects of FHIR RESTful APIs include:

• CRUD operations (Create, Read, Update, Delete) on resources
• Search functionality with standardized parameters
• Versioning of resources
• Batch and transaction support for multiple operations

Example RESTful API call:

GET http://example.com/fhir/Patient/123

This would retrieve the Patient resource with ID 123.

All CRUD operations on a FHIR server can be done using similar HTTP operations.

The US Core expects this paradigm to be implemented, and most EHRs like Epic, Cerner, and Athena Health implement FHIR APIs for third-party applications to retrieve and write data in their EHR.

RESTful FHIR also made possible the more exciting SMART on FHIR specification that lets apps run on top of FHIR data platforms.

FHIR Document Bundles

FHIR Document Bundles allow for the exchange of collections of resources as a single unit. This paradigm is useful for scenarios where a complete set of related information needs to be transferred or stored together.

FHIR Bundles are a way to package multiple resources into a single larger resource.

FHIR Bundles are a topic in itself, and we'll cover them in more detail in another article.

All you need to know is that FHIR Document Bundles:

• Contain a Composition resource (which is another resource) as the first entry, providing context
• Include all referenced resources within the bundle
• Are immutable once created
• Can be digitally signed for integrity and non-repudiation

Example structure of a Document Bundle:

{
  "resourceType": "Bundle",
  "type": "document",
  "entry": [
    {
      "resource": {
        "resourceType": "Composition",
        // ... Composition details ...
      }
    },
    // ... Other resources ...
  ]
}

The Indian FHIR Profile called ABDM uses FHIR documents to exchange Discharge Summaries across hospitals.

FHIR Messaging

FHIR Messaging enables event-based communication between systems. This paradigm is useful for scenarios where actions need to be triggered based on certain events or where asynchronous communication is preferred.

FHIR Messaging uses Bundles just like FHIR Documents. Where they differ is that FHIR Messaging:

• Uses a MessageHeader resource to define the purpose and content of the message
• Can include multiple resources related to the event
• Supports request/response patterns
• Allows for routing and reliable delivery mechanisms

Example structure of a FHIR Message:

{
  "resourceType": "Bundle",
  "type": "message",
  "entry": [
    {
      "resource": {
        "resourceType": "MessageHeader",
        // ... MessageHeader details ...
      }
    },
    // ... Other resources ...
  ]
}

An example of the FHIR Messaging paradigm in practice would be the nphies that's used extensively in Saudi Arabia for health insurance transactions.

For a more in-depth view into the implementation of these real-world use cases, check out our other article exploring how FHIR Paradigms are used across the world.

This is not all. There are a total of 6 exchange paradigms defined by FHIR - including Subscriptions. While you don't need to understand everything to really know what FHIR is, knowing a little about these paradigms helps.

Let's do a quick summary of the ones we didn't cover above:

1. Services: Allows invocation of complex services like decision support or workflow management, suitable for scenarios where simple CRUD actions are insufficient.
2. Database / Persistence: Uses FHIR resources directly within a database for data storage and retrieval, ensuring compatibility with FHIR-based APIs and other paradigms.
3. Subscription: Enables real-time notifications by allowing clients to subscribe to specific events or changes in FHIR resources, useful for timely updates like lab results or event detection.

We now have all the components to make FHIR work, but someone has to put everything together in one place for people to look at and implement.

This is where Implementation Guides come in.

5. FHIR Implementation Guides bring everything together

Implementation Guides, or IGs for short, are comprehensive documents that combine multiple FHIR components to create a practical, real-world implementation for specific use cases.

FHIR IGs = FHIR Profiles + Examples + Exchange Paradigm + LOTS of Documentation

IGs serve as a blueprint for implementing FHIR in specific contexts, providing detailed guidance on how to use FHIR resources, profiles, and exchange paradigms to achieve particular healthcare interoperability goals.

FHIR Implementation Guides usually include:

1. Profiles and Extensions: IGs define specific profiles and extensions tailored to the use case, constraining and extending FHIR resources as needed.
2. Examples: They provide concrete examples of how resources should be structured and used in the given context.
3. Exchange Paradigms: IGs specify which exchange methods (RESTful API, Documents, or Messaging) should be used and how.
4. Detailed Documentation: Extensive documentation explains how to implement the guide, including technical details, workflows, and best practices.

Each of the examples we referenced above actually has implementation guides in FHIR:

• US Core Implementation Guide
• ABDM Implementation Guide
• nphies Implementation Guide

The FHIR IG Registry serves as a central repository for published Implementation Guides, making it easier for implementers to find relevant guides for their needs. simplifier.net is another source for searching for and finding implementation guides around the world. The search by nationality option might especially be useful.

Summary

I hope that with these 5 key concepts—FHIR resources, data elements, profiles, exchange paradigms, and IGs—you are now armed with enough knowledge to confidently say you know what FHIR is and how it's used.

We also looked at how FHIR is used in practice with multiple real-world examples and IGs.

This is just the starting point. Using FHIR in the real world requires you to get your hands dirty. My free 90 min FHIR Masterclass maybe the perfect place to start.

If you want to join me and 20 other participants from around the world to build 5 real-world applications and become a certified FHIR expert, sign up for a free preview of our FHIR Bootcamp today!