Ask a health IT executive whether FHIR has “arrived,” and the answer depends entirely on which workflow you point to. Ask about a patient pulling lab results into a phone app, and the answer is largely yes — that pipe has existed for years and carries real traffic. Ask about a specialist writing a structured note back into a different vendor’s EHR, or a payer assembling a longitudinal record across five health systems without gaps, and the answer is closer to “getting there, slowly.” FHIR adoption in 2026 is a story of a floor that’s solidly built and a ceiling that’s still under construction.

That unevenness isn’t a failure of the standard. It reflects where regulation has pushed hardest — certified read APIs for individual patients — versus where the harder engineering and trust problems still live: population-scale queries, write-back, and data that was never structured to begin with. Here’s where things actually stand.

The certified API requirement did its job — for reads

The 21st Century Cures Act’s information-blocking provisions, enforced through ASTP/ONC certification criteria, required certified health IT to expose a standardized, FHIR-based API for patient and population data access — the criterion now codified at §170.315(g)(10). That requirement has been in force long enough that it shows up clearly in national survey data: ASTP/ONC’s hospital data briefs, drawn from the American Hospital Association’s IT supplement, found that roughly 81% of hospitals let patients access their health information through third-party apps, and about 70% had that access configured specifically to meet FHIR API specifications. Clinical notes access is even more widespread, reported around 95% of hospitals.

In practical terms, this means a patient at a large health system can plausibly connect a health app to their provider’s FHIR endpoint, authenticate via SMART on FHIR, and pull a US Core–conformant bundle of problems, medications, allergies, and labs. That baseline — read-only, individual-patient, USCDI-scoped — is the part of FHIR adoption that’s genuinely mature in 2026. The base standard in production is US Core 6.1.0 (aligned to USCDI v3), with US Core 7.0.0 and the more recent US Core 8.0.1 (aligned to USCDI v5, approved through the 2025 Standards Version Advancement Process cycle in August 2025) available as SVAP options for developers who want to move faster than the certification baseline requires.

Two caveats temper the celebration. First, “configured to meet FHIR specifications” and “actually used at scale by patients” are different claims — the former is an EHR capability, the latter is an adoption outcome, and the industry has historically been better at measuring the first than the second. Second, ASTP/ONC’s own regulatory posture is shifting: the HTI-5 proposed rule, out for comment in early 2026, would remove or revise a large share of legacy, non-FHIR certification criteria specifically to concentrate the certification program’s future scope on FHIR-based API requirements. If finalized, that’s a bet that the FHIR floor is now stable enough to build the rest of certification policy on top of it — a vote of confidence, but also a sign the floor’s stability is a fairly recent, fairly fragile achievement.

Patient access is real; population-level access is still catching up

FHIR access comes in two distinct flavors under the certified API criterion, and they’ve matured at very different speeds.

Patient-facing, single-record access — a patient or their authorized app pulling one person’s data — is the use case the market has actually built around. It maps cleanly to SMART App Launch’s standalone-patient-app pattern, it’s what most consumer health apps implement, and it’s the use case CMS is now explicitly measuring: under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), impacted payers — Medicare Advantage organizations, state Medicaid and CHIP programs, and qualified health plan issuers on the federal exchanges — must report annually on how many unique patients actually used their Patient Access API, including repeat users. The first such report, covering 2025 usage, was due March 31, 2026. That reporting requirement matters because it’s the first systematic attempt to measure real utilization rather than mere availability — expect the initial numbers to be modest and uneven across payers, since exposing an endpoint and driving patient awareness of it are very different accomplishments.

Population-level (bulk) access — a provider organization, payer, or public health agency pulling structured data across many patients at once via the FHIR Bulk Data Access ($export, group-export) — is required under the same certification criterion but has lagged in real-world deployment. The technical capability exists in certified systems; the operational patterns for who’s authorized to run a bulk query, how consent and minimum-necessary rules apply at scale, and how receiving systems reconcile bulk payloads against their own records are still being worked out site by site rather than standardized across the industry. Payer-to-payer data exchange, also mandated under CMS-0057-F, sits in this population-scale category and is generally further behind patient-facing access in practice.

