10.2.3 | TTA FHIR - Notified pull

This Twiin Technical Agreement (TTA) describes and specifies technical responsibilities to which parties agree when connecting to exchange transactions to facilitate the Notified Pull. This TTA is based on the TA Notified Pull, with the normative specifications remaining unchanged. The informative specifications however have been described with a specific implementation.

The possibility to exchange a patient's medical record is for example required in case of a patient referral or transfer. When different healthcare organizations are involved in a patient’s treatment plan, attention should be paid to the required legal permission and the possible ‘burden’ for the Receiving System when a medical record is transferred.

Relation to other documents

This document is written with the following documents as reference:

Nictiz - Informatiestandaard BgZ MSZ
TA Notified Pull v0.99

Format

The format of this section follows the main interactions as presented below in the simplified sequence diagram of the Notified Pull sequence.

Interaction numbers 1 and 3 are described in the 10.2.5 | TTA FHIR - Authentication & Authorization. Interaction number 2 is described in https://vzvz.atlassian.net/wiki/spaces/Twiin/pages/331847058/10.2.3.1+%7C+Notified+Pull+-+Data+interactions . A part of interaction number 4 is also described in https://vzvz.atlassian.net/wiki/spaces/Twiin/pages/331847058/10.2.3.1+%7C+Notified+Pull+-+Data+interactions, for specifics of the context of the Notified Pull see Nictiz information standards.

The sequence diagram below provides a complete sequence diagram that covers both the resource interactions and the authorization interactions of the complete Notified Pull interaction sequence.

The Twiin specific solutions for identification and addressing can be found in 10.2.5 | TTA FHIR - Authentication & Authorization and 10.2.8 | TTA - Addressing respectively.

Sequence diagram

The sequence diagram below visualizes the full flow for the Notified Pull interaction sequence including both interactions in the data layer using HL7 FHIR (described in 10.2.3.1 Notified Pull - Data interactions) and in authorization layer using OAuth 2.0 (marked cyan, described in 10.2.10 | Netwerk level security mTLS 1.3).

Each section consists of several steps. The steps correspond to the numbers in the sequence diagram.

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.
Notification about updated data by Sending Organization	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.