17 Jul
FHIR for ambient AI scribes: why getting the note into the EHR is harder than writing it
Key takeaways
- Generating an accurate clinical note is no longer the hardest part of an ambient AI scribe. Getting that note into the EHR as usable structured data is.
- A note dropped into a FHIR DocumentReference resource is not the same as data written into Condition, MedicationRequest, or Observation resources that other parts of the chart depend on.
- About 4 in 5 hospitals report using APIs to let clinician-facing apps write data into the EHR, according to an ONC data brief, a meaningfully smaller share than the roughly 9 in 10 hospitals enabling read access.
- Write-back access requires its own SMART on FHIR authorization scopes, distinct from the read scopes most vendors test against first.
- Peer-reviewed research on scaling ambient AI scribes has identified structured data integration as one of the central technical barriers to broader deployment.
- EHR vendor certification programs, not just technical FHIR compliance, often determine whether a scribe vendor can write back into a live clinical environment at all.
- The vendors that succeed here treat write-back as a distinct engineering and compliance problem from day one, not an extension of the note-generation feature.
An ambient AI scribe listens to a patient visit and produces a clean, accurate note in seconds. The clinician reviews it, makes a small edit, and approves it. That part of the problem is largely solved.
What happens next is where most vendors underestimate the work. Getting that note into the EHR correctly, as structured data the rest of the chart can actually use, not just a block of text sitting in a document field, is a separate and much harder engineering problem.
This piece breaks down why writing the note and delivering it into the EHR are not the same challenge, what FHIR actually requires for each, and why write access gets scrutinized far more heavily than read access ever does.
Table of contents
Why is writing the note the easy part now?
What does "getting the note into the EHR" actually require?
A generated note can land in the EHR in more than one way, and the difference matters more than most product teams initially assume.
The simplest path writes the note into a FHIR DocumentReference resource, essentially a structured wrapper around a block of text. That satisfies the requirement that a note exists in the chart. It does not make the clinical content inside that note usable by anything else in the EHR.
A more capable integration also writes discrete clinical facts, extracted from the same encounter, into the specific FHIR resources built to hold them: a diagnosis into Condition, a new prescription into MedicationRequest, a vital sign into Observation.
What each FHIR resource actually captures
Resource | What it holds | Why it matters for an ambient scribe |
DocumentReference | The note itself, as a document | Satisfies documentation requirements, but the content stays unstructured |
Condition | A specific diagnosis or clinical problem | Feeds problem lists, care gap tracking, and clinical decision support |
MedicationRequest | A prescribed or ordered medication | Feeds medication reconciliation and pharmacy workflows |
Observation | A discrete clinical measurement or finding | Feeds vitals tracking, trending, and quality reporting |
Why does write access face more scrutiny than read access?
What role does SMART on FHIR authorization play in write-back?
SMART on FHIR defines the OAuth2-based authorization framework that certified EHRs use to control what a third-party application can actually do once connected. Read and write permissions are governed by separate scopes, and a vendor’s app has to explicitly request, and be granted, write-specific scopes before it can post anything into the chart.
This is not a minor technical detail. A vendor that only tested and configured read scopes during early development will hit a hard wall when it tries to add write-back later, since the authorization model has to be built for both from the start, not bolted on afterward.
Why do EHR vendor certification programs matter for scribe vendors?
Meeting the FHIR standard is necessary but not sufficient. Major EHR vendors run their own certification and app marketplace programs, and a scribe vendor typically has to pass through one of these before it can write into a live customer’s EHR instance in production.
This adds a layer of review beyond general FHIR compliance: vendor-specific security review, use case approval, and in many cases a formal listing process before a health system’s IT team will even consider enabling write access for a new third-party tool.
What should ambient AI scribe vendors build for before calling integration done?
- Map the specific FHIR resources you write to, not just DocumentReference, and be explicit with customers about which structured resources your product actually populates.
- Design SMART on FHIR write scopes from the start, rather than treating write-back as an add-on to a read-only integration.
- Budget time for EHR vendor certification, since this process runs on the vendor’s timeline, not yours.
- Build clinician review and approval into the write path, so nothing posts to the chart without a human confirming it first.
- Test against your target EHR’s actual write behavior, not just FHIR structural validity, since vendor-specific quirks in how writes are processed are common.
Where does this leave teams building ambient AI scribes?
The note-generation problem behind ambient AI scribes has matured faster than the data delivery problem sitting right behind it. A note that reads well is not the same as clinical data that other systems in the chart can actually use, and the gap between those two things is where most integration timelines actually slip.
Teams that treat write-back, structured resource mapping, and EHR vendor certification as core product work from the beginning, rather than a final step before launch, are the ones that avoid discovering this gap during a customer’s IT review instead of during their own planning.
FAQs
It satisfies a basic documentation requirement, but it does not make the encounter's clinical content usable by problem lists, medication reconciliation, or clinical decision support tools elsewhere in the EHR.
Most certified EHRs support FHIR write capabilities to some degree, but actual write-back access for a given third-party vendor still depends on that vendor completing the EHR's own certification and approval process.
Writing data can alter the patient record, while reading data cannot. Health systems apply a higher level of security and clinical risk review to any integration that can change what is in the chart.
No. Read and write operations are governed by separate authorization scopes, and a vendor has to explicitly request and be granted write-specific scopes before posting data into the EHR.
Yes. Building a human review and approval step into the write path is standard practice and directly addresses the accountability question any EHR vendor or health system will ask about AI-generated clinical content.
It varies by vendor and use case, but it should be planned for as a distinct project phase with its own timeline, not assumed to run in parallel with general product development at no cost to the schedule.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
