Z1.2.1.1 | BgZ - data interactions
Original page can be found at: 10.2.3.1 Notified Pull - Data interactions
This chapter describes all relevant interactions for the Notified Pull interaction sequence on data level.
Notified pull interaction sequence
All relevant interactions for the Notified Pull interaction sequence on data level are displayed in the sequence diagram below.
Description of the interactions in this sequence diagram:
Steps | Description |
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 “Workflow Task” at the Sending System, then the flow starts with a creation of this Task on the Sending System. See Notification Task vs Workflow Task for additional details. |
2-3 | The Sending System invites the Receiving System to perform one or more Pull interactions (FHIR requests) by sending a FHIR Task resource (“Notification Task” ) to the Receiving System using a FHIR create interaction. The Receiving System processes the invitation and sends a technical response to complete the create interaction. See 10.3.1 | Twiin-01 | Send Notification Task for a detailed description. |
4-5 | When the data set for which a Notification message has been sent is updated in the Sending System, the Sending System must inform the Receiving System about this update by sending a new Notification Message. The Receiving System processes the invitation and sends a technical response to complete the create interaction. See 10.3.1 | Twiin-01 | Send Notification Task for a detailed description. |
6-7 | The “Cancellation by Sending Organization” option provides a means for the Sending System to cancel or revoke an erroneously created Notification. The Sending System communicates the cancellation to the Receiving System by sending an updated Notification Task to the Receiving System using a FHIR conditional update interaction. The Receiving System processes the interaction and sends a technical response to complete the conditional update interaction. See 10.3.2 | Twiin-02 | Cancel Notification Task for a detailed description. |
8-9 | The Receiving System extracts the intended FHIR requests from the Notification Task listed in Task.input:read-available-resource and Task.input:query-available-resources. Subsequently, the Receiving system initiates these FHIR requests and processes the responses. See 10.3.5 | Twiin-05 | Retrieve Resource for a detailed description for the retrieval of resources referenced in Task.input:read-available-resources. See 10.3.4 | Twiin-04 | Search Resource(s) for a detailed description for the retrieval of resources referenced in Task.input:query-available-resources. |
10-11 | In case that the Notification Task contains an indication that there is a Workflow Task at the Sending System that contains additional FHIR requests (i.e. when Task.input:get-worflow-task.valueBoolean is true), the Receiving System requests the Workflow Task at the Sending System. |
12-13 | The Receiving System extracts the intended FHIR requests from the Workflow Task. Subsequently, the Receiving system initiates these FHIR requests and processes the responses. See 10.3.5 | Twiin-05 | Retrieve Resource for a detailed description for the retrieval of resources referenced in Task.input:read-available-resources. See 10.3.4 | Twiin-04 | Search Resource(s) for a detailed description for the retrieval of resources referenced in Task.input:query-available-resources. |
Notification Task vs Workflow Task
The FHIR Task resource used in the Notification payload is not meant to track the status of a workflow or healthcare process that initiated the data exchange. When the data that is exchanged using the Notified Pull pattern serves for instance a patient referral or transfer, the status of that process should be tracked using a separate FHIR Task resource that is maintained and hosted by the initiator of that process, i.e. the Sending System. To keep a clear distinction between these two Task resources, the Task resource used as Notification payload is referred to as the “Notification Task”, while the Task resource that is used to track a healthcare process or workflow is referred to as a “Workflow Task”. The Notification Task is sent from the Sending System to the Receiving System using a Push interaction (HTTP POST or PUT), while the Workflow Task is hosted at the Sending System, and can be requested by the Receiving System using a Pull interaction.
The use of a Notification Task as Notification payload does not require the presence of a Workflow Task, but when a Notification Task is sent in the context of a workflow that is maintained by the initiator of that workflow using a Workflow Task, the Notification Task MUST contain a reference to that Workflow Task.
Availability of BSN
For correct handling the BSN should be available as soon as possible, when this is legally required. The Sending System has two possibilities:
The BSN is sent in the authorization assertion used in the access token request before sending the Notification Task.
The BSN is made available through the Workflow Task resource which is referenced in the basedOn attribute of the Notification Task resource. The Workflow Task resource must have a for reference with the identifier filled with the BSN.
The Receiving System must support both. Since both variants are possible for the Sending System to use, both must be supported by the Receiving System, to be able to process from any Sending System.