FHIR write test
11 FHIR writes where the server said success but stored something different.
We ran 17 small FHIR write cases on Medplum 5.2.6, with made-up data. In 11, what the AI agent said it saved was not what the server stored. In the other 6, the agent was right.1 A check that trusts the success reply caught none of the 11.1 Deedglass caught 4 and missed 7.1
The score
Three ways to check, side by side.
“Trusts the success reply” is what most code does today: a 200 or 201 means it worked. “No check” takes the agent at its word.
| Score | Deedglass | Trusts the success reply | No check |
|---|---|---|---|
| Caughtof the 11 where the server said success but stored something else | 4 of 11 | 0 of 11 | 0 of 11 |
| Stopped before the write, by a rule | 1 | 0 | 0 |
| Caught after the write, by reading it back | 3 | 0 | 0 |
| Missed | 7 | 11 | 11 |
| False alarmson the 6 where the agent was right | 0 | 0 | 0 |
| Said what was really stored | 10 of 17 | 6 of 17 | 6 of 17 |
| Left a record anyone can check offline | 17 of 17 | 0 of 17 | 0 of 17 |
Of the 4 catches, 3 came from reading the write back. The other one, a delete, came from a rule in the healthcare rules pack that blocks deletes of clinical records. It was not the read-back check. For a delete, the read-back only checks that the record now reads as deleted, and here it did.1 Deedglass raised no false alarms on the 6 cases where the agent was right.1
Where Deedglass loses
The 7 it missed.
In each of these, the server said success, and Deedglass did not flag the gap. Each case is standard FHIR behaviour or something Medplum documents, with the source linked.3
- 02Missed
A conditional update with no match creates a second Patient
The agent asked to update a patient’s phone number. No record matched the search, so the server made a new patient record instead.
Source: FHIR R4 standard, Medplum docs
- 03Missed
A transaction Bundle is applied in part
The agent sent three readings as one all-or-nothing batch. One was not valid. The server saved the other two and said OK.
Source: Medplum docs, FHIR R4 standard
- 06Missed
The id the agent chose is replaced by the server's
The agent chose its own id for a new reading, so it could link to it later. The server gave the reading a different id.
Source: FHIR R4 standard
- 09Missed
An update without If-Match overwrites another writer's change
The agent marked a reading as final. Another system had changed it first, and the agent’s save wiped out that change.
Source: FHIR R4 standard, Medplum docs
- 11Missed
A JSON Patch add replaces the identifiers instead of appending
The agent meant to add a device id to a list. The way it asked replaced the whole list, so the old id was lost.
Source: RFC 6902, Medplum docs
- 13Missed
An Observation for a patient that doesn't exist is stored
The agent saved a reading for a patient who is not in the system. The server stored it anyway.
Source: Medplum docs, Medplum discussion
- 16Missed
A retry after a lost answer stores the reading twice
The first save got no answer, so the agent tried again. Both tries were saved, so the reading is there twice.
Source: FHIR R4 standard
Where Deedglass wins
The 4 it caught.
- 01Caught by the read-back
A conditional create answers 200 and stores nothing
The agent asked to add a heart-rate reading “unless one like it is already there”. One was, so the server saved nothing new. It still said OK.
Source: FHIR R4 standard
- 05Caught by the read-back
An AccessPolicy's read-only field is dropped from a 201
The agent saved a reading with a note. Its access rules made the note read-only, so the server saved the reading without the note and said Created.
Source: Medplum docs
- 07Caught by the read-back
The author the agent set is replaced by its client
The agent named a clinician as the author. The server wrote down the agent’s own app as the author instead.
Source: Medplum docs
- 15Stopped by a rule
A deleted Observation stays readable in history
The agent deleted a reading put on the wrong patient and said it was gone. Every older version can still be read from the history.
Source: FHIR R4 standard, Medplum docs
Controls
The 6 where the agent was right.
A tool that flags everything would look good on the misses. These cases check for that. Flagging one counts as a false alarm.
- 04No false alarm
The same transaction with the feature on is refused whole
The same batch, with the server set to treat it as all-or-nothing. It turned down all three, just as the agent said.
Source: Medplum docs, FHIR R4 standard
- 08No false alarm
The server adds meta, and nothing else changes
The server added its own details, such as the version and time. Nothing the agent sent was changed.
Source: FHIR R4 standard
- 10No false alarm
The same update with If-Match is refused with 412
The agent asked the server to check the version first. The reading had changed, so the server turned the save down, just as the agent said.
Source: FHIR R4 standard, Medplum docs
- 12No false alarm
A JSON Patch on a missing element is refused
The agent tried to change a note that was not there. The server turned it down, just as the agent said.
Source: RFC 6902
- 14No false alarm
The same Observation is refused when references are checked
The same reading, with the server set to check that the patient exists. It turned the reading down, just as the agent said.
Source: Medplum docs
- 17No false alarm
Another system changes the order's status after the agent
Another system changed the order after the agent did. That later change is the other system’s, not the agent’s.
Source: FHIR R4 standard
How it was scored
From the server’s own records.
What was stored
After each step, the test reads the server’s own version tables. It never uses the server’s reply, or what a tool says.2
Limits, plainly
- One server only: Medplum 5.2.6 on PostgreSQL 18.6, with one set of project settings. Other FHIR servers and hosted EHRs are not in it yet.
- Made-up data only. No real patient is in any case.
- 17 small cases, with one or two records each. Real systems add more retries, more tools and more agents.
- The agent’s report is fixed text, not a live AI model. The test scores the checks, not the agents.
- We wrote the cases and the test, and Deedglass is one of the tools scored. That is why the misses come first.
- Deedglass ran with its default settings and the healthcare rules pack. Other settings would change some results.
Run it yourself
One command, a few minutes.
In a copy of the Deedglass source, with Docker running, one command starts Medplum 5.2.6, runs every case and removes it all at the end.2 Add your own checker and send us the result. We publish results where Deedglass loses.
In a terminal
git clone https://github.com/deedglass/deedglass
cd deedglass
make fhir-benchSee what this means for your hospital or product.
Hospitals and teams that need help with setup, support or a pilot: talk to us.
Why now
AI has moved from suggesting to writing.
AI tools in hospitals and insurers now put entries straight into records: orders, notes, codes and claims. The announcements say what the AI does. They don’t say who checks what the record holds afterwards.
Manipal Hospitals
Google Cloud says Manipal cut nurse handoff time from 90 to 20 minutes with generative AI, live in 23 of its 37 hospitals.7
Medi Assist
The Indian health-insurance administrator says its platforms enabled more than 186,000 pre-authorisations that each took under five minutes, as on 30 June 2026.8
Epic
Epic says its AI Charting drafts the clinician’s note and “queues up orders” based on the conversation.5
Microsoft
Microsoft says that with supported EHRs, Dragon Copilot orders are “directly entered into the EHR order module”.6
“Allergy recorded.”
“OK.”
Nothing new. A matching entry already existed, so nothing was saved.
None of these companies use Deedglass. Their own words show where AI in healthcare is going. Deedglass covers AI actions that go through it; it can’t see an AI feature built into your EHR that writes there directly.
Plainly
What Deedglass is not.
- Not a stamp of approval.
Using Deedglass doesn’t make you meet DPDP, HIPAA, NABH or any other rule. It gives you records to show.
- Not audited yet.
We don’t have a SOC 2 report or an ISO 27001 audit yet. We’ll say so here the day that changes.10
- Not free of patient data unless you switch PHI mode on.
Without PHI mode, the action history keeps the full request until you clear it, by the retention you set (90 days by default). Switch PHI mode on, use test data, or keep identifiers out of what agents send.10
- Not a hosted service for health data.
You run it on your servers. We don’t host patient data.
- Not a big vendor, yet.
Deedglass is built by one founder, and you deal with him directly. Everything Deedglass Health uses today is in the free, open-source core.11 The core is under Apache-2.0, so you can keep running it without us.12
- Not able to see AI built into your EHR.
Deedglass covers AI actions that go through it. An AI feature inside your EHR that writes there directly doesn’t pass through Deedglass.
Deedglass makes no clinical decisions. It doesn’t diagnose, recommend treatment, prioritise patients, interpret clinical data or change what an agent asks for. It decides whether a call runs under your rules, records it, and checks what the system stored. The rules you write can look at the kind of record, the action and amounts; Deedglass never judges whether a dose or a diagnosis is right.
Questions
What people ask about FHIR writes.
How do you check that a FHIR write saved what the agent sent?
Read the resource back after the write and compare the fields the agent sent, one by one, after dropping what the server adds on its own.4 In this test, trusting the success reply caught none of the 11 cases where the server stored something else.1
Does a 200 or 201 from a FHIR server mean the data was saved as sent?
Not always. On Medplum 5.2.6 without its transaction-bundles feature, an all-or-nothing batch with one invalid entry was answered 200, and two of its three readings were stored.2 In 11 of the 17 cases here, the reply said success and the server stored something different.1
Which FHIR write problems does Deedglass miss?
7 of the 11: a conditional update that created a new patient, a batch applied in part, a client id the server replaced, a lost update without If-Match, a patch that replaced a list, a reference to a missing patient, and a duplicate from a retry.1
Does the benchmark use real patient data?
No. Every case uses made-up data on one server, and it checks what was stored, never whether care was right.
Words on this page
Eight terms, in plain words.
- AI agent
- Software that does tasks on its own, such as drafting a note or placing an order, instead of only suggesting text for a person to copy.
- Patient record (EHR)
- The electronic health record: the system that holds a patient’s notes, orders, allergies and results. Many share data using a standard called FHIR.
- What FHIR is
- Audit trail
- A lasting list of who did what to a record, and when, kept so someone can check it later.
- Audit trails for AI
- Clinician approval
- A doctor, nurse or other clinician says yes or no before the AI’s change is saved. Nothing happens until they decide.
- More on approvals
- Sealed record
- A signed entry for each AI action: who asked, who approved, what was saved. Changing it later shows, and anyone with your public key can check it, without us.
- Fingerprint (digest)
- A short code worked out from some data. The same data always gives the same code, but you can’t read the data back from it. Records keep fingerprints instead of patient details.
- Checked and Proven
- Checked: Deedglass read the record back and compared it. Proven: it also read the database’s own change history. Neither is a clinical check.
- PHI
- Protected health information: health details that can identify a person, such as a name with a diagnosis. The US term; India’s DPDP Act treats it as personal data.
- PHI and health data
Sources
- 1Deedglass source: corpus/fhir/results/latest.json, the run of October 21, 2026 on Medplum 5.2.6 · github.com · checked 25 October 2026
- 2Deedglass source: corpus/fhir/BENCHMARK.md, the method, the scores and the limits · github.com · checked 25 October 2026
- 3Deedglass source: corpus/fhir/README.md, the scenarios and their sources · github.com · checked 25 October 2026
- 4Deedglass docs: the FHIR connector, how each write is read back · docs.deedglass.com · checked 25 October 2026
- 5Epic: Epic AI Charting rolls out alongside an expanding set of built-in AI capabilities · epic.com · checked 25 October 2026
- 6Microsoft: Meet Microsoft Dragon Copilot · microsoft.com · checked 25 October 2026
- 7Google Cloud: How Manipal Hospitals sped up nurse handoffs · cloud.google.com · checked 25 October 2026
- 8Medi Assist Healthcare Services: investor presentation, August 2026 (NSE filing) · nsearchives.nseindia.com · checked 25 October 2026
- 9HL7 FHIR R4: RESTful API (conditional create, Prefer, managing versions) · hl7.org · checked 25 October 2026
- 10Deedglass docs: Records and the record chain · docs.deedglass.com · checked 25 October 2026
- 11Deedglass source: docs/LICENSING.md, the licences (every feature free while we grow) · github.com · checked 25 October 2026
- 12Deedglass source: LICENSE (Apache-2.0) and ee/LICENSE (FSL-1.1-ALv2) · github.com · checked 25 October 2026
Vendor figures are the vendors’ own. Nothing on this page is legal advice. If something here is wrong, write to hello@deedglass.com.