Checking AI actions in Indian digital health

1. Summary

AI already writes to health records and claims. Vendors describe agents that queue orders, enter them into the EHR, write nurse handovers and process pre-authorisations, in India and abroad.^1,3,4
The reply is not the record. Standard FHIR, HL7 v2 and claims-exchange behaviour lets a write be answered as a success while the stored result differs from what the agent reported. In our public benchmark on Medplum 5.2.6 with synthetic data, 11 of 17 cases stored something different from the agent’s report, and a check that trusted the HTTP status caught 0 of them.⁸
Five controls close most of the gap: rules before each write, a read-back after it, a named person (or two) for high-risk writes, a signed record anyone can check offline, and data that stays on the hospital’s own servers in India.
They fit ABDM and NHCX as they are. They sit between the agent and the hospital’s FHIR server or HIS, use the NRCeS profiles to decide which writes need a person, and add the audit and provenance records the national guide doesn’t profile.
They help hospitals show good practice under the DPDP Rules 2025, the NABH Digital Health Standards and the EHR Standards for India. They produce evidence; they don’t make anyone meet a law or standard.
They are not clinical. Nothing in this model judges whether a diagnosis, dose or note is right. A clinician decides that.

2. The problem

2.1 AI agents already write to health records and claims

Three years ago, AI in a hospital mostly suggested. Today it also writes. Epic says its AI Charting, available from February 2026, drafts the visit note and “queues up orders” for the clinician.¹ Microsoft says Dragon Copilot orders are “directly entered into the EHR order module” with supported EHRs.²

India is moving at the same pace. Google Cloud’s case study says Manipal Hospitals cut nurse handover time from 90 to 20 minutes with generative AI, live in 23 hospitals.³ Medi Assist’s August 2026 investor presentation says more than half of its cashless pre-authorisations were completed in under five minutes.⁴ Underneath sits the national network: PIB reported on 6 July 2026 that over 104 crore health records are linked to over 93 crore ABHA accounts.⁵ The government reported 34 insurers and TPAs live on the National Health Claims Exchange (NHCX) in July 2024; we found no newer official count.⁶

None of the vendors above publicly describes an independent check of what an agent’s write actually stored. That is the gap this paper is about.

2.2 Why a “success” reply isn’t evidence

An agent usually decides that its work is done from the reply it gets. The standards that health systems run on allow that reply to say less, or something different, from what was stored:

Cases where a success reply and the stored record can differ
What the agent sends	What it is told	What may be stored
A FHIR conditional create (`If-None-Exist`) that matches an existing resource	200 OK	Nothing new. The agent may report a record it never created.⁷
Any FHIR write	A success code, often with no body	Servers only “SHOULD” return the stored resource (`Prefer: return=representation`), so the reply may not show what was kept.⁷
An update that changes nothing	200 OK	No new version. The agent’s “updated” is true in name only.
A transaction Bundle with one invalid entry	200 OK	On Medplum 5.2.6 without the transaction feature, two of three Observations were stored: a partial write.⁸
An HL7 v2 message	ACK `AA`	`AA` means the receiver accepted the message, not that each field landed where intended.⁹
An NHCX pre-authorisation or claim	An acknowledgement from the exchange	The payer’s answer arrives later as a separate callback. The acknowledgement says the exchange took the message, not what was decided.¹⁰
Any write that times out or gets a 5xx	An error	The write may or may not have happened. Retrying can create a duplicate.

We measured this. Our FHIR write-integrity benchmark plays 17 scenarios on synthetic data against a real Medplum 5.2.6 server. In 11, what the agent reports differs from what the server stores; the other 6 are controls where the report is right. With no checker, or with a check that trusts the HTTP status code, 0 of the 11 were caught. Deedglass caught 4 and missed 7, with no false alarms on the controls. Every result, including the misses, is public.⁸

2.3 The cost of errors

Errors in the record are not rare even without AI. In a 2020 JAMA Network Open survey of patients who read their visit notes, 21% reported finding a mistake, and about 40% of those judged it serious; diagnoses, medical history, and medications or allergies were the most common serious kinds.¹² AI adds new kinds. A 2026 JMIR Medical Informatics pilot that reviewed 356 AI-scribe notes found omissions in 18%, hallucinations in 11.5% and errors judged serious or of imminent risk in 2.5%.¹¹

