FHIR adoption in healthcare has moved from pilot projects to a standard feature of certified EHRs and a federal requirement for many payers. That shift happened because regulators made it happen, not because every organization chose FHIR on its own.
This guide looks at where adoption actually stands according to ASTP/ONC data, what drove it, where FHIR is still thin, and how a provider, payer or digital health company can plan its own adoption without rebuilding everything at once.
Where does FHIR adoption in healthcare stand?
Need a FHIR strategy, not just an API?
Agnotic provides fractional CTO support for healthcare organizations planning FHIR adoption, architecture and build.
FHIR adoption in healthcare is broad for reading data and narrow for most other uses. Certified EHRs expose HL7 FHIR R4 APIs for patient and population access, most hospitals let patients connect apps through them, and payers are adding FHIR APIs under CMS rules. Writing data back, real-time events and smaller care settings lag well behind.
That uneven picture is the planning problem. An organization can usually count on a FHIR read API at its larger partners, but it cannot assume FHIR will cover every flow it needs, and it should not retire its HL7 v2 interfaces on the strength of a certification checkbox.
What the hospital data shows
The clearest national numbers come from ASTP/ONC data briefs built on the American Hospital Association IT Supplement. ASTP Data Brief No. 79 reports that in 2024, 81% of hospitals enabled patient access through apps using their EHR's API specifications and 70% enabled access through apps configured to FHIR specifications.
Read those figures carefully. They describe hospitals that enabled a capability, not how many patients use it or how much data flows through it. They also cover hospitals only, so they say nothing direct about physician practices, behavioral health, long-term care or home health.
The same brief reports gaps by hospital type, with small hospitals and hospitals not using the market-leading EHR developer enabling app access at lower rates. For a product team, that means coverage across a target market depends on which EHRs and which sizes of organization it sells to.
Use data like this to set expectations, not to promise customers anything. Before committing to a FHIR-only integration, confirm the specific EHR versions and site configurations of the first few customers.
Measuring adoption inside your own organization
National figures say little about any one organization, so measure your own. Count the FHIR endpoints you expose or consume, the partners connected through each, the share of inbound and outbound data volume that moves over FHIR rather than HL7 v2 or files, and the number of registered apps that made a call in the last month.
Track errors and empty responses alongside volume. An API that is technically live but returns empty searches for half its partners is not adopted in any useful sense, and those numbers point to the mapping or configuration work that will move adoption forward.
Why did certified EHRs adopt FHIR first?
Certified EHRs adopted FHIR first because ASTP/ONC certification required it. The criterion at 45 CFR 170.315(g)(10), Standardized API for patient and population services, requires a read API that serves USCDI data through US Core profiles, with SMART App Launch for authorization and Bulk Data for population export.
That requirement explains the shape of adoption. (g)(10) is a read API, so certified EHRs share data through FHIR far more consistently than they accept it. Writing orders, notes or results back into the EHR still depends on each vendor's own write APIs or on HL7 v2 interfaces.
It also explains why USCDI and US Core define what most FHIR APIs return. Data outside those sets, such as detailed device data or specialty content, may be absent from the API even when it exists in the chart. Map each data element your product needs against what the certified API actually exposes.
How do payer API rules extend adoption?
Payer API rules extend FHIR adoption from providers to health plans. The CMS Interoperability and Prior Authorization final rule, CMS-0057-F, requires impacted payers to implement a Provider Access API, a Payer-to-Payer API and a Prior Authorization API, and to enhance the Patient Access API, from 1 January 2027.
For providers and vendors, those APIs create new data sources: claims and encounter data from payers, and a FHIR route for prior authorization. CMS recommends, but does not require, the Da Vinci implementation guides for prior authorization, so payer implementations may differ in detail.
Payer adoption also changes the build plan for analytics and care management products. Data that used to arrive in claims files on a monthly cycle may become available through APIs, which needs a different ingestion pipeline and a different consent and attribution model.
Where FHIR is still thin
FHIR is still thin wherever regulation has not pushed it: write-back, event notification, settings outside certification programs and data outside USCDI. Each gap has a practical workaround, and knowing which applies saves a project from discovering it in production.
- Write-back: certified APIs are read APIs, so writing to the EHR needs vendor-specific write endpoints or HL7 v2 messages such as ORU results or MDM documents.
- Real-time events: plan for HL7 ADT feeds for admissions, discharges and transfers, since FHIR Subscriptions support varies by vendor and version.
- Smaller and specialty settings: practices and care settings on systems outside the certification program may offer limited or no FHIR access.
- Data beyond USCDI: specialty content, detailed device data and local flowsheet rows often need vendor-specific APIs or reporting extracts.
- Bulk scale: Bulk Data export exists in certified EHRs, but site configuration, group definitions and export performance vary widely.
None of these gaps means FHIR is the wrong choice. They mean a realistic integration plan combines FHIR for what it covers well with other interfaces for the rest, behind one internal data model.
How should an organization plan its own FHIR adoption?
An organization should plan FHIR adoption around specific use cases and partners, not around the standard itself. Start with the flows that bring the most value and that FHIR covers well today, and add others as partners and rules mature.
- 1. Inventory: list every data flow in and out, with partner, format, frequency and owner, including HL7 v2 feeds, flat files and portals.
- 2. Drivers: mark which flows a rule now requires or soon will, such as payer APIs or patient access, and which are commercial choices.
- 3. Partner check: for each partner, confirm FHIR version, US Core version, supported resources, write options and Bulk Data availability.
- 4. Pick a first use case: choose one flow with a clear owner, a FHIR-ready partner and a measurable result, such as patient app access or a payer data feed.
- 5. Internal model: define a canonical model and identifier strategy so FHIR and non-FHIR sources land in the same place.
- 6. Platform choice: decide whether to run a FHIR server, use a cloud FHIR service or build a facade over existing data, based on who consumes the API.
- 7. Security and consent: design SMART on FHIR authorization, scopes, audit logs and consent rules before the first external connection.
- 8. Roadmap: sequence the remaining flows by value and partner readiness, and revisit the plan when a rule or a major partner changes.
A common failure point is starting with a platform purchase before a use case exists. The team then stands up a FHIR server with no consumer, and the work stalls when the first real partner needs a different profile or version.
FHIR server, cloud service or facade
The platform choice follows from who reads the data and where it lives. A FHIR server that stores data natively suits a new product whose own records are its source of truth. A managed cloud FHIR service suits a team that wants storage, search and scaling handled by the provider and is willing to work within that service's supported features.
A facade suits an organization whose data already lives in a legacy database or EHR and must stay there. It translates FHIR requests into queries against the existing system, which avoids a migration but makes search and write support harder to build. An organization can also run more than one pattern, for example a facade for legacy records and a native server for new app data.
Whichever pattern applies, keep validation against the target US Core profiles in the pipeline, so every release proves the API still returns what partners expect.
Which skills does FHIR adoption need?
FHIR adoption needs integration engineers who know both FHIR and HL7 v2, a clinical informaticist who can map local codes to standard terminologies, and a security engineer who owns OAuth and audit. It also needs a product owner who decides which flows matter.
Terminology is easy to underestimate. A FHIR API that returns local lab codes instead of LOINC, or local problem codes instead of SNOMED CT, is technically FHIR and practically hard to use. Budget time for mapping and for a terminology service.
Smaller organizations rarely need all of these roles full time. A part-time architect or fractional CTO can set the direction and review decisions, while a delivery team builds against that plan.
How Agnotic can help
Planning FHIR adoption is a sequencing problem: which flows to move, in what order, on what platform, and what to keep on HL7 v2. Agnotic Technologies provides fractional CTO support that works through that plan with the client, then builds it: partner capability checks, canonical models, FHIR servers or facades, SMART on FHIR security and the interfaces that FHIR does not yet cover.
Plan FHIR adoption with Agnotic
Explore Agnotic's healthcare fractional CTO service, or browse the FHIR articles hub.
Related reading on Agnotic
Continue with FHIR integration, first FHIR projects, choosing FHIR standards and HL7 v2 versus FHIR.
