FHIR Glossary

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.

FHIR Versions: R4, R5, R6

FHIR is released in numbered versions, and which one you’re working with matters more than most introductions let on.

• R4 (2019) is still the most widely implemented version in production today, and it’s the version most current regulations, including the CMS interoperability rules and most Da Vinci implementation guides, reference directly.
• R5 (2023) moved a first set of core resources to normative status, meaning they’re considered stable and protected from breaking changes.
• R6 is in ballot as of 2026 and is expected to bring most core clinical and administrative resources to normative status, alongside a handful of new resources and structural changes described below.

Normative (maturity status)

Normative is the highest maturity level in FHIR. A resource or specification element marked normative is considered stable: HL7 has committed to not making breaking changes to it in future versions. This matters for implementers because it’s the difference between building on solid ground and building on something that might still shift under you. Content that hasn’t reached this level is marked “trial use,” and can still change based on real-world implementation feedback.

Additional Resources (new in R6)

One of the more consequential structural changes in R6 is the concept of “additional resources”: resource types that can be registered with HL7 outside of the core specification’s normal release cycle. Instead of waiting for the next full FHIR version to introduce a resource for a niche or jurisdiction-specific use case, a community can get one approved and published on its own timeline. It’s a direct response to how much the ecosystem has grown since FHIR’s early days, when a handful of core resources covered most needs.

The Foundation

Resource

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: only those data elements that are, today, internationally supported by 80% of systems will be included in the core of a FHIR resource definition (that’s 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.

Reference

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.”

Profile

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 Simplifier.net platform if you want to check out a few examples.

Extension

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’re 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 U.S. contexts but not part of the core FHIR Patient resource. An extension is then used to add these data elements to a profile for the jurisdictions where this is required, as in the US Core Race extension:

Implementation Guide

A FHIR implementation guide (IG) is a comprehensive document that describes how to use FHIR resources to address a specific use case. It’s worth noting that “implementation guide” is both a FHIR resource and the name for the 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 that 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.

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. 

Terminologies

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’s typically created for a particular use case, like concepts representing individual countries or 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 included in the value set at a specific point in time, based on the defined criteria.

Binding

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

Interaction

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.

Operation

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 

Bundle

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:

Package

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.

Subscriptions

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.

Bulk Data Access (“Flat FHIR”)

Reading resources one at a time works fine for a single patient, but it falls apart when a health plan needs to hand over data for an entire population. Bulk Data Access, often nicknamed “Flat FHIR,” is the specification built for that: an asynchronous $export operation that lets a system request a large set of resources at once and pick up the resulting files when they’re ready, instead of making thousands of individual API calls. It’s the mechanism behind most of the payer-to-payer and population-level data exchange requirements described later in this glossary.

CDS Hooks

CDS Hooks is a specification developed alongside FHIR that lets clinical decision support (CDS) services trigger real-time alerts or suggestions inside an electronic health record (EHR) workflow, for example when a clinician places a medication order. It’s frequently paired with the Da Vinci Coverage Requirements Discovery (CRD) implementation guide, so a provider can find out what documentation a payer will require before they even submit a claim.

SMART on FHIR

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.

SMART App Launch

SMART App Launch is the part of SMART on FHIR that standardizes how a third-party app securely launches inside, or alongside, an EHR and requests access to specific FHIR data. Version 2 of the specification added support for more granular, resource-level scopes, so an app can be authorized to see, say, a patient’s medications without also getting access to their full record.

If you’ve made it this far, you’ve probably noticed a pattern: almost every concept above exists to answer the same underlying question, which is how do you make sure a system in one place can trust and use data made in another. That question is exactly what’s driving the current wave of interoperability regulation. We’ve been telling that story through one patient’s eight-year search for a diagnosis; the terms below are the regulatory vocabulary behind it.

Regulatory & Ecosystem Terms

FHIR doesn’t exist in a vacuum. It’s increasingly the standard that regulators point to when they mandate how health data has to move, and the terms in this section come up constantly in that context.

TEFCA (Trusted Exchange Framework and Common Agreement)

TEFCA is a U.S. nationwide policy and technical framework, established under the 21st Century Cures Act and administered by the Office of the National Coordinator for Health IT (ONC) with The Sequoia Project as its Recognized Coordinating Entity. It creates a single “on-ramp” so that health information networks can exchange data with each other under one common set of rules, rather than negotiating bilateral agreements one by one. TEFCA is increasingly incorporating FHIR-based exchange, sometimes called “TEFCA on FHIR,” alongside its original document-based exchange model.

EHDS (European Health Data Space)

EHDS is the European Union’s regulatory framework for the exchange and secondary use of health data across member states. It designates FHIR as a supported standard for cross-border primary use of electronic health records, effectively giving the EU its own version of what TEFCA is building in the U.S.

USCDI (United States Core Data for Interoperability)

USCDI is a standardized set of health data classes and elements that ONC requires systems to support for nationwide interoperable exchange. Where FHIR resources define the “how” of data exchange, USCDI defines the “what”: the specific data content that those resources are commonly used to carry.

Prior Authorization (Da Vinci PAS)

Prior authorization is the process by which a provider must get a payer’s approval before delivering a treatment or service, historically handled by fax, phone, or a payer’s proprietary web portal. The Da Vinci Prior Authorization Support (PAS) implementation guide defines FHIR-based operations that let this process happen electronically. Under the CMS Interoperability and Prior Authorization rule, payers now have to turn requests around within a fraction of the time the manual process used to take.

Payer-to-Payer Data Exchange

Payer-to-payer data exchange is a FHIR-based capability, required by CMS rules such as CMS-0057-F, that lets a patient’s health plan transfer their claims and clinical history to a new payer when the patient switches coverage. It’s a direct answer to the data loss that used to happen at every coverage transition, the same fragmentation problem at the center of most real-world interoperability failures.

CMS-0057-F

CMS-0057-F is the CMS Interoperability and Prior Authorization final rule. It requires impacted U.S. payers, including Medicare Advantage, Medicaid, CHIP, and Qualified Health Plan issuers on the federally facilitated exchanges, to stand up several FHIR-based APIs, including Provider Access, Payer-to-Payer, and Prior Authorization, on defined compliance deadlines.

Da Vinci Project

The Da Vinci Project is an HL7 initiative that brings payers, providers, and vendors together to build FHIR implementation guides for value-based care use cases. It’s the source of many of the implementation guides referenced above, including Prior Authorization Support (PAS), Clinical Data Exchange (CDex), and Coverage Requirements Discovery (CRD).

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.

Curious how these standards play out for an actual patient? Read the story that’s driving the current push for interoperability regulation, or explore Simplifier.net to see real-world profiles built on the concepts covered here.

Looking for hands-on training? Check out our FHIR Overview Course for practical training on the HL7 FHIR standard.