Transaction / Batch

The batch and transaction interactions submit a set of actions to perform on a server in a single HTTP request/response. The actions may be performed independently as a "batch", or as a single atomic "transaction" where the entire set of changes succeed or fail as a single entity. Multiple actions on multiple resources of the same or different types may be submitted, and they may be a mix of other interactions (e.g. read, search, create, update, delete, etc.), or using the operations framework.

In the case of a batch each entry is treated as if an individual interaction or operation, in the case of a transaction all interactions or operations either succeed or fail together.

Endpoint

{{fhir_base}}/fhir

Body

The content of the post submission is a Bundle with Bundle.type = batch or transaction. Each entry SHALL carry request details (Bundle.entry.request) that provides the HTTP details of the action that needs to be performed. If the HTTP command is a PUT or POST, then the entry SHALL contain a resource for the body of the action.

Batch Processing Rules

In the case of a batch each entry is treated as if an individual interaction or operation, therefore the success or failure of one change does not alter the success or failure or resulting content of another change. References within a Bundle.entry.resource to another Bundle.entry.resource that is being created within the batch are considered to be non-conformant.

When processing the batch, the HTTP response code is 200 Ok if the batch was processed correctly, regardless of the success of the operations within the Batch. To determine the status of the operations, look inside the returned Bundle. A response code on an entry of other than 2xx (200, 202 etc) indicates that processing the request in the entry failed.

Transaction Processing Rules

A transaction may include references from one resource to another in the bundle, including circular references where resources refer to each other. Where a resource is not assigned a persistent identity that can be used in the Bundle, a UUID should be used (urn:uuid:...). Server will process all urn:uuid and assigns a new id to a resource, it also updates any references to that resource in the bundle as they are processed. References to resources that are not part of the bundle are left untouched. Elements of type canonical are not replaced.

In the case of a transaction, server either accept all actions and return a 200 OK, along with a response bundle, or reject all resources and return an HTTP 400 response. A resource can only appear in a transaction once (by identity).

Because of the rules that a transaction is atomic where all actions pass or fail together and the order of the entries doesn't matter, there is a particular order in which to process the actions:

• Process any DELETE interactions
• Process any POST interactions
• Process any PUT or PATCH interactions
• Process any GET or HEAD interactions
• Resolve any conditional references

Conditional References

When constructing the bundle, the client might not know the logical id of a resource, but it may know identifying information - e.g. an identifier. This situation arises commonly when building transactions from v2 messages. The client could resolve that identifier to a logical id using a search, but that would mean that the resolution to a logical id does not occur within the same transaction as the commit (as well as significantly complicating the client). Because of this, in a transaction (and only in a transaction), references to resources may be replaced by a search URI that describes how to find the correct reference:

  "subject": {
    "reference": "Patient?identifier=1234567890"
}