In claims, time is the cost. IRDAI asks insurers to decide on cashless requests “immediately but not more than one hour” after the request, and to give final discharge authorisation within three hours.¹³ Those targets push automation, and a wrong amount, a wrong use (claim instead of pre-authorisation) or a claim sent twice costs a patient waiting at discharge, a billing desk and an insurer hours to unwind.

The checks that clinical review already provides are about content: is this note right? The question this paper answers is narrower and earlier: did the system store what the agent says it stored, was the right person asked first, and can anyone check that later without taking our word for it?

3. The model: five controls

The model puts one component between AI agents and the systems they write to. Every agent call passes through it. It works the same way whether the target is a FHIR server, an HIS’s own database or a REST API. We describe it in general terms; Deedglass is our open-source implementation, and the product details below are what it does today.

1. Rulerun, hold or refuse
2. Personone or two approve
3. Writeto the FHIR server or HIS
4. Read-backcompare stored with reported
5. Recordsigned, checkable offline

All five run on the hospital’s own servers. Control 5 also covers the data-stays-in-India rule in 3.5.

3.1 Rules before each write

Each call is matched against rules the hospital writes: by resource type, interaction, codes used for routing, and amounts. A rule says run, wait for a person, or refuse. Rules never read clinical values to decide whether something is right. Examples from the free healthcare rules pack: deletes of clinical records are refused (corrections are new versions); orders, medication changes, allergies, the problem list and final notes wait for a clinician; claims and other billing records need two different people; coverage is read-only.

For India, the free india-health pack reads each request’s meta.profile and what a Bundle holds, and names ABDM record types and NHCX bundles from the NRCeS guide, version 6.5.0. What a bundle holds counts for more than its label: a bundle labelled as a coverage eligibility request that holds a Claim is treated as a claim, and the mismatch is reported.²⁷

3.2 Read-back after each write

After the write, the resource is read again 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 (version metadata, its own tags, a generated narrative). On FHIR servers that run on PostgreSQL (HAPI FHIR JPA and Medplum), the check can go further and read the server’s own change log, so it sees everything the transaction committed, including extra resources the agent never mentioned.

There are three outcomes, never two: matches, doesn’t match (and which field), and can’t check. “Can’t check” is never shown as a pass. A conditional create the server answered with an existing resource is “doesn’t match”; an update the server kept at the same version is flagged.

3.3 Human approval for high-risk writes

Where a rule holds a write, it waits for a named person, and only a person can approve: in the console, through their own one-use emailed link, or with a signed chat click. An API key or an agent key can’t. A rule can need two different people (four eyes): one person can’t approve twice, and one refusal is final. An approval nobody decides expires after the time the rule sets, and nothing runs. The clinician reviews the request in the clinical system before approving; the model never approves on anyone’s behalf.

For hard days there is lockdown mode: every agent write waits for a person even when the rules allow it, high-risk writes need two people, and after a write ends “can’t check”, that agent’s writes are refused until a person acknowledges it. There is also Stop: one switch refuses all new agent actions on every instance within 2 seconds.

3.4 Signed records anyone can check

Each action is sealed as a record: which agent acted and for whom, which tool, which rule and rule version decided, who approved and when, what happened, and the check result, with SHA-256 fingerprints of the request and result instead of their content. Records are signed with Ed25519 and chained, so an auditor, an insurer or a regulator can check a hospital’s exported records offline with its public key, without asking the vendor.

Records can be exported as FHIR R4 AuditEvent, shaped to IHE’s Basic Audit Log Patterns, and Provenance, with ids and digests instead of clinical content.²⁰ That matters in India because the national FHIR guide profiles health records and claims but has no AuditEvent, Provenance or Consent profile.¹⁹

We have since published those record shapes as an open draft anyone can implement: Agent Action Provenance for Health (AAP-H), FHIR Provenance and AuditEvent profiles plus a JSON envelope, with an NHCX example.

3.5 Data stays in the country

The component is self-hosted: one binary and the hospital’s own PostgreSQL, on the hospital’s servers. It sends nothing to the vendor by default, so if a hospital runs it in India, its records and action history stay on its servers in India. With PHI mode on, once an action’s checks finish, stored history keeps ids and digests of the request and result, not clinical values. No patient data needs to leave the building for any of the five controls to work.

