FHIR & Healthcare Interoperability Report 2026

This report is grounded in Halkwinds' engagement-based analysis of FHIR R4 implementation programs across health systems, payers, and digital health companies, combined with direct review of the CMS Interoperability and Patient Access final rule, the ONC 21st Century Cures Act Final Rule and its subsequent information blocking enforcement rule, and the FHIR R4 specification and implementation guides published by HL7 International. It is not based on a formal, statistically representative survey instrument with a fixed respondent count, sampling window, or published margin of error; where this report describes implementation patterns, adoption behavior, or program outcomes without a named source, those statements reflect Halkwinds' own analysis of engagement patterns and are consistent with the key findings published alongside this report.

Halkwinds applies a strict attribution discipline across this report, and every substantive claim falls into one of three categories. Statements presented without attribution reflect Halkwinds Research's own analysis of engagement patterns, described above. Statistics or claims attributed to a named third party — including HL7 International, the Centers for Medicare & Medicaid Services (CMS), the Office of the National Coordinator for Health IT (ONC/ASTP), KLAS Research, Gartner, or HIMSS — are drawn from that organization's publicly available research, regulatory text, or standards documentation and are cited as such; Halkwinds does not restate third-party figures as its own data. Passages framed as "Halkwinds analysis" or "in Halkwinds' assessment," particularly in the Future Outlook, Global Trends, and Cost Analysis sections, constitute qualitative interpretation by Halkwinds researchers rather than empirical survey findings and should be read accordingly.

This report's primary regulatory frame of reference is the United States, since CMS and ONC rules are the dominant near-term compliance drivers for the health systems, payers, and digital health companies this report addresses. The Global Trends and Regional Analysis sections extend the discussion to FHIR-adjacent interoperability initiatives in other geographies, drawing on published third-party sources rather than Halkwinds' own primary research in those markets. Readers should treat findings as most directly applicable to CMS-regulated and ONC-covered entities operating under U.S. federal interoperability rules.

• Findings reflect Halkwinds' engagement-based analysis of FHIR implementation programs, not a fixed-sample survey instrument with a published margin of error.
• Three-tier attribution: unattributed Halkwinds Research analysis, named third-party sources (HL7 International, CMS, ONC/ASTP, KLAS Research, Gartner, HIMSS), and explicitly labeled Halkwinds expert analysis or forecasting.
• Primary regulatory frame of reference is U.S. federal interoperability rules — the CMS Interoperability and Patient Access rule and the ONC information blocking rule.
• Global and regional interoperability context draws on published third-party sources rather than Halkwinds primary research outside the U.S.

The healthcare interoperability regulatory landscape is defined by two parallel frameworks that together establish both the data exchange standard (FHIR R4) and the behavioral requirements for data access. The CMS Interoperability and Patient Access rule mandates FHIR R4 API implementation for Medicare Advantage, Medicaid, and federal marketplace health plans — covering Patient Access APIs, Provider Directory APIs, and Payer-to-Payer APIs with specific data content and technical requirements. The ONC 21st Century Cures Act information blocking rule creates obligations for EHR developers, health systems, and health information networks to not engage in practices that unreasonably restrict the access, exchange, or use of electronic health information — a behavioral standard that complements the technical FHIR standard.

The FHIR ecosystem extends beyond regulatory compliance into a commercial API economy. SMART on FHIR application authorization enables third-party healthcare applications to request access to EHR data with patient or provider consent — creating a technical foundation for healthcare app stores and clinically integrated application ecosystems analogous to the mobile app ecosystem but operating within healthcare regulatory constraints. Health systems that have deployed SMART on FHIR authorization infrastructure can support third-party applications that integrate directly with their EHR data environment, enabling clinical workflow augmentation tools that would otherwise require deep EHR vendor integration.

Healthcare data exchange standards evolved through a multi-decade progression before FHIR became a regulatory mandate. HL7 v2 messaging and the Consolidated Clinical Document Architecture (C-CDA) dominated the pre-2015 era, offering interoperability in a document-exchange and message-segment format that was workable for point-to-point integration but poorly suited to the API-driven, granular data access that modern applications require. HL7 International began developing FHIR as a next-generation standard in the early 2010s specifically to address this gap, publishing draft standard versions before FHIR R4 was released as the specification's normative-track version in 2019 — the version this report's key findings reference, and the version underpinning current federal interoperability rules.

