--- type: "doc" source: "source/async.html" --- \[%settitle Asynchronous patterns%\] \[%file newheader%\] \[%file newnavbar%\] ## Asynchronous Request Patterns | Responsible Owner: [\[%wgt fhir%\]]([%wg fhir%]) Work Group | [Standards Status](versions#std-process): [Informative](versions#std-process) | | --- | --- | ### Use Case All of the interactions defined in the [RESTful API](http) 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](http://hl7.org/fhir/uv/bulkdata/export.html), where simple searches may result in large amounts of data. The asynchronous request patterns, based on [rfc 7240](https://tools.ietf.org/html/rfc7240#section-4.1), cater to this use case and can be used for FHIR [Defined Interactions](http) and [Operations](operations). ### Patterns FHIR defines two asynchronous patterns: - [Asynchronous Bulk Data Request](https://build.fhir.org/ig/HL7/api-incubator/async-bulk.html) - for use in FHIR [Operations](operations) and [Defined Interactions](http) that return a large amount of data. This pattern returns a manifest with links to data files containing FHIR resources. - [Asynchronous Interaction Request](https://build.fhir.org/ig/HL7/api-incubator/async-bundle.html) - for use in FHIR [Operations](operations) and [Defined Interactions](http) 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](bundle). For now, these patterns are defined in the [API Incubator](https://build.fhir.org/ig/HL7/api-incubator) while the details are finalised through implementation testing. ### Conformance Operations can declare as part of their definition whether they will be performed synchronously, asynchronously, or either. (See [OperationDefinition.synchronicity](operationdefinition-definitions#OperationDefinition.synchronicity)) Systems can also declare whether specific operations or interactions will be handled synchronously, asynchronously, or a mixture of them with [synchronicity extensions]([%extensions-location%]StructureDefinition-synchronicity-control) in their CapabilityStatements.) \[%file newfooter%\]