The State of EHR Interoperability in 2026: Why So Much FHIR Support Is Still Only on Paper

TL;DR

FHIR support is now a baseline claim, not a buying signal. In 2026, almost every ambulatory EHR advertises FHIR, SMART on FHIR, and ONC-aligned interoperability. None of that confirms a live, customer-active, production-grade FHIR R4 endpoint in your own environment.

The real gap is between certified FHIR and operational FHIR. It shows up as failed integrations, duplicate staff work, more training exceptions, inbox spillover, and more after-hours clinician work.

Even the strongest federal adoption numbers describe a narrow, enabled capability, not broad operational use. ASTP/ONC data shows 81 percent of hospitals had enabled app-based patient access and 70 percent had enabled FHIR-based patient app access in 2024, with the FHIR figure flat since 2023 and outpatient settings lower, near 64 percent.

Healthcare IT administrators should stop asking “Do you support FHIR?” The better question is: “Is the FHIR R4 endpoint live in our current account configuration, monitored, and already used for prior authorization, referrals, patient access, and care transitions?”

Thyra is built around this distinction. It deploys as a SMART on FHIR overlay on top of your existing EHR, so workflow value can be validated against a live endpoint before any migration.

Most ambulatory buyers are still being sold interoperability twice: once in the contract and again during implementation. The contract says FHIR, SMART on FHIR, API access, and ONC certification. Implementation often reveals something narrower: the endpoint exists, but it is disabled by default, scoped to a limited use case, not broadly supported, or not truly usable in the customer's production environment.

That distinction matters more in 2026 than it did even a year ago. ONC's HTI-1 rule increased visibility around FHIR service base URLs and maintenance expectations, while the CMS Interoperability and Prior Authorization Final Rule raised the operational stakes for patient access and prior authorization workflows. A practice can be compliant on paper and still be operationally stuck.

What did our 2026 review of ambulatory FHIR claims find?

This is a qualitative review of how ambulatory EHR vendors describe FHIR support in their public messaging, websites, and marketing collateral. It is not a field test of live endpoints and not an empirical benchmark, so we do not assign a sample size or a percentage to our own finding. The pattern, however, is consistent: advertised FHIR support is now near-universal across ambulatory EHRs, while public evidence of live, customer-active, production-grade endpoints carrying real workflows is much harder to find. Industry reporting estimates roughly 80–85 percent of ambulatory EHRs now claim FHIR API support — a figure we cite as third-party industry reporting, not as our own measurement. In vendor messaging, FHIR is table stakes. In the federal adoption data, the capability that matters is enabled unevenly and has stopped climbing.

The most-cited federal figures measure one specific capability: whether hospitals have enabled FHIR-based patient app access. According to ASTP/ONC Data Brief No. 79 (August 2025), drawing on the 2024 American Hospital Association IT Supplement, 81 percent of hospitals had enabled app-based patient access and 70 percent had enabled FHIR-based patient app access. That FHIR number rose from 57 percent in 2021 to 70 percent in 2023, then held at 70 percent in 2024. The federal authors attribute the flattening to technical, financial, and operational barriers.

Three points make those numbers smaller than they sound for an ambulatory buyer. First, they describe hospitals, and outpatient settings sit lower, with FHIR-based patient app access near 64 percent in 2024. Second, adoption is highly vendor-dependent: hospitals on the market-leading EHR were far more likely to have FHIR-based patient app access enabled (83 percent) than hospitals on other systems (56 percent). Third, and most important, patient app access is a single use case. None of these figures tell a specific ambulatory practice whether its FHIR R4 endpoint is live today for prior authorization, referrals, or care transitions. The headline number measures an enabled capability in one workflow, not operational interoperability across the work a clinic actually does.

Why is the gap between certified FHIR and operational FHIR so common?

Certification proves capability exists. Operations prove capability works. A vendor can pass certification, publish a service base URL, and still leave customers with limited activation, narrow scopes, inconsistent maintenance, or unclear support ownership.

That is why ecosystem-level adoption figures do not answer the buyer's real question. A national statistic about enabled patient app access does not tell a healthcare IT administrator whether a specific practice can use a FHIR R4 endpoint today for prior authorization, referrals, care transitions, or patient-facing apps without manual cleanup.

What is the 5-level FHIR maturity model buyers should use in 2026?

The model has five levels, each describing a stronger claim than the last. Only the top two reflect interoperability a practice can actually run on, and the levels align directly with the comparison table above.

1. Level 1 — Certified FHIR. The vendor passed certification criteria. Capability may exist on paper without broad operational use, and it does not confirm anything is enabled in your account.
2. Level 2 — Published endpoint. A FHIR service base URL is listed and documented. The address exists, but the endpoint may not be active in your environment.
3. Level 3 — Enabled endpoint. Technical API access exists in your current account configuration. Access is real, though workflow support may still be narrow or limited.
4. Level 4 — Operational FHIR. Real workflows run live through the endpoint in production. This is the first level that requires evidence, monitoring, and named support ownership.
5. Level 5 — Managed FHIR. Ongoing governance, issue ownership, and review by the vendor over time. This is the lowest-risk level because someone is accountable when a workflow breaks.

The buying mistake is treating Level 1 or Level 2 as if it were Level 4 or Level 5. Most contracts are written at Level 1, while most clinical pain is solved only at Level 4 and above. Ask each vendor, in writing, which level applies to your specific account configuration today — not to their product in general.