The regulatory turning point followed quickly: CMS's Interoperability and Patient Access final rule and ONC's Cures Act Final Rule, both finalized in 2020, converted FHIR R4 from a voluntary technical standard into a compliance requirement, establishing the Patient Access API and Provider Directory API obligations that took effect for CMS-regulated payers in the following one to two years, with Payer-to-Payer API obligations phased in afterward. This sequencing — a mature technical standard followed by a government mandate that forced market-wide adoption — is the direct regulatory lineage behind the compliance requirement identified in this report's first key finding.

The 2023-2026 period has layered enforcement and ecosystem expansion on top of the initial mandate. ONC's information blocking enforcement rule established civil monetary penalty exposure for health IT developers and health information networks/exchanges, shifting compliance from a voluntary posture to one with direct financial consequences. In parallel, the Trusted Exchange Framework and Common Agreement (TEFCA), administered through The Sequoia Project as the Recognized Coordinating Entity, began onboarding Qualified Health Information Networks into a national network-of-networks model, and CMS's Interoperability and Prior Authorization final rule extended FHIR API requirements further into utilization management workflows — the current-state regulatory environment this report examines.

• 2019: HL7 International publishes FHIR R4 as the normative-track release underpinning current federal interoperability rules
• 2020: CMS Interoperability and Patient Access final rule and ONC Cures Act Final Rule establish the FHIR-based compliance framework
• 2021-2022: Patient Access API and Provider Directory API compliance deadlines take effect for CMS-regulated payers
• 2023: ONC's information blocking enforcement rule establishes civil monetary penalty exposure for health IT developers and information networks/exchanges
• 2023-2024: TEFCA network-of-networks onboarding and CMS's Interoperability and Prior Authorization final rule extend FHIR API requirements further

FHIR's adoption trajectory extends well beyond the U.S. regulatory mandate that anchors this report. HL7 International's own standards adoption tracking identifies FHIR-based initiatives in national health systems including the UK's NHS England, which has built GP Connect and NHS App integrations on FHIR-based APIs, and Australia, where My Health Record infrastructure has been transitioning toward FHIR-based exchange — evidence that FHIR is converging into a de facto global health data exchange standard even in markets without a CMS-equivalent enforcement mandate.

The European Union's European Health Data Space (EHDS) regulation designates HL7 FHIR-based profiles as the technical backbone for cross-border patient summary and e-prescription exchange across member states, a development Deloitte's European technology and regulatory research has flagged as a parallel, regulation-driven FHIR adoption wave distinct from — but technically compatible with — the U.S. CMS/ONC framework this report focuses on.

The common pattern Halkwinds observes across these markets, in Halkwinds' expert assessment, is that regulatory mandate tends to precede rather than follow technical maturity: national health systems adopt FHIR at scale primarily after a government-issued interoperability mandate creates market obligation, mirroring the sequencing this report's Historical Timeline documents for the United States. Organizations building FHIR infrastructure with an eye toward international expansion should expect this mandate-driven adoption pattern to continue shaping the pace of interoperability investment in other geographies.

FHIR implementation maturity and regulatory drivers vary meaningfully by region, shaping how health systems, payers, and digital health companies should prioritize interoperability infrastructure investment depending on where they operate.

The FHIR compliance and capability landscape differs materially across the three organizational categories most affected by this report's findings — payers, health systems, and digital health companies — each facing a distinct mix of regulatory obligation and commercial opportunity.

FHIR R4 implementation infrastructure spans a spectrum from EHR-native FHIR server implementations built into major EHR platforms (Epic's FHIR server, Oracle Health's FHIR APIs) through standalone FHIR infrastructure platforms (HAPI FHIR, Microsoft Azure Health Data Services, Google Cloud Healthcare API) to FHIR transformation and normalization middleware that handles legacy system integration. Each layer of this stack introduces data quality, latency, and consistency characteristics that affect the viability of applications built on the FHIR data exchange layer. Applications requiring real-time clinical data access have different FHIR infrastructure requirements than those using batch-mode data aggregation for population health analytics.

AI-powered data normalization addresses the semantic interoperability gap that FHIR's syntactic standardization does not solve. FHIR defines how health data is structured and transmitted — it does not standardize the clinical coding systems, terminology, and data entry practices that determine whether patient data from two different sources means the same thing when presented in the same FHIR format. A medication listed in one organization's FHIR record may use a different drug coding system than the same medication in another organization's record. AI normalization tools that reconcile disparate coding systems, resolve patient matching ambiguity, and de-duplicate clinical data across sources are necessary infrastructure for applications that aggregate and act on FHIR data from multiple health systems.

