Read from FHIR? np. Write to FHIR? please.

A federal survey of 2,253 hospitals: read-side FHIR is table stakes. The real opportunity is write-side clinical integrations.

the nighthawk · 12 min read · 2026-03-28

The federal government just published the most comprehensive survey of hospital API adoption to date. The headline number is boring in the best way: nine in ten hospitals enable patient access via an API. That number hasn't moved since 2022. FHIR-based patient access is solved.

What's interesting is everything the survey reveals about the other side of the API.

ASTP Data Brief No. 81, published February 2026, surveyed 2,253 non-federal acute care hospitals on how they share data between EHRs and third-party technology. For the first time, it breaks down API usage by specific clinical and administrative use cases. The findings tell a story of a market that has mastered reading patient data through FHIR but is still stuck on the hard part: writing data back.

If you sell software to health systems, this is where it gets interesting.

Reading is table stakes. Writing is the product.

Let's separate the two sides of hospital interoperability, because the brief makes clear they're in completely different stages of maturity.

Read-side (patient access): 87% of hospitals enable patient access to health information via an API. 71% use standards-based APIs — overwhelmingly FHIR R4. This number has climbed steadily from 69% in 2022 and the trajectory is clear. For vendors building patient-facing read apps, the market is mature and the technical surface is well-understood.

Write-side (clinical and administrative): This is where the brief gets interesting. Hospitals are actively exchanging data with third-party technology for clinical and administrative purposes at remarkably high rates:

• Remote patient monitoring: 80% of hospitals integrate data from third-party devices
• Prior authorization: 76% integrate or provide data to third-party systems
• Clinical decision support: 75%
• Telehealth: 73%
• Quality reporting: 70-76%
• Scheduling/intake: 67-68%

These numbers represent write-heavy workflows. RPM devices push vitals into the EHR. Prior auth systems submit requests and receive decisions. Quality reporting tools transmit measure data to CMS. Telehealth platforms write encounter notes back to the chart.

Hospitals are doing all of this. They're just not doing it through FHIR.

The standards gap: why hospitals still integrate "the old way"

The numbers are stark. For RPM platforms, only 24% of hospitals used standards-based APIs while 42% used proprietary approaches alone. For prior authorization — arguably the most regulation-heavy workflow in American healthcare — only 22-24%. For quality reporting, just 18-21%.

Hospitals clearly aren't opposed to standards — the read-side numbers prove they'll adopt FHIR when it works. The problem is on the vendor side. Reading a Patient resource from Epic's FHIR API is well-documented, well-sandboxed, and well-understood. Writing a clinically valid Observation back into the EHR — one that conforms to US Core profiles, uses correct LOINC coding, includes proper reference ranges, and passes the EHR's validation engine — is a different problem. Most vendors can't demonstrate they've solved it.

So the integration conversation comes down to one question: can this vendor produce FHIR resources our EHR will accept? If you can't prove it during the demo, the hospital defaults to what's safe — a proprietary interface, an HL7v2 feed, a CSV upload through a portal.

The FHIR surface area is almost entirely read-only

The asymmetry is structural. Epic's public FHIR API surface, as published on open.epic, contains 408 distinct API operations across USCDI and other industry-standard endpoints. Of those, only 27 support write operations (Create, Update, or Delete) — roughly 7%. Exclude CDS Hooks, which are decision-support workflow extensions rather than direct chart writes, and you're down to 20 direct write operations, or 5% of the total surface.

Those 20 write-capable endpoints cover only 11 of 61 resource types: AllergyIntolerance, Communication, Condition, DocumentReference, Goal, MedicationRequest, Observation, Patient, Procedure, QuestionnaireResponse, and Task. That means 82% of resource types have no write endpoint at all. You can write a new AllergyIntolerance or a DocumentReference. You cannot write a Procedure (other than radiotherapy), an Encounter with full clinical context, a MedicationRequest with dosage and dispense detail, or a lab Observation from an external device — not through FHIR.

The resources that represent the core of RPM, prior auth, quality reporting, and scheduling integrations are largely read-only in the public FHIR surface.

Now compare that to Epic's proprietary API catalog. The Vendor Services page lists 183 proprietary APIs spanning active guidelines, CTI/telephony, credit card processing, document scanning, EMPI, personnel management, printing/faxing, release of information, speech-to-text, wait times, web launch/SSO, and utilization management. Of those 183, approximately 83 are write-capable — about 45%.

The proprietary surface is six times more write-capable than FHIR, by percentage. The write-side workflows hospitals actually depend on — patient creation, prior auth submission, document scanning, utilization review — live in that proprietary catalog. That's what the ASTP brief is measuring when it finds 76% of prior auth integrations running through non-standards-based methods.

The trust gap is a testing gap

Here's where it gets concrete. When a hospital evaluates your integration, they're asking one question: can this vendor produce FHIR resources our EHR will actually accept? To earn that trust, you need to demonstrate three things:

1. Structural validity: The FHIR resources they produce parse correctly, pass validation, and conform to the profiles they claim to support (US Core 5.0.1, US Core 6.1.0, or US Core 7.0.0).

