AI agents are writing to patient records. Who checks what they changed?

A year ago, most AI in hospitals wrote text for a person to copy somewhere. Now it puts entries into the systems themselves: orders, notes, codes and pre-authorisations. That is a real gain for clinicians and claims teams, who get time back. It also moves the hard question. It is no longer only “was the AI’s answer good?” It is “what does the record hold now, who allowed it, and can we show that to someone who wasn’t in the room?”

This post looks at four things. Where AI already writes to clinical and claims systems. What can go wrong between an agent saying “done” and the record. What Indian and international rules already ask for. And a short list of checks to put in place before an agent writes to a chart.

From suggesting to writing

Picture a busy clinic morning: an AI tool drafts the note, queues two orders and moves the visit to billing before anyone has looked. If one of those entries is wrong, the question later is not what the AI suggested but what the chart actually holds. The safe pattern is simple: a clinician approves the changes that matter, the record is read back after each write, and every change leaves a sealed record.

The large electronic health record vendors now describe AI that acts inside the record:

• Epic says its AI Charting, released in February 2026, drafts the clinician’s note and “queues up orders”.¹
• Microsoft says that with supported EHRs, Dragon Copilot orders are “directly entered into the EHR order module”.²
• Solventum says its 360 Encompass autonomous coding system moves qualified encounters to billing “without coder touch”.³

India is moving just as fast, often in operations and insurance first:

• Google Cloud says Manipal Hospitals cut nurse handoff time from 90 to 20 minutes with generative AI, live in 23 of its 37 hospitals.⁴
• Medi Assist, a health-insurance administrator, says its platforms enabled more than 186,000 pre-authorisations in under five minutes, in operational highlights as on 30 June 2026.⁵
• Under the Ayushman Bharat Digital Mission, the government reported over 104 crore health records linked to over 93 crore ABHA accounts in July 2026.⁶ Every one of those records is something an agent may one day read or add to.

In most of these products a person still signs off, and that matters. But the work of putting data into the system is increasingly done by software that reports its own success.

Between done and the record

There are two different ways an agent’s write can go wrong, and they need different defences.

The content is wrong. A pilot published in 2026 that reviewed 356 notes drafted by an ambient AI scribe found omissions in 18% of notes and hallucinations in 11.5%, and rated 5.3% as holding an error that posed a serious or imminent risk.⁷ Catching that is clinical work. It needs a clinician who reads the draft before it counts, and no software tool should claim to do it for them.

The write itself isn’t what the agent says. This is less visible, and it happens even when the content is perfect. FHIR, the standard most clinical APIs use, has several places where a response can mislead:

• A conditional create that matches exactly one existing resource is ignored, and the server answers 200 OK. Nothing new is created.⁸ An agent that treats any 2xx as “saved” reports an allergy it never recorded.
• A client can ask the server to send back what it stored, but servers only “SHOULD” honour that request.⁸
• An update with an out-of-date version gets 412 Precondition Failed and writes nothing.⁸ An agent that retries without reading again can overwrite a colleague’s change.
• A timeout says nothing about whether the write committed.

What an agent can write also depends on each server. Epic’s public FHIR sandbox, for example, lists create for AllergyIntolerance and Condition, create and update for Observation, DocumentReference and ServiceRequest, and only read and search for MedicationRequest.⁹ A hospital’s own setup can differ, which is one more reason to look at what was stored instead of trusting what was sent.

Why the agent’s own log isn’t enough

When something looks wrong, the first place people look is the agent’s trace. It is a good debugging tool and a weak answer to “what happened”, for three reasons:

1. It is written by the agent. The same process that made the change describes it, sometimes in the model’s own summary.
2. It records the request, not the result. “Created AllergyIntolerance, 200 OK” can be true and the record can still hold nothing new.
3. Anyone with access can edit it. A line removed from a log file leaves no trace in the file.

A useful record is written outside the agent, says what the system held after the write, and is sealed so a later change shows.

What the rules already ask for

None of the rules below name AI agents directly in their audit duties, but each asks for something an agent’s writes have to fit into. They bind the hospital, insurer or developer.

India.

• The DPDP Rules, 2025 list “appropriate logs, monitoring and review” among minimum security safeguards and ask for those logs to be kept for one year; these duties start eighteen months after the rules were published.¹⁰
• NABH’s Digital Health Standards for hospitals include an element for a digital system that “captures the audit trails of each transaction”.¹¹
• ICMR’s 2023 guidelines ask for human oversight and manual override for AI that could cause severe or bodily injury, and for regular internal and external audits.¹²
• The India AI Governance Guidelines, which are not legally binding, say governance frameworks should have audit trails and human-in-the-loop mechanisms at critical decision points.¹³
• CERT-In’s 2022 directions ask covered entities to keep ICT system logs for a rolling 180 days within Indian jurisdiction.¹⁴
• ABDM says its consent manager ensures user consent for every data transaction.¹⁵

