--- version: "TA150" language: "nl" --- # Twiin Afsprakenstelsel 1.5.0 Dit is de actuele normatieve versie van het Twiin Afsprakenstelsel. De voorlaatste versie is te vinden via 2026-05-28 Dit is de vastgestelde release 1.5.0 voor publicatie. ## Wat is het Twiin Afsprakenstelsel? Het Twiin Afsprakenstelsel is een set samenwerkingsafspraken voor het delen en beschikbaar maken van gezondheidsgegevens; veilig en betrouwbaar, tussen zorgaanbieders, zorgnetwerken en voorzieningen. Het stelsel bevat afspraken voor zorgaanbieders en hun dienstverleners en leveranciers.​ ### Opbouw Twiin Afsprakenstelsel Het afsprakenstelsel bevat afspraken op alle lagen van het interoperabiliteitsmodel. Het afsprakenstelsel is onderverdeeld in een generiek deel en een specifiek deel met daarin de zorgtoepassingen. Het generieke deel bevat alle afspraken die van toepassing zijn op alle zorgtoepassingen. Het generieke deel van het Twiin Afsprakenstelsel bevat onder andere het vertrouwensmodel en een technische kern. Het vertrouwensmodel is een essentieel onderdeel van het Twiin Afsprakenstelsel en is de basis voor veilige en betrouwbare landelijke elektronische uitwisseling en beschikbaarheid van medische gegevens. Het vertrouwensmodel beschermt het beroepsgeheim van de zorgverlener en de privacy van de cliënt bij de uitwisseling van gezondheidsgegevens, ook al vindt deze uitwisseling tussen knooppunten van verschillende infrastructuren plaats. De technische kern bevat generieke communicatiepatronen die ingezet kunnen worden voor één of meer zorgtoepassingen. Het specifieke deel van het afsprakenstelsel bevat de implementatiewijzers voor de implementatie van specifieke zorgtoepassingen. Er is ruimte om het specifieke deel uit te breiden met implementatiewijzers van nieuwe zorgtoepassingen. Hierbij geldt telkens als eis dat de implementatiewijzer de afspraken volgt die zijn opgenomen in het generieke deel. #### Landelijk afsprakenstelsel voor gezondheidsgegevens Veilige, betrouwbare én efficiënte gegevensuitwisseling tussen alle zorgsectoren is alleen mogelijk als er eenduidige, landelijke afspraken zijn. Nu al bestaan verschillende afsprakenstelsels voor gegevensuitwisseling binnen en tussen diverse sectoren. Het Ministerie van Volksgezondheid, Welzijn en Sport heeft Twiin [aangewezen](https://www.datavoorgezondheid.nl/onderwerpen/l/landelijk-afsprakenstelsel) als Landelijk afsprakenstelsel voor gezondheidsgegevens. Het Twiin Afsprakenstelsel vormt het fundament van waaruit de komende jaren wordt toegewerkt naar [één centrale plek](https://www.twiin.nl/landelijk-afsprakenstelsel-voor-gezondheidsgegevens) voor geharmoniseerde, generieke afspraken. --- version: "TA150" language: "nl" --- # 1.1 \| Doelgroepen **Relevante onderdelen afsprakenstelsel per doelgroep** In dit hoofdstuk is per doelgroep aangegeven welke onderdelen van het Twiin Afsprakenstel vooral relevant zijn. | ****Doelgroep**** | ****Rol**** | ****Relevante onderdelen**** | | **Zorgaanbieders** | Bestuurders | [3 \| Missie, visie en doelstellingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/3-visie.md) [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [6 \| Governance](https://afsprakenstelsel.twiin.nl/normatief/ta150/6-governance.md) | | | ICT Management | [2 \| Release-informatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/2-release-informatie.md) [3 \| Missie, visie en doelstellingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/3-visie.md) [4 \| Architectuur](https://afsprakenstelsel.twiin.nl/normatief/ta150/4-architectuur.md) [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [6 \| Governance](https://afsprakenstelsel.twiin.nl/normatief/ta150/6-governance.md) [8 \| Diensten](https://afsprakenstelsel.twiin.nl/normatief/ta150/8-diensten.md) [9 \| Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/9-voorwaarden.md) [Twiin Implementatiewijzer Zorgtoepassingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/twiin-implementatiewijzer-zorgtoepassingen.md) | | | Juristen | [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [6 \| Governance](https://afsprakenstelsel.twiin.nl/normatief/ta150/6-governance.md) [7 \| Juridische context](https://afsprakenstelsel.twiin.nl/normatief/ta150/7-juridische-context.md) [9 \| Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/9-voorwaarden.md) | | | Security \& Privacy officers | [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [7 \| Juridische context](https://afsprakenstelsel.twiin.nl/normatief/ta150/7-juridische-context.md) [9 \| Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/9-voorwaarden.md) [10 \| Technische kern](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-technische-kern-1-2-0.md) | | | Projectleiders | [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [8 \| Diensten](https://afsprakenstelsel.twiin.nl/normatief/ta150/8-diensten.md) [Twiin Implementatiewijzer Zorgtoepassingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/twiin-implementatiewijzer-zorgtoepassingen.md) | | | Architecten, Ontwerpers, Beheerders | [2 \| Release-informatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/2-release-informatie.md) [4 \| Architectuur](https://afsprakenstelsel.twiin.nl/normatief/ta150/4-architectuur.md) [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [9 \| Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/9-voorwaarden.md) [10 \| Technische kern](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-technische-kern-1-2-0.md) [Twiin Implementatiewijzer Zorgtoepassingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/twiin-implementatiewijzer-zorgtoepassingen.md) | | **Zorgverleners** | | [3 \| Missie, visie en doelstellingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/3-visie.md) [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) | | **Cliënten** | | [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) | | **Leveranciers** | | [4 \| Architectuur](https://afsprakenstelsel.twiin.nl/normatief/ta150/4-architectuur.md) [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [9 \| Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/9-voorwaarden.md) [10 \| Technische kern](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-technische-kern-1-2-0.md) [Twiin Implementatiewijzer Zorgtoepassingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/twiin-implementatiewijzer-zorgtoepassingen.md) | | **Regio's** | | [4 \| Architectuur](https://afsprakenstelsel.twiin.nl/normatief/ta150/4-architectuur.md) [5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) [8 \| Diensten](https://afsprakenstelsel.twiin.nl/normatief/ta150/8-diensten.md) [9 \| Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/9-voorwaarden.md) [10 \| Technische kern](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-technische-kern-1-2-0.md) | | **Overig** | | [2 \| Release-informatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/2-release-informatie.md) [3 \| Missie, visie en doelstellingen](https://afsprakenstelsel.twiin.nl/normatief/ta150/3-visie.md)[5 \| Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-vertrouwensmodel.md) | |--------------------|-------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| --- version: "TA150" language: "nl" --- # 1.2 \| Begrippen **Algemene begrippen** Het Twiin Afsprakenstelsel volgt de begrippen uit toepasselijke wet- en regelgeving. Waar mogelijk sluit het Twiin Afsprakenstelsel aan bij begrippen uit de [DIZRA (Duurzaam Informatiestelsel in de Zorg Referentie Architectuur)](https://dizra.gitbook.io/dizra) en de [Nationale Visie en Strategie (NVS)](https://www.datavoorgezondheid.nl/nationale-visie-en-strategie/visie). **Twiin-begrippenlijst** In de Twiin-begrippenlijst zijn enkel Twiin-specifieke begrippen opgenomen. * [Begrip: Afsprakenstelsel](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-afsprakenstelsel.md) * [Begrip: Beheerovereenkomst](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-beheerovereenkomst.md) * [Begrip: Bewijs van Validatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-bewijs-van-validatie.md) * [Begrip: Deelnemersovereenkomst](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-deelnemersovereenkomst.md) * [Begrip: Dienstverleningsovereenkomst](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-dienstverleningsovereenkomst.md) * [Begrip: Dossierhouder](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-dossierhouder.md) * [Begrip: Dossierontvanger](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-dossierontvanger.md) * [Begrip: Dossierraadpleger](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-dossierraadpleger.md) * [Begrip: GTK](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-gtk.md) * [Begrip: GTK Beheerder](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-gtk-beheerder.md) * [Begrip: GTK Leverancier](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-gtk-leverancier.md) * [Begrip: Gemeenschappelijke voorziening](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-gemeenschappelijke-voorzieningen.md) * [Begrip: Governance](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-governance.md) * [Begrip: Incident](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-incident.md) * [Begrip: Regio](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-regio.md) * [Begrip: Samenwerkingsvoorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-samenwerkingsvoorwaarden.md) * [Begrip: Servicedesk Twiin Deelnemer](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-servicedesk-twiin-deelnemer.md) * [Begrip: Tijdlijn](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-tijdlijn.md) * [Begrip: Twiin Beheerorganisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-beheerorganisatie.md) * [Begrip: Twiin Bestuur](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-bestuur.md) * [Begrip: Twiin Casemanager](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-casemanager.md) * [Begrip: Twiin Deelnemer](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-deelnemer.md) * [Begrip: Twiin Dienstverlener](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-dienstverlener.md) * [Begrip: Twiin Organisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-organisatie.md) * [Begrip: Twiin Samenwerkingsverband](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-samenwerkingsverband.md) * [Begrip: Twiin Serviceportaal](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-serviceportaal.md) * [Begrip: Twiin Vertrouwensmodel](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-vertrouwensmodel.md) * [Begrip: Twiin Voorwaarden](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-twiin-voorwaarden.md) * [Begrip: Verklaring GTK Beheerder](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-verklaring-gtk-beheerder.md) * [Begrip: Verklaring GTK Leveranciers](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-verklaring-gtk-leveranciers.md) * [Begrip: Verklaring Twiin Dienstverlener](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-verklaring-twiin-dienstverlener.md) * [Begrip: Zorgtoepassing](https://afsprakenstelsel.twiin.nl/normatief/ta150/begrip-zorgtoepassing.md) --- version: "TA150" language: "nl" --- # 1.3 \| Schrijfwijze van objecten Twiin bevat in de verschillende hoofdstukken objecten zoals afspraken, eisen, specificaties en richtlijnen. Om deze op een heldere, eenduidige en juridisch duidelijke manier te duiden voor de Twiin Deelnemer, Twiin Dienstverlener en GTK Leverancier en GTK Beheerder wordt gebruik gemaakt van [RFC 2119](https://www.rfc-editor.org/info/rfc2119/). Dit is een richtlijn die vastlegt hoe woorden als MOET (MUST), ZOU MOETEN (SHOULD) en MAG (MAY) moeten worden geïnterpreteerd. ## Vereiste-niveaus | **RFC 2119-term** | **Nederlandse term** | **Interpretatie** | |------------------------------|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | MUST / REQUIRED / SHALL | MOET / VERPLICHT / ZAL | Een absolute vereiste. | | MUST NOT / SHALL NOT | MAG NIET / ZAL NIET | Een absoluut verbod. Binnen Twiin is het omschrevene niet toegestaan. | | SHOULD / RECOMMENDED | ZOU MOETEN / AANBEVOLEN | Dit is een algemene vereiste die ondersteund zou moeten worden. Er kunnen valide redenen zijn om een onderdeel wel verplicht te stellen. Zo kan een vereiste worden versterkt bij een (zorg)toepassing in Twiin. Een eis met het niveau 'ZOU MOETEN' kan binnen de BgZ wel degelijk noodzakelijk zijn. | | SHOULD NOT / NOT RECOMMENDED | ZOU NIET MOETEN / NIET AANBEVOLEN | Dit is ongewenst, tenzij er een valide reden is om het in een specifiek geval toe te laten. | | MAY / OPTIONAL | MAG / OPTIONEEL | Een vrije keuze, een optie. | ## Meta-model voor objecten Objecten die zijn opgenomen in Twiin kennen verschillende attributen om helderheid te geven over hoe en waar ze van toepassing zijn. De attributen zijn alleen zichtbaar als ze relevant zijn en een waarde hebben. | **Attribuut** | **Toelichting** | **Waardes** | |---------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ID | De codering van objecten helpt om ze vindbaar en overzichtelijk te maken. Twiin-objecten (TW) zijn geschreven volgens onderstaande logica: TW-CATEGORIE-SUBCATEGORIE-VOLGNUMMER. | Waar een categorie bijvoorbeeld een communicatiepatroon (P) of generieke functie (F) kan zijn en een subcategorie een specifieke functie daarbinnen, zoals Netwerkbeveiliging (NB). | | Naam | De naam van het object. | | | Soort | Dit geeft aan wat voor soort object het betreft. | Eis Specificatie Richtlijn Afspraak | | Status | Dit attribuut geeft de status van het object weer: * Is een object, zoals een eis geldend? Dan heeft het de status 'Normatief'. * Is het nog onderdeel in één van de fases van ontwikkeling en toetsing, dan kan het de status 'Trial', 'Candidate', 'Draft' of 'Informative' bevatten. * Is een object niet (meer) geldig, dan kent het de status 'Uitgefaseerd' of 'Vervallen'. | Uitgefaseerd Normatief Trial Candidate Draft Informative Vervallen | | Omschrijving | Omschrijving van het object met vereiste-niveau in de lopende tekst. | | | Toelichting | Toelichting op het object met mogelijk aanvullende eisen, maatregelen en best practices. | | | Vereiste | Deze waarde geeft het vereiste-niveau aan van het object. Zie hiervoor 'Vereiste-niveaus'. | MOET ZOU MOETEN MAG NIET ZOU NIET MOETEN MAG | | Implicatie bij toepassing | Aanvullende informatie wanneer het object onderdeel is van een (zorg)toepassing, zoals BgZ. Als aanvullende informatie beschikbaar is, zal dit attribuut zichtbaar zijn. | | | Rol | Niet elk object is van toepassing bij elke rol. Het atribuut 'rol' geeft duiding aan wie dit dient te ondersteunen of implementeren. | GTK GTK Beheerder Twiin Organisatie Twiin Deelnemer Twiin Dienstverlener | | Bedrijfsrol | Bij een toepassing kunnen ook aanvullende rollen betrokken zijn. Deze worden weergegeven via dit attribuut. | Nieuwe behandelaar Verwijzer Dossierhouder | | Functie (F) | Dit attribuut geeft aan op welke generieke functie het object betrekking heeft. | Identificatie Authenticatie Autorisatie Behandelrelatie Toestemming Logging Adressering Localisatie Transparantie Netwerkbeveiliging Routering | | Patroon (P) | Dit attribuut geeft aan op welk communicatiepatroon het object betrekking heeft. | Notified Pull Pull Indexed Pull Push | | Actor | Dit attribuut geeft aan op welke actor het object betrekking heeft. | GTK Ontvanger GTK Verzender EPD Ontvanger EPD Verzender | | Toepassing (T) | Dit zijn objecten die voor een specifieke toepassing gelden. | BgZ Beelden Correspondentie | | Referenties | Dit betreft verwijzingen binnen en buiten het stelsel, gerelateerd aan het object. | | | Toetsingscategorie | Vindt er een vorm van toetsing zoals validatie en kwalificatie plaats en zo ja, bij wie? | Geen Via Twiin Via programma Via (kwaliteits)richtlijn Via Nictiz Via NTV | | Toetsingsvorm | Op welke wijze wordt dit object getoetst: * Technische toets * Functionele toelichting * Zelfverklaring * (keten)test bij implementatie * Externe verklaring, zoals bijvoorbeeld voor NEN 7510 'Verklaring van Toepasselijkheid'. | Technisch Functioneel Zelfverklaring (Keten)test Externe verklaring | | Niveau | Een object kan op verschillende niveaus gelden: * Specifiek: Het betreft een afgebakend object binnen Twiin, zoals een (zorg)toepassing. * Generiek: Het betreft een object die van toepassing is door Twiin heen, en geldt voor alle onderliggende onderdelen. * Landelijk: Dit betreft een landelijk object, zoals afspraken, eisen en specificaties waar stelsels naar kunnen verwijzen. | Specifiek Generiek Landelijk | --- version: "TA150" language: "nl" --- # 1.4 \| Afsprakenstelsel als download Het Twiin Afsprakenstelsel wordt openbaar op het internet gepubliceerd. Gebruikers kunnen daarmee eenvoudig naar de voor hen relevante onderdelen navigeren en hebben altijd de verschillende versies voorhanden. Toch liever een download van het Twiin Afsprakenstelsel? * De laatste publicatie is hier te downloaden als PDF: [Twiin Afsprakenstelsel 1.5.0-20260528c.pdf](https://afsprakenstelsel.twiin.nl/__attachments/a_d0a8eb3fcaaee7249f8dbb510026df604f159100257d0a0fa08cf8e5fe12ae37/Twiin%2520Afsprakenstelsel%25201.5.0-20260528c.pdf.md) * Daarnaast zijn de huidige eisen uit het stelsel te downloaden als Excel-sheet: [Twiin Afsprakenstelsel 1.5.0-eisen-20260528.xlsx](https://afsprakenstelsel.twiin.nl/__attachments/a_82e7aadea2b37f53e6216bb520d7ccff9ae6d40d37da85bc32c137f0faca927e/Twiin%2520Afsprakenstelsel%25201.5.0-eisen-20260528.xlsx.md?cb=d9c7260086b4e152098140415837b202) --- version: "TA150" language: "nl" --- # 1 \| Leeswijzer Het Twiin Afsprakenstelsel kent een logische opbouw. Onderstaand overzicht toont een overzicht van de verschillende onderdelen van het afsprakenstelsel. Centraal hierbij is het onderscheid tussen het generieke en het specifieke deel. In het hoofdstuk [Doelgroepen](https://afsprakenstelsel.twiin.nl/normatief/ta150/1-1-doelgroepen.md) is per doelgroep aangegeven welke onderdelen vooral relevant zijn. ## Opbouw Twiin Afsprakenstelsel ![Twiin-Opbouw.png](https://afsprakenstelsel.twiin.nl/__attachments/a_c6b07be6418e65c951b1755ed21a69a3b702c072de34a6b0d137fdc54b9aff95/Twiin-Opbouw.png?cb=534874b38b8122ae12cb162c2b10e218) --- version: "TA150" language: "nl" --- # PvE \| Toestemming Toelichting over de opgenomen attributen is te vinden onder [1.3 \| Schrijfwijze van objecten](https://afsprakenstelsel.twiin.nl/normatief/ta150/1-3-schrijfwijze-van-objecten.md). ## Generieke functie: Toestemming | **TW-F-T-001** | **Aansluiting op Mitz** | |------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Legacy code** | Toestemming-01 | | **Status** | Normatief | | **Omschrijving** | Een GTK ZOU een aansluiting op Mitz MOETEN hebben. | | **Toelichting** | Een GTK die uitwisselingen ondersteunt waar uitdrukkelijke toestemming voor nodig is, ZOU een Mitz Connector Aansluiting MOETEN ondersteunen. Op het moment dat de onderliggende bronsystemen zelf de controle op de toestemming voor gegevensuitwisseling uitvoeren, is er geen noodzaak voor het GTK om dit ook te doen. | | **Vereiste** | ZOU MOETEN | | **Functie** | Toestemming | | **Rol** | GTK | | **Referenties** | [Introductie](https://vzvz.atlassian.net/wiki/spaces/MA11/pages/828278059/Introductie) | | **Toetsingscategorie** | Geen | | **Niveau** | Generiek | --- version: "TA150" language: "nl" --- # 10.2.3 \| Generieke functie - Toestemming Wanneer (een onderdeel van) het medisch dossier door de bron alvast 'klaargezet' wordt voor een later (nog niet bekend) gebruik is er (ook) toestemming van de cliënt vereist, zie [7.1 \| Juridisch kader](https://afsprakenstelsel.twiin.nl/normatief/ta150/7-1-juridisch-kader.md) en [5.5 \| Vertrouwen: Toestemming](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-5-vertrouwen-patienttoestemming.md). De dossierhoudende zorgaanbieder is verantwoordelijk voor de controle op de toestemming. Deze cliënttoestemmingen worden vaak nog geregistreerd in het EPD van de zorgaanbieder en zijn vaak specifiek voor een uitwisselingsysteem. Het registreren hiervan is een administratieve last voor de zorgaanbieder. Daarnaast is het soms voor de cliënt niet duidelijk of overzichtelijk waar en waarvoor toestemming is gegeven. Mede om deze reden is de gemeenschappelijke voorziening [Mitz](https://www.mitz-toestemming.nl/)ontwikkeld, waar steeds meer zorgaanbieders op aansluiten. Mitz biedt de functionaliteit voor het vastleggen van toestemmingen aan de zorgaanbieder en maakt het mogelijk dat deze voor meerdere elektronische uitwisselingssystemen te gebruiken is. Daarnaast biedt Mitz de cliënt de functionaliteit om een overzicht te hebben van de alle zorgaanbieders waar een behandeling heeft plaatsgevonden en om toestemmingen te beheren. De transitie om de registratie van toestemmingen over te hevelen naar Mitz is inmiddels ingezet. Het Informatieberaad Zorg heeft Mitz in 2022 opgenomen als zogenaamde '[bouwsteen](https://www.informatieberaadzorg.nl/actueel/nieuws/2022/05/12/informatieberaad-zorg-kiest-voor-mitz-en-nuts) van de basisinfrastructuur' [\[1\]](https://vzvz.atlassian.net/wiki/spaces/Twiin/pages/270927008#footnote-Mitz) in het informatiestelsel in de zorg. Dit besluit geldt in ieder geval nog tot 2027 en wordt dan geëvalueerd. Dit besluit is ook opgenomen in het integraal zorg akkoord (IZA) [\[2\]](https://vzvz.atlassian.net/wiki/spaces/Twiin/pages/270927008#c55eaf6d-5bee-406f-a1d0-9edbfe75a1fc). Hieruit volgt dat Twiin voor Mitz een pas-toe-of-leg-uit-principe toepast. Voor de gegevensuitwisselingen die in Twiin worden ondersteund en waarvoor een uitdrukkelijke cliënttoestemming noodzakelijk is, volgt Twiin de hiervoor gemaakte afspraken dat Mitz gebruikt moet gaan worden (totdat er nieuwe landelijke afspraken over toestemming zijn gemaakt). *** ** * ** *** \[1\] De website van het Informatieberaad heeft het besluit niet meer direct beschikbaar. Het besluit is wel nog terug te vinden via nieuwsberichten en het archief van het Ministerie van VWS. * [https://archief25.sitearchief.nl/archives/sitearchief/20240624100213/https://www.informatieberaadzorg.nl/](https://archief25.sitearchief.nl/archives/sitearchief/20240624100213/https://www.informatieberaadzorg.nl/binaries/informatieberaad-zorg/documenten/vergaderstukken/2022/04/25/5a-oplegnotitie-opvolging-mitz-bouwsteen/5a+Oplegnotitie+Opvolging-Mitz-bouwsteen.pdf) * * * \[2\] "Zorgaanbieders verbinden zich aan de door VWS en in afstemming met het Informatieberaad Zorg vastgestelde oplossingen voor de 6 generieke functies (zoals Mitz en ZORG-AB) en implementeren deze uiterlijk 2025 met hun leveranciers ter ondersteuning van hun zorgprocessen." --- version: "TA150" language: "nl" --- # 10.2.6 \| Generieke functie - Lokalisatie Als uitwisseling plaatsvindt via een elektronisch uitwisselingssysteem zoals bedoeld in de Wabvpz, is het ook nodig om een functie in te richten voor lokalisatie. Dit kan via een gemeenschappelijke voorziening of door het vragen aan de cliënt Raadplegende zorgaanbieders mogen gegevens alleen opvragen bij andere zorgaanbieders waar de cliënt daadwerkelijk bekend is. Bijvoorbeeld: een brede uitvraag bij meerdere zorgaanbieder met de vraag of zij de cliënt toevallig kennen en gegevens beschikbaar hebben, is niet toegestaan. Hiermee wordt namelijk het feit dat cliënt bij de raadplegende partij onder behandeling staat gedeeld met zorgaanbieders die de cliënt mogelijk niet eens kennen. Het hebben van een behandelingsovereenkomst valt namelijk ook het beroepsgeheim en mag niet zonder meer gedeeld worden. De toestemmingsvoorziening Mitz - waar nodig verplicht door Twiin - biedt een rudimentaire vorm van lokalisatie. Mitz biedt een dienst waarmee een zorgaanbieder kan vragen bij welke andere zorgaanbieders (potentiëel) gegevens van een bepaalde cliënt voor raadpleging (door de betreffende zorgaanbieder) beschikbaar zijn. Dit is de zogenaamde 'waar-vraag'. Vaak is het ook nog nodig of noodzakelijk om ook te weten welke type(n) gegevens dan beschikbaar zijn, de zogenaamde 'welke-vraag'. Deze functie biedt Mitz niet. Tot op welk detailniveau de welke-vraag beantwoordt moet worden kan ook per toepassing verschillen. Deze zal daarom, indien van toepassing, per type gegevensuitwisseling in Twiin beschreven worden. --- version: "TA150" language: "nl" --- # 10.2.7 \| Generieke functie - Netwerkbeveiliging "Hoe groter een risico, des te groter de beveiliging, zo leert onder andere de AVG. Dit geld ook voor het versleutelen bij gegevensuitwisseling" (NEN7512:2022). Volgens de norm dient er in het kader van vertrouwelijkheid een gelaagde beveiliging ('defence in depth') toegepast te worden op de gegevensuitwisseling. Hierbij onderkent de norm de volgende beveiligingslagen: * versleuteld bericht * versleuteld kanaal * veilig netwerk Afhankelijk van het risiconiveau van de gegevensuitwisseling dienen één tot drie van deze maatregelen te worden toegepast. Twiin kiest voor de toepassing van [een versleuteld kanaal en een veilig netwerk](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-10-netwerk-level-security-mtls-1-3.md). --- version: "TA150" language: "nl" --- # 10.1.2 \| Communicatiepatroon: Indexed Pull ## 1. Use case Vanuit Twiin zijn verschillende communicatiepatronen beschreven voor gegevensuitwisseling. Hieronder staat een use case beschreven, waarin van het communicatiepatroon Index Pull gebruik kan worden gemaakt. Dit is een invulling van 'opvragen'. Een uroloog in ziekenhuis A wil alle reeds bekende labuitslagen van de patiënt die bij haar onder behandeling is opvragen, om hiermee een zo compleet mogelijk dossier voor de patiënt op te bouwen. ### 1.1. Applicatiediagram Het applicatiediagram geeft een overzicht van de applicatierollen en de gegevensstroom hiertussen. Het communicatiepatroon 'geïndexeerde bevraging' bevat twee stappen. De eerste stap is nodig om een overzicht van beschikbare gegevens inzichtelijk te maken aan de zorgverlener, indien gewenst in de vorm van een tijdlijn. Dit overzicht bestaat uit verschillende metadata elementen, waaronder bijvoorbeeld cliëntnaam, cliëntnummer, type gegeven en de vindplaats van de data zelf. Het overzicht met metadata kan samengesteld worden vanuit de informatie uit verschillende zorgsystemen. Delen van het metadata overzicht worden beschikbaar gesteld via één of meerdere GtK's. Om overvraging te voorkomen wordt gebruik gemaakt van een lokalisatievoorziening. Hieronder wordt deze eerste stap in een diagram weergegeven. Aan de hand van de metadataoverzicht kan de data opgehaald worden bij of via een GtK. ![Geïndexeerde bevraging.jpg](https://afsprakenstelsel.twiin.nl/__attachments/a_a3ae159929a2c33a6b274b087b8294e08daa2be87c0c4669b4ecdc8a4460f7f0/Ge%C3%AFndexeerde%20bevraging.jpg?cb=32bd0c837e6b21d416108672dc7f866a) In bovenstaande applicatiediagram is globaal beschreven *wat* in de basis de bedoeling is voor de eerste stap. Verder in dit de uitwerking van de technische kern worden verschillende technieken beschreven in sequence transactiediagrammen om aan te geven *hoe* je tot een daadwerkelijke uitwisseling van data kunt komen. De beschrijving hieronder is een, maar niet per se dé manier om dit communicatiepatroon in te vullen. Vaak is er een keuze om bepaalde functionaliteit in het GtK te beleggen waar het ook in het XIS kan. Generieke functies zijn in bovenstaand diagram apart gezet -om te benadrukken dat het gebruik hiervan nodig is- maar de implementatie hiervan zou onderdeel van het XIS, het GtK of een centrale gemeenschappelijke voorziening kunnen zijn. 1. Vanuit een XIS wordt de vraag "geef metadataoverzicht" aan het GtK gesteld. 2. Het GtK stelt een lokalisatievraag aan een lokalisatievoorziening (bijvoorbeeld Mitz) om te achterhalen bij welke zorginstellingen gegevens van de cliënt bekend zijn. Indien nodig kan het GtK de hier bijbehorende technische adressen van opgehaald worden via ZORG-AB. 3. De vraag "geef metadataoverzicht" wordt doorgezet naar de bevraagde GtK's. 4. Een bevraagd GtK controleert: - de medische autorisatie op basis van wat er voor de betreffende use case is afgesproken en - de cliënt toestemming bij de toestemmingsvoorziening. 5. Indien akkoord stuurt het GtK de vraag door naar het bevraagde XIS 6. Het bevraagde XIS stuurt de metadata als antwoord terug naar het GtK. 7. Het bevraagde GtK stuurt deze als antwoord terug naar het vragende GtK. 8. Het vragende GtK stuurt het antwoord op zijn beurt weer terug naar de vragende XIS. ### 1.2. Benodigde generieke functies Voor de geïndexeerde uitwisseling zijn de volgende generieke functies nodig. * [10.2.1 \| Generieke functie - Identificatie en Authenticatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-7-generieke-functie-identificatie-en-authenti.md) * [10.2.2 \| Generieke functie - Autorisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-6-generieke-functie-autorisatie.md) * [10.2.3 \| Generieke functie - Toestemming](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-10-generieke-functie-toestemming.md) * [10.2.4 \| Generieke functie - Logging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-9-generieke-functie-logging.md) * [10.2.5 \| Generieke functie - Adressering](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-7-8-generieke-functie-adressering.md) * [10.2.6 \| Generieke functie - Lokalisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-11-generieke-functie-lokalisatie.md) * [10.2.7 \| Generieke functie - Netwerkbeveiliging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-12-generieke-functie-netwerkbeveiliging.md) --- version: "TA150" language: "nl" --- # 10.1.3 | Communicatiepatroon: Push # 10.1.3 \| Communicatiepatroon: Push ## 1. Use case Vanuit Twiin zijn verschillende communicatiepatronen beschreven voor gegevensuitwisseling. Hieronder staat een use case beschreven, waarin van het communicatiepatroon Push gebruik kan worden gemaakt. Dit is een invulling van 'verzenden'. Een zorgverlener besluit de cliënt die op dat moment bij hem/haar op bezoek is door te verwijzen. De zorgverlener stuurt bij de verwijzing direct de gegevens mee die hij/zij acht van belang te zijn bij de voortzetting van de behandeling. ## 2. Applicatiediagram Het applicatiediagram geeft een overzicht van de applicatierollen en de gegevensstroom hiertussen. ![Push - Applicatiediagram.jpg](https://afsprakenstelsel.twiin.nl/__attachments/a_f084d1ba0b91504eaa52b4a09ad5bb8dab9cac73d7723bf2aee1cca584f5b5e8/Push%20-%20Applicatiediagram.jpg?cb=776abe2c6964699d2e533d9a33ebba58) Het communicatiepatroon Push A beschrijft een push mechanisme waarin direct de gegevens gestuurd worden van zorgverlener A naar zorgverlener B. Er zijn verschillende generieke functies nodig om een transactie te bewerkstelligen. Deze beschrijving is een, maar niet per se dé manier om dit communicatiepatroon in te vullen. Vaak is er een keuze om bepaalde functionaliteit in het GTK te beleggen waar het ook in het XIS kan. Generieke functies zijn in bovenstaand diagram apart gezet -om te benadrukken dat het gebruik hiervan nodig is- maar de implementatie hiervan zou onderdeel van het XIS, het GTK of een centrale gemeenschappelijke voorziening kunnen zijn. ## 3. Benodigde generieke functies Voor de geïndexeerde uitwisseling zijn de volgende generieke functies nodig. * [10.2.1 \| Generieke functie - Identificatie en Authenticatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-7-generieke-functie-identificatie-en-authenti.md) * [10.2.2 \| Generieke functie - Autorisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-6-generieke-functie-autorisatie.md) * [10.2.4 \| Generieke functie - Logging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-9-generieke-functie-logging.md) * [10.2.5 \| Generieke functie - Adressering](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-7-8-generieke-functie-adressering.md) * [10.2.7 \| Generieke functie - Netwerkbeveiliging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-12-generieke-functie-netwerkbeveiliging.md) --- version: "TA150" language: "nl" --- # 10.1.4 \| Communicatiepatroon: Notified Pull ## 1. Use case Vanuit Twiin zijn verschillende communicatiepatronen beschreven voor gegevensuitwisseling, hieronder staat een use case beschreven die van het communicatiepatroon Notified Pull gebruik zou kunnen maken. Een cliënt is doorverwezen door een zorgverlener voor een onderzoek bij een zorgverlener in een andere zorgaanbieder. Zodra het onderzoek is uitgevoerd, brengt de uitvoerende zorgverlener de aanvragende zorgverlener op de hoogte dat de gegevens op te halen zijn. Communicatiepatroon Notified Pull biedt een oplossing voor de 'juridische push', waarbij gegevens van de ene organisatie aan de andere worden beschikbaar worden gemaakt. Dit is bijvoorbeeld het geval bij een verwijzing, een second opinion of een overdracht. De Notified Pull-transactie verwacht dat bij de ontvangende organisatie zorgvuldig wordt geselecteerd door de verzendende organisatie. Deze actie bevestigt de geneeskundige behandelingsovereenkomst/behandelrelatie tussen de cliënt en de toekomstige zorgaanbieder/zorgverlener en kan worden gezien als een 'veronderstelde toestemming'. De cliënt is op de hoogte van de nieuwe behandelingsovereenkomst/behandelrelatie en begrijpt daarom dat zijn medische gegevens voor de andere partij beschikbaar gemaakt worden. De Notified Pull zal een ontvangende organisatie op de hoogte stellen van medische dossiers die klaar zijn om te worden opgehaald. De ontvangende organisatie ontvangt alleen op eigen voorwaarden door te bepalen hoe en wanneer de Pull-operaties worden uitgevoerd die door de verzendende organisatie zijn voorgesteld. ## 2. Applicatiediagram Het applicatiediagram geeft een overzicht van de **applicatierollen** en de gegevensstroom hiertussen. Er zijn twee type organisaties, een verzendende en een ontvangende organisatie. Beide organisaties hebben een GTK, een zendend GTK en een ontvangend GTK. De applicaties van een zorgaanbieder worden ontsloten via een GTK. De systemen die we daarbij identificeren zijn een bronsysteem en een raadplegend systeem. | **Organisatie** | **GTK** | **Systeem** | |-------------------------|----------------|---------------------| | Verzendende organisatie | Zendend GTK | Bronsysteem | | Ontvangende organisatie | Ontvangend GTK | Raadplegend systeem | ![Notified Pull.jpg](https://afsprakenstelsel.twiin.nl/__attachments/a_9ffda2f445d6a0446939e7c3b18e6cd7abac660a3046c4cea65903eca2ea26cc/Notified%20Pull.jpg?cb=e7abf9f04782d969646d3ec2d88243e9) Het communicatiepatroon Notified Pull beschrijft een push/pull-mechanisme dat start met het sturen van een notificatie van de zorgverlener waar iets opgehaald kan worden, naar de zorgverlener die de dataset uiteindelijk op moet halen. ## Benodigde generieke functies Voor de geïndexeerde uitwisseling zijn de volgende generieke functies nodig. * [10.2.1 \| Generieke functie - Identificatie en Authenticatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-7-generieke-functie-identificatie-en-authenti.md) * [10.2.2 \| Generieke functie - Autorisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-6-generieke-functie-autorisatie.md) * [10.2.4 \| Generieke functie - Logging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-9-generieke-functie-logging.md) * [10.2.5 \| Generieke functie - Adressering](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-7-8-generieke-functie-adressering.md) * [10.2.7 \| Generieke functie - Netwerkbeveiliging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-12-generieke-functie-netwerkbeveiliging.md) --- version: "TA150" language: "nl" --- # 10.1.1 \| Communicatiepatroon: Pull ## 1. Use case Vanuit Twiin zijn verschillende communicatiepatronen beschreven voor gegevensuitwisseling, hieronder staat een use case beschreven die van het communicatiepatroon Pull gebruik zou kunnen maken. Een cliënt onder behandeling bij een specialist geeft aan dat er reeds een specifieke type dataset van hem/haar beschikbaar is bij een andere zorgaanbieder. De zorgverlener wil direct die gegevens ophalen bij die specifieke zorgaanbieder. De 'gerichte bevraging' biedt een oplossing voor de 'juridische pull'", waarbij gegevens door de raadplegende organisatie bij de beschikbaarstellende organisatie kan worden opgevraagd. Van de raadplegende organisatie wordt verwacht dat alleen gegevens opgevraagd worden die noodzakelijk zijn in de context. Van de beschikbaarstellende organisatie wordt verwacht dat alleen gegevens worden opgeleverd waar expliciete toestemming van de cliënt voor is gegeven. ## 2. Applicatiediagram Het applicatiediagram geeft een overzicht van de applicatierollen en de gegevensstroom hiertussen. ![Gerichte bevraging.jpg](https://afsprakenstelsel.twiin.nl/__attachments/a_4c771aff964ed3a4dfc932e15e97baa4ccdbffeb5fab8c99cc931a8b86e8a3bc/Gerichte%20bevraging.jpg?cb=61892d96eede2a09932c75e567a378da) In bovenstaand applicatiediagram is globaal beschreven *wat* in de basis de bedoeling is. Verder in de uitwerking van de technische kern worden verschillende technieken beschreven in sequence transactiediagrammen om aan te geven *hoe* er tot een daadwerkelijke uitwisseling van data gekomen kan worden. De beschrijving hieronder is een, maar niet per se dé manier om dit communicatiepatroon in te vullen. Vaak is er een keuze om bepaalde functionaliteit in het GTK te beleggen waar het ook in het XIS kan. Generieke functies zijn in bovenstaand diagram apart gezet -om te benadrukken dat het gebruik hiervan nodig is- maar de implementatie hiervan zou onderdeel van het XIS, het GTK of een centrale gemeenschappelijke voorziening kunnen zijn. 1. Vanuit een raadplegend XIS wordt aan het raadplegende GTK waarop hij aangesloten is een vraag gesteld. Hoe dit precies gebeurt valt buiten de scope van Twiin om te beschrijven. 2. Het raadplegende GTK gebruikt de gemeenschappelijke voorzieningen om het vervolg te bepalen. 3. Het raadplegende GTK stuurt de vraag door naar het bron-GTK. 4. Het bron GTK controleert de medische autorisatie en de cliënttoestemming bij de gemeenschappelijke voorzieningen. 5. Het bron GTK stuurt de vraag door aan het bron-XIS. Hoe dit precies gebeurt valt buiten de scope van Twiin om te beschrijven. 6. Het bron XIS geeft de gevraagde data terug aan het bron-GTK. Hoe dit precies gebeurt valt buiten de scope van Twiin om te beschrijven. 7. Het bron GTK stuurt het antwoord door aan het raadplegende GTK. 8. Het raadplegende GTK geeft het antwoord terug aan het raadplegende XIS. Hoe dit precies gebeurt valt buiten de scope van Twiin om te beschrijven. ## 3. Benodigde generieke functies Voor de geïndexeerde uitwisseling zijn de volgende generieke functies nodig. * [10.2.1 \| Generieke functie - Identificatie en Authenticatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-7-generieke-functie-identificatie-en-authenti.md) * [10.2.2 \| Generieke functie - Autorisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-6-generieke-functie-autorisatie.md) * [10.2.3 \| Generieke functie - Toestemming](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-10-generieke-functie-toestemming.md) * [10.2.4 \| Generieke functie - Logging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-9-generieke-functie-logging.md) * [10.2.5 \| Generieke functie - Adressering](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-7-8-generieke-functie-adressering.md) * [10.2.6 \| Generieke functie - Lokalisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-11-generieke-functie-lokalisatie.md) * [10.2.7 \| Generieke functie - Netwerkbeveiliging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-12-generieke-functie-netwerkbeveiliging.md) --- version: "TA150" language: "nl" --- # 10.2.2 \| Generieke functie - Autorisatie De bron van medische gegevens is verplicht om te zorgen dat niet meer gegevens worden geraadpleegd of vrijgegeven dan noodzakelijk. Dit wordt gedaan door afspraken te maken over autorisatie: wie mag wanneer en waar bij? In een zorgtoepassing moet er een rolgebaseerde autorisatieafspraak gemaakt zijn. Hier zal ieder GTK zich aan moeten houden, maar kan ook betekenen dat de autorisatieregels van de eigen zorgaanbieder(s) worden overruled. Hierdoor kan een gebruiker mogelijk meer of minder rechten hebben doen dan (initieel) intern was afgesproken. Autorisatieafspraken worden momenteel per zorgtoepassing bepaald: er zijn twee scenario's. 1. Er zijn landelijke autorisatieafspraken. Ieder GTK dat deelneemt aan een toepassing dient zich hieraan te houden. 2. Er zijn (nog) geen landelijke autorisatieafspraken. Binnen Twiin maken we een (tijdelijke) afspraak. In de NEN7520 wordt momenteel gewerkt aan een landelijk kader om te komen tot eenduidige autorisatieafspraken. Twiin zal de lijn uit de NEN7520 volgen indien deze gereed is. --- version: "TA150" language: "nl" --- # 10.2.1 \| Generieke functie - Identificatie en Authenticatie **Zorgaanbieder** De communicerende zorgaanbieders dienen als identificatie het UZI-register Abonneenummer (URA) te gebruiken. De authenticatie van deze identiteit kan nog niet op een hoog niveau en door de gehele keten plaatsvinden. **Zorgverlener/gebruiker** Zorgverleners dienen geïdentificeerd te worden op basis van een uniek ID. Waar mogelijk is dit het UZI-nummer, maar ook een lokaal-id i.c.m. het URA mag gebruikt worden. De zorgverlener/gebruiker dient lokaal geauthenticeerd te worden op eIDAS-niveau hoog. Door de keten heen kan hier nog geen bewijs van worden meegeven zodat andere partijen de zorgverlener ook met zekerheid kunnen authenticeren. Twiin zal in de toekomst meegaan met de eisen die gesteld gaan worden uit het [wetsvoorstel DIAZ](https://wetgevingskalender.overheid.nl/Regeling/WGK015084), de NEN7518 en het [DEZI-stelsel](https://www.dezi.nl/). **GTK** De GTK's dienen bij het opzetten van de gegevensuitwisseling elkaar te authenticeren op basis van een PKIo-servercertificaat. --- version: "TA150" language: "nl" --- # PvE \| Logging Toelichting over de opgenomen attributen is te vinden onder [1.3 \| Schrijfwijze van objecten](https://afsprakenstelsel.twiin.nl/normatief/ta150/1-3-schrijfwijze-van-objecten.md). ## Generieke functie: Logging | **TW-F-LO-001** | **Loggen berichtuitwisseling** | |------------------------|-----------------------------------------------------------------------------------------------------------------------------------------| | **Legacy code** | Log-01 | | **Status** | Normatief | | **Omschrijving** | Het GTK MOET alle berichtuitwisseling met andere GTK's loggen. | | **Toelichting** | Wat er functioneel gelogd moet worden is gespecificeerd in de norm NEN 7513:2024. Deze eis is van toepassing op alle Twiin-transacties. | | **Vereiste** | MOET | | **Functie** | Logging | | **Rol** | GTK | | **Toepassing** | BgZ Correspondentie | | **Referenties** | NEN 7513:2024, tabel 3 - Format van logregel voor uiwisselingsgebeurtenissen | | **Toetsingscategorie** | Via Twiin | | **Toetsingsvorm** | Zelfverklaring | | **Niveau** | Generiek | | **TW-F-LO-002** | **Loggegevens uitwisselen** | |------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Legacy code** | Log-02 | | **Status** | Normatief | | **Omschrijving** | Het GTK MOET loggegevens over uitwisselingen met andere GTK's kunnen aanleveren aan die GTK's. | | **Toelichting** | Eis uit NEN7512:2022 6.2.9: "De communicatiepartijen moeten afspraken maken over de wederzijdse inzage in de logbestanden en de termijn waarbinnen deze mogelijk wordt gemaakt." Zolang er nog geen landelijke procedures en afspraken zijn opgesteld over de uitwisseling van de logging tussen GTK's zal dit in de (uitzonderlijke) gevallen wanneer dit toch nodig is op ad hoc basis gedaan moeten worden. | | **Vereiste** | MOET | | **Functie** | Logging | | **Rol** | GTK | | **Toepassing** | BgZ Correspondentie | | **Referenties** | NEN7512:2022 6.2.9 | | **Toetsingscategorie** | Via Twiin | | **Toetsingsvorm** | Zelfverklaring | | **Niveau** | Generiek | --- version: "TA150" language: "nl" --- # 10.2.4 \| Generieke functie - Logging ## Wat is logging? De normen NEN 7510 en NEN 7513 definiëren loggen als 'het chronologisch vastleggen van gebeurtenissen' waarbij het resultaat en de bundeling ervan logging vormen. Het doel van het loggen is 'een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij persoonlijke gezondheidsinformatie is verwerkt'. Logging is een verplichting voor zorgaanbieders om zich tegenover hun cliënten, collega's, toezichthouders en anderen te verantwoorden over de zorgvuldigheid waarmee zij met de persoonsgegevens omgaan, conform de wetgeving (i.e. AVG, WABVPZ). ### Logtypes Logging kent verschillende vormen van logs met verschillende kenmerken voor specifieke doeleinden. Hieronder worden de verschillende logtypes beschreven: toegangslog, systeemlog en beheerlog. #### Toegangslog Een toegangslogwordt gebruikt om interacties van actoren/gebruikers met het systeem op te slaan (te loggen) die door het systeem worden ontvangen en verwerkt, evenals interacties van actoren die door het systeem worden gegenereerd en verzonden. Elke toegang of poging tot toegang, op elk moment, in elke situatie, tot gegevens opgeslagen in het Informatiesysteem wordt vastgelegd in de toegangslog, daarbij tevens de toegang tot de toegangslog zelf. Actoren/gebruikers kunnen zijn personen, zorgverleners, zorgaanbieders, beheerders/ondersteuners, uitwisselsystemen of andere systemen die toegang tot het systeem hebben. Wanneer er sprake is van het ontvangen en/of verzenden van interacties van actoren door een systeem, bevat de toegangslog een logging van deze interacties. Interacties zijn gebeurtenissen waarbij acties plaatsvinden die betrekking hebben op inloggen, inzien van gegevens, wijzigen van gegevens en uitloggen. Deze interacties kunnen over meerdere domeinen plaatsvinden. De loggegeven in de toegangslog zij herleidbaar tot de actoren en de daarbij behorende gegevens en bevat datum, tijd, rol en naam gebruiker verantwoordelijk voor de toegang, dossierdeel, resultaat, rol en naam gebruiker, autorisatieprotocol, toestemmingsprofiel en noodknopprocedure (ja/nee). Afhankelijk van de gebeurtenistypen, kan in de toegangslog onderscheid gemaakt worden tussen operationele gebeurtenissen (voor cliënten), gebeurtenissen die de toegangsregeling betreffen en gebeurtenissen die het loggen beïnvloeden. Verdere beschrijving van het datamodel kan worden gevonden in de NEN 7513. Met de toegangslog kunnen incidenten gesignaleerd en gelokaliseerd worden. #### Systeemlog Een systeemlog is het traditionele logboek van gebeurtenissen en interne verwerkingsdetails van één systeem of applicatie. De systeemlog wordt gebruikt door beheerders en leveranciers voor het oplossen van gelogde fouten en ter voorkoming van toekomstige fouten. * Systeem logt: * fouten of * statuswijzigingen #### Beheerlog In de beheerlog worden alle acties opgenomen die door een specifieke systeembeheerder (actor) worden uitgevoerd met betrekking tot beheer van het systeem. Het beheerlog geeft onder andere de gebeurtenissen aan die de toegangsregeling betreffen, zoals gebeurtenissen met betrekking tot structuurwijzigingen, granulariteit classificaties en rollen in het zorg informatiedomein en de algehele toegangsregeling aangaande applicaties, gegevens bevoegdheden en autorisatie protocollen. ### Te loggen gebeurtenissen De NEN 7513 bepaalt welke gegevens in de logging aanwezig moeten zijn, welke gebeurtenissen moeten worden gelogd, welke gegevens van die gebeurtenissen moeten worden vastgelegd en aan welke kwaliteitseisen het loggen en de logbestanden moeten voldoen. Ook bepaalt de norm hoe lang de logbestanden moeten worden bewaard. Verder biedt de norm houvast aan zorgaanbieders en andere beheerders van persoonlijke gezondheidsinformatie over het verstrekken van informatie over wie toegang heeft gehad tot haar of zijn elektronisch cliëntdossier. Voor een betrouwbare logging moeten niet alleen operationele gebeurtenissen worden gelogd, maar ook gebeurtenissen die de toegangsregeling betreffen, zoals structuurinstellingen, toegangsregeling en het instellen van toestemmingsprofielen, en die het loggen en logging kunnen beïnvloeden. De gebeurtenissen zijn in dit geval operationele gebeurtenissen waarbij acties of interacties plaatsvinden tussen systemen/stelsels die betrekking hebben op een cliënt (dossier). Gegevens worden vastgelegd, ingezien of anderszins verwerkt. Hiertoe behoren: * zoekacties en gegevens ophalen * gegevens aanmaken en/of muteren * starten en/of stoppen van diensten * notificeren * foutafhandelingen In de [Twiin toolkit](https://www.twiin.nl/downloads)staat een handreiking voor (dienstverleners en beheerders van) zorgaanbieders die te maken hebben met loggen en rapporteren. In de [NEN 7513:2024](https://www.nen.nl/nen-7513-2024-nl-329182) is er een nieuwe tabel opgesteld die expliciet geldt voor de gebeurtenis gegevensuitwisseling. Om zorgaanbieders en softwareleveranciers te ondersteunen bij het toepassen van logging in de zorg, is de nieuwe [Nederlandse Praktijkrichtlijn NPR 7523](https://www.nen-egiz.nl/nieuwe-praktijkrichtlijn-npr-7523-gepubliceerd-concrete-hulp-bij-implementatie-loggingnorm-nen-7513/) gepubliceerd. Deze richtlijn biedt praktische handvatten en heldere use cases voor het implementeren van NEN 7513:2024 **Ketenbrede traceerbaarheid** * Logging is niet alleen relevant binnen individuele systemen, maar ook voor interacties tussen systemen in een keten van zorginformatiesystemen. * In de NEN 7513:2024 zijn hiervoor ook nieuw te loggen elementen opgenomen die de ketenbrede traceerbaarheid bij gegevensuitwisseling kunnen te waarborgen. * Twiin kiest voor het [W3C Trace Context](https://www.w3.org/TR/trace-context-1/)-concept: dit internationale concept biedt een manier om een trace-id en span-id door te geven, zodat gebeurtenissen in meerdere systemen consistent gekoppeld kunnen worden. * Toepassing van dit principe bevordert interoperabiliteit en consistentie, zonder dat Twiin een verplicht uitwisselingsformaat voorschrijft. --- version: "TA150" language: "nl" --- # 10.1 \| Kern Volume 0a - Communicatiepatroon Overview Voor het delen en uitwisselen (beschikbaar stellen) van data heeft Twiin vier communicatiepatronen uitgewerkt (zie ook [4.4 \| Logische architectuur](https://afsprakenstelsel.twiin.nl/normatief/ta150/4-4-logische-architectuur.md)). De communicatiepatronen vallen uiteen in twee typen gegevensuitwisselingen. Functioneel ziet dit onderscheid op de initiator van de communicatie. Het gaat hierbij om verzenden en raadplegen. Is de initiator de houder van de gegevens dan wordt gesproken over 'verzenden'. Is de initiator niet de houder van de gegevens dan wordt functioneel gesproken over 'raadplegen'. Dit onderscheid in typen gegevensuitwisselingen is ook een juridisch onderscheid. De wet stelt bijzondere eisen aan een elektronisch uitwisselingssysteem zoals bedoeld in de Wabvpz. Bij het raadpleegbaar maken van gegevens is sprake van een elektronisch uitwisselingssysteem. Dit is verder uitgelegd in het [juridische kader](https://afsprakenstelsel.twiin.nl/normatief/ta150/7-1-juridisch-kader.md) onder het kopje Wabvpz. In dit volume 0 wordt op logisch niveau een overzicht gegeven van de communicatiepatronen tussen de GtK's (Gevalideerde Twiin Knooppunten) en generieke functies. Dit volume is voor een breed publiek (informatiemanagers, architecten) geschreven in het Nederlands. In de zorgtoepassingen wordt bepaald hoe een functionele use case het beste ingevuld kan worden met één of meerdere communicatiepatronen. **Overzicht communicatiepatronen:** * [10.1.1 \| Communicatiepatroon: Pull](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-5-uitwisselpatroon-pull-gerichte-bevraging.md) * [10.1.2 \| Communicatiepatroon: Indexed Pull](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-2-uitwisselpatroon-indexed-pull-geindexeerde-.md) * [10.1.3 \| Communicatiepatroon: Push](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-3-uitwisselpatroon-push-versturen.md) * [10.1.4 \| Communicatiepatroon: Notified Pull](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-4-uitwisselpatroon-notified-pull-versturen-no.md) Een communicatiepatroon kan daarnaast verschillende technische uitwerkingen hebben namelijk SOAP (IHE XDS) gebaseerd of RESTful (HL7 FHIR) gebaseerd. In volume 1 worden wordt de technische uitwerking van de communicatiepatronen gedaan en eventuele technische varianten daarin. ![PushPull.png](https://afsprakenstelsel.twiin.nl/__attachments/a_0f5ec4626cabe2c9d5ada90568eff10e2560c5924106e40e2e45e4d4d6613023/PushPull.png?cb=d8bc304fc414a3ae6149d15c73547d9b) --- version: "TA150" language: "nl" --- # 10.4.7 \| Network level security In a secure network, certificates play a crucial role by enabling the establishment of secure connections using TLS. They also ensure the authenticity and integrity of data in transit . Both the Sending System and Receiving System expose endpoints that must be protected from unauthorized and malicious interactions. More specifically, access control measures must be applied to the following endpoints: * Receiving System: Notification endpoint * Sending System: Resource endpoint * Token endpoint These endpoints can either be RESTful or SOAP based. Mutual TLS shall be used to protect all these endpoints in the following ways: * Authentication: The sending and receiving systems are mutually verifying each other's identity before establishing a secure connection. In this way only systems that are trusted (are a GTK) are allowed to set up connections. * Encryption: an mTLS connection is encrypted. This means that only the sending and receiving systems can read the exchanged data and no third, unauthorized party can 'listen in'. * Integrity: mTLS assures that the data has not been modified by any unauthorized party during transmission. Any tampering attempts would alert the recipient. * Protection against replay attacks: Each message sent over the connection includes a sequence number, and the recipient keeps track of the sequence numbers it has received. If a message with a previously received sequence number arrives, it is considered a replayed message and is rejected. This prevents attackers from intercepting and resending previously valid messages. ## Terminology * Certificate Authority (CA): A trusted entity responsible for issuing and managing certificates used in secure network connections. * Certificate Revocation List (CRL): A list maintained by a Certificate Authority, containing revoked certificates to prevent the use of compromised or invalid certificates. * Public Key Infrastructure overheid (PKIo): A PKI structure controlled by the Dutch government, governing the issuance and management of certificates in the Netherlands. * Trusted Service Provider (TSP): A party authorized to issue PKIo certificates within the PKIo infrastructure, ensuring the integrity and security of the certificates they issue. ## Network level security: mTLS 1.3 At the network level, mutual TLS (mTLS) must be applied. The TLS-implementation must comply with the security level "Good" as specified by the National Cyber Security Centre (NCSC). At the time of writing, the (Security guidelines for Transport Layer Security 2025-05) require version 1.3 of the TLS standard for the security level "Good". In the case one or more of the cipher suites (Appendix B of the Security guidelines) are declassified by NCSC will this be described in a future version of the Twiin specification. The exchange of a client certificate during the mTLS handshake does not only enable the server to authenticate the client on network level, but it also enables the server to issue certificate bound access tokens as specified in as an additional security measure on application level. See section [Resource server authorization: OAuth 2.0](#) for requirements on application level security using OAuth 2.0. ### CRL / OCSP / CPS The validity of a certificate shall be verified using a CRL, OCSP, or CPS check. A determined validity may be relied upon for a maximum of one hour, after which the verification must be performed again. If the validity of a certificate cannot be established, the connection shall be terminated, as it shall also be terminated if the certificate is found to be invalid. ## PKIoverheid Both the client and server certificates must be PKIo-certificates that are issued under the CA "Staat der Nederlanden Private Services CA -- G1" (this includes UZI server certificates issued by UZI-registry (CIBG)). --- version: "TA150" language: "nl" --- # 10.3.1.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. ![image-20230718-084330.png](https://afsprakenstelsel.twiin.nl/__attachments/a_1f409be350c43383678025881b51d008152516f3b240504eb7ea950243bfa690/image-20230718-084330.png?cb=62f6b261a6087ecaf661cf3ef391e99d) 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](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-3-1-notified-pull-data-interactions.md#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.5.1 \| Twiin-01 \| Send Notification Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-1-twiin-01-send-notification-task.md) 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.5.1 \| Twiin-01 \| Send Notification Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-1-twiin-01-send-notification-task.md) 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.5.2 \| Twiin-02 \| Cancel Notification Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-2-twiin-02-cancel-notification-task.md) 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.5.5 \| Twiin-05 \| Retrieve Resource](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-5-twiin-05-retrieve-resource.md) for a detailed description for the retrieval of resources referenced in Task.input:read-available-resources. See [10.5.4 \| Twiin-04 \| Search Resource(s)](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-4-twiin-04-search-resource-s.md) 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. See [10.5.3 \| Twiin-03 \| Get Workflow Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-3-twiin-03-get-workflow-task.md) | | 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.5.5 \| Twiin-05 \| Retrieve Resource](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-5-twiin-05-retrieve-resource.md) for a detailed description for the retrieval of resources referenced in Task.input:read-available-resources. See [10.5.4 \| Twiin-04 \| Search Resource(s)](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-4-twiin-04-search-resource-s.md) 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](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-5-tta-fhir-authentication-authorization.md) 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. --- version: "TA150" language: "nl" --- # 10.3.1 \| TTA FHIR - Notified pull This Twiin Technical Agreement (TTA) describes and specifies the 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](https://www.twiin.nl/tanp), with the normative specifications remaining unchanged. The informative specifications, however, have been described using a specific implementation. The possibility to exchange a client's medical record is for example required in case of a patient referral or transfer. When different healthcare organizations are involved in a client'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 references: * Nictiz - Informatiestandaard BgZ MSZ * [TA Notified Pull v1.x.x (latest version)](https://www.twiin.nl/tanp) ## Format The format of this section follows the main interactions as presented below in the simplified sequence diagram of the Notified Pull sequence. ![Scherm­afbeelding 2023-05-10 om 16.56.18.png](https://afsprakenstelsel.twiin.nl/__attachments/a_9e9df8cb4b5c19b152605bdbc440d9939fd81ba7f7cd2b76cd18e7a85be029f5/Scherm%C2%ADafbeelding%202023-05-10%20om%2016.56.18.png?cb=1c2d0599a6315aeaf965a817ae543a94) Interaction numbers 1 and 3 are described in the [10.4.2 \| TTA FHIR - Authorization](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-5-tta-fhir-authentication-authorization.md). Interaction number 2 is described in[10.3.1.1 Notified Pull - Data interactions](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-3-1-notified-pull-data-interactions.md). A part of interaction number 4 is also described in [10.3.1.1 Notified Pull - Data interactions](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-3-1-notified-pull-data-interactions.md). For specifics of the context of the Notified Pull, see Nictiz information standards. The sequence diagram below provides a complete overview 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.4.2 \| TTA FHIR - Authorization](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-5-tta-fhir-authentication-authorization.md) and [10.4.5 \| TTA - Addressing](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-8-tta-addressing.md) 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.3.1.1 Notified Pull - Data interactions](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-3-1-notified-pull-data-interactions.md)) and in authorization layer using OAuth 2.0 (marked cyan, described in [10.4.7 \| Network level security](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-10-netwerk-level-security-mtls-1-3.md)). Each section consists of several steps. The steps correspond to the numbers in the sequence diagram. ![image-20231207-102552.png](https://afsprakenstelsel.twiin.nl/__attachments/a_b93df1da0536ff7bda179546a3853151df167b031182546bad4cb7a590571e74/image-20231207-102552.png?cb=52744f2a43b5cd8b1fd9ae1f52821866) |-------------------------------------------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **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 the creation of this task on the Sending System. | | **Invite the Receiving Organization** | 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. | | **Invite the Receiving Organization** | 3 | The Sending System creates one or two assertions, which can be used to request an access token in the next step. | | **Invite the Receiving Organization** | 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 other elements, 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. | | **Invite the Receiving Organization** | 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. | | **Cancellation by Sending Organization** | 13 | The Sending System repeats steps 3-5. | | **Cancellation by Sending Organization** | 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. | | **Receiving Organization performs Pull interaction(s)** | 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. | | **Receiving Organization performs Pull interaction(s)** | 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. | | **Receiving Organization performs Pull interaction(s)** | 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. | | **Receiving Organization performs Pull interaction(s)** | 28-31 | The Receiving System initiates the (additional) Pull interactions listed in the workflow task, and processes the responses. | --- version: "TA150" language: "nl" --- # Appendix: Token Request Examples ## Token Request ### request YAML POST /receiver-auth-server/token Host: sending-server.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer assertion=ew0KICAidHlwIjogIkp[...omitted for brevity...] client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer client_assertion=ew0KICAidHlwIjogIkp[...omitted for brevity...] ### **client_assertion jwt payload** JSON { "jti": "4f0dfb37-7f9d-45fa-8187-9e260b80f949", "iss": "sending-ehr-issuer-id", "iat": "1572468316", "exp": "1572468916", "aud": "auth-server-id", "sub": "sending-ehr-system-id" } ### **assertion jwt payload** JSON { "jti": "4f0dfb37-7f9d-45fa-8187-9e260b80f949", "iss": "sending-ehr-issuer-id", "iat": "1572468316", "exp": "1572468916", "aud": "auth-server-id", "sub": "sending-organization-id", "user_id": "responsible-user-id", "user_role": "responsible-user-role", "authorizer": "receiving-organization-id", "authorization_base": "ZGFhNDFjY2MtZGFmMi00YjZkLThiNDYtN2JlZDk1MWEyYzk2", "patient": "urn:oid:2.16.840.1.113883.2.4.6.3.123456782" } --- version: "TA150" language: "nl" --- # 10.4.2 \| TTA FHIR - Authorization Attention! The specifications and requirements in this chapter are still a specific implementation for the Notified Pull communication pattern and have not yet been generalized to work for other communication patterns. ## Resource server authorization: OAuth 2.0 On application level both the Notification endpoint of the Receiving System and the FHIR endpoint of Sending System are considered as resource endpoints that must be secured by . This implies that a client that wants to interact with a resource server (FHIR or Notification endpoint) must obtain an access token from an authorization server before it can interact with that resource server. The client must present this access token as bearer token in the HTTP Authorization header of each request to the resource server as specified in . For further information on the transaction involved, please go to [Twiin-07 \| Token Request](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md) --- version: "TA150" language: "nl" --- # 10.4.6 \| TTA - Localisation Localisation is searching the sources that (might) have relevant information on the client. Localisation on a broad level is done via an interface [Mitz](https://vzvz.atlassian.net/wiki/spaces/MA11/pages/829655816/Koppelvlakken)offers. This means the GTK should offer Mitz Connector functionality when an explicit patient consent is necessary for the information exchange the GTK supports. With the so-called [open authorization query](https://www.mitz-toestemming.nl/sites/default/files/2022-05/VZVZ_Mitz_Implementatiehandleiding_OpenGesloten_v3.8.0.pdf) a healthcare provider can ask Mitz which other healthcare providers maintain records of a certain client may and can be consulted for one or more data categories. The result gives 0 or more healthcare providers (identified with URA) that have client consent to share the requested datatype and *might* have it. The URA-identifier in combination with the type of electronic service(s) that need to be addressed can be used as search parameter to find corresponding Twiin GTK interfaces in ZORG-AB (see [addressing](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-8-tta-addressing.md)). --- version: "TA150" language: "nl" --- # 10.4.3 \| TTA - Patient Consent In certain use cases that require specific patient consent, Twiin mandates the use of Mitz. Mitz is an online consent management system that allows patients to manage their consent choices for the exchange of medical data between healthcare providers. If a component is a (source) GTK and needs to offer Mitz Connector functionality, it must support multiple Mitz interfaces as specified in the [Mitz Afsprakenstelsel](https://vzvz.atlassian.net/wiki/spaces/MA11/pages/828278059/Introductie) to be able to check a patient consent registered in Mitz. --- version: "TA150" language: "nl" --- # 10.4.5 \| TTA - Addressing To communicate between GTK's, the technical endpoints must be known. In the addressing functionality ZORG-AB technical endpoints of all Twiin Participants and their GTK's are published. These endpoints are registered and kept up tot date in ZORG-AB by the Twiin governance. In this way Twiin makes reliable addressing information public to all GTK's. However, the use of ZORG-AB is not requirement, and alternate means of obtaining addressing information is permitted. It is not mandatory to use the ZORG-AB interfaces, it is mandatory for the GTK management organisations to inform Twiin about (changes in) the addressing information. To search for GTK endpoints with ZORG-AB, you can use the Get_Organization and Get_Endpoint transactions. When additional internal routing is necessary, the Twiin Participant in question is responsible for making relevant routing information available to other participants. This information may be retrieved by other participants using the applicable Twiin transactions for routing information retrieval, such as: * Get HealthcareService (to determine the appropriate internal service or organisational context) * Get ActivityDefinition / PlanDefinition (to determine the expected action or workflow step) These transactions enable the requesting party to obtain sufficient information to correctly populate and direct the notification or workflow Task. --- version: "TA150" language: "nl" --- # 10.4.4 \| TTA - Logging In the context of exchanging medical information, every component involved is required to keep a record of its actions. This process is called logging. The logging of actions follows two standards: NEN7513 and IHE ATNA profile. If a component is an Audit Record Repository (server), it must support all transactions. On the other hand, if a component sends logging (client), it can choose any transaction it wants to use. [IHE ITI-20 \| Record Audit Event](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-1-ihe-iti-20-record-audit-event.md) Both the NEN7513:2024 standard and the IHE ATNA profile only cover the logging of an access/data exchange events. The fact that, in an OAuth implementation, access tokens are first requested, issued, and possibly revoked is not explicitly addressed in these logging standards and profiles. Therefore, there does not appear to be any mandatory requirement to log such events. As a result, this may create a challenge later on when setting up monitoring and alerting for abuse patterns or unauthorized use. --- version: "TA150" language: "nl" --- # 10.2 \| Kern Volume 0b - Generieke functies Naast de communicatiepatronen, die op generiek niveau beschrijven welke vormen van gegevensuitwisselingen mogelijk zijn, zijn er ook zogenaamde generieke functies. Dit zijn functionaliteiten die door meerdere typen gegevensuitwisselingen ingevuld moeten worden. Veel van deze generieke functies borgen een stukje vertrouwen in de uitwisselingsketen, zoals identificatie en authenticatie, maar sommige generieke functies zijn ondersteunend zoals bijvoorbeeld het lokaliseren van medische gegevens of een terminologieserver die kan vertalen van en naar verschillende codestelsels (nu niet uitgewerkt binnen Twiin). Omdat zorgaanbieders en ICT-leveranciers niet voor iedere gegevensuitwisseling een andere implementatie willen hebben van een generieke functie proberen we over de gegevensuitwisselingen heen eenzelfde technische uitwerking van een generieke functie te maken. Dit gebeurt, net als bij de communicatiepatronen, in een zogenaamde Technical Agreement/Technische Afspraak (TA). Dit onderscheid in een techniek-agnostische functionele beschrijving van een generieke functie en de specifieke technische implementatie zie je weer terug in het onderscheid dat gemaakt is in de verschillende volumes. Het kan zijn dat voor de implementatie van een generieke functie gekozen is/wordt om dit in een technische implementatie te ondersteunen die door meerdere partijen gebuikt wordt of zelfs moet worden. Dit noemen we dan een gemeenschappelijke voorziening, zie ook de definitie uit de NVS: . Vanuit het Ministerie van Volksgezondheid, Welzijn en Sport is er een [programma](https://www.datavoorgezondheid.nl/generieke-functies)gestart waarin bepaalde generieke functies op landelijk niveau worden ontworpen. Twiin is nauw betrokken bij deze ontwikkelingen en zal aansluiten op de keuzes die op landelijk niveau worden gemaakt. Overzicht van (in Twiin uitgewerkte) generieke functies: * [10.2.1 \| Generieke functie - Identificatie en Authenticatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-7-generieke-functie-identificatie-en-authenti.md) * [10.2.2 \| Generieke functie - Autorisatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-6-generieke-functie-autorisatie.md) * [10.2.3 \| Generieke functie - Toestemming](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-10-generieke-functie-toestemming.md) * [10.2.4 \| Generieke functie - Logging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-9-generieke-functie-logging.md) * [10.2.5 \| Generieke functie - Adressering](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-7-8-generieke-functie-adressering.md) * [10.2.7 \| Generieke functie - Netwerkbeveiliging](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-1-12-generieke-functie-netwerkbeveiliging.md) --- version: "TA150" language: "nl" --- # 10.3 \| Kern Volume 1a - Technical Agreements - CP The goal of this volume is to describe the Twiin generic, reuseable exchange patterns (Dutch: Twiin communicatiepatronen) in the format of Technical Agreements. General remarks on the transaction schemas: * The transaction schemas are intended for the availability of all forms of data. The term 'dataset' refers to: * zib-based datasets, such as BgZ * Individual healthcare information building blocks * Other datasets * Documents (e.g., PDFs for correspondence) * Transaction specifications based on: * Documents: IHE XDS/XCA, HL7 FHIR * Resources: Based on HL7 FHIR * [10.3.1 \| TTA FHIR - Notified pull](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-3-tta-fhir-notified-pull.md) --- version: "TA150" language: "nl" --- # 10.5.1 \| Twiin-01 \| Send Notification Task This section describes the transaction needed for the notification. ## Scope ![Twiin-01.png](https://afsprakenstelsel.twiin.nl/__attachments/a_685b495f560c76ce95516565ab632c7aa42162f0d60c289a12f3f13bfd3ed5f0/Twiin-01.png?cb=9c0d914c00b07e8342a4c1413fd143ff) This transaction delivers a notification from the Sending GTK to the Receiving GTK based on the specified referral. ## Use Case Roles **Actor:**Sending GTK **Role:**Sends Notification Tasks on behalf of a referring user. **Actor:**Receiving GTK **Role:** Receives and processes Notification Tasks ## Referenced Standards * HL7® FHIR® standard STU3 ## Messages ### Request message The Notification message is sent by the Sending GTK when it needs to notify the Receiving GTK about one or more FHIR® resources that have been made available to the Receiving GTK. The Notification that is sent to the Receiving GTK must be able to convey at least the following details: * Identification of Sending GTK, Sending Organization and practitioner * Identification of Receiving Organization * References to individual FHIR® resources that have been made available at the Sending GTK * FHIR® search or read queries that can be used to retrieve FHIR® resources that have been made available at the Sending GTK * Authorization base (see [Twiin-07 \| Token Request \| Authorization base](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-base) ) The payload of this message consists of a resource that contains at least the details mentioned above. This message is sent to communicate both a new and an updated data set to the Receiving GTK. The message results in a Task instance that will be referred to as the Notification Task. For the time being, the STU3 version of the FHIR® standard will be used because this TA will first be applied in the context of the BgZ (Basisgegevensset Zorg). Within that context, data is exchanged based on FHIR® STU3. As soon as data has to be exchanged using the Notified Pull pattern for newer FHIR® versions, it becomes opportune to provide or adopt a specification of the Notification for the corresponding FHIR® version. The Sending GTK must initiate the Notification message using a [create](https://hl7.org/fhir/STU3/http.html#create) interaction, i.e. sending an HTTP POST request to the Task endpoint of the Receiving GTK. The media type of the HTTP body must be either *application/fhir+json* or *application/fhir+xml*. When generating the Notification message, the Sending GTK must set the Task attributes as specified in the table below. For complete information on constructing a FHIR® Task Resource, see . |--------------------------------------|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Attribute** | **Card.** | **Description** | | **definitionReference** | 0..1 | This element will be used for routing purposes. The value could determine the organisational unit which will handle the notification. The display of this reference should be filled if no reference to a workflow Task exists and this value shall reference a valid ActivityDefinition resource. See also: [10.4.5 \| TTA - Addressing](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-8-tta-addressing.md) The referenced ActivityDefinition may be retrieved by the requesting system using transaction [Twiin-08](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-5-11-twiin-08-get-activitydefinition-plandefinition.md). This allows the requesting system to obtain additional information on: * the expected action or workflow step * required or expected input for processing the notification * any constraints relevant for interpreting or handling the Task The retrieval of the ActivityDefinition is based on the reference provided in the definitionReference element. The requesting system may resolve this reference and perform a FHIR read interaction as specified in [Twiin-08](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-5-11-twiin-08-get-activitydefinition-plandefinition.md). If the referenced ActivityDefinition includes a reference to a PlanDefinition, this may optionally be retrieved by the requesting system to obtain additional workflow context. | | **basedOn** | 0..\* | Optional reference to a [request-Type resource](https://hl7.org/fhir/workflow.html#list) that produced this event. If a workflow has been initiated and a Workflow Task is present, this must be referenced. | | **groupIdentifier** | 1..1 | Unique identifier of the data set that is made available. An update to an existing data set at the Sending GTK triggers a new Notification Task, and thus a new Notification Task instance. Multiple Notifications Tasks on the same data set must share one unique identifier so that the Receiving GTK can identify them as relating to the same data set at the Sending GTK. | | **identifier** | **1** ..**1** | Business identifier of the task. This is a required field for traceability and cancellation of individual Notifications. | | **status** | 1..1 | The state communicated by this event. Fixed value: * requested See also: | | **intent** | 1..1 | Indicates the "level" of actionability associated with the Task[^\[2\]^](#). Preferred value: * proposal See also: | | **code.coding** | **1**..1 | A code briefly describing what the task involves: * system = "http://fhir.twiin.nl/fhir/CodeSystem/TaskCode" * code = "pull-notification" | | **restriction.period** | 0..1 | The period during which the data will be available for retrieval. | | **requester.agent.identifier** | 1..1 | Identifier of the system that created this Notification. This could be the originating EHR System or the routing gateway system, dependent on which system created the Notification Task. | | **requester.onBehalfOf.identifier** | **1**..1 | Identifier of the Organization at which the data has been made available. The identifier shall be in the system "http://fhir.nl/fhir/NamingSystem/ura" | | **owner.identifier** | **1**..1 | Identifier of the Receiving Healthcare Organization. The identifier shall be in the system "http://fhir.nl/fhir/NamingSystem/ura" | | **input:authorization-base** | **1** ..**1** | The [Twiin-07 \| Token Request \| Authorization base](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-base) to be used when retrieving the data. Constraints: * type.coding * system = "http://fhir.twiin.nl/fhir/CodeSystem/TaskParameter" * code = "authorization-base". * valueString | | **input:get-workflow-task** | 0..1 | An indicator to show whether or not all available resources are part of this Notification. Constraints: * type.coding * system = "http://fhir.twiin.nl/fhir/CodeSystem/TaskParameter" * code = "get-workflow-task" * valueBoolean Where valueBoolean: * true, the basedOn Workflow Task must be retrieved to get all available resources; * false (default), all available resources are available in the next (two) input slices. If this input slice is not added, the presumed value shall be false. | | **input: read-available-resource** | 0..\* | The FHIR®-read interactions that can be performed to retrieve the data that was made available. Constraints: * type.coding (one or more of:) * *Generic typing:* * system = "http://hl7.org/fhir/restful-interaction" * code = "read" * *SNOMED CT typing****(deprecated)****:* * system = "http://snomed.info/sct" * code = a SNOMED CT code * *LOINC typing****(deprecated)****:* * system = "http://loinc.org" * code = a LOINC code * *FHIR profile typing* ***(prefered)***: * system = "http://fhir.twiin.nl/fhir/NamingSystem/FhirProfile" * code = a FHIR profile-id, e.g. "http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse" * valueReference format * \[resourcetype\]/\[id\] Where: * resourcetype denotes a FHIR® resourcetype; * id represents a logical id of a FHIR® resource instance. | | **input: query-available-resources** | 0..\* | The FHIR®-search interactions that can be performed to retrieve the data that was made available. Constraints: * type.coding (one or more of:) * *Generic typing:* * system = "http://hl7.org/fhir/restful-interaction" * code = "search-type" * *SNOMED CT typing****(deprecated)****:* * system = "http://snomed.info/sct" * code = a SNOMED CT code * LOINC typing***(deprecated)***: * system = "http://loinc.org" * code = a LOINC code * *FHIR profile typing* ***(prefered)***: * system = "http://fhir.twiin.nl/fhir/NamingSystem/FhirProfile" * code = a FHIR profile-id, e.g. "http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse" * valueString format * \[resourcetype\]{?\[parameters\]} Where: * Resourcetype denotes a FHIR® resourcetype; * parameters can be added to refine a FHIR®-search. | The Sending GTK MAY choose not to list the available FHIR® resources in Task.input. In that case, the Sending GTK MUST provide a reference to a Workflow Task resource in Task.basedOn. This Workflow Task MUST list the available FHIR® resources in Task.input, in the same format that is specified for the Notification Task. Additionally, in this case the Notification Task MUST have an entry in Task.input with the following values: * Task.input.type.coding.system: "http://fhir.twiin.nl/fhir/CodeSystem/TaskParameter" * Task.input.type.coding.value: "get-workflow-task" * Task.input.valueBoolean: true The Receiving GTK must accept both media types *application/fhir+json* and *application/fhir+xml*. On receiving the submission, the Receiving GTK must validate the resource and respond with one of the HTTP codes defined in the [10.5.1 \| Twiin-01 \| Send Notification Task \| Response message](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-1-twiin-01-send-notification-task.md#Response-message) . The Notification should trigger an event in the Receiving GTK to facilitate the expected Pull. Persistence of the Notification Task as a FHIR® resource is not required, whether it is necessary to persist is purely up to the receiving GTK and its internal implementation. When the data set for which a Notification message has been sent is updated in the Sending GTK, the Sending GTK must inform the Receiving GTK about this update by sending a new Notification Message. In this case, Task.input:read-available-resource and Task.input:query-available-resources should only list the updated FHIR® resources. This way, the update can be communicated as a delta to the original data set. This relieves the Receiving GTK of determining which resources have changed in a larger set of resources. Note that the value of Task.identifier for the new Notification Task must differ from the value of Task.identifier Notification Task for the original data set, while the value of Task.groupIdentifier must be the same for all Notification Tasks on the same data set. This way, consecutive Notification Tasks on the same data set can be related to each other by the value of Task.groupIdentifier. ### Response message This message must be provided when a success or error condition needs to be communicated in response to an inbound request message. Success is only indicated once the Notification is received and completely processed. To enable the Sending GTK to know the outcome of technical / syntactic processing of the Notification Task, the Receiving GTK must return either an empty body or an OperationOutcome resource. This body must be accompanied with the correct HTTP status code, e.g.: * 200 OK -- Notification received and not persisted. * 201 Created -- Notification received and persisted. In this case http-headers Location and Etag should be filled. * 400 Bad Request -- Notification could not be parsed or failed basic FHIR® validation rules. * 404 Not Found -- Resource type not supported, or wrong endpoint. * 412 Precondition Failed -- The processing of the Notification Task could not be finished, since the criteria were not selective enough. * 422 Unprocessable Entity -- The Notification Task resource violated applicable server business rules. This should be accompanied by an OperationOutcome resource providing additional detail. Whether or not the resources referenced from any of the input elements can be retrieved shall not be a factor in the HTTP status. The Sending GTK processes the response according to application defined rules. --- version: "TA150" language: "nl" --- # 10.6.5 \| Addressing - ZORG-AB Transacties Beschreven in de "VZVZ ZORG-AB Implementatiehandleiding". Voor meer informatie: Dit is een externe transactie. Zie voor meer informatie: Binnen Twiin worden de volgende transacties gebruikt: * GET Organization * GET Endpoint [ZORG-AB 2.9.1](https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases) kent twee type interfaces die gebruikt kunnen worden: Native REST (OData URL conventies) en een HL7 FHIR interface. De GTK kan kiezen of, en zo ja welke interface van ZORG-AB gebruikt wordt. ZORG-AB dient nog wel aangepast te worden om ook Twiin Electronic Services te kunnen registreren. Hiervoor komt dan ook een zoekparameter, maar een gebruiker zou ook alle elektronische diensten van een bepaalde zorgaanbieder kunnen opvragen en daaruit een passende dienst kiezen (bijv die binnen het eigen domein). Twiin publiceert de GTK informatie in ZORG-AB. Het gebruik van de ZORG-AB transacties door een GTK is niet verplicht. --- version: "TA150" language: "nl" --- # 10.6.3 \| Patient Consent - Mitz Transacties Beschreven in de "Implementatiehandleiding Mitz (Open \& gesloten autorisatievraag)". Dit is een externe transactie. Zie voor meer informatie: [Mitz Afsprakenstelsel 1.0](https://vzvz.atlassian.net/wiki/spaces/MA11/overview). Binnen Twiin worden de volgende transacties gebruikt: * Open toestemmingsvraag Request conform XCPD \[TR-0020\] * Open toestemmingsvraag Request \[TR-0030\] * Gesloten toestemmingsvraag Request \[TR-0040\] * Gesloten toestemmingsvraag Response \[TR-0041\] voor een directe link naar de Mitz Implementatie handleiding kan onderstaande link gebruikt worden --- version: "TA150" language: "nl" --- # 10.5.2 \| Twiin-02 \| Cancel Notification Task This section describes the transaction needed for the cancellation of the notification. ## Scope ![Twiin-02.png](https://afsprakenstelsel.twiin.nl/__attachments/a_ef1b486ae981a7508bf9b6bd91c8e15977b923672bf5432223746a5e4a7b6bc7/Twiin-02.png?cb=33a65ce88ca33858244b529a6d8c189f) This transaction delivers a cancellation notification from the Sending GTK to the Receiving GTK based on the specified referral. Twiin only requires that a GTK can receive this message, sending and processing the message is optional. | **Actor** | **Sending Twiin-02** | **Receiving Twiin-02** | **Processing Twiin-02** | |---------------|----------------------|------------------------|-------------------------| | Sending GTK | Optional | N/A | N/A | | Receiving GTK | N/A | Mandatory | Optional | ## Use Case Roles **Actor:**Sending GTK **Role:**Sends Cancellation Notification Tasks on behalf of a referring user. **Actor:**Receiving GTK **Role:** Receives and processes Cancellation Notification Tasks ## Referenced Standards * HL7® FHIR® standard STU3 ## Messages ### Request message The Notification Cancellation request message is sent when the Sending GTK needs to send a cancellation of a previous Notification to the Receiving GTK. Just as the Notification message, the payload of this message consists of a FHIR® STU3 Task resource. The Sending GTK can cancel a previous Notification using a [conditional update](http://hl7.org/fhir/stu3/http.html#cond-update) interaction on the Task that represents that previous Notification. This is done by sending an HTTP PUT request to the Task endpoint of the Receiving GTK, where the value of Task.identifier of that previous Notification is included in the query parameters of the PUT request. The media type of the HTTP body must be either *application/fhir+json* or ++*application/fhir+xml*++. When generating the Notification Cancellation message, the Sending GTK must set the Task attributes as specified in the table below. For complete information on constructing a FHIR® Task Resource, see . |---------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Attribute** | **Card.** | **Description** | | identifier | **1** ..**1** | Business identifier of the Notification Task; the value of this identifier must be equal to the value of the identifier of the Notification Task that is to be cancelled. | | status | 1..1 | The state communicated by this event. Fixed value: * cancelled | | intent | 1..1 | Indicates the "level" of actionability associated with the Task[^\[1\]^](#). Preferred value: * proposal See also: | | code.coding | **1**..1 | A code briefly describing what the task involves: * system = "http://fhir.twiin.nl/fhir/CodeSystem/TaskCode" * code = "pull-notification" | In the absence of a reference to the patient (for example, within the Workflow Task), the token request for this cancellation SHALL include the patient's BSN within the assertion. The Receiving GTK must accept both media types *application/fhir+json* and *application/fhir+xml*. On receipt of the submission, the Receiving GTK must validate the resource and respond to the cancellation message according to the requirements specified in [Notification response](#). The Notification SHOULD trigger an event in the Receiving GTK to cancel any intended Pull interaction. Persistence of the Notification Task as a FHIR® resource is not necessary. ### Notification response This message must be provided when a success or error condition needs to be communicated in response to an inbound [Notification message](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-2-twiin-02-cancel-notification-task.md#Notification-message). Success is only indicated once the Notification is received and completely processed. To enable the Sending GTK to know the outcome of technical / syntactic processing of the Notification Task, the Receiving GTK must return either an empty body or an OperationOutcome resource. This body must be accompanied with the correct HTTP status code, e.g.: * 200 OK -- Notification received and not persisted. * 201 Created -- Notification received and persisted. In this case http-headers Location and Etag should be filled. * 400 Bad Request -- Notification could not be parsed or failed basic FHIR® validation rules. * 404 Not Found -- Resource type not supported, or wrong endpoint. * 412 Precondition Failed -- The processing of the Notification Task could not be finished, since the criteria were not selective enough. * 422 Unprocessable Entity -- The Notification Task resource violated applicable server business rules. This should be accompanied by an OperationOutcome resource providing additional detail. The Sending GTK processes the response according to application defined rules. --- version: "TA150" language: "nl" --- # 10.5.3 \| Twiin-03 \| Get Workflow Task This section describes the transaction of the retrieval of the Workflow Task. If a workflow Task is used, its definitionReference shall be populated and shall reference a valid ActivityDefinition resource. This reference is used to provide additional context on the expected action and may be used for routing and processing purposes. The referenced ActivityDefinition may be retrieved by the requesting system using transaction [Twiin-08](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-5-11-twiin-08-get-activitydefinition-plandefinition.md). The retrieval of the ActivityDefinition is based on the reference provided in the definitionReference element. The requesting system may resolve this reference and perform a FHIR read interaction as specified in [Twiin-08](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-5-11-twiin-08-get-activitydefinition-plandefinition.md). ## Scope ![Twiin-03a.png](https://afsprakenstelsel.twiin.nl/__attachments/a_d964b8b155ea7b43d0936cb6e40ab5826743140d23b369251d1aaed9a9805e4c/Twiin-03a.png?cb=0915ae5f15848b5c6cac0afc5f32403d) This transaction supports getting the Workflow Task by the Requesting System at the Resource Server. ## Use Case Roles **Actor:**Requesting GTK **Role:**Requests the workflow Task on behalf of a requesting user. **Actor:**Responding GTK **Role:** Processes the request and responds with the requested resource. ## Referenced Standards * HL7® FHIR® standard STU3 ## Messages ### Request message The requesting system wants to obtain the workflow Task for information about a known workflow. The workflow Task is retrieved using a the FHIR® read interaction, i.e. executing an HTTP GET request to the Task endpoint of the resource server. GET [base]/Task/[id] The requesting system may provide the HTTP Accept header. Valid values for this header are *application/fhir+json* or *application/fhir+xml*. If none is set, the resource server will use its default. ### Response message The resource server returns the workflow Task that is requested. The payload of this message consists of a resource that contains relevant information to the workflow. This message is returned to the Receiving System. The media type of the HTTP body must be either *application/fhir+json* or *application/fhir+xml*, based on the Accept header or default response content type. At this time there is no generic specification of the contents of the workflow Task more specific than the FHIR® specification. Persistence of the Workflow Task as a FHIR® resource is not necessary. When an error occurs an OperationOutcome resource must be returned with more details on the reason. The HTTP response must be accompanied with the correct HTTP status code, e.g.: * `200` OK -- The request is accepted and responded * `401` Not Authorized - Authorization is required for the interaction that was attempted * `404` Not Found -- The request could not be processed, i.e. the resource with that id doesn't exist. * `410` Gone -- The request could not be processed, because the resource does not exist anymore. The requesting system processes the response according to application defined rules. --- version: "TA150" language: "nl" --- # 10.5.4 \| Twiin-04 \| Search Resource(s) This section describes the transaction of the retrieval of the FHIR® resources. In the communication pattern notified pull these resources are referenced in the input field of the Notification or Workflow Task. These input fields contain valueString in the input slice: query-available-resources. ## 1. Scope ![Twiin-04a.png](https://afsprakenstelsel.twiin.nl/__attachments/a_6be3a0ea3ae6ab8c31b65b41d577cb8321fc0cdf648b30bff0561510b4595957/Twiin-04a.png?cb=0bd6019faabcf3cf8d391b56bfc23701) This transaction supports the request of resources by the Requesting GTK to the Resource Server. ## 2. Use Case Roles **Actor:**Requesting GTK **Role:**Sends a request for resources on behalf of a retrieving user. In the communication pattern notified pull, this is the Receiving GTK. **Actor:**Responding GTK **Role:** Processes the request and responds with the requested resources. Note: In the communication pattern notified pull, this is the Sending GTK. ## 3. Referenced Standards * HL7® FHIR® standard STU3 ## 4. Messages ### 4.1. Request message The requesting GTK wants to obtain the resources that were referenced in the Task. These resources are retrieved using a FHIR® search interaction, i.e. executing an HTTP GET request to the resource servers FHIR® endpoint. If there is a relative path, the input valueString must be appended to the FHIR® base-url. GET [base]/?parameter=value **Percent-encoding of query parameters** When constructing URLs that include query parameters (e.g., code=...), it is important to percent-encode any reserved characters that could cause syntactic ambiguity, in accordance with . **Exception** The slash character (/) may appear unencoded in query parameter values, as it is explicitly allowed in the query component of a URI per RFC 3986 (see Appendix A), and is commonly accepted by web servers and FHIR implementations. The requesting GTK may provide the HTTP Accept header. Valid values for this header are *application/fhir+json* or *application/fhir+xml*. If none is set, the resource server will use its default. ### 4.2. Response message The responding GTK returns the resource(s) that are requested. The payload of this message consists of a FHIR® Bundle resource that contains the requested resource(s). This message is returned to the Receiving GTK. The media type of the HTTP body must be either *application/fhir+json* or *application/fhir+xml*, based on the Accept header or default response content type. When an error occurs an OperationOutcome resource must be returned with more details on the reason. The HTTP response must be accompanied with the correct HTTP status code, e.g.: * `200` OK - The search was processed and a valid response was returned * `400` Bad Request - The search could not be processed or failed basic FHIR® validation rules * `401` Not Authorized - Authorization is required for the interaction that was attempted * `404` Not Found - The resource type not supported The requesting GTK processes the response according to application defined rules. --- version: "TA150" language: "nl" --- # 10.5.5 \| Twiin-05 \| Retrieve Resource This page describes the transaction of the retrieval of the FHIR® resources. In the communication pattern notified pull these resources are referenced in the input field of the Notification or Workflow Task. These input fields contain valueReference in the input slice: read-available-resource. ## Scope ![Twiin-5.png](https://afsprakenstelsel.twiin.nl/__attachments/a_d1468ff385a5e1ba0eb1b872e7ab5465c38aaf084fd761dcb99bdc5225f708ae/Twiin-5.png?cb=2b2b31960be3bf1e1cab1d071e7d26df) This transaction supports the request of resources by the Requesting System to the Resource Server. ## Use Case Roles **Actor:**Requesting GTK **Role:**Sends a request for a specific resource on behalf of a retrieving user. In the communication pattern notified pull, this is the Receiving GTK. **Actor:**Responding GTK **Role:** Processes the request and responds with the requested resource. Note: In the communication pattern notified pull, this is the Sending GTK. ## Referenced Standards * HL7® FHIR® standard STU3 ## Messages ### Request message The requesting GTK wants to obtain the resources that were referenced in the Task. These resources are retrieved using a FHIR® read interaction, i.e. executing an HTTP GET request to the resource servers FHIR® endpoint. If there is a relative path, the input valueReference must be appended to the FHIR® base-url. GET [base]// The requesting GTK may provide the HTTP Accept header. Valid values for this header are *application/fhir+json* or *application/fhir+xml*. If none is set, the resource server will use its default. ### Response message The responding GTK returns the resource that is requested. The payload of this message is the requested FHIR® resource. This message is returned to the requesting GTK. The media type of the HTTP body must be either *application/fhir+json* or *application/fhir+xml*, based on the Accept header or default response content type. When an error occurs an OperationOutcome resource must be returned with more details on the reason. The HTTP response must be accompanied with the correct HTTP status code, e.g.: * `200` OK - The search was processed and a valid response was returned * `401` Not Authorized - Authorization is required for the interaction that was attempted * `404` Not Found - The resource could not be found * `410` Gone - The resource was deleted The requesting GTK processes the response according to application defined rules. --- version: "TA150" language: "nl" --- # 10.5.6 \| Twiin-06 \| WADO-WS In the Netherlands the WADO-WS transaction is used in the SOAP based exchange pattern Indexed Pull. Although this is a deprecated transaction it is still used by most consumers to 'stream' images. Which means, request images in other formats than the 'full DICOM' format. (for example JPEG in lower resolution) A Requesting GTK can choose to implement the WADO-WS transaction An Responding GTK should be able to receive the WADO-WS transaction ![WADO.png](https://afsprakenstelsel.twiin.nl/__attachments/a_45240974af566e66876ce8429c419d0b7188529e514a4166fde80175f3261447/WADO.png?cb=d2ec5ec2348defb59693c678d73b9873) XML IHE XDS-I.b Imaging Document Source Retrieve Imaging Document Set Retrieve Rendered Imaging Document Set Deprecated Retrieve Rendered Imaging Document Set Retrieve Rendered Imaging Document Set Response Retrieve Document Set Response --- version: "TA150" language: "nl" --- # Twiin-07 \| Token Request This page describes the transaction of the retrieval of the OAuth tokens ## Scope ![image-20231030-142053.png](https://afsprakenstelsel.twiin.nl/__attachments/a_553e4fd85dbd0087b03e0a709fc7c22c64502e9a840bfd5bcff2f1a85c130c34/image-20231030-142053.png?cb=23051eff48a7010b0aa62c0bf4c3d7e5) This transaction supports the request of an authentication token by the Requesting System to the Resource Server. ## Use Case Roles **Actor:**Authorization Client **Role:**Client requesting an access token to authorize RESTful transactions. **Actor:**Authorization Server **Role:** Server that grants access tokens ## Relevant Standards * *OAuth 2.1*: The OAuth 2.1 Authorization Framework, published as draft-ietf-oauth-v2-1-01, 1 February 2021. * *JWT Access Token*: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, published as draft-ietf-oauth-access-token-jwt-10, September 2020. * *RFC4648*: The Base16, Base32, and Base64 Data Encodings, October 2006 * RFC6749: The OAuth 2.0 Authorization Framework, October 2012. * *RFC7519*: JSON Web Token (JWT), May 2015. * *RFC7522*: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants, May 2015. * *RFC7523*: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants, May 2015. * *RFC7515*: JSON Web Signature (JWS), May 2015. * *RFC7518*: JSON Web Algorithms (JWA), May 2015. * *RFC8705*: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, February 2020. ## Messages ### Request message The resource server must be able to authenticate the client as a trusted client. The client is specified as the **system** that submits the access token request (not to be confused with the **organization** for which that system is acting). The OAuth specs leave room for different authentication methods for client authentication. The authentication methods that are proposed in the OAuth 2.0 core specifications () all rely on the exchange of shared secrets. The use of shared secrets is considered as a security risk since they are prone to leakage. The use of an authentication method that relies on digital signatures using asymmetric cryptography offers better security. Therefore, the client must authenticate itself by providing a client assertion by means of a signed JWT as specified in . The client assertion is a JWS Compact Serialized JWT that consists of a header, a payload, and a signature. The signature is created using a key pair belonging to the initiating system or to a third party trusted by the initiating system. The header carries the claims listed below: |-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| | **Claim** | **Description** | **Required** | | **typ** | Token type, must be "JWT" | Yes | | **alg** | Cryptographic algorithm used to sign the client assertion. See . All algorithms are described at [Twiin-07 \| Token Request \| Signature Algorithms](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Signature-Algorithms). | Yes | | **kid** | Identifier of the key pair used to sign this JWT. See . | Yes | The payload contains a set of claims listed below: |-----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| | **Claim** | **Description** | **Required** | | **jti** | Unique identifier of the client assertion. See . The jti (JWT ID) is a unique identifier for a token and must not be reused. An assertion containing a duplicate jti (i.e., one that has been previously processed) shall be rejected to prevent replay attacks. Implementations should maintain a mechanism to track used jti values for the duration of their validity period. | Yes | | **iss** | Identifier of the system that issued the client assertion. See and . | Yes | | **iat** | The time at which the client assertion was issued. See . If there is an agreed age of a client assertion. | Conditional | | **exp** | The expiration time on or after which the client assertion shall not be accepted for processing. See and . The expiration time (exp) claim in the assertion shall not exceed 5 minutes (300 seconds) from the time of issuance. Any assertion with an exp value set beyond this limit must be rejected. | Yes | | **nbf** | The time before which the token shall not be accepted for processing. See and . | No | | **aud** | Identifier of the authorization server token endpoint where this client assertion is to be used. See and . | Yes | | **sub** | Identifier of the OAuth client that requests access. This claim must match the value of the client_id parameter in the access token request. Note that the client is specified as the system that submits the access token request. | Yes | The Issuer of the client assertion may include additional claims in the assertion, but the Issuer shall not require the authorization server to process these claims. The exchange of the public key that corresponds to the private key that was used to sign the client assertion between the Assertion Issuer and the authorization server is beyond the scope of this normative specification. This is the added value of Twiin. Twiin unambiguously describes the agreements that system providers typically need to make with each other.Note that the authorization server can authenticate the client on network level by the client certificate that the client must present during the mTLS handshake (see section [Network level security](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-2-5-tta-fhir-authentication-authorization.md)). In theory, this could be used by the authorization server to authenticate the client on application level. However, this may cause problems since it introduces additional and potentially unwanted requirements on TLS termination and related matters. Therefore, a client must always provide a client assertion in the access token request. #### Authorization grant OAuth 2.0 requires the use of an authorization grant to request an access token. As specified in "an authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token." OAuth 2.0 specifies several different authorization grants. Additionally, there are several RFC's that specify extension grants, e.g. . Because this TA applies to situations where a resource client is acting on behalf of a user (health professional) that works for an organization (healthcare provider), the use of the JWT Bearer Assertion authorization grant as specified in is the most suitable authorization grant. This means that the resource client must provide an authorization assertion in each access token request to identify the acting user, organization, and authorization base to prove that it is authorized to access the requested data. This authorization assertion acts as the authorization grant that the client can present to prove that it is authorized to access the protected resources. The authorization assertion is a JWS Compact Serialized JWT that consists of a header, a payload, and a signature. The signature is created using a key pair belonging to the initiating organization or to a third party trusted by the initiating organization. The header carries the claims listed below: |-----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| | **Claim** | **Description** | **Required** | | **typ** | Token type, must be "JWT" | Yes | | **alg** | Cryptographic algorithm used to sign the authorization assertion. See . All algorithms are described at [Twiin-07 \| Token Request \| Signature Algorithms](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Signature-Algorithms). | Yes | | **kid** | Identifier of the key pair used to sign this JWT. See . | Yes | The payload contains a set of claims that carry information required by NEN 7512 and NEN 7513. |------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| | **Claim** | **Description** | **Required** | | **jti** | Unique identifier of the authorization assertion. See . The jti (JWT ID) is a unique identifier for a token and must not be reused. An assertion containing a duplicate jti (i.e., one that has been previously processed) shall be rejected to prevent replay attacks. Implementations should maintain a mechanism to track used jti values for the duration of their validity period. | Yes | | **iss** | Identifier of the system that issued the authorization assertion. See and . | Yes | | **iat** | The time at which the authorization assertion was issued. See . This is only required if there is an agreed age of an authorization assertion. | Conditional | | **exp** | The expiration time on or after which the authorization assertion shall not be accepted for processing. See and . The expiration time (exp) claim in the assertion shall not exceed 5 minutes (300 seconds) from the time of issuance. Any assertion with an exp value set beyond this limit must be rejected. | Yes | | **nbf** | The time before which the token shall not be accepted for processing. See and . | No | | **aud** | Identifier of the authorization server token endpoint where this authorization assertion is to be used. See and . | Yes | | **sub** | Identifier of the **healthcare organization**that requests access. **URA nummer** is mandatory, *additionaly*other identifiers may be added. The codesystem (`issuing_system`) for the identifier is also mandatory. For the URA this is OID: 2.16.528.1.1007.3.3 [5.1 \| Vertrouwen: Identificatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-1-vertrouwen-identificatie.md) Allowed format for this identifier is: * `http://fhir.nl/fhir/NamingSystem/ura|` | Yes | | **sub_role** | Code of the type of the **organization** (healthcare supplier) that requests access. **RoleCodeNL** is mandatory. The codesystem (`issuing_system`) for the identifier is also mandatory. For the RoleCodeNL this is OID: 2.16.840.1.113883.2.4.15.1060 Sub role is required when the responding party needs to check the patient consent. For instance when a user does not have an authorization base when requesting patient information. | Conditional | | **user_id** | Identifier of the **responsible user**(healthcare professional) who requests access. **Preferred: UZI nummer** Allowed formats for this identifier are: * `urn:oid:2.16.528.1.1007.3.1.` (without leading zero of UZI) * `http://fhir.nl/fhir/NamingSystem/uzi-nr-pers|` [5.1 \| Vertrouwen: Identificatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-1-vertrouwen-identificatie.md) **User or system** In some cases a system is allowed to access data without a specific user being involved. Whenever there is a request for patient information, the identifier of the responsible user MUST be communicated. The only known exception to this rule is the retrieval of the Workflow Task that is requested based on the Notification Task in the TTA Notified Pull. | Yes | | **user_role** | Code of the role of the responsible user (healthcare professional) who requests access. **Preferred: UZI rolcode** Allowed formats for this code are: * `urn:oid:2.16.840.1.113883.2.4.15.111.` [5.1 \| Vertrouwen: Identificatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-1-vertrouwen-identificatie.md) User identification (user_id and user_role claims) is only required in the authorization assertion when access to patient data is requested. This implies that these claims are not required in authorization assertions used in access token requests for Notification endpoints. | Conditional | | **authorizer** | Identifier of the **healthcare organization**that grants access. **URA nummer** is mandatory, *additionaly*other identifiers may be added. The codesystem (`issuing_system`) for the identifier is also mandatory. For URA this is OID: 2.16.528.1.1007.3.3 [5.1 \| Vertrouwen: Identificatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-1-vertrouwen-identificatie.md) Allowed format for this identifier is: * `http://fhir.nl/fhir/NamingSystem/ura|` | Yes | | **authorization_base** | See [Authorization base](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-base) | No | | **patient** | Identifier of the patient for whom data is exchanged. [5.1 \| Vertrouwen: Identificatie](https://afsprakenstelsel.twiin.nl/normatief/ta150/5-1-vertrouwen-identificatie.md) Allowed format for this identifier is: * `urn:oid:2.16.840.1.113883.2.4.6.3.` (without leading zero of BSN) Patient identification is only required when the Sending System requests access to the Notification endpoint of the Receiving System and the Sending System does not provide a Workflow Task that refers to a Patient resource containing the BSN of the patient. This way, the Receiving System is always able to identify a patient by BSN based on a Notification. The Receiving System must support receiving the BSN through the patient claim. | Conditional | The Issuer of the authorization assertion may include additional claims in the authorization assertion, but the Issuer shall not require the authorization server to process these claims. The exchange of the public key that corresponds to the private key that was used to sign the authorization assertion between the Assertion Issuer and the authorization server is beyond the scope of this normative specification. Therefore, system vendors have to make mutual agreements about the exchange of these public keys. #### Authorization scope The scope defines the requested access to the FHIR Server as specified in . If a scope is provided in the access token request or access token response, it must be expressed in a string of space delimited scopes as defined in . The following additional requirements apply to the scope values: * When requesting an access token for a Notification endpoint at the Receiving System, the scope value must be one of: * system/Task.c?code=http://fhir.twiin.nl/fhir/CodeSystem/TaskCode\|pull-notification (create) * system/Task.u?code=http://fhir.twiin.nl/fhir/CodeSystem/TaskCode\|pull-notification (update) * When requesting an access token for a FHIR endpoint at the Sending System, the query parameters in the scopes must match (a subset of) the queries in the FHIR search requests listed in Task.input of the Notification Task (see [Notification message](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-1-twiin-01-send-notification-task.md)). The client must provide the requested scope in the access token request, except for cases where an authorization base is provided in the access token request as part of the authorization assertion. The authorization server must provide the granted access scope in the access token response in accordance with and the requirements mentioned above. The issued access token must grant access to the granted scope that the authorization server specifies in the access token response. The granted scope must be equal to or less than the scope that can be derived from the authorization base consent token. #### Access token request Based on the paragraphs above each access token request contains the parameters listed below: |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| | **Parameter** | **Value** | **Required** | | **grant_type** | "urn:ietf:params:oauth:grant-type:jwt-bearer" | Yes | | **assertion** | JWT authorization assertion as specified in paragraph [Authorization grant](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-grant). | Yes | | **client_assertion_type** | "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" | Yes | | **client_assertion** | JWT client assertion as specified in paragraph [Request message](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Request-message). | Yes | | **client_id** | ID of the resource client. This ID is issued by the authorization server. The value of the "client_id" parameter must identify the same client as is identified by the client assertion. | Yes | | **scope** | Space separated list of requested scopes, see paragraph [Authorization scope](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-scope). The scope must not be encoded before the `x-www-form-urlencoded` encoding. e.g. before encoding it should look like: patient/Observation.s?code=http://loinc.org|29463-7 | Conditional | Note that the access token request effectively contains two JWT assertions: 1. A client assertion that is used to authenticate the client. This assertion identifies and authenticates the **system** that is requesting access. 2. An authorization assertion that is used as an authorization grant. This assertion identifies both the **organization** and **user** that are requesting access. Separating client authentication from client authorization in two separate assertions enables the client to select different Assertion Issuers for the two assertions. The targeted authorization server must register both Issuers as trusted Assertion Issuers for a specific client. #### Access token requirements The access token will be processed only by the party that issued the access token. Therefore, the form and contents of the token are determined by the authorization server (audience), so the access token is opaque to the resource client. The resource client should not take any dependency on the format or contents of an access token. The authorization server MAY issue certificate bound access tokens as specified in , but this is not mandatory. To enable the server to issue certificate bound access tokens, the client MUST support mTLS for access token and resource requests as specified in section [Network level security: mTLS 1.3](https://vzvz.atlassian.net/wiki/x/HgOnBg). The validity period of an OAuth 2.0 access token shall not exceed 15 minutes. Implementations must ensure that the exp (expiration) claim in the token is set accordingly, with a maximum lifetime of 900 seconds (15 minutes) from the time of issuance. Clients should be designed to handle token expiration by obtaining a new access token as required. ### Authorization base When the Sending System receives a request from the Receiving System to access certain data, it is the primary responsibility of the Sending System to verify that the Receiving System is authorized to access that data. When a system receives an authorization base, it shall not use the UZI-rolcode to determine whether access should be granted. When publishing data on a resource server to be collected by the Receiving System, many Sending Systems register the authorization to access that data as an authorization base of some kind. To facilitate that authorization process, the Sending System may submit the authorization base (or a reference to it) to the Receiving System as part of the Notification (see section [Notification message](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-1-twiin-01-send-notification-task.md#Messages)). If the Receiving System received an authorization base in the Notification, it must include that authorization base in the access token request to the Sending System (see section [Authorization grant](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-grant)). This enables the authorization server of the Sending System to determine if the requested access can be granted based on the provided authorization base. Since an authorization base is to be processed by the Sending System only, the form and contents of an authorization base are determined by the Sending System. The Receiving System should not take any dependency on the format or contents of an authorization base. ### User authentication Healthcare professionals are identified in their EHR system by logging in with their personal account. When a user of the Receiving System wants to request resources at the Sending System, the Sending System must be able to identify the user at the Receiving System as a legitimate healthcare professional who is working for the receiving organization before it can provide the requested data. Therefore, the Receiving System must implement the appropriate means to ensure the authenticity of the user. The Sending System can identify the healthcare professional at the receiving organization that is requesting patient data by the following claims in the authorization assertion of the access token request (see [Authorization grant](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-7-twiin-07-token-request.md#Authorization-grant)): * **sub**: Identifier of the healthcare organization * **user_id**: Identifier of the responsible user (healthcare professional) * **user_role**: Code of the role of the responsible user (healthcare professional) The type of identifiers used for organizations and users is beyond the scope of this TA. The same applies to the use of role codes. ### Trust relationships The picture below shows the different roles involved in the interactions, and clarifies the dependencies between these roles. ![image-20230517-140924.png](https://afsprakenstelsel.twiin.nl/__attachments/a_2ec98106e02103219a3e13fcf05a4f63181aad38c218d756a47f80166e046bd9/image-20230517-140924.png?cb=3f1b56e3af5876b55146d4d2002bd8b6) The Sending System hereby performs the following roles: * Notification Client; * Resource Server Endpoint. The Receiving System performs the roles: * Notification Server Endpoint; * Resource Client. Sending System and Receiving System both implement the role of Authorization Server. The role of Assertion Issuer can be performed by a third-party, but can also be performed by the Sending System or by the Receiving System. Assertion Issuers producing client assertions do not necessarily have to produce authorization assertions as well. Different Issuers can be used for these types of assertions. Before issuing a client assertion or an authorization assertion, the Assertion Issuer has to make sure that applicable requirements regarding user authentication and other mutual security agreements between the Sending System and Receiver System have been met. Trust and required level of user authentication between parties has to be arranged and agreed upon prior to performing the interaction. ### Signature Algorithms For verifying cryptographic tokens, we enforce the use of the following algorithms: * **ES256** (Elliptic Curve P-256 with SHA-256) * **ES512** (Elliptic Curve P-521 with SHA-512) * ***PS256*** *(RSASSA-PSS with SHA-256) -- Planned for future use* Implementations must explicitly reject any other algorithms to ensure security and compliance with best practices. For signing cryptographic tokens, one of the supported algorithms should be used. --- version: "TA150" language: "nl" --- # 10.5 \| Kern Volume 2a - Transactions - CP Under this section, the transactions are described of the generic core of Twiin herein all transactions between GTK's are described and a reference is made to the transactions of the common facilities. * [10.5.1 \| Twiin-01 \| Send Notification Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-1-twiin-01-send-notification-task.md) * [10.5.2 \| Twiin-02 \| Cancel Notification Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-2-twiin-02-cancel-notification-task.md) * [10.5.3 \| Twiin-03 \| Get Workflow Task](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-3-twiin-03-get-workflow-task.md) * [10.5.4 \| Twiin-04 \| Search Resource(s)](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-4-twiin-04-search-resource-s.md) * [10.5.5 \| Twiin-05 \| Retrieve Resource](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-5-twiin-05-retrieve-resource.md) * [10.5.6 \| Twiin-06 \| WADO-WS](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-3-6-twiin-06-wado-ws.md) * [10.5.7 \| IHE ITI-38 \| Cross Gateway Query](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-2-ihe-iti-38-cross-gateway-query.md) * [10.5.8 \| IHE ITI-39 \| Cross Gateway Retrieve](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-3-ihe-iti-39-cross-gateway-retrieve.md) * [10.5.9 \| IHE RAD-75 \| Cross Gateway Retrieve Imaging Document Set](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-6-ihe-rad-75-cross-gateway-retrieve-imaging-d.md) * [10.5.10 \| IHE ITI-90 \| Get Healthcare Service](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-5-10-ihe-iti-90-get-healthcare-service.md) * [10.5.11 \| Twiin-08 \| Get ActivityDefinition / PlanDefinition](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-5-11-twiin-08-get-activitydefinition-plandefinition.md) These transactions are generic and used within multiple "zorgtoepassingen". Each Twiin "zorgtoepassingen" has its own implementation guide containing references to this section. In this section, the IHE transactions of the generic core of Twiin are described, all IHE transactions between GTK's are described and a reference is made to the transactions of the common facilities. --- version: "TA150" language: "nl" --- # IHE ITI-20 \| Record Audit Event ## Scope At every non-logging transaction an audit event is recorded and sent to the Audit Record Repository. ### Use Case Roles ## Referenced standards |----------------|---------------------------------------------------------------------------------------------------------------| | RFC5424 | The Syslog Protocol. | | RFC5425 | Transmission of Syslog Messages over TLS | | RFC5426 | Transmission of Syslog Messages over UDP | | RFC7525 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | | DICOM | DICOM PS3.15 Annex A.5 | | ASTM E2147-01 | Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems | | NIST SP 800-92 | Guide to Computer Security Log Management. | | W3C XML 1.0 | Extensible Markup Language (XML) 1.0 | | *HL7 FHIR* | *Release 4* [*http://hl7.org/fhir/R4/index.html*](http://hl7.org/fhir/R4/index.html) | | *RFC4627* | *The application/json Media Type for JavaScript Object Notation (JSON)* | ## Messages ### Send Audit Event -- Syslog Interaction For more technical specification, see the original document: NB: This transaction is always performed in combination with the [transaction ITI-40](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-5-ihe-iti-40-provide-x-user-assertion.md) where user data is added in a SAML token. NB: All transactions are logged with an ITI-20 audit transaction, see IHE:ITI volume 2 for the correct implementation. ***Send Audit Resource Rerquest Message - FHIR Feed Interaction*** This is part of the ITI TF Supplement: Add RESTful ATNA (Query and Feed) - Status: Trial Implementation For more technical specification, see the original document: paragraph 3.20.4.2 of ***Send Audit Bundle Request Message - FHIR Feed Interaction*** This is part of the ITI TF Supplement: Add RESTful ATNA (Query and Feed) - Status: Trial Implementation For more technical specification, see the original document: paragraph 3.20.4.3 of --- version: "TA150" language: "nl" --- # 10.4.1 \| TTA - Identification \& Authentication The world of identification and authentication in (Dutch) healthcare is changing rapidly. New regulation on European level (EHDS) is recently published and will come into effect the coming years. Also on and national level ([DIAZ](https://wetgevingskalender.overheid.nl/Regeling/WGK015084) law) and NEN7518 are currently developed. The [UZI-register](https://www.uziregister.nl/) will be replaced by the [DEZI-register](https://www.dezi.nl/) and new technologies for authentication, like digital wallets and supporting technical standards ([Verifiable Credentials](https://www.w3.org/TR/vc-overview/), [Decentralized Identifiers](https://www.w3.org/TR/did-1.1/)) will be come more broadly available and supported. Therefore Twiin does not set technical requirements that won't be future-proof in a few years. Identification and and authentication of healthcare workers and healthcare providers is important, though. Identification and authentication across the entire network help build the trust required for the exchange of medical data, therefore it is not surprising that NEN7512 defines specific requirements for this. --- version: "TA150" language: "nl" --- # 10.5.7.1 \| ITI-38 examples For reference only ## ITI-38 request XML urn:ihe:iti:2007:CrossGatewayQuery urn:uuid:7948cf8b-81fa-486d-a7d6-ca121b6b9c98 http://www.w3.org/2005/08/addressing/anonymous http://testing.interoplab.eu:8080 /interoplab__responding_gateway/rg/xcq '999999011^^^&2.16.840.1.113883.2.4.6.3&ISO' ('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved') ## ITI-38 response XML urn:ihe:iti:2007:CrossGatewayQueryResponse urn:uuid:7948cf8b-81fa-486d-a7d6-ca121b6b9c98 0a177cec96cc04e2fe4443cb213f7816abfe72b6 nl-NL 1.1.4567332.1.1 2459 999999011^^^&2.16.840.1.113883.2.4.6.3&ISO 20191023024209 2.16.840.1.113883.6.96 2.16.840.1.113883.5.25 1.3.6.1.4.1.19376.1.2.3 2.16.840.1.113883.2.4.15.1060 2.16.840.1.113883.6.96 2.16.840.1.113883.6.96 ## ITI-38 request incl. SAML-token (ITI-40) XML xds-bridge-xua-proxy u0aMCbaPxaD3NKUcm9RTKJ8nYu0= ca4w0ETLyPgQHWjUQS8FFTzNNrjt5fZ5+5LFWrao11H354IwHw0CksI8qD/GVZ6pkmbkwNPZV8Pf DlGsvzDstsytnSB7/8PNVberVJVehg7CwC/nd3SoL7aRpj96c8yxL9gaUDrU3EzoPy4j9Vb2UbF2 W8EXATeosHJjPTTnsnBGHVYBRfarqAv32Ll99cTG4fN03Vlz+IJAp/qBofD2Mgz0iJRoucwqjOes 9O5I8qRB60CIhEd7Z/P8X3hRNZULQQoZn8AyRHdoqY/AgLLUKE/JUQsxYKa3BbGJw7JmFPtI7I4c +wlM577HcMbfq8VjeS31QL8Pzj48rQV4AnsS9w== MIIDyzCCArMCAQEwDQYJKoZIhvcNAQELBQAwgasxCzAJBgNVBAYTAk5MMRUwEwYDVQQIDAxadWlk LUhvbGxhbmQxHzAdBgNVBAcMFkNhcGVsbGUgYWFuIGRlbiBJSnNzZWwxGjAYBgNVBAoMEVZBTkFE IEhlYWx0aCBDYXJlMRQwEgYDVQQLDAtEZXZlbG9wbWVudDELMAkGA1UEAwwCY2ExJTAjBgkqhkiG 9w0BCQEWFnhkc3RlYW1AdmFuYWRncm91cC5jb20wHhcNMTcxMTI4MTQyMzM5WhcNMTgxMTI4MTQy MzM5WjCBqjELMAkGA1UEBhMCTkwxFTATBgNVBAgMDFp1aWQtSG9sbGFuZDEfMB0GA1UEBwwWQ2Fw ZWxsZSBhYW4gZGVuIElKc3NlbDEaMBgGA1UECgwRVkFOQUQgSGVhbHRoIENhcmUxFDASBgNVBAsM C0RldmVsb3BtZW50MQowCAYDVQQDDAF4MSUwIwYJKoZIhvcNAQkBFhZ4ZHN0ZWFtQHZhbmFkZ3Jv dXAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuv+sbPxoGUh3H2FUBr3dnBEZ fUSMqbD/2rrADDrMZVh/RqZ+oBeQhOuD0enWt5+IMA/eZ4d8g5qUiU8gXAdpJ/49A7+kFZOL82jd zwga/XP2WPBLucmjw9rwjM3clHdWRdFsjF5Iw+NVo8cmY7Vebi673q7mWPIKY4vdFC2UBNQtblot YnswbvoQHRhXaTKjQ/zEp6viK/gD+o32ee0MSn/0d0jKhMVufvR1P3tzwAQnK6J/i5fDI3QnghKx 5KC7IHETv0/qskSTYQge40GJtjtOpgrP1xTEII2TnadBVevyBPdes4Wi/5RLYxpj8aWDNUXzRbcj HTRPDx5FUnOHGwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQARV+dsvKrfU1w46a3LTiAWn+V2Fx3c 1kHyj8FkOLFouHp8H/55nhOFlW7qskWHiILuEA7HN29kO+JenNUF0V9K2wrNV5tEMrvTKIFqXOxu VwO5Vu0tHE43VGNdbucuR2zD3irmsIpLdwDxkN/9NPMEBPLYu4g7+v896EM5c/3uJtaBfP0ufOGv Abx+nEBlGyTuMUPbgstTvwT/Tvkc0YFzIuz7wNAaWpkELd6Hj+9r/DMzbNshjKTs0WK9wffQxphJ NI4LW1L5LF6W84HQFGrP9+gwODLAHQ4bBKIOWXDxPXyLeMwjbm5hCKB/PE1oMu84iFsQwSzcPERz HbXy1EJU anton@ziekenhuis.nl OTV-ABB-REGISTER urn:oasis:names:tc:SAML:2.0:ac:classes:X509 urn:ihe:iti:2007:CrossGatewayQuery urn:uuid:ba8fc617-bcd1-467b-b1f7-87957a7ad16f http://www.w3.org/2005/08/addressing/anonymous http://testing.interoplab.eu:8080/interoplab__responding_gateway/rg/xcq '999999011^^^&2.16.840.1.113883.2.4.6.3&ISO' ('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved') ('CT^^1.2.840.10008.2.16.4') ('309964003^^2.16.840.1.113883.6.96') --- version: "TA150" language: "nl" --- # 10.5.7 \| IHE ITI-38 \| Cross Gateway Query ## Scope This transaction is used by the Requesting GTK to retrieve metadata. The Requesting GTK sends this request to all Responding GTK's where information is available. Prior to this transaction the Requesting GTK first needs to retrieve information about where metadata can be retrieved. This is needed to prevent excessive usage of the transaction to GTK's where no information is available. The Mitz open question specifications can be found on their website: [Bijlage \| Architectuurdocumenten](https://vzvz.atlassian.net/wiki/x/-xJfMQ) ### Use Case Roles ![ITI-38.png](https://afsprakenstelsel.twiin.nl/__attachments/a_bd838ae2e5ce51b580770e16cc102fe1dd5080f29bb7bdd388c9e0329236eb10/ITI-38.png?cb=4e2f125108c496e1954085b3c7287a7e) This transaction uses SOAP v1.2 and Synchronous Web Services. ## Referenced standards Implementers of this transaction shall comply with all requirements described in[Web Services for IHE Transactions.](https://profiles.ihe.net/ITI/TF/Volume2/ch-V.html#Appendix%20V) |------------|---------------------------------------------------| | ebRIM | OASIS/ebXML Registry Information Model v3.0 | | ebRS | OASIS/ebXML Registry Services Specifications v3.0 | | ITI TF-3:4 | Metadata used in Document Sharing profiles | ## Messages ### Cross Gateway Query For more technical specification, see the original document: The ITI-38 transaction supports the optional $**targetCommunityIdList** parameter allowing an Initiating Gateway actor to request a response from one or more "home communities" that are served by the Responding Gateway actor. The follow behavior is expected |----------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------| | **$targetCommunityIdList** | **Expected behavior** | | **Not included** | Backward compatibility use-case. The responding gateway is expected to return the same response as if no $targetCommunityIdlist was included in the request. | | **Empty** | The Responding gateway respond with an error. | | **Includes homeCommunityIds that are not known to the Responding Gateway** | Responding returns a partial success response indicating which homeCommunityIds were not recognized. The Initiating gateway should not treat this as an error. | | **Includes homeCommunityIds that are known to the Responding Gateway** | Responding returns a success response. | NB: This transaction is always performed in combination with the [transaction ITI-40](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-5-ihe-iti-40-provide-x-user-assertion.md) where user data is added in a SAML token. NB: All transactions are logged with an ITI-20 audit transaction, see IHE:ITI volume 2 for the correct implementation." --- version: "TA150" language: "nl" --- # 10.5.8.1 \| ITI-39 examples For reference only ## ITI-39 request In the example below, two documents are retrieved XML urn:ihe:iti:2007:RetrieveDocumentSet urn:uuid:6d090619-abb5-4758-8146-f71a9e1868a4 http://www.w3.org/2005/08/addressing/anonymous http://testing.interoplab.eu:8080/interoplab__repository/rep/ret urn:oid:1.1.4567334.1.4 1.1.4567332.1.1 1.3.6.1.4.1.12559.11.13.2.1.227 urn:oid:1.1.4567334.1.4 1.1.4567332.1.1 1.3.6.1.4.1.12559.11.13.2.1.231 ## ITI-39 response In the example below, the response shows a DICOM object (KOS). The multipart is not shown in the example. XML urn:ihe:iti:2007:CrossGatewayRetrieveResponse urn:uuid:818cf943-1127-47b9-b5d7-16feedac311b http://www.w3.org/2005/08/addressing/anonymous uuid:353219ca-e86a-4590-b49a-3587dd7394ed 1.3.6.1.4.1.12559.11.34.1.3.1 2.25.329127271855121542029064767251061713151 1.3.6.1.4.1.12559.11.34.1.3.1 2.25.329127271855121542029064767251061713151 application/dicom ## ITI-39 request including SAML-Token XML xds-bridge-xua-proxy u0aMCbaPxaD3NKUcm9RTKJ8nYu0= ca4w0ETLyPgQHWjUQS8FFTzNNrjt5fZ5+5LFWrao11H354IwHw0CksI8qD/GVZ6pkmbkwNPZV8Pf DlGsvzDstsytnSB7/8PNVberVJVehg7CwC/nd3SoL7aRpj96c8yxL9gaUDrU3EzoPy4j9Vb2UbF2 W8EXATeosHJjPTTnsnBGHVYBRfarqAv32Ll99cTG4fN03Vlz+IJAp/qBofD2Mgz0iJRoucwqjOes 9O5I8qRB60CIhEd7Z/P8X3hRNZULQQoZn8AyRHdoqY/AgLLUKE/JUQsxYKa3BbGJw7JmFPtI7I4c +wlM577HcMbfq8VjeS31QL8Pzj48rQV4AnsS9w== MIIDyzCCArMCAQEwDQYJKoZIhvcNAQELBQAwgasxCzAJBgNVBAYTAk5MMRUwEwYDVQQIDAxadWlk LUhvbGxhbmQxHzAdBgNVBAcMFkNhcGVsbGUgYWFuIGRlbiBJSnNzZWwxGjAYBgNVBAoMEVZBTkFE IEhlYWx0aCBDYXJlMRQwEgYDVQQLDAtEZXZlbG9wbWVudDELMAkGA1UEAwwCY2ExJTAjBgkqhkiG 9w0BCQEWFnhkc3RlYW1AdmFuYWRncm91cC5jb20wHhcNMTcxMTI4MTQyMzM5WhcNMTgxMTI4MTQy MzM5WjCBqjELMAkGA1UEBhMCTkwxFTATBgNVBAgMDFp1aWQtSG9sbGFuZDEfMB0GA1UEBwwWQ2Fw ZWxsZSBhYW4gZGVuIElKc3NlbDEaMBgGA1UECgwRVkFOQUQgSGVhbHRoIENhcmUxFDASBgNVBAsM C0RldmVsb3BtZW50MQowCAYDVQQDDAF4MSUwIwYJKoZIhvcNAQkBFhZ4ZHN0ZWFtQHZhbmFkZ3Jv dXAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuv+sbPxoGUh3H2FUBr3dnBEZ fUSMqbD/2rrADDrMZVh/RqZ+oBeQhOuD0enWt5+IMA/eZ4d8g5qUiU8gXAdpJ/49A7+kFZOL82jd zwga/XP2WPBLucmjw9rwjM3clHdWRdFsjF5Iw+NVo8cmY7Vebi673q7mWPIKY4vdFC2UBNQtblot YnswbvoQHRhXaTKjQ/zEp6viK/gD+o32ee0MSn/0d0jKhMVufvR1P3tzwAQnK6J/i5fDI3QnghKx 5KC7IHETv0/qskSTYQge40GJtjtOpgrP1xTEII2TnadBVevyBPdes4Wi/5RLYxpj8aWDNUXzRbcj HTRPDx5FUnOHGwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQARV+dsvKrfU1w46a3LTiAWn+V2Fx3c 1kHyj8FkOLFouHp8H/55nhOFlW7qskWHiILuEA7HN29kO+JenNUF0V9K2wrNV5tEMrvTKIFqXOxu VwO5Vu0tHE43VGNdbucuR2zD3irmsIpLdwDxkN/9NPMEBPLYu4g7+v896EM5c/3uJtaBfP0ufOGv Abx+nEBlGyTuMUPbgstTvwT/Tvkc0YFzIuz7wNAaWpkELd6Hj+9r/DMzbNshjKTs0WK9wffQxphJ NI4LW1L5LF6W84HQFGrP9+gwODLAHQ4bBKIOWXDxPXyLeMwjbm5hCKB/PE1oMu84iFsQwSzcPERz HbXy1EJU anton@ziekenhuis.nl OTV-ABB-REGISTER urn:oasis:names:tc:SAML:2.0:ac:classes:X509 urn:ihe:iti:2007:RetrieveDocumentSet urn:uuid:6d090619-abb5-4758-8146-f71a9e1868a4 http://www.w3.org/2005/08/addressing/anonymous http://testing.interoplab.eu:8080/interoplab__repository/rep/ret urn:oid:1.1.4567334.1.4 1.1.4567332.1.1 1.3.6.1.4.1.12559.11.13.2.1.227 urn:oid:1.1.4567334.1.4 1.1.4567332.1.1 1.3.6.1.4.1.12559.11.13.2.1.231 --- version: "TA150" language: "nl" --- # 10.5.8 \| IHE ITI-39 \| Cross Gateway Retrieve ## Scope This transaction is used by the Requesting GTK to retrieve one of more documents from the Responding GTK. ### Use Case Roles ![ITI-39.png](https://afsprakenstelsel.twiin.nl/__attachments/a_4c6f9a20a9104a0362f0c03ee563384308bd4d9a0cccd24e7210852d91489461/ITI-39.png?cb=54f3d8ea523e68291aa646d2f9da9d36) This transaction uses SOAP v1.2 and Synchronous Web Services. ## Referenced standards Implementers of this transaction shall comply with all requirements described in[Web Services for IHE Transactions.](https://profiles.ihe.net/ITI/TF/Volume2/ch-V.html#Appendix%20V) |------------|--------------------------------------------------------------------------------------| | ebRIM | OASIS/ebXML Registry Information Model v3.0 | | ebRS | OASIS/ebXML Registry Services Specifications v3.0 | | ITI TF-3:4 | Metadata used in Document Sharing profiles | | MTOM | SOAP Message Transmission Optimization Mechanism | ## Messages ### Cross Gateway Retrieve For more technical specification, see the original document: NB: This transaction is always performed in combination with the [transaction ITI-40](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-5-ihe-iti-40-provide-x-user-assertion.md) where user data is added in a SAML token. NB: All transactions are logged with an ITI-20 audit transaction, see IHE:ITI volume 2 for the correct implementation." --- version: "TA150" language: "nl" --- # IHE ITI-40 \| Provide X-User Assertion ## **Scope** This transaction is used to add user attributes in the SOAP TTA transactions. The attributes are placed in a SAML-token in the security header of a, for example, ITI-75 transaction. ### Use Case Roles ![image-20230912-163616.png](https://afsprakenstelsel.twiin.nl/__attachments/a_f453873f9df8c14fa58636182dce9c62c775ea82bb3420ef7fc1c43aed50b860/image-20230912-163616.png?cb=da9a53b9d3fc3fdc1e1bdc27b9b4c128) ## **Referenced Standards** * OASIS * [SAMLCore](http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) SAML V2.0 Core standard * [WSS10](http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf) OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004. * [WSS11](http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf) OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006. * [WSS:SAMLTokenProfile1.0](http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf) OASIS Standard, "Web Services Security: SAML Token Profile", December 2004 * [WSS:SAMLTokenProfile1.1](http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf) OASIS Standard, "Web Services Security: SAML Token Profile 1.1", February 2006 * XSPA-SAMLv1.0 OASIS Standard, "Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of the Security Assertion Markup Language (SAML) for Healthcare v1.0" , November 2009 * SAML 2.0 Profile For XACML 2.0 OASIS Standard, February 2005 ### Informative -- assist with understanding or implementing this transaction * IHE Profiles * [Personnel White Pages](https://profiles.ihe.net/ITI/TF/Volume1/ch-11.html) Profile * [Enterprise User Authentication](https://profiles.ihe.net/ITI/TF/Volume1/ch-4.html) Profile * [Basic Patient Privacy Consents](https://profiles.ihe.net/ITI/TF/Volume1/ch-19.html) Profile * OASIS * SAML V2.0 Standards . * SAML V2.0 Technical Overview * SAML Executive Overview * SAML Tutorial presentation by Eve Maler of Sun Microsystems * SAML Specifications * WS-Trust - OASIS Web Services Secure Exchange (WS-SX) TC * XSPA-XACMLv1.0 OASIS Standard, "Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare v1.0" , November 2009 ## **Messages** Provide X-User Assertion For more technical specification, see the original document: **Twiin implementation** The SAML token is only valid for 10 minutes. The SAML token has the following attributes (in addition to the required attributes from the SAML-standard) |------------------------------------------------------|----------|--------------| | **Element** | **Opt.** | **DataType** | | urn:nl:otv:names:tc:1.0:subject:mandated | **C** | HL7 V3 II | | urn:ihe:iti:xua:2017:subject:provider-identifier | R | HL7 V3 II | | urn:oasis:names:tc:xacml:2.0:subject:role | R | HL7 V3 CE | | urn:ihe:iti:appc:2016:document-entry:event-code | O | HL7 V3 CV | | urn:nl:otv:names:tc:1.0:subject:provider-institution | R | HL7 V3 II | | urn:oasis:names:tc:xspa:1.0:subject:organization | O | String | | urn:oasis:names:tc:xspa:1.0:subject:organization-id | O | anyURI | | urn:oasis:names:tc:xspa:1.0:subject:purposeofuse | R | HL7 V3 CV | The SAML token is only required in the transactions **between** GTK (external traffic). |---------------------------|-------------------------------------------------------------------------------------|---| | Identification Raadpleger | | | | Name: | urn:nl:otv:names:tc:1.0:subject:mandated | | | Type: | urn:hl7-org:v3:II | | | Example: | `extension="123456789" root="2.16.528.1.1007.3.1" assigningAuthorityName="CIBG"` | | | Opt.: | **Conditional** , required if the person is mandated by the *verantwoordelijke-id.* | | |----------------------------------|----------------------------------------------------------------------------------| | Identification Verantwoordelijke | | | Name: | urn:ihe:iti:xua:2017:subject:provider-identifier | | Type: | urn:hl7-org:v3:II | | Example: | `extension="123456782" root="2.16.528.1.1007.3.1" assigningAuthorityName="CIBG"` | | Opt.: | **Required,** UZI-nummer *verantwoordelijke.* | |---------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------| | *Rolcode* *verantwoordelijke* healthcare provider | | | Name: | urn:oasis:names:tc:xacml:2.0:subject:role | | Type: | urn:hl7-org:v3:CE | | Example: | `code="01.013" codeSystem="2.16.840.1.113883.2.4.15.111" codeSystemName="RoleCodeNL" displayName="Arts v. maag-darm-leverziekten"` | | Opt.: | **Required,** UZI *rolcode* | |---------------|-----------------------------------------------------------------| | Data category | | | Name: | urn:ihe:iti:appc:2016:document-entry:event-code | | Type: | urn:hl7-org:v3:CV | | Example: | `code="GGC007" codeSystem="2.16.840.1.113883.2.4.3.111.5.10.1"` | | Opt.: | **Optional** | |---------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| | Identification *verantwoordelijke* provider | | | Name: | urn:nl:otv:names:tc:1.0:subject:provider-institution | | Type: | urn:hl7-org:v3:II | | Example: | ` ` | | Opt.: | **Required, URA** | |---------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------| | Alternative Identification *verantwoordelijke* provider | | | Name: | urn:oasis:names:tc:xspa:1.0:subject:organization | | Type: | String | | Example: | ` Family Medical Clinic ` | | Opt.: | **Conditional, required if**urn:oasis:names:tc:xspa:1.0:subject:organization-id is not empty | |--------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Alternative Identification *verantwoordelijke* provider (id) | | | Name: | urn:oasis:names:tc:xspa:1.0:subject:organization-id | | Type: | AnyURI | | Example: | ` http://familymedicalclinic.org ` | | Opt.: | **Conditional, required if**urn:oasis:names:tc:xspa:1.0:subject:organization is not empty | |----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---| | Purpose of use | | | | Name: | urn:oasis:names:tc:xspa:1.0:subject:purposeofuse | | | Type: | urn:hl7-org:v3#CV | | | Example: | \ \ \ | | | Opt.: | **Required** | | --- version: "TA150" language: "nl" --- # 10.5.9 \| RAD-75 examples For reference only ## RAD-75 request XML urn:ihe:rad:2009:RetrieveImagingDocumentSet http://xtdchixjenkins01:8086/XCAI urn:uuid:ab70c66b-7f7f-42d1-bfac-e2afcc4ad6f2 http://www.w3.org/2005/08/addressing/anonymous urn:oid:1.2.34.567.8.6 23 24 6 ## RAD-75 response XML urn:ihe:rad:2011:CrossGatewayRetrieveImagingDocumentSetResponse urn:uuid:8f62a0f3-1906-4b32-9b22-e37585fb4cc5 http://www.w3.org/2005/08/addressing/anonymous uuid:abb813bb-9c7b-48ec-a26f-6779b219cccf urn:oid:1.3.6.1.4.1.21367.2011.2.6.169 1.3.6.1.4.1.21367.2011.2.1.304 1.2.40.0.13.1.1.192.168.0.2.20060712144818517.32770 application/dicom ## RAD-75 request incl. SAML-token XML urn:ihe:rad:2009:RetrieveImagingDocumentSet http://xtdchixjenkins01:8086/XCAI urn:uuid:ab70c66b-7f7f-42d1-bfac-e2afcc4ad6f2 http://www.w3.org/2005/08/addressing/anonymous xds-bridge-xua-proxy u0aMCbaPxaD3NKUcm9RTKJ8nYu0= ca4w0ETLyPgQHWjUQS8FFTzNNrjt5fZ5+5LFWrao11H354IwHw0CksI8qD/GVZ6pkmbkwNPZV8Pf DlGsvzDstsytnSB7/8PNVberVJVehg7CwC/nd3SoL7aRpj96c8yxL9gaUDrU3EzoPy4j9Vb2UbF2 W8EXATeosHJjPTTnsnBGHVYBRfarqAv32Ll99cTG4fN03Vlz+IJAp/qBofD2Mgz0iJRoucwqjOes 9O5I8qRB60CIhEd7Z/P8X3hRNZULQQoZn8AyRHdoqY/AgLLUKE/JUQsxYKa3BbGJw7JmFPtI7I4c +wlM577HcMbfq8VjeS31QL8Pzj48rQV4AnsS9w== MIIDyzCCArMCAQEwDQYJKoZIhvcNAQELBQAwgasxCzAJBgNVBAYTAk5MMRUwEwYDVQQIDAxadWlk LUhvbGxhbmQxHzAdBgNVBAcMFkNhcGVsbGUgYWFuIGRlbiBJSnNzZWwxGjAYBgNVBAoMEVZBTkFE IEhlYWx0aCBDYXJlMRQwEgYDVQQLDAtEZXZlbG9wbWVudDELMAkGA1UEAwwCY2ExJTAjBgkqhkiG 9w0BCQEWFnhkc3RlYW1AdmFuYWRncm91cC5jb20wHhcNMTcxMTI4MTQyMzM5WhcNMTgxMTI4MTQy MzM5WjCBqjELMAkGA1UEBhMCTkwxFTATBgNVBAgMDFp1aWQtSG9sbGFuZDEfMB0GA1UEBwwWQ2Fw ZWxsZSBhYW4gZGVuIElKc3NlbDEaMBgGA1UECgwRVkFOQUQgSGVhbHRoIENhcmUxFDASBgNVBAsM C0RldmVsb3BtZW50MQowCAYDVQQDDAF4MSUwIwYJKoZIhvcNAQkBFhZ4ZHN0ZWFtQHZhbmFkZ3Jv dXAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuv+sbPxoGUh3H2FUBr3dnBEZ fUSMqbD/2rrADDrMZVh/RqZ+oBeQhOuD0enWt5+IMA/eZ4d8g5qUiU8gXAdpJ/49A7+kFZOL82jd zwga/XP2WPBLucmjw9rwjM3clHdWRdFsjF5Iw+NVo8cmY7Vebi673q7mWPIKY4vdFC2UBNQtblot YnswbvoQHRhXaTKjQ/zEp6viK/gD+o32ee0MSn/0d0jKhMVufvR1P3tzwAQnK6J/i5fDI3QnghKx 5KC7IHETv0/qskSTYQge40GJtjtOpgrP1xTEII2TnadBVevyBPdes4Wi/5RLYxpj8aWDNUXzRbcj HTRPDx5FUnOHGwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQARV+dsvKrfU1w46a3LTiAWn+V2Fx3c 1kHyj8FkOLFouHp8H/55nhOFlW7qskWHiILuEA7HN29kO+JenNUF0V9K2wrNV5tEMrvTKIFqXOxu VwO5Vu0tHE43VGNdbucuR2zD3irmsIpLdwDxkN/9NPMEBPLYu4g7+v896EM5c/3uJtaBfP0ufOGv Abx+nEBlGyTuMUPbgstTvwT/Tvkc0YFzIuz7wNAaWpkELd6Hj+9r/DMzbNshjKTs0WK9wffQxphJ NI4LW1L5LF6W84HQFGrP9+gwODLAHQ4bBKIOWXDxPXyLeMwjbm5hCKB/PE1oMu84iFsQwSzcPERz HbXy1EJU anton@ziekenhuis.nl OTV-ABB-REGISTER urn:oasis:names:tc:SAML:2.0:ac:classes:X509 ns2:HomeCommunityId>urn:oid:1.2.34.567.8.6 23 24 6 --- version: "TA150" language: "nl" --- # 10.5.9 \| IHE RAD-75 \| Cross Gateway Retrieve Imaging Document Set ## Scope This transaction is used by the Requesting GTK to retrieve images from sources behind Responding GTK's. Prior to this transaction, the '[10.5.7 \| IHE ITI-38 \| Cross Gateway Query](https://afsprakenstelsel.twiin.nl/normatief/ta150/10-4-2-ihe-iti-38-cross-gateway-query.md) is used for the necessary information (specifically the metadata of the KOS Objects and the KOS objects of the set of images to be requested) ### Use Case Roles ![rad75.png](https://afsprakenstelsel.twiin.nl/__attachments/a_d45f49e6c916f477984f1e33d10d9a20a0cbf73fe1d20ad8ce82b37a2068bb0e/rad75.png?cb=78fcdb4e5d318a580df0fde9c6bb87ce) This transaction uses SOAP v1.2 and Synchronous Web Services. ## Referenced standards Implementers of this transaction shall comply with all requirements described in[Web Services for IHE Transactions.](https://profiles.ihe.net/ITI/TF/Volume2/ch-V.html#Appendix%20V) |------------|--------------------------------------------------------------------------------------| | ebRIM | OASIS/ebXML Registry Information Model v3.0 | | ebRS | OASIS/ebXML Registry Services Specifications v3.0 | | ITI TF-3:4 | Metadata in Document Sharing profiles | | MTOM | SOAP Message Transmission Optimization Mechanism | | XOP | XML-binary Optimized Packaging http://www.w3.org/TR/2005/REC-xop10-20050125/ | ## Messages ### Cross Gateway Retrieve Imaging Document Set For more technical specification, see the original document: NB: This transaction is always performed in combination with the transaction ITI-40 where user data is added in a SAML token. NB: All transactions are logged with an ITI-20 audit transaction, see IHE:ITI volume 2 for the correct implementation." --- version: "TA150" language: "nl" --- # IHE ITI-81 \| Retrieve Audit Record This transaction is informative. Not for implementation in Twiin 1.4 ## Scope An Audit Viewer requests (a selection of) audit events from the Audit Record Repository based on FHIR. ### Use Case Roles ## Referenced standards |----------|-----------------------------------------------------------------------| | RFC2616 | IETF Hypertext Transfer Protocol -- HTTP/1.1 | | RFC4627 | The application/json Media Type for JavaScript Object Notation (JSON) | | RFC6585 | IETF Additional HTTP Status Codes | | RFC5424 | The Syslog Protocol | | RFC3339 | Date and Time on the Internet: Timestamps | | HL7 FHIR | Release 4 | ## Messages **Retrieve ATNA Audit Events Message** This is part of the ITI TF Supplement: Add RESTful ATNA (Query and Feed) - Status: Trial Implementation For more technical specification, see the original document: paragraph 3.81.4.1 of [Next Page](https://afsprakenstelsel.twiin.nl/llms-full.txt/1)