Can FHIR API Integration Unify Our EHR Silos by 2028?

AdvancedUNO
15 Jun, 2026
Can FHIR API Integration Unify Our EHR Silos by 2028?

7 min read

The Clinical Interoperability Ledger

  • The Core Shift: Moving away from fragile, custom point-to-point connections toward standardized HL7 FHIR R4 and SMART on FHIR API integrations.
  • The Driver: The 21st Century Cures Act and ONC Health IT Certification require certified health technology to provide API access to all electronic health record data elements without special effort.
  • The Financial Cliff: By 2028, CMS will exclude healthcare organizations lacking unified integration platforms from participating in actively funded value-based care models.
  • The Operational Friction: Migrations remain half-finished due to legacy data mappings, EHR vendor API pricing, and identity matching failures.
  • The Next Frontier: Next-generation agentic AI platforms, such as Innovaccer Gravity on Amazon Bedrock AgentCore, require these standardized data pipelines to coordinate clinical care teams in real time.

Why Does Clinical Data Still Stall When a Patient Crosses the Hallway?

A clinician reviewing a complex case shouldn't have to copy data across three systems that do not line up, yet this remains the norm in enterprise care.

In the quiet corners of our clinics, the failure of technology is rarely a failure of capability. It is a failure of execution. We have built extraordinary digital repositories for patient data, yet we have isolated them in proprietary silos. When a clinical team requires a complete picture of a patient's history, they are often met with a fragmented view. A lab result lives in one portal, a specialist's note in another, and the primary care history in a third. The clinician is left to act as the human bridge, manually reconciling data under the pressure of a ticking clock.

To resolve this, the federal government intervened with the 21st Century Cures Act. The Office of the National Coordinator for Health Information Technology (ONC) subsequently published rules against information blocking, mandating that certified electronic health record (EHR) platforms support standardized application programming interfaces. Specifically, the mandate focuses on HL7 FHIR R4 (Fast Healthcare Interoperability Resources) and the SMART on FHIR framework. This is not merely a technical upgrade. It is a regulatory and financial necessity. Over the next four to eight fiscal quarters, the pressure to transition will intensify. Healthcare organizations that fail to adopt unified integration platforms by 2028 will find themselves locked out of lucrative care models funded by the Centers for Medicare & Medicaid Services (CMS).

The transition, however, is not happening overnight. It is a slow, uneven migration. While new applications are built on modern API standards, legacy systems still rely on decades-old HL7 v2 messages or fragile database queries. We are living in a half-finished house, where the front door has a modern biometric lock but the back windows are held shut with duct tape.

The Mechanics of SMART on FHIR and the Bulk Data Pipeline

To understand why this migration is stuck, we must look at how these integration technologies actually work. Standard FHIR APIs are excellent for retrieving data for a single patient in real time. When a clinician opens a SMART on FHIR application within their EHR workflow, the app uses OAuth 2.0 and OpenID Connect to authenticate the user and secure authorization. It queries the EHR for specific resources—such as Observations, Conditions, or MedicationRequests—and displays them directly within the clinical screen, without requiring a separate login.

Think of SMART on FHIR as a secure universal power adapter; instead of rewiring the entire building's electrical system for every new appliance, you plug into a standardized wall outlet that safely regulates the voltage.

This works beautifully for individual clinical encounters. However, modern healthcare requires managing entire populations. If a health system wants to identify every patient with uncontrolled hypertension across a network of 48 clinics, querying patients one by one via standard FHIR APIs is operationally unfeasible. It would overwhelm the EHR database and trigger strict rate limits imposed by vendors like Epic or Oracle Health.

The Population-Level Engine: Bulk FHIR Access

This is where the SMART/HL7 FHIR Bulk Data Access API becomes necessary. Instead of individual queries, the Bulk API allows systems to request data elements across an entire patient population in a single, asynchronous operation. The EHR compiles the requested resources and exports them as Newline Delimited JSON (NDJSON) files, which are then transferred securely to an analytical platform or an agentic AI engine.

Rule of Thumb: If your FHIR integration strategy relies on mapping custom clinical notes to unstructured text fields without a standardized terminology server, your semantic interoperability will break at the first CMS audit.

The table below illustrates how these different integration approaches compare in a real-world enterprise setting:

Integration Approach Primary Protocol Data Payload Format Security & Auth Scalability Limit
Legacy Interfaces HL7 v2 / MLLP Pipe-delimited text VPN / IP Whitelisting High latency, rigid schemas
SMART on FHIR RESTful FHIR R4 Standard JSON OAuth 2.0 / OIDC Limited by EHR API rate limits
Bulk FHIR API NDJSON Export Newline Delimited JSON Backend Services Auth Asynchronous, high-throughput

How to Plan an EHR Integration Strategy Around FHIR R4

To see how this works in practice, let us look at a representative secondary-market multi-specialty group operating 142 clinical workstations. They are deploying a remote patient monitoring tool to track diabetic patients. Historically, this would require a custom database integration that took six months to build and cost upwards of $80,000 in vendor fees. Under a modern FHIR framework, the deployment follows a structured, repeatable path.

  1. Scope and Consent Authorization: The clinical IT team registers the monitoring application in the EHR's developer portal. During this step, they define the exact scopes required—such as patient/Observation.read and patient/Condition.read. The EHR generates secure client credentials, ensuring that the application can only access data for patients who have explicitly consented to the monitoring program.
  2. Resource Mapping and Validation: The team maps the blood glucose readings from the remote devices to the standard FHIR Observation resource. They validate that the units of measure conform to the Unified Code for Units of Measure (UCUM) standard. This step is critical; if the device records glucose in millimoles per liter but the EHR expects milligrams per deciliter, the clinical decision support alerts will fail.
  3. Workflow Integration via SMART: The application is embedded directly within the clinician's daily workflow. When a nurse opens a patient's chart, the EHR passes a secure context token to the application. The app launches inside the frame, pulls the latest blood glucose trends from the cloud, and highlights any readings that exceed the patient's target threshold. The nurse never has to leave the primary EHR screen.

This standardized approach reduces deployment times from months to weeks.

It shifts the focus of the IT department from writing custom code to managing data quality and clinical workflows.

Where the Interoperability Roadmap Fractures

  • The Myth of Automatic Compliance: Many healthcare executives believe that purchasing an ONC-certified EHR guarantees immediate compliance and interoperability. In reality, certified EHRs merely provide the raw API endpoints; the health system's internal IT team must still configure the security policies, manage identity matching, and maintain the data pipelines.
  • Underestimating Semantic Drift: It is a mistake to assume that because two systems support FHIR R4, they will understand each other automatically. A "Condition" resource mapped in one system may use ICD-10-CM codes, while another uses SNOMED CT; without active semantic normalization, clinical software will fail to aggregate the data accurately.
  • Ignoring API Call Volume Limits: IT teams often design applications that poll the EHR for updates every few minutes. EHR vendors frequently charge transactional fees or impose strict rate limits on API calls, which can lead to unexpected operational costs or service disruptions during peak clinical hours.

Frequently Asked Questions

What happens to our HIPAA audit trail when a third-party SMART on FHIR app's OAuth token is refreshed silently in the background?

The EHR's authorization server must log every token refresh event, linking it back to the original user session and the specific application client ID. Under HIPAA security rules, the health system must be able to produce an audit trail showing exactly which user authorized the app and what data resources were accessed during the silent refresh window. If the third-party app stores this data externally, it must also maintain its own compliant access logs that can be federated upon request.

How do we handle clinical safety risks when a FHIR API payload contains conflicting medication codes during a transition of care?

An integration pipeline must never silently overwrite conflicting data or auto-reconcile clinical discrepancies without human oversight. When a FHIR payload contains conflicting codes—such as an RxNorm code that does not match the local formulary—the receiving system must route the record to a clinical reconciliation queue. The EHR must display both options to a licensed clinician, requiring manual confirmation before updating the active medication list.

The CMIO's Long-Horizon View: The path to true interoperability is not paved with revolutionary software suites or autonomous AI agents operating in a vacuum. It is built on the unglamorous, disciplined work of maintaining clean data standards, enforcing strict API governance, and respecting the clinical workflow. Until we treat data plumbing with the same clinical gravity we reserve for patient safety, our systems will remain expensive, isolated islands.

When was the last time your IT team audited your EHR's API gateway logs to see how many legacy HL7 v2 interfaces could be retired in favor of a single, secure FHIR endpoint?

Related from this blog

Sources

Next Post Previous Post
No Comment
Add Comment
comment url