How to Use FHIR Resources & APIs: A Complete Handbook for Healthcare IT Teams

September 9, 2025 admin HL7

Fast Healthcare Interoperability Resources (FHIR) is an open standard that enables the safe transfer of medical data between systems. Health Level Seven International created it, and it has swiftly become the industry standard for health data APIs. FHIR utilizes well-established web technologies, facilitating faster and easier integration.

This standard allows for real-time information sharing across clinics, hospitals, EHR providers, and even patient-facing apps. The outcomes include improved care coordination and smoother data flow.

Accessibility is one of FHIR’s greatest benefits. There are no licensing fees associated with the specification. This has been a significant factor in its global popularity.

It is now essential for healthcare IT teams to learn how to leverage FHIR resources and APIs. To meet compliance standards, achieve interoperability, and stay up to speed with rules that now require standardized APIs for the sharing of health data, it is essential.

Understanding the FHIR Standard

The shortcomings of previous healthcare data standards were addressed by FHIR. It was designed to be quick, adaptable, and user-friendly for developers.

As a result, new healthcare apps can be designed and integrated faster. A standardized data format and a RESTful API for sharing that data are the two fundamental components that form the basis of FHIR. In a nutshell, it specifies what medical information should be sent as well as how.

This strategy addresses fragmented systems, one of the major problems facing healthcare. FHIR facilitates the exchange of critical data, including medication lists, test results, and patient records, by guaranteeing that various apps speak the same language.

FHIR develops throughout several iterations. Every update adds new functionality or resource types while also enhancing the standard.

For example, the first to obtain normative status for important components of the standard was FHIR Release 4, which was released in 2019.
The framework was extended to 157 identified resource types with numerous improvements in 2023 with the release of FHIR Release 5, the next significant milestone.
Nevertheless, FHIR R4 is still used in the majority of production environments by 2025. It is the reliable option due to its maturity and good compliance with legal standards. Backward compatibility is supported by FHIR, which is beneficial.

Most of the time, R4-based systems can work with R5 systems. To guarantee seamless version transitions, hospital IT teams must carefully prepare updates.

Related: What is HL7 FHIR Standard – A Detailed Guide

FHIR Resources: The Building Blocks of Healthcare Data

The FHIR data model is based on FHIR resources. Every resource stands for a distinct healthcare organization or idea. Imagine it as a little, independent data packet that contains all of the information about that thing. Patient, Encounter, Observation, MedicationRequest, and AllergyIntolerance are a few typical instances. Each type defines the fields and relationships needed for that data, acting as a template.

For instance, the Patient resource records vital information, including name, identifiers, gender, date of birth, and contact data.
For example, a lab test result, heart rate, or blood pressure reading may be stored in the Observation resource.
There are 157 distinct resource types in the FHIR release today.

When combined, they encompass a vast array of medical information. Diagnostics, drugs, procedures, billing information, and even definitional artifacts that are used to shape additional data are all included in these resources, which go beyond basic clinical data.

Because of its modular architecture, FHIR is scalable and adaptable, enabling reliable information sharing between clinical, administrative, and financial systems.

The philosophy is that by combining or linking these modular resources, complex healthcare scenarios can be represented. If a particular use case isn’t directly covered by the base resources, FHIR’s design allows for customization through “profiling” to extend or constrain resources as needed.

Related: How FHIR Resources and Profiles Power Modern Health Interoperability

Key Characteristics of FHIR Resources: All FHIR resources share some common features that make them consistent and interoperable:

1. Unique Identifier (URL)

