FHIR Integrations and Interoperability in Healthcare

Introduction

Patient data locked in disconnected systems creates real, measurable harm. A 2025 JAMA Network Open study of 8,122 family physicians found that fewer than 15% reported an ideal interoperability experience — with only 8% reporting ideal access to test results from outside hospitals. At care transition points like hospital discharge or interfacility transfers, that gap isn't just inconvenient. It delays decisions, triggers duplicate tests, and breaks down handoffs between clinical and logistics teams.

FHIR (Fast Healthcare Interoperability Resources) has become the dominant standard for solving this problem. Built on modern web APIs and structured data formats, FHIR enables healthcare systems to share patient information in real time, across organizations, platforms, and care settings — including the logistics and transport workflows that activate after a clinical decision is made.

This article covers what FHIR is, how it differs from HL7 v2, where it's used across the care continuum, how SMART on FHIR extends it into clinical workflows, and what implementation challenges to plan for.

---

Key Takeaways

• FHIR uses RESTful APIs and modular "resources" to enable real-time, standardized patient data exchange
• ONC's Cures Act Final Rule makes FHIR-based APIs a compliance requirement for certified health IT
• HL7 v2 and FHIR coexist — most organizations layer FHIR APIs on top of existing v2 infrastructure
• SMART on FHIR allows third-party apps to launch directly inside EHR systems without manual data re-entry
• In practice, FHIR deployments reduce scheduling time, cut duplicate data entry, and accelerate discharge workflows

What Is FHIR and Why Does Healthcare Need It?

The Standard, Defined

FHIR — Fast Healthcare Interoperability Resources — is a data exchange standard developed by HL7 International. It uses RESTful APIs and HTTP operations to expose clinical data as structured, retrievable units called resources. Each resource represents a discrete piece of patient information:

• Patient records
• Medications
• Encounters
• Observations
• Diagnostic reports

Unlike older document-based approaches, FHIR lets systems request exactly the data they need, in real time, using the same web standards that power modern software.

FHIR R4, published in 2019, was the first version with normative content — meaning its core components are stable and locked for production use. US implementations align to HL7 US Core v9.0.0, which constrains FHIR R4 profiles for the US market and specifies required data elements, terminology bindings, and must-support expectations.

The Regulatory Driver

Federal regulation has turned FHIR from a best practice into a compliance requirement. ONC's Cures Act Final Rule — implementing the 2016 21st Century Cures Act — requires standardized APIs for patient and population services under 45 CFR 170.315(g)(10), explicitly referencing FHIR R4 and US Core. CMS's Interoperability and Patient Access Final Rule separately requires covered payers to implement FHIR-based APIs for patient data access.

By 2022, ONC reported that 74% of hospitals used FHIR-based APIs to enable patient app access — up from 62% the year before.

The Practical Payoff

Because FHIR resources use standardized definitions, any FHIR-compliant system can receive and interpret data from any other. That eliminates the need for custom point-to-point interfaces between every pair of systems: a historically expensive and brittle approach that broke down every time one vendor updated their schema.

How FHIR Enables Healthcare Interoperability

The Three Foundational Building Blocks

Effective FHIR interoperability rests on three layers working together:

• FHIR Resources — Modular data units (Patient, Encounter, Observation, etc.) with standardized definitions
• RESTful APIs — The transport mechanism enabling on-demand data requests using standard HTTP operations
• FHIR Profiles (US Core) — Implementation constraints that enforce consistency in required fields and coding systems across organizations

The Architecture in Practice

A working FHIR integration typically involves four layers:

1. FHIR Server — Stores and exposes patient data as retrievable resources
2. API Gateway — Controls and routes traffic between systems
3. Authentication Layer (OAuth 2.0) — Restricts access using scoped authorization tokens
4. Middleware/Integration Layer — Translates legacy formats like HL7 v2 messages into FHIR resources

This layered approach is what makes FHIR practical in the real world. Most healthcare organizations don't operate on greenfield infrastructure; they run decades-old HL7 v2 pipelines alongside modern EHRs. Middleware absorbs that complexity, and it's precisely this abstraction that allows modern on-demand data exchange to sit on top of legacy infrastructure.

Why Resource-Based Exchange Matters

Older message-based standards transmit entire documents regardless of what the receiving system actually needs. FHIR inverts this: systems request specific resources on demand. A transport coordinator needs a patient's demographics and discharge destination — not the full clinical record. FHIR delivers exactly that, in real time, without overwhelming the receiving system.

Terminology: The Glue That Makes It Actionable

US Core terminology profiles bind FHIR resource elements to standard code systems, ensuring both sides of an exchange interpret data identically:

• LOINC — Laboratory and clinical observations
• SNOMED CT — Clinical concepts and diagnoses
• ICD-10-CM — Diagnosis and procedure codes
• RxNorm — Medications

Without consistent terminology, a "sodium" result from one system and a "Na+" result from another remain clinically ambiguous. Standardized bindings eliminate that ambiguity — which matters just as much for a discharge planner routing a patient as it does for a clinician reading lab results.

---

