The short answer
Picture a complaint arriving months after a visit: the note says something the doctor doesn’t remember writing. Was it the AI scribe’s draft, a colleague’s edit or the doctor’s own words? If the record only shows who signed, nobody can tell, so keep the AI’s draft, every edit, the signer and what actually reached the chart.
For every note or order an AI scribe produces, a hospital should be able to show five things later: the draft exactly as the AI wrote it, every change a person made, who signed and when, what was actually stored in the EHR, and which tool and version produced the draft. Most EHR audit logs record that a user signed a note. Few record which sentences the AI wrote, so the difference between “the clinician wrote this” and “the clinician approved this” disappears. That difference matters when something in a note turns out to be wrong.
This post is about records and governance, not clinical judgement.
Deedglass
An AI-drafted order waits for a clinician
-
1The AI drafts
Medication order
Metformin 500 mg, twice daily
Bed 12 · AI scribe
Waiting for a clinician -
2A clinician decides
Why it was held
Medication changes need a clinician
DeclineApproveDr. N. Shah approved -
3Saved, then checked
- Saved to the record
- Read back: matches
Record sealedCheck it offline
Why the normal EHR audit log isn’t enough
AI scribes have moved past dictation. Epic says its AI Charting, released in February 2026, “drafts the clinician’s note, and queues up orders”.1 Microsoft says of Dragon Copilot: “With supported EHRs, orders are directly entered into the EHR order module”.2
The drafts aren’t perfect. A pilot published in JMIR Medical Informatics in April 2026 reviewed 356 ambient-AI-scribe notes and found omissions in 64 (18%), hallucinations in 41 (11.5%), and 19 notes (5.3%) with errors rated as posing serious or imminent risk.3 That’s one pilot, run in 2024, with one product; it isn’t a rate for every scribe. But it shows why review exists, and why a record of the review matters.
A traditional audit log is built around users. It records that Dr Rao opened the chart, edited the note and signed it. It doesn’t record that 90% of the signed text came from a model, that two sentences were deleted, or that a queued order was accepted unchanged. If a signed note contains an error, the log can’t tell you whether the AI introduced it and the reviewer missed it, or the clinician wrote it.
What the rules already ask for
None of the main audit rules mention AI scribes by name, but they set the floor:
| Source | What it asks for |
|---|---|
| ISO 27789:2021 | Each audit record identifies at least the user, the subject of care, the function performed and the date and time4 |
| HIPAA Security Rule, 164.312(b) | Audit controls: mechanisms that record and examine activity in systems holding ePHI5 |
| India EHR Standards (NRCeS) | Record all actions on health information, including viewing, with date, time, record and user; detect alterations to records and to audit logs66 |
Read with AI in mind, “the user” and “the function performed” now have two parts: the tool that drafted and the person who approved. A record that names only the person meets the letter of the user field and loses the information that matters.
The five events to record
| # | Event | Record | Why |
|---|---|---|---|
| 1 | AI draft created | Full draft text, tool, model version, time, encounter | Shows exactly what the AI said |
| 2 | Clinician edits | Each change, or the diff between draft and final | Shows what the reviewer changed |
| 3 | Signature | Signer, time, authentication method | Shows who took responsibility |
| 4 | Stored result | What the EHR holds after signing, read back | Shows what reached the record |
| 5 | Queued orders accepted | Each order: drafted by AI, accepted, edited or rejected | Orders carry more risk than prose |
Event 4 is the one most often skipped. The signed text and the stored text should match, but integrations trim, convert and map fields. A read-back after signing confirms the record holds what the clinician approved.
Event 5 deserves its own line because an accepted order acts in the world. For how to model AI-drafted orders so nothing is actionable before sign-off, see our post on draft orders and clinician sign-off.
Mapping it to FHIR
FHIR R4 has two resources for this, and they do different jobs. Provenance tracks the activity that created, revised or signed a version of a resource, with agents that each have a type, role and who, plus an optional signature.8 AuditEvent is “a record of an event made for purposes of maintaining a security log”, and servers supporting it generally don’t accept updates or deletes to it.7
A practical split: a Provenance for the AI draft (agent: the scribe device, role author), another for the signature (agent: the clinician, role attester), both targeting specific versions of the DocumentReference or Composition. AuditEvents record the access and the signing action for the security log. Our post on AuditEvent vs Provenance goes deeper.
HL7’s AI Transparency on FHIR guide defines AI Provenance and AI Device profiles to mark data an AI system influenced; it went to its first STU ballot in January 2026, and no official version has been published yet.9 Watch it, but don’t wait for it.
Our own open draft, AAP-H, profiles Provenance and AuditEvent with a signed JSON envelope that records which agent acted, who approved, what the agent claimed and what the system of record shows afterwards.10 A valid record shows the issuer wrote those values and nothing changed since; it doesn’t show the AI was right.10 Details are on the spec page.
Governance: who owns what
A record only helps if someone owns each part:
- Clinical leads set which note sections and which order types the scribe may draft, and which need a second look.
- Health information management owns the record: what’s kept, for how long, and how amendments work.
- IT and security own the logs, access to them, and tamper detection.
- The vendor documents what its tool records and exports. If it can’t export the original draft, that’s a gap to raise before signing a contract; our vendor questions post has twenty to ask.
- Quality and safety reviews a sample of draft-versus-signed diffs each month.
A monthly sample of diffs is cheap and tells you whether review is happening. A note signed with zero edits in a few seconds doesn’t mean there’s a problem, but a pattern of them is worth a conversation.
Questions people ask
Does the EHR’s audit log already show what the AI wrote?
Usually it shows who opened, edited and signed. Whether it keeps the AI’s original draft depends on the product. Ask the vendor, and test an export.
Is keeping the AI draft required?
The rules we cite don’t name AI drafts. They require audit controls and recording of actions on health information.56 Keeping the draft is how those apply when part of the author is software.
What should we keep if we can keep only one thing?
The draft-to-signed diff with the signer and time. It answers the question that comes up after an error: what did the AI write, and what did the clinician change?
More on how hospitals can set this up is on our healthcare page, and the FHIR write integrity study shows why event 4, the read-back, matters. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).
Written with AI assistance and checked against our claims register.