10.3.2 | TTA SOAP - Indexed Pull (IHE)

Doel: Deze TTA beschrijft en specificeert de technische verantwoordelijkheden voor partijen die het communicatiepatroon Geïndexeerde bevraging (Indexed Pull) inzetten voor een koppelvlak op basis van IHE XCA-profielen (ITI-38, ITI-39, RAD-75). De afspraak borgt gestandaardiseerde uitwisseling van medische data tussen GTK-applicaties, met inzet van Mitz voor toestemming en ZORG-AB voor adressering.

Status: gereed, m.u.v. (tijdelijke) afspraken over authenticatie passend binnen het wettelijk kader.

Planning voor opname in Twiin: VWS wil het kader voor de invulling van authenticatie (zie ook 10.3.1 | TTA FHIR - Harmonized Notified Pull (v2.x)) voor de zomer 2026 opleveren. Het streven van Twiin is voor het einde van 2026 de TTA Indexed Pull toe te kunnen voegen aan het Twiin Afsprakenstelsel.

(Verwachte) impact: Gemiddeld. De TTA sluit aan op bestaande IHE-implementaties, maar vereist van GTK’s aanpassingen voor de integratie met Mitz (open en gesloten bevraging) en ZORG-AB (endpoint-opvraging), alsmede ondersteuning van SAML-tokens conform de Twiin-specificaties.

Benodigde acties voor opname Twiin Afsprakenstelsel: Het maken van tijdelijke afspraken rondom authenticatie die zijn toegestaan door VWS, passend binnen de huidige overgangssituatie ten aanzien van UZI en de transitie naar DEZI-conforme middelen.


This Twiin Technical Agreement (TTA) describes and specifies technical responsibilities to which parties agree when connecting to exchange transactions to facilitate the Indexed Pull.

The Indexed Pull starts with several transactions required to locate where data is to be retrieved, as well as the required endpoints where this data can be retrieved.

MITZ localization and consent are used, and Zorg-AB is deployed to retrieve endpoints. The goal is to move toward this approach in a later version of the Twiin Technical Agreement. The transactions are already shown for reference.

MITZ, Steps 1 and 2

This concerns the “Open Query,” which performs an initial check to determine where data can be requested. This prevents so-called over-querying. Twiin Participants are responsible for ensuring that when a healthcare provider requests data, only Twiin Participants known to have data available are queried. A Twiin Participant will be expected to demonstrate that this is being done; however, how this is achieved is currently outside the scope of Twiin.

Zorg-AB, Steps 3 and 4

This concerns retrieving the actual endpoint of the Twiin Participant after a response has been received in Step 2 indicating that data is available. Twiin Participants will be required to make known the endpoint at which another Twiin Participant can request available data and are obligated to notify all other Twiin Participants if this endpoint changes.

MITZ, Steps 6, 7, 10, and 11

This concerns the “Closed Query,” in which the Twiin Participant from whom the data is requested performs the consent check. It is the responsibility of the Twiin Participant to verify patient consent and to be able to demonstrate how this mechanism works. How this must function is currently outside the scope of Twiin.

Sequence diagram

The sequence diagram below visualizes the full flow for the Indexed Pull interaction sequence.

Twiin describes the transaction between the GTK applications, applications behind these GTK applications can communicate with a GTK in any way they want, provided that the GTK uses the transactions shown in this diagram


image-20231019-140550.png


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

Section

Step

Description

Authorisation (Open)

1 optional

Before initiating the retrieval of the Timeline data, a XIS behind the Initiating GTK sends a request to this GTK.

After this request is recieved the GTK first sends an ‘open’ authorisation request to the Public Service know as ‘MITZ’

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties - OTV-TR-00020

2 optional

This request is replied to by MITZ, in this request, the GTK’s where data is available, are given back to the Initiating GTK

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties - OTV-TR-00030

Localisation

3 optional

After the GTK ‘knows' where available data can be retrieved, the Initiating GTK then requests the endpoints at the Public Service know as ZORG-AB

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-zorg-ab-transacties

4 optional

ZORG-AB replies to this request with the endpoints

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-zorg-ab-transacties

Retrieve Timeline data

5 required

Using the endpoints the GTK uses this information to send the query. With this transaction a SAML token is included

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-38

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-38-examples#ITI-38-request

6 optional

The responding GTK then checks if the patients permission is in check at MITZ

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties - OTV-TR-00040

7 optional

A response is sent back

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties - OTV-TR-00050

8 required

After the ‘closed authentication’ transaction is done, the Responding GTK retrieves the metadata at the XIS(es) connected with the Responding GTK and sends this back to the Initiating Gateway.

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-38

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-38-examples#ITI-38-response

The Initiating GTK bundles the replies of the one or more Responding GTK’s and sends this back to the XIS application originally requesting the data from the Initiation Request. A Timeline can now be built using this data in the XIS

Retrieve Document

9 required

Using the Timeline data, a request for a document can now be done from within the XIS (Consumer, connected to the Initiating GTK).

The XIS then sends this request to the Initiating GTK.

The Initiating GTK then sends a request including a SAML token to the Responding GTK where the XIS (Source, connected to the Responding GTK) is behind and the requested document is available.

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-39

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-39-examples#ITI-39-request

10 option

(see step 6)

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties - OTV-TR-00040

11 option

(see step 7)

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties - OTV-TR-00050

12 required

After the ‘closed authentication’ transaction is done, the Responding GTK retrieves the document from the XIS where this document is available and sends this back to the Initiating Gateway

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-gf-mitz-transacties

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-iti-39-examples#ITI-39-response

The Initiating Gateway on its turn returns this document to the XIS from where the document is requested from.

Rendering Images

13 option

the WADO-WS transaction can be used by a Requesting GTK to retrieve DICOM images in a different format and resolution.

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-twiin-06-wado-ws

14 option

The images are sent back in the requested format

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-twiin-06-wado-ws

Retrieving Images

15 required

It is also possible the request is done for images instead of documents. Prior to this transaction a KOS object is retrieved using steps 9-12. Using the information in the retrieved KOS object images can be requested.

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-rad-75

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-rad-75-examples#RAD-75-request


16 required

The images are sent back https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-rad-75

https://afsprakenstelsel.twiin.nl/twiin-kern-trans-cp-ihe-rad-75-examples#RAD-75-response