Section

Step

Description

Invite the Receiving Organization

1

If the Notified Pull is part of a managed workflow involving both the Sending Organization and the Receiving Organization, and this workflow specifies the creation of a FHIR Task “Workflow Task” at the Sending System, then the flow starts with a creation of this Task on the Sending System.

2

The Sending System creates an authorization base, which is used later to communicate a presumed consent for the exchange of patient information. The Receiving System must treat the authorization base as an opaque element. The Receiving System should not depend on any information contained in the authorization base.

3

The Sending System creates one or two assertions, which can be used to request an access token in the next step.

4-5

The Sending System requests an access token which can be used in step 6. The Receiving System processes the token request and returns a token response containing (among others) an access token. The Sending System must treat the access token as opaque. The Sending System should not depend on any information contained in the access token.

6-7

By invoking a create interaction regarding a FHIR Task (“Notification Task”) on the Receiving System, the Sending System invites the Receiving System to perform one or more Pull interactions. The Receiving System processes the invitation and sends a technical response to complete the create interaction.

Notification about updated data by Sending Organization

8

The Sending System repeats steps 3-5.

9-10

The Sending System updates the Notification Task on the Receiving System using the create interaction. The Receiving System returns a technical response message.

Cancellation by Sending Organization

11-12

The “Cancellation by Sending Organization” option provides a means for the Sending System to cancel/revoke an erroneously created Notification.

Depending on the implementation at the Sending Organization, the Sending System might have to start the cancellation by revoking the authorization base created in step 2, by sending a revocation request to the Sending Organization’s Authorization Server. The Authorization Server processes the request and returns a response.

13

The Sending System repeats steps 3-5.

14-15

The Sending Organization informs the Receiving Organization by updating the Notification Task on the Receiving System (Task.status is set to “cancelled”). The Receiving System returns a technical response message.

Receiving Organization performs Pull interaction(s)

16

The Receiving System creates one or two assertions, which can be used to request an access token in the next step.

17-19

The Receiving System requests an access token which can be used to perform the intended Pull interactions. The Sending Organization’s Authorization Server processes the token request and returns a token response containing (among others) an access token. Depending on the Sending System implementation, the Sending System can choose to verify the consent before issuing an access token (preferred option).

The Receiving System must treat the access token as an opaque element. The Receiving System should not depend on any information contained in the access token.

20-23

The Receiving System initiates the intended interactions and processes the responses. The Sending System verifies the access token and can additionally decide to verify the authorization base at this point in the flow.

24-27

In case the Notification Task indicates that a Workflow Task is available that contains (additional) Pull interactions to be performed, the Receiving System obtains this Workflow Task from the Sending System.

28-31

The Receiving System initiates the (additional) Pull interactions listed in the Workflow Task, and processes the responses.