4. Mapping to ABDM building blocks

ABDM is federated: registries identify people, facilities and professionals; the Health Information Exchange and Consent Manager (HIE-CM) moves records between providers under patient consent; Health Information Providers (HIPs) create records and Health Information Users (HIUs) request them.^17,16,18 Records travel as FHIR R4 bundles in the NRCeS profiles.¹⁴ The model sits inside the hospital, between its agents and its own HIS or FHIR server. It doesn’t replace or talk to any national component.

ABDM building blocks and where the five controls apply
ABDM building block	Where AI agents touch it	What the model adds	What it doesn’t do
ABHA (health account) and linking	An agent links a visit or record to a patient’s ABHA in the HIS	A rule can hold linking writes for a person; the record keeps fingerprints of the request, not the ABHA number itself	It doesn’t verify ABHA numbers with ABDM
Health Facility and Professional Registries	Agents fill facility or practitioner references in records	Read-back compares the references stored with those the agent sent	It doesn’t check a registry entry is real
HIP: creating records (OPConsultRecord, DischargeSummaryRecord, PrescriptionRecord and others)	Scribes and assistants draft notes and discharge summaries into the HIS before they are shared	The pack names the record type from its profile; a final record waits for a clinician; a preliminary one runs and is read back	It doesn’t validate every element against the profiles; use the guide’s validator
HIU: requesting records	An agent pulls records from other providers for a summary	Reads are recorded too; a rule can refuse reads without the right context	It doesn’t check the consent artefact with the gateway
HIE-CM and gateway	Consent and exchange between HIPs and HIUs	Nothing directly: these are national services	It doesn’t sit on, or change, the national exchange
Audit and provenance (not profiled in the IG)	“Which AI wrote this, and who approved it?”	Signed records, exportable as FHIR AuditEvent (IHE BALP) and Provenance	It records only actions that pass through it

A practical start for a hospital: put the model in front of one agent that writes one ABDM record type, such as discharge summaries, on a test FHIR server with synthetic data. Hold final summaries for a clinician, read back every write, and review a week of records with the HIS team.

5. Mapping to NHCX flows

NHCX carries claims between providers and payers as FHIR bundles in the NHCX profiles: coverage eligibility, pre-authorisation, claim, communication and payment notice.¹⁵ The exchange is asynchronous: the sender gets an acknowledgement, and the answer comes back later as a callback.¹⁰ The model governs what the hospital’s agents write into the hospital’s systems before a bundle leaves, and records each step.

NHCX flows and suggested rules
NHCX flow (bundle)	Suggested rule	What the record shows
Coverage eligibility request	Runs, and is read back	Which agent asked, when, and what was stored
Pre-authorisation (Claim, use “preauthorization”)	One person approves, two above an amount the hospital sets (the pack’s example is INR 1,00,000), within 45 minutes	Who approved, when, and the time from request to approval, against IRDAI’s one-hour target
Final claim (Claim, use “claim”)	Two people approve at any amount	Both approvers and times; the total and currency as read from the request
A claim whose use, total or currency can’t be read	Two people approve	That the request was unreadable, and who let it through
A bundle whose label doesn’t match what it holds	Refused	The mismatch, with no request sent
Claim response, payment notice, other payer-side records	Two people approve before an agent writes them into the HIS	Who posted the payer’s answer, and whether it was stored as sent
Communication and task bundles	Run, and are read back	The request for more documents and what the agent attached

Two limits matter here. The model does not talk to the NHCX gateway, so the exchange’s acknowledgement and the payer’s callback are outside it; it records what the hospital’s agents did with them. And it does not measure the end-to-end turnaround; it timestamps each step that passes through it.

6. Showing good practice under DPDP and NABH

Duties under Indian law and accreditation fall on the hospital or insurer, not on a software vendor. What the model can do is produce evidence a hospital may use in its own review. The table says which expectation each artefact relates to, and what it doesn’t cover. This is not legal advice; a hospital’s counsel decides what the evidence is enough for.