FHIR vs. HL7: Key Differences and When Each Is Used

FHIR isn't a replacement for HL7 — it's the latest evolution of the standard. HL7 International developed both standards. FHIR builds on decades of lessons from HL7 v2 (introduced in 1987) and HL7 v3, applying modern web architecture to the same interoperability problem.

Side-by-Side Comparison

Dimension	HL7 v2	FHIR R4
Data format	Pipe-delimited messages	JSON / XML resources
Integration style	Point-to-point, message-based	API-based, resource-based
Real-time access	Limited	Native, on-demand
Scalability	Low (custom per connection)	High (standardized APIs)
Implementation complexity	High for each new interface	Lower with shared standards
US regulatory status	Not mandated for new APIs	Required under ONC certification

The Hybrid Reality

Most healthcare organizations aren't starting from scratch. Their core clinical workflows — ADT feeds, lab results, medication orders — still run on HL7 v2. Replacing all of that overnight would disrupt operations.

The practical approach: layer FHIR APIs on top of existing HL7 v2 infrastructure via middleware. The flow works in three steps:

1. Legacy systems continue sending HL7 v2 messages without disruption
2. Middleware translates those messages into FHIR resources
3. Modern applications and patient-facing tools connect via FHIR APIs

This keeps clinical workflows intact while organizations meet ONC certification requirements and open new integration pathways on their own timeline.

---

Real-World FHIR Use Cases Across the Care Continuum

EHR-to-EHR Interoperability

FHIR APIs allow clinicians to access patient records across different hospital systems at the point of care. When a patient transfers from a community hospital to a tertiary center, the receiving team can pull medications, recent labs, and encounter history directly — rather than waiting for faxed records or re-ordering tests already completed.

The cost of not doing this is real. A peer-reviewed study found that 32% of transferred patients with incompatible electronic records had duplicate testing within 12 hours, and roughly 20% had at least one test repeated that wasn't clinically indicated.

Major EHR vendors — Epic, Oracle Health, athenahealth, MEDITECH — all publish FHIR R4 APIs, making cross-system access increasingly feasible without custom integration work.

Patient Logistics and Care Coordination

That clinical data access only solves half the problem. The other half is operational: getting the right information to transport providers, skilled nursing facilities, and home health agencies without re-entering it at every handoff.

Without FHIR, care coordinators manually key the same patient demographics into multiple systems — introducing transcription errors and burning time on phone and fax workflows that haven't changed in decades.

VectorCare's SMART on FHIR integration with Epic shows how this works end-to-end. When a care coordinator initiates a transport or discharge request inside Epic, FHIR APIs automatically pull:

• Patient demographics, pickup location, and destination
• Real-time tracking updates written back to the patient's chart
• Full transaction documentation — no separate login, no duplicate entry required

For a 250-bed hospital running 25 daily transports, this compresses annual coordination labor from roughly 4,714 hours to approximately 456 hours — a 90%+ reduction.

Patient-Facing Applications

FHIR APIs allow patients to access their own health records through mobile apps and patient portals. As of 2022, 74% of US hospitals provided FHIR-based API access for patient apps. This supports medication adherence, chronic disease self-management, and compliance with patient access mandates under the Cures Act.

Population Health and Analytics

Bulk FHIR (also called Flat FHIR) enables asynchronous export of patient-level data across thousands of records — without taxing real-time API systems. Health systems use it for risk stratification, value-based care reporting, and population-level gap analysis. The Bulk Data Access implementation guide supports export at the all-patients, subset, or defined-group level.

Telehealth and Remote Patient Monitoring

A 2024 peer-reviewed study on smartwatch-based remote monitoring described FHIR integration as a key step toward connecting consumer wearables with standardized clinical workflows. FHIR enables wearable devices and telehealth platforms to transmit biometric data directly into EHR systems — supporting continuous chronic care monitoring without requiring additional clinical documentation.

---

SMART on FHIR: Connecting Applications Directly Into EHR Workflows

What SMART on FHIR Is

SMART on FHIR — developed out of Boston Children's Hospital's Computational Health Informatics Program — provides a standardized framework for third-party applications to connect to EHR systems. It layers OAuth 2.0 and OpenID Connect on top of FHIR data access, defining exactly how apps request authorization, receive patient context, and launch within the EHR environment.

The result functions like an app store model for healthcare: developers build once against the SMART App Launch specification and deploy across any EHR that supports the standard.

The Clinical Workflow Benefit

SMART on FHIR apps launch directly inside the EHR interface. A clinician doesn't switch systems, re-enter a patient name, or open a separate browser tab. The app receives patient context automatically — and any documentation it generates writes back to the chart.

VectorCare's SMART on FHIR Epic integration makes this concrete. When a transport or logistics request is initiated inside Epic, VectorCare pulls demographics, insurance, and encounter data automatically via FHIR APIs. The care coordinator books transport in under a minute. Real-time tracking updates appear in the patient's chart without any additional steps.

What previously took 31 minutes of phone and fax coordination now takes less than 60 seconds.

