Unknown Core Capabilities of FHIR: A Beginner’s Guide

FHIR has become a common Interoperability standard used by USA Healthcare Practices. As an open-source standard, FHIR enables easier interoperability and integration between healthcare systems and applications. While there are common capabilities of FHIR like APIs, resource modeling, and terminology building, some unknown powerful capabilities are built into the standard that are less widely understood. 

This blog article will walk you through FHIR’s key functionalities, allowing you to fully leverage the FHIR standard. Even if you are unfamiliar with the FHIR standards, understanding these fundamental characteristics will help you reach FHIR’s full potential in health interoperability.

Understanding the FHIR Standard

HL7 International designed the current health data sharing standard, known as FHIR.

It enables healthcare providers to transfer patient health information between systems, such as demographics, lab results, medications, allergies, clinical notes, and more. Here are the most critical things to know immediately:

• FHIR is a protocol that is open source.
• Its wide ecosystem of servers, client libraries, and implementation guidelines makes it available to developers of all skill levels.
• FHIR conforms to modern web standards.  JSON, REST, and OAuth 2.0 are the same building blocks utilized in modern program development. This makes FHIR integrations dramatically easier than older healthcare standards.
• FHIR is resource-dependent. Each item of clinical data is represented as a ‘ resource ‘, which is a structured, standardized unit such as Patient, Observation, Medication, or Appointment. 
• FHIR supports security. Authentication and authorization controls are built into the specification, giving practices precise control over who can access patient health data.

FHIR vs HL7 v2: What’s Different and Why It Matters

If you’ve been working in healthcare IT for a while, you’ve most likely seen HL7 v2.

It has been the major messaging standard since the 1980s and is still widely used today. Understanding what separates FHIR from HL7 v2 explains why the industry has gradually transitioned to FHIR over the last decade.

The Core Differences

Feature	HL7 v2	FHIR
Format	Pipe-delimited, proprietary text	JSON, XML, or RDF
Architecture	Point-to-point messaging	RESTful API
Web compatibility	Not natively web-friendly	Built on modern web standards
Readability	Requires specialized parsers	Human-readable and developer-friendly
Extensibility	Limited, tightly coupled	Built-in extension mechanism
Query capability	Limited	Full RESTful query via API
US regulatory alignment	Not mandated	Required by the ONC 21st Century Cures Act

Why It Matters in Practice

HL7 v2 communications are notoriously hard to understand. The format is restrictive, field delimiters vary between implementations, and various systems commonly use v2 in different ways, necessitating custom-built interfaces for integration between two HL7 v2-based systems.

FHIR addresses this at the foundational level. Because FHIR uses JSON and REST, formats any modern developer understands, building and maintaining integrations is faster and cheaper.

Regulatory note

The ONC 21st Century Cures Act Final Rule and CMS interoperability rules both mandate FHIR-based APIs for certified EHR technology. HL7 v2 has no equivalent regulatory mandate going forward.

HL7 v2 isn’t going away overnight, too much existing infrastructure depends on it. However, for each new integration or healthcare application established today, FHIR is the foundation upon which to build. 

FHIR R4 vs R5: Which Version Should Beginners Learn First?

This is one of the most commonly asked questions by those new to FHIR, and the answer is simpler than most tutorials reveal. 

Start with R4. Build on R4. The US regulatory ecosystem runs on R4.

FHIR R4: The Current Production Standard

FHIR R4 was adopted in December 2018 and has since become the most widely utilized version of the standard globally.

• According to the Firely State of FHIR 2025 poll, 40% of respondents use R4 as their primary version, far outpacing any other release. 
• FHIR R4 is mandated under the ONC Cures Act Final Rule, CMS Patient Access API, CMS Prior Authorization requirements (CMS-0057-F), and the TEFCA Framework.
• R4 APIs are accessible through major EHRs such as Epic, Oracle Health (Cerner), and athenahealth. As of 2026, no vendor offers production R5 APIs.
• The US Core Implementation Guide (the standard baseline for US FHIR implementations) is based on R4, and all versions from 3.1.1 to 9.0.0 continue to use R4. 

