FHIR APIs and Healthcare Interoperability: What Engineering Teams Need to Know in 2026

ONC’s information blocking rules moved from guidance to enforcement in 2024, and health systems that have not yet built FHIR API infrastructure are running out of runway. The rule is not new — it has been in effect since 2021. What changed is who bears the penalty, and how aggressively the ONC is pursuing violations.

For engineering teams responsible for healthcare platforms, the practical question is no longer whether FHIR compliance is required. It is how to build it correctly, at what scale, and on what timeline.

Quick Summary

• ONC information blocking enforcement now includes civil money penalties for health IT developers and health information networks — not just covered healthcare providers
• FHIR R4 is the required standard for patient access APIs under the 21st Century Cures Act, and CMS interoperability rules extend that requirement to payer platforms
• Legacy HL7 v2 data is still the dominant format inside most EHR systems — FHIR platform builds require conversion pipelines, not just new API endpoints
• SMART on FHIR authorization is a separate engineering challenge from FHIR resource implementation, and is where most teams underestimate scope
• Health systems need to audit current data flows against information blocking exceptions before building new FHIR infrastructure — the exception landscape is complex

What Did ONC Information Blocking Enforcement Actually Change?

The ONC information blocking rule prohibits covered actors from interfering with the access, exchange, or use of electronic health information. The rule has been law since April 2021. What changed in 2024 is the enforcement mechanism.

Before 2024, information blocking complaints were investigated by the ONC Inspector General, but civil money penalties against health IT developers and health information networks had not been formally activated. The final rule activating those penalties — up to $1 million per violation for health IT developers — changed the calculation for every vendor selling into the US healthcare market.

The practical effect for engineering teams: platforms that restrict or obstruct patient data access, even inadvertently through technical design decisions, now carry direct financial exposure for the software vendor. This is not a compliance checkbox problem. It is an architectural problem that requires understanding which data flows in a platform might constitute information blocking, and redesigning them if they do.

HL7 FHIR R4 is the technical standard underlying the patient access API requirement, and most of the interoperability work happening in health systems in 2026 is centered on implementing FHIR R4 endpoints that meet the specification. The gap between “we have a FHIR endpoint” and “we are FHIR R4 conformant” is where most platform builds encounter unexpected engineering scope.

Why Is Healthcare Interoperability Engineering Harder Than Teams Expect?

FHIR interoperability looks straightforward on paper: define resources, expose REST APIs, implement SMART on FHIR authorization. Engineering teams that have built APIs in other domains typically assume this is a three-to-six week sprint. It is rarely that.

Three factors consistently extend FHIR platform timelines beyond initial estimates.

Legacy data is not FHIR-shaped. The data inside most EHR systems arrives via HL7 v2 messages — a format that is semantically different from FHIR in ways that require judgment calls during conversion, not just field mapping. A patient name in an HL7 v2 PID segment and a FHIR Patient resource look similar. The data lineage, the null handling, the code system references, and the relationship to other resources are different in ways that matter when the data drives clinical decisions. Building a conversion pipeline that handles edge cases correctly — without losing data that matters clinically — is a domain knowledge problem, not just a software problem.

SMART on FHIR authorization is a separate engineering challenge. SMART on FHIR is the OAuth 2.0-based authorization framework that controls which applications can access which patient data. Implementing it correctly requires handling both patient-facing and provider-facing launch contexts, managing refresh token lifecycles for long-running integrations, and coordinating with EHR authorization servers that each implement the specification slightly differently. Most teams underestimate this scope during planning and discover it during integration testing.

EHR vendor APIs are not uniform. Epic’s FHIR implementation, Oracle Health’s FHIR implementation, and athenahealth’s FHIR implementation each have quirks, extension resources, and capability statement gaps that diverge from the HL7 FHIR R4 specification. A platform built to integrate with multiple EHRs has to handle these divergences without building a separate code path for each EHR — which requires an abstraction layer that most teams design too late.

Healthcare software development for interoperability requires mapping these complexity drivers before the build begins, not after they surface in sprint three.

What Does a Production-Ready FHIR Platform Architecture Look Like?

Production FHIR platforms in health systems share architectural patterns that teams building for the first time consistently underestimate.