Expectations, the evidence the model produces, and its limits
Expectation (source)	Evidence the model produces	What it doesn’t cover
DPDP Rules 2025: “appropriate logs, monitoring and review” among security safeguards, and logs kept for one year; most of these duties start eighteen months after publication, around May 2027²¹	A signed record of every agent action, kept for as long as the hospital sets (1 to 3,650 days) and exportable for offline checking	It is not the hospital’s full processing log, and it doesn’t cover systems the agent doesn’t reach through it
DPDP Rules 2025: personal data breach reporting²¹	Records help reconstruct which resources an agent touched, when, and with what result	Detection and notification are the hospital’s
NABH Digital Health Standards, 2nd edition: the system “captures the audit trails of each transaction” (DIS.2(d))²²	A per-transaction record for each agent action, with its check result and approver	Human users’ actions inside the HIS
EHR Standards for India (2016): record all actions on health information, “including viewing”; ISO 27789 for audit trails; SHA-256 or stronger hashing²³	Reads are recorded too; SHA-256 fingerprints; signed records	Only actions that pass through the model
ICMR AI guidelines (2023): human oversight where AI could cause serious harm, and regular audits²⁴	Rules that hold writes for named clinicians; records of each approval; Stop and lockdown	Model validation and training-data review
India AI Governance Guidelines (2025, voluntary): audit trails and human-in-the-loop checks at critical decision points for agents²⁵	Approvals, records and check results	Organisation-wide AI governance
CERT-In Directions (2022): ICT logs kept for a rolling 180 days within India²⁶	Records stay on the hospital’s servers in India when it hosts there	Clock synchronisation and incident reporting are the host’s

A hospital preparing for a NABH digital health assessment, or for the DPDP Rules’ May 2027 start, can use these records to show who changed what with AI, who approved it, and what the system stored. It still needs its own policies, its HIS audit trail and its own review.

7. Honest limits

It is not clinical software. It doesn’t diagnose, recommend treatment, prioritise patients or judge whether a note, order or claim is right. A clinician or the billing desk decides that when they approve. Reports from pilots count data mismatches and staff hours, never patient outcomes.
It misses things. In our own benchmark it caught 4 of 11 diverging cases and missed 7: among them a conditional update that created a new patient, a transaction applied in part, a lost update sent without If-Match, a reference to a missing patient and a duplicate from a retry. We publish the misses.⁸ The benchmark ran on one server version (Medplum 5.2.6) with synthetic data.
It sees only what passes through it. AI built into an HIS that writes directly to its own database is outside it unless the HIS routes those writes through.
It reads profiles, it doesn’t validate them. It reads meta.profile and bundle contents; it doesn’t check every element against the NRCeS StructureDefinitions.
It doesn’t check ABDM consent with the gateway, and it doesn’t talk to the ABDM gateway or NHCX.
Approvals add waiting. A held write waits for a person. Hospitals need at least two named approvers per rule, a tested notification path and a written manual fallback for every agent workflow.
Fingerprints are not secrecy. Digests of short values can be guessed, so records are protected like any other sensitive log.
Young software, small company. The FHIR connector is in beta. We don’t have a SOC 2 report or an ISO 27001 audit yet, there is no single sign-on yet, and we aren’t on ABDM’s list of approved integrators.

8. An open invitation to pilot

We invite Indian hospitals, insurers, TPAs, HIS vendors and health-tech teams to test this model with us, free:

Six weeks, one workflow, such as discharge summaries, nurse handover notes, ePharmacy orders or pre-authorisations.
Synthetic data only (Synthea or the FHIR examples) on a test server you choose. We never receive patient data; the software runs on your machines.
What you get: the rules tuned to your workflow, a read-back on every write, approvals for the writes you name, signed records your auditor can check offline, and a written summary at week six of what matched, what didn’t and what we changed.
What we ask: honest notes on what is missing or wrong. We name you in public only if you say yes in writing.

Deedglass is open source under the Apache-2.0 licence and free to run on your own servers. To start, write to hello@deedglass.com with the workflow and the system your agent writes to, or read how design partnerships work. The healthcare overview is at deedglass.com/healthcare, and the benchmark at deedglass.com/healthcare/benchmark. Our FHIR write integrity study, which sent the official ABDM and NHCX example bundles to four FHIR server setups and read them back, is at deedglass.com/research/fhir-write-integrity-2026.

9. Sources