R4 is not only recommended but required if you are developing something that must interact with US healthcare systems today. 

FHIR R5: The Next-Generation Release

FHIR R5 was released in March 2023 and had more than 4,000 changes from R4, including:

• 20+ new resource types, with 8 focused on medication definitions
• Topic-based subscriptions, a fully reworked framework for real-time, event-driven notifications
• 55+ new resources focused on patient engagement and care coordination
• Enhanced vital signs profiles and improved Group resources for public health use cases

These are notable upgrades. However, as of 2026, R5 use in production environments remained in the single digits. The majority of integration partners are still on R4, which restricts the practical advantage of using R5 resource types that your partners cannot yet use. 

FHIR R6: What’s Coming Next

FHIR R6 began its normative balloting process in January 2026, with final publication anticipated in 2027 or later. It promises backward compatibility with R4’s normative resources and will align with US Core v10 and USCDI v7.

The Decision Framework

Your situation	Best version
Building for US regulatory compliance	R4 (required)
Integrating with Epic, Cerner, or other major EHRs	R4 (only option in production)
Just learning FHIR	R4 (most resources, tutorials, and tooling)
Research or experimental public health use cases	R5 may be relevant
New greenfield project, no partner constraints	R4, with R6 awareness

FHIR vs HL7 v2: What’s Different and Why It Matters

If you’ve been in healthcare IT for a while, you’ve most likely come across HL7 v2. It has been the primary message standard since the 1980s and remains popular today. Understanding what sets FHIR apart from HL7 v2 explains why the industry has gradually transitioned to FHIR over the last decade.

The Core Differences

Feature	HL7 v2	FHIR
Format	Pipe-delimited, proprietary text	JSON, XML, or RDF
Architecture	Point-to-point messaging	RESTful API
Web compatibility	Not natively web-friendly	Built on modern web standards
Readability	Requires specialized parsers	Human-readable and developer-friendly
Extensibility	Limited, tightly coupled	Built-in extension mechanism
Query capability	Limited	Full RESTful query via API
US regulatory alignment	Not mandated	Required by the ONC 21st Century Cures Act

Why It Matters in Practice

HL7 v2 messages are notoriously difficult to understand. The format is inflexible, field delimiters vary between implementations, and various systems commonly use v2 differently, necessitating the use of custom-built interfaces for integration between two HL7 v2 systems.

FHIR addresses this at the fundamental level. Because FHIR uses JSON and REST, formats any modern developer understands, building and maintaining integrations is faster and cheaper.

HL7 v2 isn’t going away overnight, too much existing infrastructure depends on it. However, FHIR is the standard around which every new integration or healthcare application should be developed.

FHIR R4 vs R5: Which Version Should Beginners Learn First?

This is one of the most commonly asked questions by those new to FHIR, and the answer is simpler than most tutorials reveal.

Start with R4. Build on R4. The US regulatory ecosystem runs on R4. Here’s why.

FHIR R4: The Current Production Standard

FHIR R4 was finished in December 2018 and is now the most widely acknowledged version of the standard worldwide.

• According to the Firely State of FHIR 2025 research, 40% of respondents use R4 as their primary version, well outpacing any other release. 
• The ONC Cures Act Final Rule, CMS Patient Access API, CMS Prior Authorization rules (CMS-0057-F), and TEFCA framework all require FHIR R4.
• R4 APIs are exposed by major EHRs, including Epic, Oracle Health (Cerner), and athenahealth. As of 2026, neither vendor offers production R5 APIs.
• The US Core Implementation Guide (the official baseline for FHIR implementations in the United States) is based on R4, as are versions 3.1.1 through 9.0.0.

R4 is not only recommended but necessary if you are developing something that must interact with US healthcare systems today.

FHIR R5: The Next-Generation Release

FHIR R5 was launched in March 2023, introducing more than 4,000 improvements from R4, including:

• 20+ new resource types, with 8 focused on medication definitions
• Topic-based subscriptions, a fully reworked framework for real-time, event-driven notifications
• 55+ new resources focused on patient engagement and care coordination
• Enhanced vital signs profiles and improved Group resources for public health use cases

