What is FHIR in healthcare? A guide to the HL7 standard

HL7 data standards like FHIR are helping to create connected healthcare ecosystems that empower patients, clinicians, and organisations – and improve patient care and advocacy.

Infor_3D Platform Image_Library_Dark_03.jpg

What is FHIR in healthcare?

FHIR meaning and definition
Why is FHIR important?
Benefits of FHIR standards
Building blocks of FHIR
Use cases and examples
Implementing FHIR
Best practices for FHIR integration
Achieving FHIR compliance
FAQs

Today’s world is a digitalised and connected place – and our healthcare information needs to be too. Before HL7 and other data standards, important health data was stored in physical office silos and relied on snail mail, fax machines, and error-prone manual entries to share it. Now hospitals, labs, clinics, pharmacies, payers, wearables, and other healthcare systems can easily communicate and share data that’s critical for providing efficient and effective patient care.

What does FHIR stand for? FHIR meaning and definition

Pronounced “fire,” FHIR stands for “fast healthcare interoperability resources.” It’s a data standard designed to allow medical information to flow across different systems using web technologies like REST APIs and XML. Created by HL7, a non-profit organisation that develops global standards for the healthcare industry, FHIR defines a common data model made of modular “resources” that allows many types of health systems to exchange medical records. It also supports exchanging data through RESTful interfaces, as well as messaging and document-based workflows. FHIR is one of the most important standards used today by many commercial and federal initiatives.

Why is the FHIR standard important?

FHIR is useful in many real-world hospital and clinical scenarios. Without standards like HL7 FHIR, their systems, apps, and devices couldn’t share critical information for treating and caring for patients. This connectivity is what makes it possible, for example, for an A&E doctor to treat an unconscious patient safely with quick access to their medical history. Or for a patient to be able to access their electronic health records (EHR) before a doctor’s appointment to help them think of questions in advance. It also paves the way for running advanced, AI-driven analytics.

Earlier HL7 standards laid the groundwork for today’s connected healthcare ecosystem by creating common rules for exchanging information. FHIR is the latest iteration, including a cleaner design and web-friendly tools for simpler, faster, and more reliable data sharing.

What are the main benefits of FHIR?

More complete, accurate records

Health records have fewer errors, typos, or gaps caused by manually entering data from paper documents. Repeat tests and imaging are also reduced, saving time and costs.

Seamless interoperability

FHIR standards create a kind of connected global healthcare network where patients and providers can access complete information regardless of where it was generated.

Empowered patients

When patients can view their own health records, they can use them to ask informed questions, stay on top of potential health issues, and advocate for their own care.

Innovation

Integrating with EHR records and other data sources becomes as straightforward as connecting to a web service, making it easier to build smart solutions and apps in the cloud.

AI and analytics

Analytics and AI systems need standardised data for training, making predictions, and generating clinical insights. FHIR does this without having to cleanse or map data.

Compliance and security

FHIR uses secure communication and authentication protocols like HTTPS and OAuth 2.0 to comply with data protection standards and control access to sensitive information.

Loading component...

How does FHIR work?

There are three basic components that allow FHIR to exchange healthcare data in a consistent way: FHIR resources, a built-in API, and a dedicated server. Here’s how they all work together.

FHIR resources: FHIR breaks down medical data into small, reusable parts called “resources.” Each resource contains information about specific things – lab results, patient records, and appointments, for example. These resources all follow the same structure and naming rules outlined by FHIR, which means different systems can easily exchange data because they’re all speaking the same language.
FHIR API: The built-in API allows resources to be exchanged across systems using modern web technologies, such as REST APIs, HTTPS, JSON, or XML. It also defines how apps can make requests, search data, and send data consistently.
FHIR server: A server is also needed to store the resources and let other apps read or write information through standard HTTP requests. The server must also support standardised search parameters and validate data to ensure resources follow the right rules.

Through these components and processes, FHIR allows hospitals, apps, and platforms to keep their own software and databases while still consistently exchanging data.

Common FHIR use cases and examples

FHIR allows data to be shared across diverse healthcare organisations and systems, including life sciences, providers and payers, pharma companies, and research projects. Each connection requires a different FHIR use case – whether connecting patients with lifesaving cancer research or monitoring patient vitals remotely. Most of these have established implementation guides for faster integrations.

