Blog/FHIR R4

Conditional FHIR Writes Are Searches with Consequences

Ilavrita Engineering · October 3, 2026

Conditional FHIR Writes Are Searches with Consequences

Primary query: FHIR conditional create update delete
Version: dev
Source revision: 7e036d413940d3978a5042409d387a4d52f2485c
FHIR version: R4 4.0.1
Data: synthetic only

Ilavrita remains a developer preview. Do not use patient data.

Last verified: October 3, 2026

A normal FHIR update names the resource you want to change. A conditional update asks the server to discover that resource first.

That makes conditional interactions more than HTTP conveniences. They turn search semantics into write semantics.

At the current Ilavrita revision, conditional create, update and delete are implemented. The search that selects the target runs under authorization for that resource type.

Conditional create is an identity decision

The familiar pattern is: create this resource only if no existing resource matches a search condition.

That can prevent duplicate records, but only if the server and client agree on what the search means. Silently ignoring an unsupported parameter would be especially dangerous here: the server could create when it should match, or match a broader population than the caller intended.

Ilavrita's general search rule therefore matters directly to conditional writes: unsupported search behavior is refused rather than quietly discarded.

Conditional update and delete raise the stakes

For a read, a bad search returns the wrong data.

For a conditional write, a bad search can mutate the wrong data.

The implementation resolves the condition through the supported search machinery and requires the caller's grant to search the relevant type. Conditional behavior does not become a shortcut around authorization merely because the target ID was omitted from the URL.

Transactions make conditions more interesting

Ilavrita also supports conditional references and ifNoneExist inside a transaction Bundle.

Now the server is resolving identity while executing an all-or-nothing set of writes. That is precisely where hand-wavy search behavior becomes dangerous: another entry may depend on the resource selected or created by the condition.

The implementation work explicitly added conditional-reference and ifNoneExist resolution to the transaction path rather than assuming ordinary request handling automatically covered it.

Refusal was part of the implementation history

Repository history is useful here because it shows an intermediate safety posture: before conditional create was implemented, Ilavrita changed behavior to refuse it rather than quietly performing something that looked close enough.

Later commits implemented conditional create, update and delete and then conditional behavior inside transactions.

That progression captures a design rule worth keeping: refusal is a valid feature state. Pretending partial support is complete is not.

What the evidence supports

At revision 7e036d413940d3978a5042409d387a4d52f2485c, README lists conditional create, update and delete as working, and repository commits implement those interactions. Tests also cover conditional reads and related HTTP behavior.

This article does not claim every FHIR conditional edge case or every search modifier exists. The server still deliberately exposes a bounded search surface.

Use the CapabilityStatement and current documentation for the exact runtime contract.

Evidence

Conditional interactions are convenient because the client can describe identity instead of already knowing it. That convenience is safe only when the search underneath is narrow, explicit and authorized.

Back to blog