This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

3.2.6 Asynchronous Request Patterns

Responsible Owner: FHIR Infrastructure Work Group

Standards Status: Informative

3.2.6.1 Use Case

All of the interactions defined in the RESTful API are described as synchronous operations - that is, the client makes a query and waits for the server to respond with the outcome in the HTTP response. This pattern is not always suitable when significant server side processing is necessary or when substantial amounts of data must be returned.

A good example of this is the $export operation , where simple searches may result in large amounts of data.

The asynchronous request patterns, based on rfc 7240 , cater to this use case and can be used for FHIR Defined Interactions and Operations.

3.2.6.2 Patterns

FHIR defines two asynchronous patterns:

• Asynchronous Bulk Data Request - for use in FHIR Operations and Defined Interactions that return a large amount of data. This pattern returns a manifest with links to data files containing FHIR resources.
• Asynchronous Interaction Request - for use in FHIR Operations and Defined Interactions that are not processed synchronously or may take a lot of time to process. For example, a server that accepts a high volume of sensor data and queues it for saving, or an operation that re-indexes the data in a server to add a new search parameter. This pattern returns a Bundle Resource.

For now, these patterns are defined in the API Incubator while the details are finalised through implementation testing.

3.2.6.3 Conformance

Operations can declare as part of their definition whether they will be performed synchronously, asynchronously, or either. (See OperationDefinition.synchronicity)

Systems can also declare whether specific operations or interactions will be handled synchronously, asynchronously, or a mixture of them with synchronicity extensions in their CapabilityStatements.)