Health Interoperability
20 Min Read

FHIR Glossary

Ward Weistra

Subscribe to our newsletter


FHIR is a hot topic (excuse the pun) in the healthcare sector. With its role in revolutionizing healthcare data exchange and the steady expansion of legislation mandating FHIR, it’s becoming an important part of the future of healthcare interoperability.

But there’s a lot to wrap your head around and it can get a little overwhelming. That’s why we’ve created a FHIR glossary to break down some of the most common terms and guide you through the maze of FHIR jargon.

What is FHIR?

FHIR (Fast Healthcare Interoperability Resources) is a global standard designed to streamline the exchange of healthcare data across different systems. It was created to address the need for patient-controlled data management, data transparency, and advanced analytics for improved patient care. For the background on why FHIR exists, you can read our What is FHIR blog.

The Foundation


FHIR is based on a carefully crafted top-level data model: FHIR resources. A resource represents a healthcare-related concept such as a patient, practitioner, medication, or observation. Each resource encapsulates specific data elements relevant to its respective domain. 

For example, if you search for a patient on a FHIR server, you receive an instance of a Patient resource with a given patient’s data organized according to the Patient resource type.

Each resource (e.g. Patient) has 4 components:

  • Core data elements: Essential structured and coded data elements (e.g. name or date)
  • Extensions: Custom additional elements to capture data not in the core set (e.g. race)
  • Human readable summary: Provides a summary of the resource
  • Metadata: Information about the resource itself (e.g. version or when it was last updated)

FHIR has an 80/20 design rule that only those data elements that are today, internationally supported by 80% of systems, will be included in the core of a FHIR resource definition (where you see the Core data element component above).

The remaining 20% of data elements that aren’t included in the standard FHIR specification are covered by “extensions” (more on that below), enabling flexibility and customization. 


Resources may contain references to other resources which allow you to build a web of interlinked FHIR resources, much like a link on a webpage. This supports the expression of complex health data and the building of a clinical story. 

Conformance Module

Due to the huge variability across the healthcare ecosystem, the core FHIR specification requires further adaptation for particular use cases.

The conformance module is a set of FHIR resources (conformance resources) that can be used to represent these adaptations and define the capabilities, rules, and expectations for systems that implement FHIR to ensure interoperability.

The following section lists a few of the core conformance resources and their usage. 

Structure Definition

Structure definitions (SD) describe the structure, constraints, and extensions of resources and data types defined in the FHIR specification. SDs are not only used to describe the content in the resource itself but also how these structures are used in implementations. Two important types of SDs are “profiles” and “extensions”. 


The core FHIR specification is too broad for use in specific contexts when factoring in the different practices, requirements, and regulations across different countries and projects.

A profile is a conformance resource that describes how generic FHIR resources should be used to meet those specific use cases or requirements, ensuring consistency and interoperability. You might find that the term “profile” is sometimes used interchangeably with “structure definition”. 

Profiles are used to customize FHIR resources by: 

  • Adding new elements to a resource that are not part of the base FHIR specification
  • Restricting or extending existing elements, such as narrowing down the allowable values, data types, or cardinality (e.g. making an optional element mandatory) of existing elements
  • Defining specific value sets or code systems that should be used for coded elements

You can find more than 25,000 FHIR profiles from around the world on Firely’s platform if you want to check out a few examples.


Remember the 80/20 rule? Extensions represent the remaining 20% of data elements that aren’t included in the core FHIR specification.

Extensions are used to add new data elements to resources that are required for specific use cases without modifying the core specification. They are often defined within profiles to specify which extensions are allowed or required in a particular context. 

For example, suppose you need to include information about a patient’s race and ethnicity in a resource, which is mandatory in some countries but not part of the core FHIR Patient resource. An extension is then used to add these data elements to a profile for the countries in which this is mandatory.

Here is an example of how this is represented:

Implementation Guide

A FHIR implementation guide (IG) is a comprehensive document which describes how to use FHIR resources to address a specific use case. However, it’s important to note an IG is both a FHIR resource and the name for a document used to describe the full specification or the documentation around it. 

The IG resource contains the machine-readable part of the structure of a full implementation guide and shows which resources (e.g. capability statements, profiles, extensions, value sets) and which pages are within it. An IG document is the human readable version which describes how FHIR should be implemented.

For a more detailed overview, visit HL7’s ImplementationGuide page.

Capability Statement

A capability statement documents the capabilities of a FHIR server by defining the features and functionalities that the server supports. This includes the resources, operations, and interactions the server can handle, as well as any constraints or requirements for using those features. 

The capability statement is used by clients to understand what a server can and can’t do, and to configure their interactions based on what the server supports. Some of the key components of a capability statement are:

  • Software information (e.g. name, version, release date)
  • Implementation details (e.g. its description, URL, and additional documentation)
  • The version of the FHIR specification the server complies with
  • The formats supported by the server for input and output (e.g., JSON, XML)
  • Messaging capabilities including supported message events and endpoints
  • Support for FHIR documents, including profiles and operations

Search Parameter

Search Parameter resources define criteria for how you can search for resources based on specific attributes or combinations of attributes. For example, you could define a search parameter to find patients by their family name.

Here is an example of how it might look:

In addition to standard search parameters defined by FHIR, implementers can create custom search parameters to meet specific requirements. We’ve written a guide on how to easily upload a custom search parameter into Firely Server as an example. 


