FHIR R4 Batches and Transactions: Which Resource Changes Succeeded?

Identify the Bundle's purpose before inferring a change

An offer to exchange one FHIR Bundle leaves the central buying question unanswered: what does the server do with its entries? A Bundle packages resources and context. Its type identifies the intended use; packaging several resources together does not, by itself, require their changes to take effect together.

This article uses the permanent HL7 FHIR R4 v4.0.1 specification, checked October 20, 2026. Those pages identify a later release, so the rules here are explicitly R4 rules. The comparison concerns the server interaction contract, rather than a healthcare system operating procedure.

A searchset carries search results. A collection carries resources without a particular use assigned by the specification. A batch or transaction carries entry-level request details describing actions for the server. The corresponding batch-response and transaction-response types carry outcomes. These distinctions explain why receiving a Bundle is insufficient evidence of a grouped mutation.

Start with the required result. If three identified resources must change as one server decision, that grouping belongs in the interface requirement. A supplier's general statement that it supports FHIR does not identify the relevant interaction or establish support for it on the selected server.

References: [B1][H1]

Read an independent batch through its entry outcomes

R4 processes each batch entry as an individual interaction or operation. The entries that change server state must have no interdependencies: one change's success or failure should not determine another change's success, failure or resulting content. The specification explicitly treats a reference to another resource being created within the same batch as nonconformant.

That constraint matters when comparing offers. Batch is a way to package independent actions, and can be appropriate when independence matches the actual requirement. It does not supply a grouping guarantee for changes that need to stand or fall together. Putting dependent clinical changes in a larger batch does not resolve that mismatch.

For a correctly processed batch, the outer HTTP response is 200 even when an operation inside it fails. R4 directs the reader to the returned Bundle for the individual statuses; a non-2xx entry status indicates that its request failed. The outer code answers whether the batch itself was processed correctly. It supplies no count or identity of successfully applied changes by itself.

An offer evidenced only by an HTTP 200 receipt therefore leaves the resource outcomes unresolved. The useful evidence connects each requested action to its entry response and interprets that outcome under the applicable interaction.

References: [H1]

Establish the selected server's transaction behavior

For an R4 transaction, the server must accept all actions and return HTTP 200 with a response Bundle, or reject the group and return a 400- or 500-class response. The outcome must not depend on the order of resources in the submitted transaction. R4 also limits a resource identity to one occurrence and requires failure when identities overlap among the specified change actions, including after applicable conditional identity resolution.

These are rules for the named interaction. The specification expressly warns that not every server implements transactions; batch support must also be established. A FHIR label or a demonstration of individual updates does not establish transaction support. Ask the supplier to identify the server endpoint, applicable R4 implementation and supported interactions, using its CapabilityStatement and applicable implementation documentation as evidence about that selected service.

Support also needs to cover the proposed resource actions and their conditions. The transaction grouping does not remove the normal processing and validation rules for those actions. When a required action fails those rules, the group's rejection is the meaningful transaction outcome.

The buyer needs that supported contract and an applicable outcome, rather than an assumption that any server accepting a Bundle provides the same behavior.

References: [H1]

IND-FHIR-02: compare two alternatives from the same state

Consider fictional case IND-FHIR-02. A, B and C are three existing, distinct, independently identified Observation resources. Their initial abstract content states are A0, B0 and C0; the proposed states are A1, B1 and C1. These labels are neither patient values nor actual FHIR version IDs.

There are no cross-entry dependencies, references to newly created resources, overlapping identities, concurrent changes or other operations. Authentication, authorization and all other applicability conditions are stipulated satisfied. The same substantive validation rule rejects B1 in both alternatives; A1 and C1 are separately acceptable. A successful update is stipulated to apply its corresponding symbolic new state. Each alternative contains one supplied interaction, with no retry or uncertain reply.

Compare alternative runs starting from the same A0/B0/C0 state. The transaction is not submitted after the batch. For the batch alternative, stipulate correct batch processing, outer HTTP 200, completed successful A and C updates and a failed B update. For the transaction alternative, stipulate a server that supports the required R4 transaction behavior and the same validation failure for B1.

References: [H1]

Two applied changes leave a different state from zero

The batch leaves the new A and C states alongside the original B state. Its outer 200 is compatible with that result because batch processing and entry success are different questions. Under the stated independence assumptions, B's validation failure does not require the acceptable A and C changes to be undone.

The transaction leaves all three resources in their original states. A1 and C1 being individually acceptable does not make them applied changes in this rejected group. The transaction's value for a grouping requirement is precisely that B's failure prevents a partial change across these three resource actions.

The difference is more useful than the two-versus-zero count alone. A buyer requiring the three changes together can reject the batch alternative's A1/B0/C1 outcome against that requirement. The rejected transaction preserves the initial group and reports failure; it has not delivered A1/B1/C1 either. Successful delivery of the requested group still needs an accepted transaction outcome under the applicable contract.

Conversely, where the three changes are genuinely independent and the requirement permits separate outcomes, the stipulated batch result can be assessed action by action. The requirement determines whether partial completion is acceptable.

References: [H1]

Use response shape to keep outcome evidence intact

For a batch or successful transaction, R4 returns a Bundle with one response entry per request entry, in the same order. Its type is batch-response or transaction-response. Each entry's response details the outcome, including status and applicable location and ETag information for resource identity and versioning. The Bundle definition qualifies location as present when the operation returns one, and ETag as relevant to the resource.

This correspondence helps connect a reported result to the requested action. It does not prescribe an execution sequence. In particular, the ordering of response entries must not be read as permission to make transaction correctness depend on the submitted resource order.

For a failed transaction, the response is a single OperationOutcome instead of that response Bundle. In IND-FHIR-02, there are no successful A and C response entries inside a failed transaction to count as completed updates. An explanation of why the group failed and evidence that particular independent batch entries succeeded have different meanings.

References: [H1][B1]

Compare the offer at the server and consumer boundaries

If the purchase requirement is that the three resource changes take effect as one server decision, ask the offer to name the supported transaction interaction and explain how its response establishes acceptance or rejection of that group. A larger batch, a higher resource count or an outer 200 receipt cannot demonstrate that property. Additional GPU throughput changes no R4 grouping rule.

Keep the server result separate from the AI consumer's state. An accepted transaction for these resource actions does not establish an atomic update of an external cache, search index, model input or S3 dataset. The offer needs a separate account of what that consumer has received and which server state it represents. The related S3 dataset-release guide explains coherent multi-object releases at that different boundary; the NVMe guide separates device-write guarantees from application grouping.

The DICOM guide addresses another distinct input question: which image resources, pixel population and representation a consumer receives. It supplies no FHIR transaction support or FHIR-to-DICOM conversion. The API idempotency guide addresses repeated requests and their effects; the one-interaction alternatives here establish no retry behavior.

Neither accepted resource content nor transport status establishes clinical accuracy, treatment suitability, consent, authorization, regulatory compliance or medical-device qualification. Those judgments require their own applicable evidence and responsible parties. This analysis used public specifications and a fictional case; no patient, customer or healthcare system data was accessed.

References: [H1]

Connect a separate equipment project to physical cabling scope

If the wider deployment also creates a physical storage or network cabling package, Leviathan's Structured Cabling & Fiber Installation service provides a route to discuss agreed fiber and copper installation, endpoint labels and physical connection records. The related service and project inquiry apply to that separately scoped equipment work.

Share a nonconfidential equipment summary, approved endpoints and routes, material responsibilities and required physical handoff to discuss scope and availability. FHIR/EHR integration, application operation and clinical validation remain with the appointed software and healthcare providers.

References: [L1]