The data layer needs to handle both FHIR-native data and converted legacy data without losing provenance. That means data model decisions about how to track where a FHIR resource came from, what version of the source data it represents, and how to handle updates when the source system changes — decisions that have downstream consequences for audit trails and compliance documentation.

The API layer needs conformance testing built into the CI/CD pipeline. ONC certification testing [VERIFY] for FHIR conformance is a formal process, but the engineering goal is a platform that passes conformance testing because it was built conformantly — not a platform that was retrofitted to pass the test. Automated conformance checks at the build stage catch specification gaps before they become certification blockers.

The authorization layer needs to handle the full SMART on FHIR launch context spectrum — standalone launch, EHR launch, patient-facing launch — and the token management infrastructure that keeps long-running integrations authorized without requiring manual re-authentication. Most production FHIR platforms also need to handle the edge case where a patient revokes access mid-session, which requires event-driven propagation through the authorization layer.

The software development approach at CodeBranch applies an agentic pipeline specifically suited to this kind of architecture: AI agents handle FHIR resource schema generation, conformance test suite construction, and integration boilerplate, while senior engineers focus on the data mapping decisions and authorization design that require healthcare domain knowledge. The result is faster delivery on the high-volume work without cutting corners on the decisions that matter most.

How Should Health Systems Approach FHIR Migration from Legacy Systems?

Health systems with established EHR infrastructure face a FHIR migration challenge that is different from greenfield FHIR builds. The data exists. The clinical workflows exist. The question is how to expose that data through FHIR APIs without disrupting the workflows that depend on legacy data exchange formats.

The migration approach that works in production starts with a complete audit of existing data flows — mapping which HL7 v2 interfaces are in use, which clinical workflows depend on them, and which ones can be migrated to FHIR without touching clinical functionality. Not all HL7 v2 interfaces should be migrated. Some are deeply embedded in clinical workflows where the FHIR equivalent introduces more risk than benefit during the transition.

The FHIR layer typically runs alongside legacy interfaces during migration, not as a replacement. Patient access APIs, third-party application integrations, and new platform features use FHIR. Existing internal workflows that are stable and low-risk continue on HL7 v2 until migration can be sequenced safely.

Data quality remediation is almost always part of FHIR migration. Legacy data that was acceptable in an HL7 v2 context — because the receiving system knew how to interpret the gaps — fails FHIR validation because the resource schema is more explicit about required fields. Surfacing those data quality problems before migration begins, rather than during API testing, is what separates migrations that complete on schedule from ones that stall.

What Should Engineering Teams Validate Before Starting a FHIR Build?

Before any FHIR platform build begins, three things need to be validated that most teams skip.

First, the information blocking exception landscape. The ONC rule includes eight exceptions — including care coordination, preventing harm, and privacy — that permit certain restrictions on data access under specific conditions. Understanding which exceptions apply to the specific platform and use case determines the compliance scope of the build. Engineering teams that skip this step sometimes build FHIR endpoints that technically expose data they should be restricting under a valid exception — or restrict data that the rule requires them to expose.

Second, the EHR capability statements for every EHR the platform needs to integrate with. A capability statement is the machine-readable declaration of what FHIR resources and operations an EHR server supports. Reviewing these before scoping the build reveals which integration requirements are standard and which require workarounds — and prevents scope surprises during testing.

Third, the authorization model for every launch context the platform needs to support. Whether the platform is patient-facing, provider-facing, or both changes the SMART on FHIR implementation requirements significantly. Platforms that discover mid-build that they need to support both launch contexts typically require architectural rework that would have been straightforward to plan for upfront.

The Product Definition phase at CodeBranch covers all three of these validation steps as part of the pre-build architecture process. The output is an integration architecture document that specifies which FHIR resources are in scope, how legacy data will be converted, how authorization is structured, and what the conformance testing strategy looks like before a single line of production code is written.

Written by the CodeBranch team — Medellin, Colombia. CodeBranch specializes in agentic software development for healthcare companies. codebranch.co

CodeBranch is an agentic software development boutique and nearshore development partner based in Medellin, Colombia. We specialize in building AI-optimized development pipelines for product teams in the United States — from new product builds to AI transformation sprints to dedicated nearshore teams. With 20+ years of engineering experience and 10+ years delivering AI solutions, we work within US time zones with the cost advantage of being based in Colombia. codebranch.co