Regulatory compliance requirements are the primary adoption driver for FHIR implementation, particularly for covered payers under the CMS Interoperability rules. Organizations that have not implemented required Patient Access, Provider Directory, and Payer-to-Payer APIs face compliance penalties that create straightforward investment justification — but compliance requirements alone produce minimum-viable implementations rather than the capability-grade infrastructure that enables commercial and clinical use case participation. Organizations that use regulatory compliance as the opportunity to invest in production-quality FHIR infrastructure generate more durable returns than those that invest only in regulatory minimum compliance.

Digital health application ecosystem participation is a commercial adoption driver for health systems and payers that see FHIR infrastructure as enabling new digital health product development opportunities. EHR platforms with well-implemented SMART on FHIR authorization can support third-party application ecosystems that extend clinical workflow capabilities beyond what the EHR vendor's native development roadmap delivers. Health systems that have published FHIR APIs supporting SMART on FHIR applications are enabling digital health innovation partnerships with companies that build AI diagnostic tools, care navigation applications, and remote monitoring integration tools on the health system's patient data foundation.

In Halkwinds' expert assessment, the incremental investment required to move from a minimum-viable, certification-passing FHIR implementation to the production-grade capability layer this report's key findings describe — encompassing performance testing under realistic load, semantic normalization tooling, and patient-matching infrastructure — regularly exceeds the cost of the initial compliance build itself. This pattern is directionally consistent with Gartner's broader enterprise IT research finding that organizations systematically underestimate post-deployment integration and data-quality costs relative to initial platform licensing, a dynamic this report observes specifically in FHIR API programs that pass regulatory certification but require substantial additional investment before supporting production clinical or commercial use cases.

AI-powered semantic normalization, identified throughout this report as necessary infrastructure rather than an optional layer, represents a specific and often unbudgeted line item within this capability-tier investment. Organizations planning FHIR infrastructure spend should budget for terminology reconciliation, patient-matching, and data de-duplication tooling as a distinct cost category from the FHIR API server or middleware licensing cost itself, since these two categories are frequently procured from different vendors and staffed by different technical teams.

Information blocking non-compliance carries a cost-avoidance dimension that should be weighed alongside direct infrastructure investment. ONC's enforcement rule creates civil monetary penalty exposure for health IT developers and information networks/exchanges that impede health data access without a qualifying exception, and — consistent with this report's Business Impact finding that enforcement activity is increasing — the cost of proactive compliance program development is substantially lower than the cost of enforcement response and remediation after an information blocking complaint is filed.

The business impact of FHIR interoperability infrastructure investment operates through multiple channels that are often not captured in traditional IT ROI models. Care coordination applications that use FHIR data to surface care gaps, medication discrepancies, and transition of care information demonstrate measurable impact on preventable readmissions and emergency visits — outcomes that generate direct financial value in value-based care contracts and quality bonus programs. Patient engagement applications built on Patient Access APIs are demonstrating improved member retention and care access patterns that translate to measurable payer and health system financial outcomes.

Information blocking compliance risk is a financial impact dimension that is often underweighted in FHIR investment analysis. ONC enforcement of the information blocking rule creates financial penalties for EHR developers, health IT networks, and health systems that impede health data access — and enforcement activity is increasing. Organizations that have not assessed their practices against the information blocking rule's permitted restrictions are accepting compliance risk that may materialize as enforcement activity expands. The cost of proactive compliance program development is substantially lower than the cost of enforcement response and remediation.

FHIR implementation architecture decisions — particularly the choice between EHR-native FHIR APIs and independent FHIR infrastructure platforms — have long-term implications for data freshness, system performance, and maintenance complexity. EHR-native FHIR implementations have the advantage of direct access to the clinical data store with minimal data latency, but may have API design, rate limiting, and data completeness characteristics determined by the EHR vendor's implementation priorities rather than the application requirements of the health system's specific use cases. Independent FHIR infrastructure platforms provide more architectural flexibility but introduce data synchronization complexity and potential data freshness challenges for real-time clinical applications.

Patient matching is one of the most consequential FHIR implementation challenges for multi-organizational data exchange. Identifying which patient records across multiple health systems belong to the same individual — without a universal patient identifier — requires probabilistic matching algorithms that make errors in both directions (false matches that create mixed records and false non-matches that prevent correct longitudinal data assembly). FHIR implementations that participate in multi-organizational data exchange must address patient matching architecture with a level of rigor appropriate for the clinical consequences of matching errors — mixed records can result in clinical decisions made on incorrect patient data.