2. Semantic correctness: The resources use appropriate terminology (SNOMED CT for conditions, LOINC for observations, RxNorm for medications), include required coded elements, and represent clinical concepts accurately.

3. Clinical realism: The resources aren't just structurally valid empty shells. They represent the kind of data complexity the EHR will actually encounter — patients with multiple comorbidities, longitudinal lab trends, medications with dosage and frequency, encounters spanning ambulatory, inpatient, and emergency settings.

The problem is that none of this is testable against today's publicly available sandboxes.

Open Epic gives you eight patients with sparse data, optimized for read-side OAuth testing. Cerner's sandbox is similar. The SMART Health IT sandbox has ~100 Synthea patients with basic structural validity but no clinical depth. Logica Health's sandbox was retired in 2024. (RIP — it was actually decent.)

None of these support write-side testing. None produce data at USCDI v3 density. None validate against US Core profiles. And none give you the kind of clinically realistic patient records you'd need to walk into a hospital and demonstrate that your write-side integration actually works.

So vendors ship integrations that haven't been tested against realistic data. Hospitals encounter validation errors and malformed resources. Everyone defaults to the proprietary interface that works.

The regulatory timeline makes this urgent

Three converging mandates are about to compress the standards gap, whether vendors are ready or not:

CMS-0057-F (January 2027): Medicare Advantage plans, Medicaid managed care plans, and QHP issuers must implement four FHIR-based APIs: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. The payer side of every prior authorization integration currently handled via fax and proprietary portals is about to become a FHIR endpoint. Vendors who can write compliant prior auth requests via FHIR will win. Those who can't will be locked out.

USCDI v3 (January 2026): All certified EHR modules must support USCDI v3, which nearly doubles the required data elements from v1. New data classes include health insurance information, clinical notes with LOINC type coding, and assessment/plan of treatment. Every resource a vendor writes to an EHR will be validated against this richer schema.

HTI-4 Final Rule: Establishes new API criteria for prior authorization that enable providers to submit requests and receive decisions through standards-based methods. The brief explicitly calls this out: "these new API criteria, along with reciprocal requirements finalized by CMS for health plans, can enhance bidirectional exchange for this purpose and reduce hospital effort."

The regulatory direction is clear: write-side FHIR is moving from optional to required. (And even on the read side, FHIR still can't do real-time event delivery — most write-heavy workflows still depend on HL7v2 for notifications.)

The vendor divide tells you where to compete

The brief reveals sharp disparities in who has adopted standards-based APIs:

Source: 2024 AHA Annual Survey Information Technology Supplement

Independent hospitals on non-Top-3 EHRs are 20-30 points behind on standards adoption. These are often rural, critical access, or community hospitals. They're subject to the same regulatory requirements as large health systems but have a fraction of the IT staff.

These hospitals don't need vendors who assume Epic's FHIR surface area is available. They need vendors who've tested against the weird stuff — EHR systems with less mature FHIR implementations, resources with missing optional fields, the edge cases that only appear when you move beyond the Top 3.

If your test data only covers the happy path, you'll find out in production. At the worst possible time.

What breaks the cycle

The brief's summary puts it plainly: hospitals broadly share data with third-party technology, but "most of this data sharing occurs via non-standards-based APIs and/or non-API-based methods." It calls for continued monitoring of "the special effort involved with sharing data between the EHR and third-party applications — special effort the Cures Act interoperability provisions seek to limit."

The "special effort" is the old way. Custom integrations, proprietary APIs, HL7v2 feeds, manual portal uploads. Hospitals resort to this because it's what they can trust to work.

The way to break the cycle is to make FHIR the thing they can trust. And that starts with vendors who can prove — before the contract is signed, during the demo, in the pilot — that their systems produce FHIR resources that are structurally valid, semantically correct, profile-conformant, and clinically realistic.

That proof requires testing against data that actually represents what production looks like: US Core-aligned patient records at USCDI v3 density, with the comorbidity patterns, medication histories, imaging studies, clinical notes, and encounter complexity that real hospitals generate. Not eight sandbox patients. Not structurally valid but clinically empty Synthea defaults.

The read-side wave succeeded because the standards were clear and the test infrastructure existed. The write-side wave needs the same thing: vendors who can prove their output actually conforms, tested against data that looks like what hospitals generate — not eight sandbox patients.

ASTP Data Brief No. 81 (February 2026) using data from the 2024 AHA Annual Survey Information Technology Supplement (N = 2,253 non-federal acute care hospitals).

mock.health — US Core 6.1 compliant FHIR sandbox with the clinical density you need for write-side testing. Free tier →

Related posts

• FHIR, USCDI, and US Core: What They Are, How They Fit — FHIR says how to send data. USCDI says what data. US Core says exactly how to format it. Here's how the three standards fit together.
• Your FHIR Architecture Determines Your Test Data Strategy — Facade, hybrid, or FHIR-native — each architecture breaks differently. Here's what to test for each model and what breaks when you don't.
• FHIR Is Not Enough: Real-Time Integrations Still Need HL7v2 — FHIR answers 'what does this patient look like now?' To ask for changes you'll have to remember how HL7v2 works.

All posts · Home · Docs