On a server, each resource instance is identified by a distinct URL (e.g., https://fhirserver.com/Patient/12345). The resource type and a server-assigned ID are included in this URL, which makes referencing the resource simple.

2. Standard Metadata

Standard metadata elements are carried by every resource, including timestamps for the latest modification, a logical ID, and a version tag if the resource has been updated. This metadata is part of the resource’s header and helps with versioning and audit trails.

3. Human-Readable Narrative

There is a human-readable synopsis of each resource that provides a written description of its content. This guarantees that an application can safely convey the story to a clinician even if it is unable to comprehend the structured data.

For instance, an observation would read, “Blood Pressure 120/80 mmHg sitting,” but a patient resource might have a narrative such as, “John Doe, male, born Jan 1, 1980…”

4. Defined Data Elements

Each resource type defines a specific set of data elements relevant to that entity. For a Patient, these include demographics; for an Encounter, they include visit dates, type, and participants; for a MedicationRequest, fields like medication, dosage, timing, prescriber, etc.

The data elements are structured and use coded values whenever possible (for instance, gender might be coded as “male” or “female” rather than free text).

5. Extensibility Framework

No single standard can anticipate every need, so FHIR provides an extension mechanism. Every resource can be extended with additional elements not part of the core specification, using a defined structure that ensures other systems can safely ignore or process the extensions.

Implementers can also profile a resource by publishing a StructureDefinition resource that declares how the base resource is adapted for that context. This means healthcare organizations can tailor resources to local requirements without breaking interoperability by adhering to the formal profiling rules.

FHIR APIs: How to Exchange Data with FHIR

Defining resources is only half of the story, the other half is how these resources are exchanged between systems. That’s where the FHIR API comes in. Nearly all data interchange in FHIR takes place via a web-based API. The majority of implementations use a RESTful methodology. The FHIR RESTful API creates, reads, updates, and deletes resources stored on an FHIR server using common HTTP endpoints and methods.

Every kind of resource has a base endpoint, which is frequently referred to as a “resource collection.” The endpoint’s URL pattern is [BaseServer]/[ResourceType], which is consistent.

A server may, for instance, make its Patient endpoint available via https://fhirserver.com/Patient.

The following URL would thus provide access to a specific patient record: https://fhirserver.com/Patient/12345

Developers and healthcare IT teams can find or create links to data more easily because of this consistent layout. You may easily obtain the appropriate information as long as you are aware of the resource type and identity.

Core FHIR RESTful Operations

A comprehensive yet understandable set of API interactions for resource management is defined by the FHIR specification:

Create: On the server, add a new resource. The server assigns an ID when an HTTP POST is made to the resource type’s endpoint, such as POST to /Patient to create a new patient record.

Read: Using a resource’s ID, retrieve its current contents. The patient’s data is returned by an HTTP GET to /{ResourceType}/{id}, such as GET /Patient/12345.

Update: Use its ID to edit an existing resource, or create one if none already exists. (HTTP PUT with the updated data, replacing the old version of the resource, to /{ResourceType}/{id}).

Delete: Remove a resource. (HTTP DELETE to /{ResourceType}/{id} to delete that record.)

Search: Query a resource type based on criteria. Patients born on a specific day may be found using (HTTP GET to /{ResourceType}?[parameters], for example, GET /Patient?birthdate=1980-01-01. Results are returned in a Bundle of matching resources.)

History: Get a resource’s or type’s change history. (For the version history of a particular resource, use GET /{ResourceType}/{id}/_history; for all modifications of that type, use GET /{ResourceType}/_history.)

FHIR’s Extended Operation

FHIR defines a collection of extended operations in addition to the fundamental create, read, update, and delete actions. These give healthcare data interchange more adaptability for more intricate use cases.

Batch & Transaction

Clients can use a bundle of actions to send several requests in a single HTTP call. Every request is handled independently by a batch. All requests are handled as a single atomic unit in a transaction, which means that they either succeed or fail collectively.

Patch

Partial updates are possible with this process. Clients can submit just the modified fields rather than the complete resource. This speeds up processing and conserves bandwidth.

Versioned Read

Historical versions of a resource can be retrieved via FHIR. Users can examine earlier entries by adding a version ID in the request, like GET /{ResourceType}/{id}/_history/{versionId}. Data lineage tracking and audit trail maintenance depend on this.

Custom Operations

Specialized operations, typically preceded by a dollar sign ($), are also permitted by FHIR APIs. Advanced queries or server-side logic may be triggered by them. For example:

$validate determines if the content of a resource is legitimate.
All of the patient’s associated records are returned by $everything on a patient.
A bulk export may be started by $bulk-data, depending on how it is implemented.
GET or POST queries to specific URLs, as /[ResourceType]/{id}/$[operationName], are used to invoke certain actions.

Capabilities

A Capability Statement, formerly known as a Conformance Statement, is required to be published by each FHIR server. This resource is returned by a request to [BaseServer]/metadata.

It outlines the sorts of resources, operations, and search parameters that the server provides. All FHIR servers are required to implement this one interaction, which allows clients to learn about the capabilities of the server.

Common Use Cases for FHIR in Healthcare IT

Because of its flexible APIs and standardized resources, FHIR can be used in a wide range of real-world healthcare IT settings. FHIR is revolutionizing the use and sharing of data in the following important use cases:

Patient Access and Mobile Health Apps

Giving patients direct access to their medical records via third-party apps is one of FHIR’s most revolutionary features. This is currently required by contemporary interoperability regulations for insurers and healthcare providers. FHIR-based APIs allow patients to access visit summaries, lab results, prescriptions, and even claims information.

A surge of patient-facing applications has been spurred by this change. Hospital EHR systems now easily interface with smartphone wellness apps and personal health record technologies.

One well-known example is Apple Health, which uses FHIR to enable consumers to download medical records straight to their iPhones from several institutions.
Patients can combine data from several providers into a single perspective by using this method.
When necessary, they may also decide to share it.

Everything is based on standard queries rather than custom integrations. In addition to empowering patients, this encourages innovation and expands the ecosystem of health apps that aim to enhance care and participation.

Provider-to-Provider Data Exchange

Healthcare providers are increasingly exchanging health information via FHIR. Hospitals and clinics can share data in real time using FHIR APIs rather than faxing or using outdated HL7 v2 messages.

When a patient is referred to a specialist from a primary care clinic, for example, the referring provider can send the patient’s summary record to the specialist’s system as a collection of FHIR resources (Patient, Encounter, Condition, Medication, Observation, etc.).
The receiving EHR can automatically ingest these standardized resources, avoiding manual re-entry.
Similarly, regional Health Information Exchanges and national networks are adopting FHIR to allow querying for a patient’s records across organizations.
Because every provider has access to the most recent information, the outcome is a faster, more dependable data flow and better coordinated care.

Public Health Reporting and Analytics

Timely data reporting to public health authorities and for research has been a challenge with legacy systems. FHIR streamlines this by providing standard resource formats for common public health data needs. For instance, a clinical system can notify public health registries about an infectious disease case by sending them an Immunization record or an Observation and Diagnostic Report over an FHIR API.

Certain systems used FHIR to transmit test results and immunization records to government databases in almost real-time during the COVID-19 epidemic.

Similarly, the FHIR Bulk Data API enables authorized analysts to extract substantial collections of de-identified patient data in a consistent format for analysis in research and population health analytics.

This allows large-scale projects like quality measurement, clinical research, and AI development, and is significantly more efficient than the previous method of each institution giving data in multiple formats.

Payer-Provider Data Integration

FHIR is also being used by health providers and insurers to enhance data sharing. A complete picture of patient health and expenses can be obtained by merging the clinical data that providers retain and the claims data that payers typically hold.

Using FHIR, payers can access certain clinical data from provider EHR systems for care management or prior authorization decisions.

For instance, an insurer might request recent lab results or patient encounter notes using the provider’s FHIR API rather than requesting that a clinic fax documents.
Conversely, a lot of insurers now make FHIR APIs available so that approved providers and patients can obtain claims, insurance coverage details, and prior authorization statuses in a uniform manner.
FHIR’s payer-provider data integration ensures that everyone is using the most recent information and lessens administrative overhead.

These application cases all highlight FHIR’s function as an enabler of interoperability.

FHIR offers a standard language and toolkit that lowers integration friction, whether it’s a patient app extracting data from an EHR or two hospital systems sharing records.

Related: FHIR API Strategy for Health Systems: Build vs. Extend vs. Integrate

FHIR in the Regulatory and Industry Landscape

Global use of FHIR is increasing as a result of robust industry and regulatory support. The 21st Century Cures Act Final Rule in the United States requires interoperability through the use of FHIR APIs. Standardized APIs, mostly based on FHIR R4, must be supported by all certified EHR systems as of late 2022.

Core patient and demographic data must be made electronically accessible by providers and health plans, or else they risk fines for noncompliance. Many healthcare organizations have upgraded their systems as a result of this push, which has prompted major manufacturers like Epic, Cerner (Oracle Health), and Allscripts to integrate extensive FHIR compatibility.

Adoption is prevalent worldwide:

UK: For national digital health services, NHS England mandates FHIR “UK Core” profiles.
Germany: FHIR is essential to national e-prescription and EHR systems.
FHIR frameworks have been released by national authorities in Canada and Australia.

Because of its stability and regulatory support, FHIR R4 continues to be the industry standard even as FHIR R5 (2023) adds new resources and subscription models. While keeping an eye on R5 and making plans for R6, many firms stick with R4.

Adopting FHIR R4 now helps hospital IT professionals stay compliant, get ready for future developments, and facilitate smooth data transfer between systems.

CapMinds HL7 FHIR Services: Powering Seamless Healthcare Interoperability

At CapMinds, we don’t just talk about interoperability, we deliver it.

Our HL7 FHIR services help healthcare organizations accelerate integration, improve compliance, and unlock real-time data exchange across providers, payers, and patient apps.

Whether you’re implementing FHIR APIs for patient access, building payer–provider data workflows, or scaling your EHR infrastructure, our team ensures smooth, secure, and standards-compliant execution.

With CapMinds, you gain a partner that combines healthcare expertise with advanced digital health tech. Our service portfolio includes:

HL7 FHIR API Development & Integration – Build secure, scalable interfaces for providers, payers, and apps.
Custom EHR/EMR Development – Tailored solutions to fit your specialty and workflows.
Healthcare Data Migration & Interoperability – Move and connect data safely across systems.
Compliance & Security Services – HIPAA, TEFCA, and industry-grade security frameworks.
Ongoing Support & Optimization – Ensure reliable performance and regulatory alignment.

CapMinds empowers healthcare IT teams to stay ahead of regulations, reduce integration costs, and deliver 30% faster interoperability outcomes.

Partner with CapMinds today to turn FHIR into a true driver of healthcare innovation.

Contact us