The FHIR Terminology Module has been developed to standardize terms and codes used to represent medical concepts, which is essential for consistent and accurate data exchange. Within the Terminology Module, there are three important terms to become familiar with: code systems, value sets, and bindings. 

Code System

A code system is a collection of codes that represent a specific medical concept (such as a diagnosis or procedure) and provide the meanings, hierarchies, and relationships between these codes.

It is typically created for a particular use case like concepts representing individual countries and colors. Each code within a code system has a unique identifier and a definition. 

Code systems are maintained by an organization that defines a set of concepts together as a unit. Examples of code systems include HL7’s internal code systems, and external terminologies such as SNOMED CT, LOINC, and ICD-10.

For a more complete list, check out HL7’s code systems page.

Value Set

A value set is a collection of codes from one or more code systems and is used to establish constraints on the codes for use in a particular context. Essentially, it selects a subset of codes and specifies their usage across various FHIR elements. 

Value sets consist of two parts: intension and extension. Intension (.compose) is the definition of which codes are intended to be in the value set and specifies the criteria or rules for including codes. Extension (.expansion) is the actual list of codes that are included in the value set at a specific point in time, based on the defined criteria.  


Value Sets are often “bound” to elements in FHIR resources, meaning that the values for those elements must come from the specified value set.

Binding refers to the association between an element and a specific value set. These bindings specify rules around the use of the element, such as only accepting codes from a particular value set. 

Bindings can vary in their level of strictness and flexibility, and FHIR specifies several types:

  • Required: The element must use a code from the specified value set. 
  • Extensible: The element should use a code from the value set if possible, but other codes are allowed if necessary. 
  • Preferred: The element should ideally use a code from the value set, but it’s not mandatory. 
  • Example: The value set provides example codes, but other codes can be used.

Additional FHIR Concepts


Interactions in FHIR are the basic, standardized CRUD (Create, Read, Update, Delete) actions performed on resources using RESTful principles. These interactions allow clients to manage and manipulate resources stored on a FHIR server.

Some common interactions are:

  • Create (POST): Adds a new resource to the server. 
  • Read (GET): Retrieves the content of a resource by its ID. 
  • Update (PUT): Replaces an existing resource with new data. 
  • Delete (DELETE): Removes a resource from the server. 
  • Search (GET with search parameters): Retrieves a set of resources matching specified criteria.

For example:

  • GET /Patient/123: Reads the patient resource with ID 123. 
  • POST /Patient: Creates a new patient resource.


Operations are specialized actions that go beyond the standard CRUD interactions and provide a way to perform complex, server-side operations.

Operations can execute custom logic on the server and are used for tasks like conversions, validations, and batch processing. It’s easy to distinguish between interactions and operations as operations will always start with a $ sign.

Some common operations are:

  • $validate: Validates a resource against a profile. 
  • $convert: Converts a resource from one format to another, such as converting between FHIR resources, XML, JSON, or other formats. 
  • $everything: Retrieves all related resources for a patient. 
  • $expand: Expands a value set to include all its members. 
  • $submit: Submits data for processing (e.g. claims, documents).

For example, if we use the $everything operation, it might look like:

  • GET [base]/Patient/[id]/$everything 


A Bundle is a container for a collection of resources. It is used to group multiple related resources together for operations such as:

  • Returning search results that meet a certain criteria
  • History tracking
  • Messaging
  • Transactions (e.g. creating, updating, and deleting resources)
  • Event notifications 

For example, if we use the $everything operation from above, the response would be a Bundle containing all related resources for the specified patient.

Here’s a snippet of what the response might look like:


With many people profiling, extending, and constraining the FHIR specification to meet their specific use cases, the community began to arrange these use-cases into projects (described by implementation guides).

However, because projects build upon (and depend on) other projects and the need to share projects grew, a management system became necessary. This is where FHIR packages come in.

A FHIR package is a collection of FHIR resources (like a directory with a JSON file-per-resource). A FHIR Package is not a FHIR resource, but basically a fancy Zip file (.tgz) based on the Node Package Manager (NPM) standard. This makes it easier for developers and implementers to manage and share resources within their projects.


In FHIR, subscriptions are a mechanism for clients or subscribers to receive real-time notifications or updates about changes to specific resources on a FHIR server. This can include additions, updates, or deletions of resources that match the specified criteria.

You might use subscriptions in scenarios where timely updates are crucial, such as monitoring patient data, tracking changes in clinical conditions, or managing workflow automation.


SMART on FHIR is a set of standards for integrating third-party applications, such as health apps with Electronic Health Record (EHR) systems using FHIR. One important component of this framework is its specification of OAuth 2.0-based authorization and authentication protocols.

This allows users to securely authenticate and authorize access to their health data. This ensures that only authorized users and applications can access sensitive patient information when using an authorization server like Firely Auth.

Ready for FHIR?

Whether you’re new to FHIR or seeking to deepen your understanding, we hope our FHIR glossary has helped in providing a solid foundation to navigate the complexities of this transformative standard. Looking for more? Check out our FHIR Overview Course for hands-on training of the HL7 FHIR standard. 

Want to stay on top of Interoperability and Health IT? 

Subscribe to our newsletter for the latest news on FHIR. 

Post a comment

Your email address will not be published. Required fields are marked *