The honest summary: the API surface for population access exists almost everywhere certification requires it. Whether organizations are actually running it in production at meaningful volume is a separate, much less certain question — and one where good national data still doesn’t exist for 2026.

TEFCA’s FHIR roadmap is moving from pilots toward infrastructure

The Trusted Exchange Framework and Common Agreement (TEFCA) launched at the end of 2023 built on IHE-based document exchange — the same document-centric approach underlying Carequality and CommonWell — because that was the technology the founding QHINs already had in production. FHIR was always meant to follow, and the RCE (The Sequoia Project, under contract to ASTP/ONC) published a formal “FHIR Roadmap for TEFCA Exchange,” now in its second version, laying out four progressive stages: FHIR content support within a single QHIN’s own network; QHIN-facilitated FHIR exchange for that QHIN’s participants; direct QHIN-to-QHIN FHIR connectivity; and, eventually, End-to-End FHIR Exchange brokered by QHINs all the way down to individual participants and subparticipants.

By 2026, TEFCA’s overall network has scaled well past pilot status — more than 21,000 organizations are live across QHINs, participants, and subparticipants, representing upward of 96,000 individual connections spanning hospitals, clinics, post-acute facilities, and public health authorities. The QHIN roster itself has grown steadily beyond the original five to include eHealth Exchange, Epic Nexus, Health Gorilla, KONZA, MedAllies, CommonWell, eClinicalWorks, and Oracle Health Information Network, among others. Infrastructure work to support Stage 4 end-to-end FHIR exchange is planned for calendar year 2026, with full realization treated industry-wide as a 2026–2027 milestone rather than something already complete.

Security is the other moving piece. TEFCA’s FHIR exchange is converging on OAuth-based frameworks — commonly discussed under the “FAST Security” label — with January 2026 cited as a target for broader implementation across TEFCA FHIR transactions. Large QHIN-affiliated systems appear to be incorporating these requirements into their FHIR services now, but “target date” and “universally implemented” are not synonyms, and this is exactly the kind of milestone worth re-checking against the RCE’s own published status rather than taking as settled.

One useful gut-check for readers: treat any specific TEFCA participant count, QHIN roster, or stage-completion date as a snapshot. The network is genuinely growing quickly, which is good news, but it also means numbers age fast — confirm current figures against the RCE’s designated-QHIN listing and roadmap updates directly.

Where the gaps remain: data quality, write access, and beyond-USCDI data

Three gaps consistently separate “FHIR is technically available” from “FHIR fully supports the workflow.”

Data quality and unstructured content. USCDI defines the required data classes and elements, not a guarantee that every element arrives clean, complete, or coded consistently across source systems. A FHIR Condition or Observation resource is only as reliable as the underlying documentation practice that generated it, and a meaningful share of clinically important detail — nuance in progress notes, imaging impressions, free-text rationale — still lives in unstructured or semi-structured form that structured FHIR resources don’t fully capture. ASTP/ONC’s own USCDI expansion process acknowledges this directly: USCDI is explicitly scoped to include both structured and unstructured data needed for patient care, which is itself a tacit admission that structured coverage alone isn’t sufficient. The draft USCDI v7, out for public comment in early 2026 with finalization expected mid-year, proposes roughly 30 additional data elements — a sign the core dataset is still actively expanding rather than settled.

Write access. The certified API mandate was built around read access — a patient or app pulling data out of a certified system. Writing data back in (placing an order, updating a care plan, pushing a patient-reported observation into the record of a different vendor’s EHR) is not required by the standardized API certification criterion in the same way, and in practice remains far more restricted: gated per customer, limited to specific resource types such as DocumentReference notes or patient-generated Observations, and typically requiring vendor-specific onboarding rather than the open, standardized floor that read access now enjoys. Where genuine bidirectional write capability is needed today — order placement, billing transactions — many organizations still fall back to legacy HL7v2 interfaces run through an interface engine, layering FHIR reads on top of a write architecture that predates FHIR entirely.