Patient information exchange

Allows a patient’s core health data and medical history to be securely shared across hospitals, doctors’ surgeries, and other healthcare settings.

Guides: US Core, IPS, and UK Core

Patient access to health data

Empowers people to access their own health data through APIs designed for consumer apps – such as Apple Health.

Guides: SMART on FHIR, US Core, CARIN Blue Button

Labs and medical systems

Creates a pathway for laboratories to send new results and diagnostic reports to a clinician’s EHR system – immediately or by request.

Guides: US Core, LOINC

Payers and providers

Clears the way for payers and providers to share pertinent documentation, clinical data, and prior authorisations, all automatically.

Guides: DaVinci PAS, CRD, DTR

Public health reporting

Packages clinical data as anonymised FHIR resources to send to public health agencies per required reporting requirements.

Guides: UDS+ IG, eCR IG

Cancer research and oncology workflows

Connects cancer programmes with tumour data, staging information, genetic findings, and available treatments across research sites.

Guide: mCODE

Loading component...

FHIR implementation guide

Here's a quick overview of the eight implementation steps:

STEP 1: Decide which parties need to exchange data
Here’s where you choose which use cases you will implement. For example, you might need to exchange data between a hospital and clinic or a mobile app and electronic medical records (EMR) systems. Here are different versions and corresponding implementation guides for specific scenarios, such as sharing lab results or building a patient app.

STEP 2: Choose your FHIR version
Specific vendors, regulators, platforms, and global regions guide which version you will need to use (e.g., R4 or STU3). R4 is FHIR Release 4, v4.0.1 is the most common. Sometimes you may need to exchange data with a system or app built with older versions like DSTU2 or STU3, which you can either match or use an integration engine to connect with.

To support more advanced analytics and AI features, some providers and app developers may require R5, the newest version of FHIR. R4, R5, and future versions all contain “stable,” unchanging content, which makes for an easier transition.

STEP 3: Define your resources and profiles
The most common FHIR resources are used in almost every clinical workflow, from patient registration through to follow-ups and everything in between. They are:

Patient (used in every workflow)
Practitioner (clinicians or providers)
Encounter (e.g., a visit used for billing or medical context)
Observation (contains measurable data such as vitals and lab results)
Condition (significant symptoms, problems, and diagnoses)
Medication request (prescription orders and history)
Medication (drug details like codes and ingredients)
Allergy intolerance (e.g., adverse reactions, allergies)
Procedure (surgeries, therapies, treatments)
Diagnostic report (summaries for pathology and other tests)
Care plan (patient's care plan, goals, etc., used to coordinate care or manage chronic diseases)
Appointment/schedule (all related data)
Immunization (vaccination records)

In fact, this is the core set used by national FHIR standards such as Core US and Core UK because they are the most basic elements needed to tell a complete clinical story. Once you’ve defined your resources, the next step is to create profiles, which are basically rules for refining your resource data. They include elements like required fields, codes, and constraints for greater consistency.

STEP 4: Set up your FHIR server
Before data can be exchanged, it needs a home where it can live and be accessible. You have a couple of options: use a managed cloud service and APIs, or run your own open source or vendor-supplied server in your own data centre or cloud. These apps can request or send health data using RESTful web services.

STEP 5: Map existing data to FHIR resources
Different EHR, lab, and billing systems use their own internal formats to store data. This data needs to be mapped to your defined FHIR resources. The process involves transforming codes, IDs, history, and structures so they can be matched to the correct FHIR profile. You’ll also need to decide how to handle updates to the same patient or results so they are accurately represented over time.

STEP 6: Add security, authentication, and access controls
Safeguard your sensitive data and comply with regulations by adding the following security features:

HTTPS to encrypt requests to receive or send health data
Authentication and authorisation using standards like SMART on FHIR
Role-based access control for patients, clinicians, and apps/systems
Logging and audit trails to show who accessed or changed data

Many platforms and services include these security measures.

STEP 7: Test and validate
Use test apps to make FHIR API calls, and make sure the results show the correct data and codes. You should also run interoperability tests with your partner systems. Stop once you’re sure your data is both technically valid and clinically sound.

STEP 8: Go live and repeat
It’s a good idea to monitor your security logs, error rates, and API performance so you can make tweaks as needed – and inform your next project. You may also need to make adjustments as newer FHIR versions or requirements are released. Once everything is running smoothly, you can start adding new use cases over time.

Loading component...

Best practices for FHIR integration

Here are some proven best practices for a smoother integration process:

Focus on one use case or data need first. Limiting your focus early on allows for quick wins, a more manageable project scope, and lessons learned that you can apply to the next integration project.
Follow established implementation guides. Following existing guides for your use case and region – and keeping customisations to a minimum – speeds up the integration process and improves interoperability.
Map and normalise data carefully. Local fields, codes, and identifiers must be aligned with the structure of FHIR resources. This process not only ensures the structure of the data is technically valid, but also that the clinical data (e.g., systolic and diastolic blood pressure mapping) is accurate.
Use proven FHIR platforms or services. Instead of maintaining your own FHIR server, consider using established solutions and managed services to help keep costs and complexity in check. Most platforms provide versioning, scaling, security patches, and compliance controls.
Apply modern security standards. Use standard, not custom, security frameworks to authorise what apps are allowed to do and who can access them. OAuth 2.0, OpenID Connect (OIDC), and SMART on FHIR are the most widely used security standards across EHRs, cloud platforms, and healthcare apps.
Validate using automated tools and test suites. Using pre-built FHIR validators, compliance checkers, and official testing frameworks like Inferno can speed up the validation process. Validate both technical schema and required fields as well as clinical workflows.
Plan for good, long-term governance. Establish data governance rules for resources over their lifecycle. For example, allowing only standard fields over custom extensions will help prevent “FHIR drift” between systems – slight differences that cause incompatibilities over time.
Track and record FHIR APIs. By logging usage patterns, errors, performance, validation failures, and more, you can learn how well the APIs are working and also identify areas for improvement.
Prioritise the clinician and app-developer experience. Deliver a friction-free experience by providing clear API documentation, examples, sample data, and test clients. Keep essential information front and centre. And focus on creating intuitive apps with support for mobile and bedside workflows.
Design for the future. Create a structure that will allow new resources, apps, and partners to be introduced without having to rebuild from the ground up. Using messaging and event patterns to sync information across systems in real time, for example, allows systems to send automatic updates when events such as medication changes or lab results are available instead of relying solely on API functions.

Loading component...

Achieving FHIR compliance using a healthcare integration engine

A healthcare integration engine is software that connects different healthcare systems, routes messages, formats data, and ensures data is exchanged seamlessly – whether systems use HL7 standards, custom APIs, or their own databases. The engine supports easier compliance with FHIR regulations through the following:

Managed FHIR server

Provides a secure, scalable access point for sharing clinical data in real time. The server supports accessing and exchanging FHIR-compliant data through a standards-based API architecture.

Prebuilt FHIR adapters

A ready-to-use component that includes built-in configuration tools, validation and mapping logic, and monitoring – to share data easily between legacy healthcare systems and different versions of FHIR apps.

Anonymised data

Quickly anonymises data in an FHIR format to share data and run analytics while protecting patients’ personal health information – a requirement of SafeHarbour regulations and the UDS+ federal reporting system.

Loading component...

Conclusion

For so many years, critical health information was frustratingly scattered and hard to share. But today, FHIR is bringing order and clarity to that landscape, giving every system a common language and helping clinicians, patients, and partners work from the same trustworthy picture.

As organisations strengthen their digital foundations, FHIR offers a welcoming path forward. Its modular design and broad industry support make it easier to adopt new tools, connect with partners, and give patients more meaningful access to their own records. And as the healthcare ecosystem continues to evolve, FHIR helps ensure that everyone can move in step, with clearer insights and safer, more coordinated care.

See how Infor Cloverleaf, our award-winning healthcare integration platform, offers a fast, cost-effective way to adopt FHIR standards without replacing your IT investments.

Infor Cloverleaf

Loading component...

What is FHIR in healthcare? A guide to the HL7 standard