Why does paper interoperability create real workflow debt?

Paper interoperability creates workflow debt because staff still have to do the integration work by hand. When APIs are nominal rather than operational, the burden shifts to front-desk teams, referral coordinators, billers, medical assistants, and clinicians.

It shows up as duplicate entry, support tickets, training exceptions, inbox overflow, and after-hours cleanup. If prior authorization data does not move cleanly, someone rekeys it. If referral data arrives inconsistently, staff reconcile it manually. If patient-facing apps connect unreliably, the help desk becomes the integration layer.

That is one reason EHR software has not reduced documentation burden as much as buyers expected. The chart may be digital, but the workflow is still fragmented. Clinicians still spend time reconstructing context across notes, labs, messages, device feeds, and external records, then finish the unresolved work after clinic hours. This is the same pattern behind turning the clinical inbox into completed actions rather than a queue that simply grows.

Why is inbox management now a major burnout driver?

Inbox management drives burnout because it concentrates unresolved clinical, administrative, and interoperability failures into one queue that clinicians clear after hours. Results, refill requests, prior authorization questions, referral follow-up, patient messages, and device data all land in the same bottleneck.

This is not only a clinician observation. In the same 2024 analysis, ASTP/ONC noted that the rising volume of inbox messages represents a growing source of unmeasured care delivery, and that workflow optimization and support are needed to enable patient access without placing undue burden on clinicians. The federal data that celebrates enabled access also flags the operational cost of leaving the workflow layer unsolved.

For IT leaders, that creates three concrete risks:

• Training risk: staff learn workarounds instead of learning the system.
• Compliance risk: fragmented data flows make governance, audit review, and access tracking harder.
• Operational risk: after-hours clinician work increases error exposure, delays response times, and makes staffing less predictable.

How should healthcare IT administrators pressure-test a vendor's FHIR claims?

Ask for proof in your current account configuration, not a generic demo tenant. The strongest evidence is a production demonstration of a real workflow, such as prior authorization or referral exchange, plus documentation of monitoring, support ownership, and active use by existing customers.

Adoption also varies sharply by platform, so a category-level claim that FHIR is everywhere tells you little about your specific system. The federal data makes this concrete: hospitals on the market-leading EHR were far more likely to have FHIR-based patient app access enabled than hospitals on other systems. Whatever the vendor's marketing says, the answer that matters is whether the endpoint is live, monitored, and already carrying real work in an environment like yours. This is also where a run-alongside overlay model can lower risk, because you validate the endpoint against live workflows before committing to a migration.

Frequently Asked Questions

How can I verify whether a vendor's FHIR endpoint is really live?

Ask for proof in your current account configuration, not a generic demo environment. The strongest evidence is a production demonstration of a real workflow, plus documentation of monitoring, support ownership, and active customer use. Asking who owns an issue when a workflow breaks will tell you more than any certification badge.

Is ONC certification enough to trust interoperability claims?

No. Certification confirms baseline capability, but it does not prove that the endpoint is broadly enabled, workflow-ready, or well-managed in production. For more on what certification does and does not cover, see what new EHR vendors need to know about ONC certification in 2026.

Why hasn't EHR software reduced documentation burden?

Because digitizing the chart is not the same as integrating the workflow. Documentation burden stays high when clinicians still have to gather context manually across notes, messages, labs, referrals, and external systems. That is especially relevant in endocrinology and primary care, where fragmented data creates extra coordination work.

Why is inbox management a major driver of clinician burnout?

Because the inbox becomes the catch basin for every unresolved workflow failure. When referrals, prior authorization, patient messages, and results do not move cleanly through the system, clinicians finish the coordination work after hours. Federal analysis now describes this rising message volume as a growing source of unmeasured care delivery.

Should I switch EHRs if my current vendor's FHIR support is limited?

Not always. A full EHR migration is disruptive, and a run-alongside or overlay model is often a lower-risk way to get better workflows in the short term while keeping your current system in place. The general principle is to validate workflow outcomes against a live FHIR endpoint first, then decide on migration once your team has evidence in hand.

About the Author

References

1. Office of the National Coordinator for Health Information Technology, HTI-1 Final Rule — https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program
2. Centers for Medicare and Medicaid Services, Interoperability and Prior Authorization Final Rule (CMS-0057-F) — https://www.cms.gov/priorities/key-initiatives/burden-reduction/interoperability/policies-and-regulations/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f
3. HL7, FHIR R4 Specification — https://www.hl7.org/fhir/R4/
4. ASTP/ONC, Growth of Health IT-Enabled Patient Engagement Capabilities Among U.S. Hospitals 2021 to 2024, Data Brief No. 79, September 2025 — https://healthit.gov/data/data-briefs/growth-health-it-enabled-patient-engagement-capabilities-among-us-hospitals-2021/
5. ONC Health IT, Certification Program Resources — https://www.healthit.gov/topic/certification-ehrs
6. Thyra, Why FHIR R4 Is the Foundation for Modern EHR Interoperability — https://thyrahealth.com/blog/2026/01/fhir-r4-foundation/
7. Thyra, Integrating AI-Powered Electronic Health Records — https://thyrahealth.com/blog/2026/02/integrating-ai-powered-electronic-health-records/