These are significant improvements. However, R5 deployment in production contexts remained in the single digits as of 2026. Most integration partners are still on R4, which restricts the practical value of leveraging R5 resource types that your partners cannot currently consume. 

FHIR R6: What’s Coming Next

FHIR R6 began its normative balloting process in January 2026, with final publication anticipated in 2027 or later. It promises backward compatibility with R4’s normative resources and will align with US Core v10 and USCDI v7.

The Decision Framework

Your situation	Best version
Building for US regulatory compliance	R4 (required)
Integrating with Epic, Cerner, or other major EHRs	R4 (only option in production)
Just learning FHIR	R4 (most resources, tutorials, and tooling)
Research or experimental public health use cases	R5 may be relevant
New greenfield project, no partner constraints	R4, with R6 awareness

Core Capabilities of FHIR

1. FHIR Path

One of the main core capabilities of FHIR is the FHIR Path – a Path-based language for retrieving data from FHIR resources. It mainly uses a simple path-based approach to express queries across JSON structures. 

FHIR Path enables complex queries without having to use a general programming language. Here are some key features of the FHIR Path:

• Filter resources based on the criteria
• Return partial results by indexing into resources
• Sort the results set
• FHIR Path can be used for any information model as it acts as an abstract model.
• Chain expressions to form queries

FHIR Path is an essential tool that extracts health data from the FHIR server.

2. GraphQL Support

Using GraphQL provides an alternative querying mechanism for FHIR servers. GraphQL in FHIR allows users to specify in a single request exactly the data they need from one or more resources. The GraphQL ensures that only the requested fields are returned. 

This enables the users to avoid over-fetching data. GraphQL schemas can automatically generate FHIR resource definitions. 

GraphQL offers flexibility and precision not easily achievable with standard APIs. Existing GraphQL client libraries can be leveraged. However, GraphQL may add more implementation capacity on the server side.

3. Bulk Data APIs

When use cases involve larger data sets, the Bulk Data APIs come into play. FHIR defines bulk data APIs to export and digest resources efficiently. The NDJSON avoids having to parse or hold an entire large JSON File in memory. 

Bulk APIs also specify multiple resources per request to reduce talkiness. Error handling is robust against network failures through the use of asynchronous import/export operations with retries. 

• Bulk export enables analytics on larger FHIR data sets. 
• Bulk import allows migrating data or updating many resources at once.

Careful testing is required to tune the performance and resources for bulk operations.

4. Authorization

The FHIR specification provides authorization hooks to control access policies for FHIR APIs. Authorization can be implemented based on user identity, assigned roles, consent policies, contexts, and more. Scope-based access rules can restrict permitted actions on resources.

• Confidential patient data may require specific consent
• Audit logging of access provides transparency
• Authorization services that conform to industry standards like OAuth 2.0 integrate well with FHIR
• Client Applications should limit data exposure only to authorized users.

Appropriate authorization is crucial for securing sensitive healthcare data while enabling access to treatment.

Related: 8 Benefits of Adopting the FHIR Standard for Healthcare APIs

5. Extensibility

One of the Key strengths of FHIR is the extensibility – adding custom extensions and profiles. The Extensibility mechanism allows adapting base resources for local requirements. Profile constrains core resources by setting cardinalities, value sets, or data types.

• Extensions define what is new in the base specification
• Terminology bindings customize code systems and value sets
• Extensions can add data needed for specific use cases
• Profiles ensure implementation conforms to rules

With proper design and governance, extensibility enables localized customization of FHIR. However, caution is required as extensive customization can hamper interoperability.

SMART on FHIR Explained: Authorization for Healthcare Apps

FHIR specifies the data format and the API. However, it does not answer a key question: how can a third-party application acquire authorization to access a patient’s EHR data? 

That is exactly what SMART on FHIR solves.

What SMART on FHIR Is

SMART on FHIR is an open authorization framework that extends FHIR APIs with OAuth 2.0 and OpenID Connect (OIDC), enabling healthcare apps to authenticate users and access patient data across multiple EHR systems.