Epic, “Epic AI Charting rolls out alongside an expanding set of built-in AI capabilities” (February 2026). www.epic.com/epic/post/epic-ai-charting-rolls-out-alongside-an-expanding-set-of-built-in-ai-capabilities
Microsoft, “Meet Microsoft Dragon Copilot” (3 March 2025). www.microsoft.com/en-us/microsoft-cloud/blog/healthcare/2025/03/03/meet-microsoft-dragon-copilot-your-new-ai-assistant-for-clinical-workflow/
Google Cloud, “How Manipal Hospitals sped up nurse handoffs” (customer case study). cloud.google.com/blog/topics/customers/how-manipal-hospitals-sped-up-nurse-handoffs-across-37-hospitals
Medi Assist Healthcare Services, investor presentation (August 2026). nsearchives.nseindia.com/corporate/MEDIASSIST_09082026195837_MAHSInvestorPresentationAug26.pdf
Press Information Bureau, ABDM factsheet (6 July 2026). static.pib.gov.in/WriteReadData/specificdocs/documents/2026/jul/doc202676912801.pdf
Ministry of Health and Family Welfare via PIB, NHCX status (21 July 2024). pib.gov.in/PressReleasePage.aspx?PRID=2037634
HL7 FHIR R4, RESTful API (conditional create, Prefer, version-aware updates). hl7.org/fhir/R4/http.html
Deedglass, FHIR write-integrity benchmark (Medplum 5.2.6, synthetic data, run 21 October 2026). deedglass.com/healthcare/benchmark
HL7, v2 table 0008 (acknowledgment codes). hl7.org/fhir/R4/v2/0008/index.html
HCX open protocol specifications (Swasth), exchange protocol and API structure. github.com/hcx-project/hcx-specs
JMIR Medical Informatics (2026), AI scribe pilot review of 356 notes. medinform.jmir.org/2026/1/e103162/PDF
Bell SK et al., “Frequency and types of patient-reported errors in electronic health record ambulatory care notes”, JAMA Network Open 2020;3(6):e205867. pmc.ncbi.nlm.nih.gov/articles/PMC7284300/
IRDAI, Master Circular on health insurance business (29 May 2024). irdai.gov.in/document-detail?documentId=4942918
NRCeS (C-DAC Pune), FHIR Implementation Guide for ABDM 6.5.0. nrces.in/ndhm/fhir/r4/index.html
NRCeS, NHCX profiles in the ABDM FHIR guide. nrces.in/ndhm/fhir/r4/hcx-profile.html
ABDM, Health Information Exchange and Consent Manager. abdm.gov.in/strapicms/uploads/ABDM_HIE_CM_ea5d4c0559.pdf
ABDM, architecture overview (registries, HIE-CM, gateway). abdm.gov.in/strapicms/uploads/ABDM_v3_b69454eed2.pdf
NHA, guidelines for Health Information Providers and Users. abdm.gov.in/strapicms/uploads/HIP_HIU_Guidelines_f85df336ec.pdf
NRCeS, profiles in the ABDM FHIR guide (no AuditEvent, Provenance or Consent profile). nrces.in/ndhm/fhir/r4/profiles.html
IHE, Basic Audit Log Patterns (BALP). profiles.ihe.net/ITI/BALP/
MeitY, Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)). www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf
NABH, Digital Health Standards for Hospitals, 2nd edition (September 2025). nabh-portal-live.s3.ap-south-1.amazonaws.com/wp-content/uploads/2025/07/02133924/NABH-Digital-Health-Standards-For-Hospitals-2nd-Edition_September-2025.pdf
MoHFW and NRCeS, EHR Standards for India (2016). nrces.in/standards/ehr-standards-for-india
ICMR, Ethical guidelines for application of AI in biomedical research and healthcare (2023). www.icmr.gov.in/icmrobject/custom_data/pdf/Ethical-guidelines/Ethical_Guidelines_AI_Healthcare_2023.pdf
MeitY, India AI Governance Guidelines (November 2025). static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc2025115685601.pdf
CERT-In, Directions under section 70B(6) (28 April 2022). www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf
Deedglass documentation, India: ABDM and NHCX. github.com/deedglass/deedglass/blob/main/docs/healthcare/INDIA.md

Sources were read between 18 and 26 October 2026. Vendor figures are the vendors’ own. Product statements describe Deedglass 0.12 and its public documentation. Written by Arjun Prabhakaran. Corrections are welcome at hello@deedglass.com; we date every change.