• Set FHIR capability standards exceeding regulatory certification minimums for production use case support — certification passing does not equal production-grade API capability.
• Address patient matching architecture before multi-organizational FHIR data exchange — matching errors have direct clinical safety implications.
• Invest in AI-powered semantic normalization for FHIR data aggregation — syntactic FHIR compliance doesn't solve terminology and coding system heterogeneity.
• Conduct information blocking rule assessment before implementing any data access restriction — the rule's permitted restriction categories are specific and don't include historical information access barriers.
• Design SMART on FHIR authorization infrastructure for third-party application support if digital health ecosystem participation is a strategic objective.
• Assess FHIR API rate limiting and data completeness characteristics for each planned use case — API performance constraints often emerge in production use that weren't apparent in compliance testing.

Data quality and completeness risks in FHIR-based clinical applications are significant and not always visible to health system or payer technology teams whose FHIR implementations were designed for regulatory certification rather than clinical use. Patient records returned by FHIR APIs often have incomplete clinical histories — missing encounters from non-participating organizations, medication data reflecting only dispensing events rather than actual patient medication lists, and problem list data reflecting clinician documentation practices rather than actual clinical status. Clinical applications built on this data must be designed to present data incompleteness clearly to clinicians rather than presenting incomplete data as complete clinical histories.

Privacy and security requirements for FHIR-based patient data access are more complex than standard HIPAA frameworks because FHIR enables patient-authorized third-party access to health data for applications that may not be traditional healthcare providers or payers. SMART on FHIR authorization enables patients to authorize health apps that may have data use practices, secondary data sharing arrangements, and security postures that are not subject to HIPAA — creating patient privacy risks that organizations must address in their patient communication and third-party application review processes.

• Design clinical applications to surface FHIR data incompleteness explicitly — applications presenting incomplete records as complete are a patient safety risk.
• Implement third-party application review processes for SMART on FHIR-authorized apps — patient privacy risks from non-HIPAA-covered applications require organizational oversight.
• Monitor FHIR implementation performance in production continuously — API performance characteristics change as data volumes grow and use patterns evolve.
• Engage legal counsel on information blocking rule interpretation before implementing any health data access restrictions — the rule's exception categories are narrower than many organizations assume.
• Assess payer-to-payer API implementation requirements before member plan transition dates — implementation complexity is higher than initial regulatory summaries suggest.

Health systems and payers should treat FHIR infrastructure investment as a strategic capability platform rather than a compliance project. The regulatory requirements establish the minimum capability floor; the strategic opportunity is the clinical and commercial use cases that become achievable with production-grade FHIR infrastructure but are not achievable with minimum-viable compliance implementations. Organizations that frame FHIR investment against the capability-enabled use cases — AI-powered care coordination, SMART on FHIR application ecosystem, digital health product development — generate investment cases that justify production-quality infrastructure rather than regulatory minimum compliance.

AI capabilities for FHIR data normalization and clinical data quality should be prioritized alongside the core FHIR API infrastructure. The value of health data access scales with the quality of semantic interoperability — data that arrives in FHIR format but requires manual reconciliation to be clinically useful has not achieved the interoperability goals that motivate FHIR investment. AI normalization tools that automatically reconcile terminology, resolve patient matching ambiguity, and de-duplicate clinical data across sources should be evaluated as core infrastructure components rather than optional augmentation layers.

Large health systems, national payers, and multi-state digital health platforms are the organizations best positioned to move beyond the FHIR compliance floor, and this report's key findings suggest they should. Enterprises should set internal FHIR capability standards — performance under realistic production load, data completeness benchmarks by clinical domain, and semantic normalization coverage — that exceed CMS and ONC certification minimums, since certification alone does not guarantee the production-grade behavior this report's findings identify as the differentiator between compliant and capable implementations.

Enterprises have the scale to justify dedicated investment in the two infrastructure categories this report identifies as commonly unbudgeted: AI-powered semantic normalization (terminology reconciliation, patient matching, de-duplication) and SMART on FHIR authorization infrastructure sufficient to support a third-party application ecosystem. Enterprises should also lead on information blocking compliance program maturity, given that ONC enforcement activity is increasing and enterprises' scale of data exchange creates proportionally larger exposure if practices are found to impede information access without a qualifying exception.

Mid-size health systems, regional health plans, and smaller payer organizations typically cannot justify the full capability-tier investment this report describes for enterprises, and should instead sequence FHIR investment deliberately. The most efficient starting point is to rely on EHR-native FHIR server capabilities (Epic, Oracle Health, and similar platforms) rather than standing up independent FHIR infrastructure, since this report's Technology Landscape section identifies EHR-native implementations as lower-latency and lower-maintenance-complexity for organizations without dedicated interoperability engineering teams.

