Is Your EHR Actually FHIR Compliant?

Shikha Kumar · 23 Jul, 2026

Share

Ask a vendor if their EHR (electronic health record system) is FHIR-compliant, and most will say yes without hesitation, because it’s almost always technically true. 

Ask them to prove it exchanges data with your specific payers, labs, and referral partners in production, and the confidence tends to get quieter. 

That gap, between certified and actually interoperable, is where a lot of healthcare organizations are sitting right now without fully realizing it.

Quick answer: FHIR compliance and real-world interoperability are not the same thing. An EHR can pass ONC’s FHIR conformance testing while still failing to exchange usable data with your actual referral partners, payers, and health information networks, because certification tests the format of the data, not whether your specific connections were ever built and verified. The only way to know which one you actually have is to test real data exchange with a real partner system, not read the vendor’s spec sheet.

How Big is the Real-World Interoperability Gap?

This isn’t a fringe problem. According to ONC’s most recent interoperability data, 43 percent of U.S. hospitals now engage in all four domains of interoperable exchange, electronically sending, receiving, finding, and integrating outside data, up from 28 percent in 2018. 

That’s real progress, and it also means well over half of hospitals still don’t. Even among hospitals that do exchange data, only 74 percent actually integrate what they receive into the patient’s record rather than just viewing it separately, and just 61 percent of office-based physicians can electronically query external sources at all.

FHIR specifically has grown fast on paper: outpatient FHIR app adoption climbed from 49 percent in 2021 to 64 percent in 2024. But adoption of the standard and working interoperability in practice are two different curves, and the gap between them is exactly where the claim-versus-reality problem below shows up.

Why “FHIR-Compliant” is a Weaker Claim Than It Sounds

FHIR (Fast Healthcare Interoperability Resources) defines a data format and an API structure. It does not define which specific resources, profiles, or data elements a given vendor chooses to implement. 

Two systems can both pass FHIR conformance testing while structuring patient demographics differently, handling temporal data inconsistently, or supporting only a partial slice of the resources a real integration needs.

ONC (the Office of the National Coordinator for Health IT) certification, specifically the 2015 Edition Cures Update, is the regulatory floor here, not the ceiling. It confirms that a system passed a standardized test under controlled conditions. It doesn’t confirm that the system can exchange data with your actual network of payers, labs, specialists, and referral partners, because that depends on choices the vendor made that certification doesn’t force.

The Other Layers Most Compliance Checks Miss

FHIR compliance sits inside a bigger regulatory stack, and a check that only confirms “do you support FHIR R4” misses most of it.

USCDI v3 (the U.S. Core Data for Interoperability, version 3) became the mandatory data-content baseline on January 1, 2026. 

As recent industry guidance notes, ONC-certified EHRs now have to support this specific, expanded set of data classes, including social determinants of health, not just whatever FHIR resources a vendor happened to build first. 

An EHR certified before that update may need real engineering work to catch up, regardless of what the certification badge on its marketing page says.

TEFCA (the Trusted Exchange Framework and Common Agreement) is the newest layer on top of that: a federally designed “network of networks” that lets a single connection reach any provider connected to any participating Qualified Health Information Network, or QHIN. 

TEFCA went live with its first QHINs designated in December 2023, and the FHIR-based exchange under it began piloting in 2025. Whether your organization actually participates in TEFCA, Carequality, or CommonWell is a separate question from whether your EHR is FHIR-compliant, and in practice, it’s usually the more important one.

The enforcement layer has real teeth, too. The Information Blocking Rule, in effect since April 2021, allows penalties of up to $1 million per violation for health IT developers and health information networks found to be unreasonably restricting data access. 

A vendor that can’t clearly explain how their FHIR APIs satisfy this rule, or what their documented exceptions are, hasn’t fully worked through the compliance picture either, whatever their certification says.

Where the Claim and the Reality Usually Diverge

Here’s what that gap looks like in practice.

A specialty practice signs off on a new EHR partly because it’s marketed as FHIR-native and ONC-certified. Referrals still get faxed six months later, not because the API doesn’t exist, but because the practice was never connected to the health information exchange its main referral partners actually use. 

The certification was real. The interoperability it implied never got tested against the specific partners the practice actually works with, and nobody discovered the gap until it started costing staff time every week.

What a Real Audit Tests That a Spec Sheet Doesn’t?

A spec sheet review isn’t an audit. It’s a vendor’s word, formatted as a document. A real audit tests actual behavior: which specific FHIR resources and profiles are implemented, not just “FHIR R4 supported.” 

Whether your organization is actually connected to a health information network, and whether that connection is used routinely or exists only on paper. Whether patient matching and demographic data are clean enough for an exchange to resolve correctly on the first try. 

Whether your prior authorization workflow can connect to a payer’s FHIR-based API today, or would need custom work when CMS-0057-F’s deadline arrives. 

And whether “FHIR-compliant” in your vendor contract is backed by a specific, testable list of capabilities, or just the phrase itself.

None of this requires distrust of your vendor. It requires treating “FHIR-compliant” as a starting question rather than a finished answer, the same way you’d verify any other claim with real operational and compliance consequences attached to it.

Certification tells you that a system passed a test. It doesn’t tell you whether that system can do the specific job your organization needs, with your specific partners, under your specific deadlines. 

If you haven’t mapped where your own systems sit against the gaps above, a Modernization Readiness Audit covers exactly this, alongside the broader platform picture, for organizations in the healthcare sector. 

Author

Shikha Kumar

Co-Founder & Director