United States. HIPAA’s Security Rule asks for audit controls that “record and examine activity” in systems that contain or use electronic protected health information, and for protection against improper alteration or destruction.¹⁶

Five checks before an agent writes to a chart

1. Decide each call before it runs. Write down which resource types and actions an agent may use. Deny deletes of clinical records outright; correct with a new version instead.
2. Put a named person on the risky writes. Orders, medication changes and claims should wait for a clinician or a second reviewer, and the agent must never approve itself.
3. Check the record, not the response. After each write, read the resource back from the server, or read the database’s own change log, and compare it with what the agent reported.
4. Seal the record outside the agent. Sign each record and link it to the last one, so an auditor can check the history without trusting your servers or you.
5. Keep patient data in place. Record ids and digests rather than clinical content, salt patient references, and keep the whole system on servers in the country where the data belongs.

How Deedglass helps

Deedglass sits between an agent and the systems it writes to. It covers the first four checks today; for the fifth, it runs on your own servers, and in PHI mode, once an action is sealed and its checks are done, it keeps ids and digests of its request and result, not their content.²⁵ It makes no clinical decisions: it doesn’t diagnose, recommend or change what an agent asks for. It decides whether a call runs under your rules, records it, and checks what the system stored.²²

What works today:

• REST APIs, including a FHIR server’s. The REST connector calls the API through tools you define, such as one per resource type and action, your rules decide each call, and a read-back checks the fields you name after each write.¹⁸
• The FHIR connector (beta). It puts a FHIR R4 server’s REST API behind Deedglass as one tool per interaction (read, vread, search, history, create, update, patch, delete) on the resource types you list; a call naming any other type is refused before anything is sent.²³ Each write is read back at the version the server reported and the fields the agent sent are compared one by one, after dropping what the server adds on its own (Checked).²³
• Proven checks on FHIR servers on Postgres. On HAPI FHIR JPA 8.x and Medplum 5.x running on Postgres, a FHIR connector write can be Proven: Deedglass reads the FHIR server’s own change log and checks that the transaction holding the version the server reported is what the agent sent, and nothing else.²³
• A free healthcare-fhir rules pack. It denies deletes of clinical records (they are corrected with a new version), holds orders and medication changes, allergies, the problem list and final notes for a clinician’s approval, needs two different people for claims and other billing records, keeps coverage read-only and has every other write read back. No rule judges whether a clinical change is right.²⁴
• Health-tech apps on Postgres. With logical decoding on, Deedglass checks each agent write it runs against Postgres’s change log and can undo the rows after a person countersigns.¹⁹
• Approvals. A rule can require one or two people from an approver list; with two, one person can’t approve twice, one refusal is final, and an agent can never approve itself.²¹
• Records and self-hosting. Sealed records hold ids, digests, decisions and times, not the request or the result, while the action history keeps the full request until you prune it²⁰, and Deedglass runs on your servers with your own Postgres and sends us nothing by default.²⁰
• AuditEvent and Provenance export. Records export as FHIR R4 AuditEvent, shaped to the IHE Basic Audit Log Patterns profiles, and Provenance, shaped to the HL7 AI Transparency on FHIR ballot’s AI Provenance profile, with ids and digests instead of clinical content.²⁶

The binding rests on the version the FHIR server reported, which is weaker than the marker the Postgres connector writes. Deletes are Proven on HAPI only, and HAPI FHIR 7.x and older, deletes on Medplum, other FHIR servers and managed EHRs are Checked.²³

Deedglass doesn’t make anyone meet DPDP, HIPAA, NABH or any other rule. It gives you records you can show. To see where these checks miss, read our FHIR write benchmark. To shape the FHIR connector, become a design partner.

Try it

Not a developer? Since Deedglass 0.15.0, one line, npx deedglass, opens Deedglass as an app in your browser on your own computer, with no Docker or account.²⁷ It shows what your AI tools did, what is waiting for a person to approve, and locked records you can check later.²⁷ What’s new in 0.15.0 walks through it.

Watch an agent’s write get checked, caught and put back in the playground, in your browser with synthetic data. If your health-tech app keeps its data in Postgres, see what your agent’s database role can change today: put its database URL in an environment variable and run the free scan, npx deedglass scan --postgres-dsn-env DATABASE_URL. It runs read-only queries on that database and sends nothing anywhere else. The grade is explained here.

Written with AI assistance and checked against our claims register.