Informative only. Please contact info@twiin.nl if you are implementing this exchange pattern.
For this use-case the exchange pattern Index pull via SOAP is used. Below you will find the description of this exchange pattern.
Original page can be found at: TTA SOAP - Pull - Indexed Pull
Doel: Deze TTA beschrijft en specificeert de technische verantwoordelijkheden voor partijen die aansluiten op de Indexed Pull, 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: In ontwikkeling - nog niet compleet.
Planning voor opname in Twiin: Nog niet bepaald.
(Verwachte) impact: Gemiddeld. De TTA sluit aan op bestaande IHE-implementaties, maar vereist van GtK-applicaties 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
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’ 10.6.3 | Patient Consent - 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 10.6.3 | Patient Consent - 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 |
|
4 optional |
ZORG-AB replies to this request with the endpoints |
|
|
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 |
|
6 optional |
The responding GtK then checks if the patients permission is in check at MITZ 10.6.3 | Patient Consent - Mitz Transacties - OTV-TR-00040 |
|
|
7 optional |
A response is sent back 10.6.3 | Patient Consent - 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. 10.5.7 | IHE ITI-38 | Cross Gateway Query 10.5.7.1 | 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. |
|
10 option |
(see step 6) 10.6.3 | Patient Consent - Mitz Transacties - OTV-TR-00040 |
|
|
11 option |
(see step 7) 10.6.3 | Patient Consent - 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 10.5.8 | IHE ITI-39 | Cross Gateway Retrieve 10.5.8.1 | 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. |
|
14 option |
The images are sent back in the requested format |
|
|
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. 10.5.9 | IHE RAD-75 | Cross Gateway Retrieve Imaging Document Set |
|
|
16 required |
The images are sent back 10.5.9 | IHE RAD-75 | Cross Gateway Retrieve Imaging Document Set |
⬅️ 10.3 | Kern Volume 1a - Technical Agreements - CP
10.3.1.1 Notified Pull - Data interactions ➡️