SMEs should prioritize closing the compliance-to-capability gap only in the specific data domains and use cases that matter most to their patient population and payer contracts, rather than pursuing uniform capability improvement across all FHIR resource types. Partnering with standalone FHIR infrastructure vendors (HAPI FHIR, Microsoft Azure Health Data Services, Google Cloud Healthcare API) for semantic normalization needs is generally a more capital-efficient path for SMEs than building AI normalization tooling in-house, consistent with this report's Cost Analysis finding that normalization tooling is frequently procured from different vendors than core FHIR API infrastructure.

Digital health startups are, per this report's Industry Analysis, primarily consumers rather than providers of FHIR infrastructure — their FHIR strategy should center on SMART on FHIR authorization integration rather than any attempt to build direct EHR data pipelines. Startups should design their application architecture from day one to handle the data completeness and performance variability this report documents across payer and provider FHIR implementations, treating incomplete or delayed FHIR responses as an expected operating condition rather than an edge case.

Because SMART on FHIR-authorized applications fall outside standard HIPAA coverage in the way this report's Risks & Challenges section describes, startups should build patient consent, data use disclosure, and security practices that meet or exceed HIPAA-equivalent standards even where not strictly required — both to reduce patient privacy risk and because health system and payer partners increasingly vet third-party applications' data practices before granting SMART on FHIR access. Startups should also budget for semantic normalization of ingested FHIR data early rather than treating it as a post-launch concern, since this report identifies semantic interoperability gaps as a problem that affects data aggregated from multiple sources almost immediately at any meaningful scale.

FHIR R5 and subsequent version evolution will introduce capabilities addressing semantic interoperability limitations that FHIR R4 does not resolve — including improved clinical data provenance, enhanced subscription mechanisms for real-time data push, and richer clinical terminology binding. Organizations building FHIR infrastructure now should design for version evolution by choosing implementation platforms with demonstrated track records of standards version migration, and by maintaining separation between FHIR version-specific implementation details and the clinical use cases that FHIR infrastructure supports.

The FHIR-enabled AI application ecosystem will expand significantly over the 2026-2030 period as the regulatory data access foundation matures. AI applications in clinical decision support, care coordination, population health, and patient engagement that have historically been constrained by data access limitations are beginning to deploy at scale using FHIR API access. Health systems and payers with production-grade FHIR infrastructure will be the most attractive platforms for these AI application partnerships — creating a compounding advantage for early FHIR capability investors relative to organizations that treated FHIR as a compliance checkbox rather than a strategic infrastructure investment.

This report draws on verified third-party regulatory text, standards documentation, and published research, distinct from Halkwinds' own engagement-based analysis described in the Research Methodology section. Readers seeking primary source material for the regulatory and standards claims in this report should consult the following external sources directly, since regulatory rules and standards specifications are updated periodically and this report reflects a point-in-time analysis as of its publish date.

• HL7 International — FHIR R4 specification and implementation guides (external standards body, not a Halkwinds publication)
• Centers for Medicare & Medicaid Services (CMS) — Interoperability and Patient Access final rule and Interoperability and Prior Authorization final rule (external federal regulatory text)
• Office of the National Coordinator for Health IT (ONC/ASTP) — 21st Century Cures Act Final Rule and information blocking enforcement rule (external federal regulatory text)
• The Sequoia Project — Trusted Exchange Framework and Common Agreement (TEFCA) program documentation (external, Recognized Coordinating Entity)
• KLAS Research and HIMSS Analytics — health IT and interoperability maturity assessments (external, verified third-party research)
• Gartner and Deloitte — enterprise IT cost benchmarking and European technology regulatory research cited in the Cost Analysis, Global Trends, and Regional Analysis sections (external, verified third-party research)
• European Commission — European Health Data Space (EHDS) regulation text (external regulatory source)
• Canada Health Infoway — PS-CA national FHIR profile documentation (external, national coordinating body)

Halkwinds is a technology strategy and engineering firm specializing in healthcare AI and digital health product development. Halkwinds' interoperability practice covers FHIR R4 implementation architecture, SMART on FHIR application development, AI-powered data normalization, and ONC/CMS compliance program design for health systems, payers, and digital health organizations.

Halkwinds Research publishes practitioner analysis on emerging healthcare technology trends. Readers seeking to engage Halkwinds on FHIR implementation strategy, healthcare data exchange architecture, or interoperability-dependent application development can explore the firm's capabilities at halkwinds.com or review the CareAxis healthcare platform.