Without SMART, each EHR vendor handles authorization differently. One requires client secrets, another uses JWT assertions, and the third employs a proprietary technique. As a result, each partner requires specific integration code, resulting in a maintenance nightmare that increases linearly with the number of partners.

SMART addresses this issue by limiting OAuth 2.0 to a predefined, healthcare-specific profile. Once deployed, your app can be launched from any SMART-compatible EHR without having to recreate your authorization layer each time. 

The Two SMART Patterns

Pattern 1: EHR Launch (User-Facing Apps)

A physician or patient has already accessed an EHR and launched a SMART app during that session. The flow:

• The EHR passes a launch token to the app.
• The app connects you to the EHR’s authorization server.
• The user accepts the app’s data scope requests.
• The authorization server delivers an access token and a launch context (current patient ID, encounter ID).
• The token is used by the app to access FHIR resources via the EHR’s FHIR API.

Pattern 2: Backend Services (System-to-System)

This pattern oversees headless workflows, analytical pipelines, nightly data synchronizations, and population health jobs. Instead of requiring a user login, the backend service authenticates with asymmetric key pairs.

SMART Scopes: Granular Permission Control

SMART defines a structured scope terminology that specifies precisely what data a program is permitted to access:

[patient|user|system]/[ResourceType].[read|write|*]

Examples:

• patient/Observation.read — read Observations for the in-context patient only
• user/Patient.read — read Patient resources for all patients the logged-in user has access to
• system/Medication. read — system-level read access to Medication resources

What Is a FHIR Capability Statement?

Every FHIR server generates a paper outlining exactly what it can do. This paper is referred to as the Capability Statement.

What a Capability Statement Contains

A Capability Statement is an FHIR resource that may be accessed on any FHIR server through the standard endpoint [base]/metadata. It claims, in machine-readable form:

• FHIR version refers to the server’s implementation of the specification.
• The server’s supported resources are the resource kinds that it can manage. 
• supported interactions—for each resource, which REST activities are available: read, search, create, update, delete, and history
• Which search parameters are supported for each resource, and which are required vs. optional?
• Security protocols—whether SMART on FHIR is enabled, and the URLs for authorization and token endpoints.
• Operations — which custom FHIR operations ($everything, $validate, etc.) are implemented

Why the Capability Statement Matters for Integration

When integrating with a new FHIR server, the Capability Statement serves as the starting point.

It clearly and automatically shows you what you can and cannot do before you write a single line of integration code. Practical examples include:

• Before developing a medication reconciliation feature, confirm that the server supports Medication and MedicationRequest with read and search interactions.
• Before relying on a certain search parameter, ensure that it is listed. Many servers discreetly offer empty results for unsupported search criteria.
• Before implementing SMART, check the security section for the authorization server URLs

How to Retrieve a Capability Statement

To obtain a Capability Statement, submit a single HTTP GET request:

GET https://your-fhir-server.com/fhir/metadata Accept: application/fhir+json.

The response is a JSON (or XML) FHIR resource that can be automatically processed or manually inspected. Capability Statements can be retrieved and queried using methods integrated into most FHIR client libraries.

CapMinds Health Data Exchange Solution

Though the capabilities of FHIR are powerful, without the right navigation, healthcare practices find it difficult to achieve interoperability. 

For seamless health data exchange, healthcare practices need to rely on an experienced technical team to ensure seamless data exchange between healthcare systems. CapMinds can be your go-to interoperability solution.

Why can CapMinds be your Go-to Interoperability Solution?

• We are experienced professionals with years of experience in the field.
• Our technical team is an expert who will analyze your healthcare practice thoroughly to tailor the Interoperability solution.
• We prioritize safety, security, encryption, and authentication to protect your healthcare patients’ data.
• Our comprehensive solution ensures seamless interoperability, adhering to industry standards and using standard protocols.
• We offer comprehensive training sessions to healthcare staff.
• Our affordable health interoperability solution benefits healthcare practices at all levels.

If you want to seamlessly integrate healthcare systems, we will assist you by navigating all the potential challenges and ensuring seamless health data exchange.

Reach out to CapMinds Health Data Exchange Solution for your Healthcare Practice.