Data beyond USCDI’s scope. Certification requirements, and therefore most production FHIR APIs, are scoped to USCDI’s defined data classes. Data that falls outside that scope — certain specialty workflows, some genomic and social-risk detail, imaging beyond basic references, and other content not yet formally added to USCDI — is exchanged unevenly if at all through certified FHIR channels, and where it moves, it often does so through vendor-specific extensions or non-FHIR channels rather than a standardized path. Each annual USCDI/US Core cycle closes part of this gap, but it closes it incrementally, one version at a time, not all at once.

What’s genuinely in production vs. what’s still aspirational

Pulling the threads together, a fair 2026 scorecard looks like this:

Solidly in production: certified, USCDI-scoped, read-only, single-patient FHIR API access via SMART on FHIR — the pattern nearly every certified EHR now supports and a large majority of hospitals have configured; TEFCA as a live, rapidly scaling network for treatment-purpose document exchange; and annual USCDI/US Core version increments as a working, if incremental, standards-update cycle.

Real but uneven: population-level bulk FHIR export, which is certified and technically present but not uniformly operationalized; patient usage (as opposed to mere availability) of Patient Access APIs, now being measured systematically for the first time under CMS-0057-F reporting; and TEFCA’s FHIR roadmap, which has moved from paper to active infrastructure work but has not yet reached its Stage 4 end-to-end vision.

Still substantially aspirational: standardized, cross-vendor FHIR write-back for clinical orders and care coordination; comprehensive exchange of data that falls outside USCDI’s current scope; and a resolved industry-wide answer to unstructured-data quality, which no version of USCDI or US Core can fully solve through schema alone.

None of this is cause for pessimism — the distance FHIR has covered since the Cures Act API mandate took effect is substantial, and the direction of regulatory travel (HTI-5’s FHIR-first refocusing, TEFCA’s roadmap, annual USCDI cycles) points consistently toward closing these gaps rather than living with them indefinitely. But anyone evaluating a vendor’s “FHIR-enabled” claim in 2026 should ask which of these three tiers the claim actually describes, because the difference between them is the difference between a mature capability and a roadmap slide.

Frequently Asked Questions

Is FHIR mandatory for U.S. health IT in 2026?

Certified health IT must support a standardized FHIR-based API under ASTP/ONC’s §170.315(g)(10) criterion, and provisions of the CMS Interoperability and Prior Authorization rule extend similar FHIR API requirements to many payers. Coverage isn’t universal across every system, but it’s mandatory for the large share of the market using certified EHRs or subject to CMS’s payer rules.

What’s the difference between patient access and population-level FHIR access?

Patient access lets one authorized person or app retrieve a single patient’s records, typically via SMART on FHIR. Population-level (bulk) access lets an organization retrieve structured data across many patients at once using FHIR Bulk Data operations. Both are required by certification, but patient access is far more mature in real-world use as of 2026.

Can FHIR APIs be used to write data back into an EHR, not just read it?

Some write capability exists — commonly for notes (DocumentReference) or patient-generated observations — but it’s typically gated per vendor and per customer rather than standardized the way read access is. Full write-back for orders, care plans, or billing generally still relies on legacy interfaces rather than open FHIR APIs.

What is TEFCA’s role in FHIR adoption, and is it fully FHIR-based yet?

TEFCA launched on IHE-based document exchange and is transitioning to FHIR in stages under a published roadmap, moving from single-network FHIR support toward full end-to-end FHIR exchange between participants and subparticipants. As of 2026, that transition is actively underway with infrastructure work targeted for the year, but it has not yet reached its final stage.

Why isn’t all clinical data available through FHIR APIs even where FHIR is implemented?

Certified FHIR APIs are scoped to USCDI’s defined data classes, and USCDI itself still excludes or only partially covers some specialty, genomic, and unstructured clinical content. Each annual USCDI update expands that scope incrementally, but full coverage of every clinically relevant data type has not been reached.

Readers should treat any adoption percentages or program milestones cited here as a point-in-time snapshot; figures from ASTP/ONC, CMS, and the TEFCA RCE are updated regularly and should be verified against healthit.gov and HL7.org directly for the most current status. Nothing in this article should be read as legal, compliance, or medical guidance.