This page is part of the FHIR Specification v6.0.0-ballot3: Release 6 Ballot (3rd Draft) (see Ballot Notes). The current version is 5.0.0. For a full list of available versions, see the Directory of published versions

3.2.6.0 Asynchronous Request Patterns

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

3.2.6.0.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.0.2 Patterns

FHIR supports 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.

3.2.6.0.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.)