FHIR conditional create: when If-None-Exist stores nothing, and when it stores two

The short answer

A FHIR conditional create (POST with an If-None-Exist header) creates the resource only if no existing resource matches the search. If exactly one matches, R4 says the server ignores the post and returns 200 OK, creating nothing; if more than one matches, it returns 412.¹ So a 200 here doesn’t mean “saved”, and a 201 doesn’t promise there’s only one copy. In our October 2026 study, all four server setups answered 200 to a conditional create that matched one resource and stored nothing³, and one setup stored two copies from two conditional creates on the same identifier inside one transaction.³ After any conditional create, search by the identifier and count.

What R4 says about If-None-Exist

The header carries a search, typically on a business identifier:

Code A request one program sends to another over the web.

POST /fhir/Patient
If-None-Exist: identifier=https://hospital.example/mrn|00042
Content-Type: application/fhir+json

R4 defines three outcomes:¹

The middle row is the one that surprises people. The request “succeeded” in the sense that the server did what the spec says. But the body you sent was not stored. If your body differed from the existing resource (a corrected phone number, a new address), that change is gone, and the reply looks like success.

Case 1: 200 OK and nothing stored

On 26 October 2026 we sent synthetic writes to four setups: HAPI FHIR JPA Server 8.12.0 run locally twice (starter defaults, and with request validation on), the HAPI public test server (build 8.13.10-SNAPSHOT) and the Firely Server 6.11.0 public sandbox, and read every one back.³

All four answered 200 to a conditional create that matched one existing resource, and stored nothing.³ That’s R4 behaviour, not a defect. The point is narrower and more practical: the reply alone can’t tell your code whether anything was written.

A client that treats any 2xx as “stored what I sent” will log success for a write that didn’t happen. An agent that reports “created patient record” back to a person will be wrong, confidently.

Case 2: two copies from one transaction

The opposite failure turned up in a transaction. We put two conditional creates on the same identifier in one transaction Bundle. The Firely sandbox stored two copies; HAPI stored one.³ Behaviour here depends on the server and its configuration, so we name versions and use neutral wording; our study page has the raw runs.

R4 does set rules for transactions: entries are processed as a unit, and the server must resolve references between entries in the Bundle.² It’s easy to assume that “conditional” plus “transaction” means “one copy, enforced by the server”. Our results say check, don’t assume.

Sources:³,³.

How to tell what happened

Three checks, in order of cost:

1. Read the status code precisely. 201 means a resource was created; 200 to a conditional create means one already matched. Don’t collapse them into “success”.
2. Read the Location header or the returned resource id, and fetch it. Compare it with the body you meant to store.
3. Count by identifier. Search Patient?identifier=system|value after the write. One result is what you wanted. Zero means nothing was stored; two or more means duplicates you now need to resolve.

For a transaction, do the count for each identifier the Bundle touched, and check each entry’s response status rather than the Bundle’s overall reply.

Why this matters for agents

Agents retry. A timeout, a dropped connection or a model that isn’t sure the first call worked will send the same create again. Conditional create is the standard defence against that duplicate. It works when one match exists. But it also turns “I tried to update this patient’s details” into “I was told 200 and nothing changed”, and in a transaction it may not prevent the duplicate at all on every server.

Duplicates in patient data cost real money and time to clean up later; our posts on an agent that retried and wrote twice and on writes that said success show the general pattern. The rule that follows is simple: an agent’s write isn’t done when the server replies. It’s done when a read-back shows the record is in the state the agent meant.

A checklist

• Use If-None-Exist on a stable business identifier, never on a name or date of birth alone.
• Treat 200 and 201 as different outcomes in code and in logs.¹
• After a 200, fetch the matched resource and compare it with what you meant to write. If they differ, you need an update, not a create.
• After any create, search by identifier and count. Alert on zero or on more than one.
• In transactions, don’t rely on two conditional creates for the same identifier collapsing into one; send one entry per identifier.³
• Record the reply, the read-back and the count together, so a reviewer can see what was checked.
• Name the server, version and configuration whenever you write down how it behaved.

Questions people ask

Why does a conditional create return 200 instead of an error?

Because R4 defines it that way: when exactly one resource matches, the server ignores the post and returns 200 OK.¹ It’s designed to make the create safe to repeat, not to tell you about changes in your body.

Does If-None-Exist update the existing resource?

No. It creates nothing when one match exists. To change the existing resource, use an update, ideally with If-Match on the version you read.

Can a transaction still create duplicates?

On one setup we tested, yes: two conditional creates on the same identifier in one transaction stored two copies on the Firely sandbox, and one on HAPI.³ Search by identifier after the write to be sure.

The FHIR write integrity study has every case and server. To watch a read-back catch a write that said success, run npx deedglass health pilot, a 15-minute pilot on synthetic data⁴; the healthcare overview explains the rest. 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.