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.
Federal hospital patient-access data describes a particular capability, not a guarantee of operational interoperability for an independent practice.
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 designed to bring incoming work, relevant context, and a draft together for physician review. Integration availability depends on your EHR and the workflow you want to use. We confirm the data source, permissions, and any read or write connection before a pilot begins.
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 public FHIR messaging, not a field test of live endpoints or an empirical benchmark. A vendor's claim of API support needs to be checked against the actual enabled workflow.
ASTP/ONC Data Brief No. 79 examines hospital patient-engagement capabilities using the American Hospital Association IT Supplement. It concerns hospital capabilities, not Thyra compatibility or a particular independent practice's workflow.
Hospital patient-app access does not establish whether a particular practice can use an endpoint for prior authorization, referrals, or care transitions. Confirm the required scope, permissions, data, and operational behavior directly.
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.
| Interoperability claim | What it sounds like | What it may mean in practice | Buyer risk |
|---|---|---|---|
| Certified FHIR | "We support FHIR" | Vendor passed certification criteria | Capability may exist without broad operational use |
| Published endpoint | "We have a service base URL" | URL is listed and documented | Endpoint may not be active in your environment |
| Enabled endpoint | "Your account can access the API" | Technical access exists in current configuration | Workflow support may still be limited |
| Operational FHIR | "Customers use it live" | Real workflows run through the endpoint | Requires evidence, monitoring, and support |
| Managed FHIR | "We maintain and review it" | Ongoing governance, issue ownership, and review | Lowest implementation risk |
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.
- 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.
- 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.
- 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.
- 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.
- 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. Reviewing the vendor's integrations and 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 workflows, 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.
References
- 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
- 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
- HL7, FHIR R4 Specification: https://www.hl7.org/fhir/R4/
- 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/
- ONC Health IT, Certification Program Resources: https://www.healthit.gov/topic/certification-ehrs
- Thyra, Why FHIR R4 Is the Foundation for Modern EHR Interoperability: https://thyrahealth.com/blog/2026/01/fhir-r4-foundation/
- Thyra, Integrating AI-Powered Electronic Health Records: https://thyrahealth.com/blog/2026/02/integrating-ai-powered-electronic-health-records/