The MTP (Medical Transfer Protocol) SMART on FHIR app — built through VectorCare's partnership with Priority Dispatch Corp and listed on Epic Showroom — takes this further. It brings evidence-based interfacility transfer protocols directly into the Epic workflow, covering:

• Scheduled transfers
• Up-care transports
• Behavioral health transfers

Patient acuity, equipment needs, and transport modality recommendations are determined by structured protocol rather than institutional memory, with ICD-10 billing codes attached at the dispatch level.

CDS Hooks: Workflow-Triggered Decision Support

CDS Hooks is a complementary standard that fires event-driven triggers at specific clinical moments — a discharge order, a medication prescription, a bed assignment. When a hook fires, relevant patient data is sent to an external decision support service, which returns real-time recommendations directly within the clinician's workflow.

Think of the three standards as distinct layers: FHIR handles the data, SMART handles the app launch, and CDS Hooks handles the trigger. Together, they enable logistics or clinical decision support to activate automatically when the right clinical event occurs — rather than waiting for a manual request.

SoFaaS: FHIR Integration at Platform Scale

VectorCare's 2026 launch of SoFaaS (SMART on FHIR as a Service) extends this model to other healthcare vendors — enabling organizations to build and deploy EHR-embedded logistics applications without rebuilding FHIR infrastructure from scratch. The platform model replaces the point-to-point custom integration work that has historically made EHR connectivity expensive and slow.

---

Common Challenges in FHIR Integration and How to Overcome Them

Data Mapping and Semantic Inconsistency

Legacy systems store data in formats (HL7 v2 pipes, custom databases, proprietary schemas) that don't map neatly to FHIR resources. A "diagnosis" field in one system may not correspond directly to a FHIR Condition resource in another. Clinical terminology compounds this: one organization's "shortness of breath" coded differently from another's creates downstream reconciliation problems.

Best practice: Adopt US Core profiles as your baseline implementation constraint, align all data elements to standard terminologies (LOINC, SNOMED CT, ICD-10-CM, RxNorm), and validate mappings before go-live — not after your first failed data exchange.

Versioning and Adoption Variability

Even when two systems share a version label, they don't always behave the same way. FHIR has progressed through DSTU2 (2014), STU3, R4 (2019), and R5 (2023) — and implementation differences within R4 alone can create compatibility friction that isn't apparent until testing.

Best practice:

• Standardize on FHIR R4, the version referenced in current ONC certification criteria
• Define implementation guides for every integration point
• Require conformance validation as part of go-live criteria
• Test interoperability directly — two systems labeled "R4 compliant" won't always exchange data cleanly without it

Security and Compliance Complexity

Data mapping and versioning problems are recoverable. Security failures often aren't. FHIR APIs expose protected health information, and misconfigured access controls (overly broad scopes, missing audit logs, unencrypted transport) create HIPAA exposure that compounds with each new API connection.

Best practice:

• Implement OAuth 2.0 with SMART on FHIR for all app authorization
• Enforce role-based access controls scoped to specific patient contexts
• Use TLS for all API communication
• Maintain detailed audit logs covering every API interaction
• Review HHS HIPAA Security Rule requirements for ePHI technical safeguards, which include access control, audit controls, integrity, and transmission security

---

Frequently Asked Questions

What is a FHIR integration?

A FHIR integration is a connection between healthcare systems that uses the FHIR standard to exchange patient data in a structured, standardized format via APIs. It allows different EHRs, applications, and platforms to share information in real time without requiring custom-built interfaces for each pair of systems.

What is the difference between HL7 and FHIR integration?

HL7 v2 uses message-based, point-to-point interfaces that require custom development for every new connection. FHIR uses RESTful APIs that enable on-demand, real-time data exchange using modern web standards. FHIR uses RESTful APIs that enable on-demand, real-time data exchange using modern web standards. That makes it faster to implement, easier to scale, and more compatible across diverse systems than HL7 v2.

Is FHIR still used?

FHIR is the dominant healthcare data exchange standard. ONC reported that 74% of US hospitals used FHIR-based APIs for patient app access in 2022, and adoption has continued since. FHIR R4 is required under current ONC certification criteria and CMS interoperability rules.

What is SMART on FHIR?

SMART on FHIR is a framework that allows third-party applications to securely connect to EHR systems using standardized OAuth 2.0 authentication. Apps launch directly within the EHR interface and receive patient context automatically — no separate login, no manual data re-entry required.

Is FHIR required for regulatory compliance?

For certified health IT in the US, yes. ONC's Cures Act Final Rule and 45 CFR 170.315(g)(10) require FHIR R4-based APIs, and the CMS Interoperability and Patient Access Final Rule extends parallel requirements to covered payers. Information blocking prohibitions add further compliance pressure for any organization restricting electronic data access.

How does FHIR improve patient care coordination?

FHIR enables care teams across hospitals, transport providers, SNFs, and home health agencies to share real-time patient information in a standardized format. This eliminates manual handoffs and duplicate data entry, ensuring that clinical details — demographics, diagnoses, and equipment needs — reach the next provider automatically before the transition occurs.