1.4.1Twiin Implementatiewijzer Zorgtoepassingen
Z1.5 | BgZ: PvE¶
Validatie-eisen¶
| Eis | Categorie | Actor | Omschrijving | Toelichting inclusief aanvullende documentatie |
|---|---|---|---|---|
| BgZ-2a-AA-11 | BgZ Authn en Authz | GtK verzender | GtK verzender borgt dat de autorisatierichtlijn BgZ is toegepast. Concreet betekent dit dat alleen de in de richtlijn geautoriseerde rollen een andere partij mogen notificeren voor het ophalen van de BgZ. De GtK verzender mag vervolgens vertrouwen op de interne autorisatieregels bij de GtK ontvanger (indien deze een valide authorization base heeft, zie ook BgZ-1-authz-03) | Access Policy: GtK verzender moet borgen dat alleen gebruikers met de in de autorisatiematrix opgesomde rollen BgZ notificaties mogen versturen: Z1.4.4 | BgZ: Autorisatie | autorisatiematrix BgZ |
| BgZ-2a-AA-15 | BgZ Authn en Authz | GtK verzender | GtK verzender heeft het afgesproken access policy geïmplementeerd bij het verzenden van een notificatie | Access Policy: GtK verzender mag door gebruikers met de in de autorisatiematrix opgesomde rollen een BgZ laten verzenden: Z1.4.4 | BgZ: Autorisatie | autorisatiematrix BgZ |
| BgZ-3-1 | content | GtK verzender | GtK verzender dient een Workflow-task aan te maken die voldoet aan de BgZ FHIR Workflow Task implementation. | Profiel: Z1.4.2 | BgZ: FHIR Workflow Task implementation |
| BgZ-3-2 | content | GtK ontvanger | GtK ontvanger dient een Workflow-Task die voldoet aan het BgZ Workflow Task Profile te kunnen interpreteren. | Profiel: Z1.4.2 | BgZ: FHIR Workflow Task implementation |
| BgZ-3-3 | content | GtK verzender | GtK verzender dient een Notificatie-task aan te maken die voldoet aan het afgesproken profiel. | Profiel: 10.5.1 | Twiin-01 | Send Notification Task | id 10.3.1|Twiin 01|SendNotificationTask Request message Referentiecodes: Z1.4.1 | BgZ: FHIR Task reference codes (deprecated) |
| BgZ-3-4 | content | GtK ontvanger | GtK ontvanger dient een Notificatie-task die voldoet aan het afgesproken profiel te kunnen interpreteren. | Profiel: 10.5.1 | Twiin-01 | Send Notification Task | id 10.3.1|Twiin 01|SendNotificationTask Request message Referentiecodes: Z1.4.1 | BgZ: FHIR Task reference codes (deprecated) |
| BgZ-3-5 | content | GtK verzender | GtK verzender dient FHIR-resources conform de implementation guide van de informatiestandaard BgZ beschikbaar te kunnen stellen. | Profielen: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_2017_Technical_IG |
| BgZ-3-6 | content | GtK ontvanger | GtK ontvanger dient FHIR-resources conform de implementation guide van de informatiestandaard BgZ te kunnen interpreteren. | Profielen: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_2017_Technical_IG |
| BgZ-3-7 | content | GtK verzender | GtK verzender dient correspondentie/ niet-discrete data conform Z3 | COR: Implementatiewijzer Correspondentie beschikbaar te kunnen stellen. | |
| BgZ-3-8 | content | GtK ontvanger | GtK ontvanger dient correspondentie/ niet-discrete data conform Z3 | COR: Implementatiewijzer Correspondentie te kunnen interpreteren. | |
| BgZ-3-9 | content en autorisatie | GtK verzender | Het raadplegen van de gegevens mag alleen gebeuren binnen de geldigheidsduur van de verwijzing/overdracht: 1 jaar. Dit is het laatste moment in de tijd waarop nog op basis van de veronderstelde toestemming de informatie mag worden opgevraagd. De geldigheidsduur moet worden opgenomen in de Task. Daarna is de veronderstelde toestemming niet meer geldig bij de verwijzende/overdragende instelling en mag de informatie alleen op basis van de use case 'Opvraging BgZ bij eerdere behandelaar' en vooraf vastgelegde uitdrukkelijke patiënttoestemming worden opgevraagd via een elektronisch uitwisselingssysteem. | De geldigheidsduur van een verwijzing dan wel overdracht binnen de tweede lijn is gebaseerd op de geldigheidsduur die gehanteerd wordt tussen de eerste en tweedelijns verwijzingen, namelijk één jaar. Dit afgestemd met de volgende koepels FMS, NVZ, NFU en ZKN en wordt tot nader order gehanteerd als veldnorm. |
| BgZ-3-10 | routering | GtK verzender | Een GtK verzender dient, indien de beoogde GtK ontvanger dit vereist, de definitionReference in de Send Notification te vullen met de daardoor aangeleverde parameters | Deze parameters bieden de GtK ontvanger de mogelijkheid om een binnenkomende notificatie intern verder te routeren. Het is aan de Twiin-Deelnemer om deze lijsten te verspreiden onder de Twiin Deelnemers. Dit is een tijdelijke eis / oplossing totdat de TA routering is afgerond. Zie: 10.4.5 | TTA - Addressing |
| BgZ-3-11 | beschikbaarheid | GtK verzender en ontvanger | Het GtK en systemen 'achter het GtK' dienen ieder een beschikbaarheid van minimaal 99,5% te hebben. | Dit percentage is gebaseerd op de vuistregel dat dit: • Betrouwbaar genoeg is voor deze toepassing. • De kosten beperkt houdt in vergelijking met hogere beschikbaarheidsniveaus (>99,9%), waarin deze exponentieel stijgen. |
Aanvullende ketentest-eisen¶
| Eis | Categorie | Actor | Omschrijving | Toelichting inclusief aanvullende documentatie |
|---|---|---|---|---|
| BgZ-1-FO-03 | FO Nictiz | GtK verzender | GtK verzender maakt informatie beschikbaar conform de BgZ specificatie op basis van zibs versie 2017. | Specificatie: https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf |
| BgZ-1-FO-04 | FO Nictiz | GtK ontvanger | GtK ontvanger kan informatie opvragen die voldoet aan de BgZ specificatie op basis van zibs versie 2017. | Specificatie: https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf |
| BgZ-1-FO-05 | FO Nictiz | EPD verzender | Voor het vastleggend systeem 'achter' de GtK verzender geldt: Het EPD moet nieuwe gegevens, die vastgelegd worden als gevolg van een behandeling in de eigen instelling, vastleggen als zibs voor zover de gegevens onderdeel kunnen zijn van een later aan te maken BgZ. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-06 | FO Nictiz | EPD verzender | Voor het vastleggand systeem 'achter' de GtK verzender geldt: Het EPD moet nieuwe gegevens die vastgelegd worden als zibs voorzien van metagegevens. Daarbij moet alle velden die gevuld zijn in de Metagegevens tabel gevuld worden voor nieuwe zibs. Velden die leeg zijn in de metagegevens tabel mogen gevuld worden, maar dat hoeft niet. Vastleggen gebeurt zoveel mogelijk automatisch, bijvoorbeeld door huidige datumtijd te gebruiken. De datumtijd en zorgverlener kunnen onderdeel zijn van de zib (zo kent de zib Verrichting een Uitvoerder en een VerrichtingStartDatum). Waar dat niet het geval is, worden de BasisElementen gebruikt. In dat geval kan de ingelogde zorgverlener Auteur zijn en de huidige datumtijd gebruikt worden. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-07 | FO Nictiz | GtK verzender | GtK verzender moet een BgZ kunnen sturen bij verwijzing naar een andere zorginstelling of zorgverlener. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-08 | FO (Nictiz) | GtK verzender | GtK verzender moet een verwijsbrief in document-formaat kunnen sturen bij verwijzing naar een andere zorginstelling of zorgverlener. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-09 | FO Nictiz | Verwijzer | Een Verwijzer (zorgverlener) moet een andere zorginstelling kunnen kiezen om een BgZ mee te delen, met eventueel specialisme. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-10 | FO Nictiz | GtK antwoorder | GtK antwoorder moet de mogelijkheid bieden om op een opvraging een BgZ beschikbaar te stellen. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-11 | FO Nictiz | EPD verzender | Voor het vastleggend systeem 'achter' de GtK verzender geldt: Een EPD moet metagegevens toevoegen aan een BgZ. Voor zibs die aangemaakt zijn na implementatie van de informatiestandaard zijn dat minimaal alle velden die gevuld zijn in de Metagegevens tabel. Voor historische zibs worden de metagegevens zo goed mogelijk gevuld. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-12 | FO Nictiz | GtK verzender, GtK ontvanger | GtK verzender en GtK ontvanger moeten beschrijven welke secties en welke zibs van de BgZ wel en niet ondersteund worden. Deze documentatie moet beschikbaar zijn bij kwalificatie en voor ketenpartners. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-13 | FO Nictiz, meta gegevens | GtK verzender | GtK verzender dient, wanneer een gegevenselement van elders betrokken is en er zijn metagegevens op zib-niveau opgeslagen, deze metagegevens mee te zenden. Bijvoorbeeld: medicatie is opgehaald van het LSP en de identificaties van de LSP-bevraging zitten in het EPD, dan dienen deze meegezonden te worden. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-14 | FO Nictiz, meta gegevens | GtK verzender | GtK verzender: Wanneer een gegevenselement van elders betrokken is, en er zijn geen metagegevens opgeslagen, dan worden deze niet meegezonden. Bijvoorbeeld: medicatie is overgenomen van een papieren AMO (Actueel Medicatie Overzicht). Op een AMO staan geen metagegevens op rij-niveau. Deze kunnen dus niet opgeslagen en meegestuurd worden. Er moet geen eigen identificatie aangemaakt worden wanneer het medicatievoorschrift elders is opgesteld. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-15 | FO Nictiz, meta gegevens | GtK verzender | GtK verzender: Wanneer het gegevenselement niet van elders betrokken is, en het systeem kan persistente identificaties (die bij een volgende bevraging hetzelfde zijn) aanmaken, dan dienen deze meegezonden te worden. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-16 | FO Nictiz, meta gegevens | GtK verzender | GtK verzender: Wanneer het gegevenselement niet van elders betrokken is, en het systeem kan geen persistente identificaties aanmaken, dan worden geen identificaties meegezonden. Andere metagegevens mogen wel meegestuurd worden. Deze situatie is niet wenselijk en dient uitgefaseerd te worden, maar is zeker voor historische gegevens niet uit te sluiten. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-17 | FO Nictiz, meta gegevens | GtK verzender | GtK verzender: Wanneer het systeem geen onderscheid kan maken tussen eigen en van elders betrokken informatie, worden geen identificaties meegezonden. Deze situatie is niet wenselijk en dient uitgefaseerd te worden. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-18 | FO Nictiz | GtK ontvanger | GtK ontvanger moet de mogelijkheid bieden om een BgZ op te vragen bij een beschikbaarstellend EPD. Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen | |
| BgZ-1-FO-19 | FO Nictiz | Nieuwe behandelaar | Use case "Opvraging BgZ bij eerdere behandelaar": Een zorgverlener moet een te bevragen zorginstelling kunnen kiezen, ofwel een lijst tonen met alle beschikbare BgZ's in een repository. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-20 | FO Nictiz | GtK ontvanger, EPD ontvanger | GtK ontvanger en de eventuele achterliggende systemen (zoals een EPD) moeten de mogelijkheid bieden om een BgZ te ontvangen. Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen | |
| BgZ-1-FO-21 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Het EPD moet de betrokken afdelingen (administratief en/of specialisme) kunnen verwittigen van een ontvangen BgZ, waarna die BgZ ingezien kan worden. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-22 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet alle informatie die via een BgZ ontvangen wordt kunnen tonen aan de zorgverlener. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-23 | FO Nictiz | GtK ontvanger, EPD ontvanger | GtK ontvanger en de systemen 'achter' GtK ontvanger moeten beschrijven welke mogelijkheden ze wel en niet bieden betreffende hergebruik. Deze documentatie moet beschikbaar zijn bij kwalificatie en voor ketenpartners. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-24 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet alle informatie die via een BgZ ontvangen wordt, kunnen tonen aan de zorgverlener. De informatie die getoond wordt, moet uit de gestructureerde zibs in de BgZ getoond worden waar deze aanwezig zijn. Het gaat niet om het inzien van een PDF of tekstuele secties uit een document. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-25 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet in staat zijn een ontvangen of geraadpleegde BgZ over te nemen wanneer dat medisch relevant is. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-26 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet in staat zijn een ontvangen of geraadpleegde verwijsbrief over te nemen wanneer dat medisch relevant is. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-27 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD dat gegevens overneemt neemt deze over als discrete zibs. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-28 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD dat zibs overneemt moet deze ook weer als zibs kunnen ontsluiten. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-29 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet metagegevens op document-niveau op kunnen slaan. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-30 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet metagegevens op zib-niveau op kunnen slaan. Wanneer deze aanwezig zijn, is opslaan van document-metagegevens optioneel. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-31 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Bij iedere overgenomen zib worden metagegevens opgeslagen. Dit is minimaal: • de instelling vanwaar de gegevens betrokken zijn; • de gegevens die gevuld zijn in de Metagegevens tabel. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-FO-32 | FO Nictiz | EPD ontvanger | Voor de systemen 'achter' GtK ontvanger geldt: Daarnaast wordt de verantwoordelijke zorgverlener overgenomen wanneer deze in de zib of de metagegevens van de zib zit. Bij historische of van oorspronkelijk elders betrokken gegevens kan deze zorgverlener niet altijd gevuld zijn. Daarnaast gaat het alleen om gegevens van de zorgverlener waar dit medisch relevant is. Bijvoorbeeld een voorschrijver van medicatie, steller van een diagnose of uitvoerder van een verrichting is relevant. Administratief personeel dat gegevens zoals contactpersonen invoert is dat niet. | Specificatie: https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_MSZ_Informatiestandaard#Systemen_en_systeemrollen |
| BgZ-1-VIPP5-1 | VIPP 5 | GtK verzender | GtK verzender kan de BgZ en correspondentie verzenden naar andere instellingen van Medisch Specialistische Zorg. | Zie Handreiking VIPP 5 assessments, bijlage II, paragraaf 1.5, alinea module 3 Zie https://www.vipp-programma.nl/over-vipp/doelstellingen |
| BgZ-1-VIPP5-2 | VIPP 5 | GtK ontvanger | GtK ontvanger kan de BgZ en correspondentie ontvangen vanuit een andere instelling van Medisch Specialistische Zorg. | Zie Handreiking VIPP 5 assessments, bijlage II, paragraaf 1.5, alinea module 3 |
| BgZ-1-VIPP5-3 | VIPP 5 | GtK ontvanger, EPD ontvanger | GtK ontvanger en de systemen achter GtK ontvanger (bijvoorbeeld het EPD) kunnen aangewezen of gekozen secties van de BgZ ontvangen en hergebruiken vanuit een andere instelling van Medisch Specialistische Zorg. | Zie Handreiking VIPP 5 assessments, bijlage II, paragraaf 1.5, alinea module 3 |
| BgZ-1-VIPP5-4 | VIPP 5 | Twiin deelnemer | De Twiin deelnemer (zorgorganisatie) heeft procedures rondom het uitwisselen van de BgZ en correspondentie met andere instellingen van Medisch Specialistische Zorg beschreven en geïmplementeerd. | Zie Handreiking VIPP 5 assessments, bijlage II, paragraaf 1.5, alinea module 3 |
| BgZ-1-AVG-01 | TA NP | Nieuwe behandelaar | De nieuwe behandelaar mag alleen de gegevens opvragen die relevant zijn voor de uitvoering van de nieuwe behandelrelatie. De nieuwe behandelaar (en de zorgorganisatie waarvan zij/hij deel uitmaakt) is ervoor verantwoordelijk om dataverzoeken proportioneel te houden. |
Notified Pull-eisen¶
| Eis | Titel | Omschrijving/Toelichting/Uitleg/Implicaties | Prescription Level/Type | Toetsing | Transactie/verwijzing |
|---|---|---|---|---|---|
| BgZ-2a-TANP-01 | Aanbieden notificatie-endpoint | De GtK-ontvanger dient een notificatie-endpoint aan te bieden aan de GtK-verzender. Een endpoint kan worden gedeeld door meerdere Twiin Deelnemers (bijv. een endpoint per GtK/ SaaS-dienst) of er kan sprake zijn van een endpoint per Twiin Deelnemer. | Verplicht | Validatie | Zie o.a. Z1.2.1 | TTA Exchanging BgZ - FHIR Notified Pull |
| BgZ-2a-TANP-02 | Aanbieden resource-endpoint | De GtK-verzender dient een resource-endpoint aan te bieden aan GtK-ontvanger. Een endpoint kan worden gedeeld door meerdere Twiin Deelnemers (bijv. een endpoint per GtK/ SaaS-dienst) of er kan sprake zijn van een endpoint per Twiin Deelnemer. | Verplicht | Validatie | Zie o.a. Z1.2.1 | TTA Exchanging BgZ - FHIR Notified Pull |
| BgZ-2a-TANP-03 | Aanbieden token-endpoint | De GtK-verzender en de GtK-ontvanger dienen een token-endpoint aan elkaar aan te bieden. Een endpoint kan worden gedeeld door meerdere Twiin Deelnemers (bijv. een endpoint per GtK/ SaaS-dienst) of er kan sprake zijn van een endpoint per Twiin Deelnemer. | Verplicht | Validatie | Zie o.a. Z1.2.1 | TTA Exchanging BgZ - FHIR Notified Pull |
| BgZ-2a-AA-06 | Aanmaken authorization_base | De GtK-verzender is in staat een digitale representatie van de in de context van een verwijzing veronderstelde toestemming aan te maken (authorization_base). Omdat de authorization_base alleen door GtK-verzender wordt verwerkt, worden de vorm en inhoud ervan bepaald door GtK-verzender. GtK-ontvanger mag niet afhankelijk zijn van het formaat of de inhoud van authorization_base. De vorm en inhoud van de authorization_base is (nog) niet gebonden aan normatieve eisen. Het bepalen van vorm en inhoud doet GtK-verzender bij voorkeur in afstemming met de gebruikte infrastructuur. |
Verplicht | Validatie | Zie Z1.2.1.2 | BgZ: Authentication & Authorization | Authorization base |
| BgZ-2a-AA-07 / BgZ-2a-AA-12 | Aanmaken autorization_grant | De GtK-verzender en GtK-ontvanger zijn in staat een authorization_grant aan te maken die voldoet aan de specificaties |
Verplicht | Validatie | Specificaties: 10.4.2 | TTA FHIR - Authorization | id 10.2.5|TTAFHIR Authentication&Authorization Authorization grant |
| BgZ-2a-AA-08 | Aanmaken access token request voor notification-endpoint | De GtK-verzender is in staat conform de specificaties een access token request voor toegang tot het notificatie-endpoint aan te maken en aan GtK-ontvanger te versturen. | Verplicht | Validatie | Specificaties: Z1.2.1.2 | BgZ: Authentication & Authorization | Access token request Twiin-07 | Token Request |
| BgZ-2a-AA-09 | Gelijke waardes in authentication_grant en access token request | De GtK-verzender en GtK-ontvanger dienen ervoor te zorgen dat het veld sub in de authentication_grant en het veld client_id in het access token request dezelfde waarde bevatten. |
Verplicht | Validatie | Specificaties: Z1.2.1.2 | BgZ: Authentication & Authorization | Access token request Twiin-07 | Token Request |
| BgZ-2a-AA-10 | Afhandelen access token request voor notification server endpoint | De GtK-ontvanger is in staat conform de specificaties een access token request van GtK-verzender voor toegang tot het notificatie server endpoint af te handelen | Verplicht | Validatie | Specificaties: Z1.2.1.2 | BgZ: Authentication & Authorization | Access token request Twiin-07 | Token Request |
| BgZ-1-authz-03 | Controleren autorization_base | De GtK-verzender dient te controleren of de grondslag (authorization_base) waarmee de GtK-ontvanger een verzoek doet daadwerkelijk is uitgegeven (aan de GtK-ontvanger). Wanneer de grondslag niet meekomt in de uitwisseling, is er geen sprake van het notified pull communicatiepatroon en dient de GtK-ontvanger op basis van de in de autorisatierichtlijn beschreven rollen het verzoek te autoriseren. |
Verplicht | Validatie | Autorisatiematrix: Z1.4.4 | BgZ: Autorisatie | autorisatiematrix BgZ Transacties: 10.5.4 | Twiin-04 | Search Resource(s) , 10.5.5 | Twiin-05 | Retrieve Resource Autorisatierichtlijn: https://www.aorta-lsp.nl/over-aorta-lsp/autorisatierichtlijnen/autorisatierichtlijn-basisgegevensset-zorg-bgz |
| BgZ-2b-trans-01 | Aanmaken Workflow-Taks | De GtK-verzender is in staat een Workflow-Task aan te maken indien verzender geen Workflow-Task stuurt als payload van de Notification-Task. | Verplicht | Validatie | Transactie 1 van Z1.2.1.1 | BgZ - data interactions |
| BgZ-2b-trans-02 | Versturen notificatie-create-request | GtK-verzender is in staat een notificatie-create-request te versturen. | Verplicht | Validatie | Transactie 2 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.1 | Twiin-01 | Send Notification Task | id 10.3.1|Twiin 01|SendNotificationTask Request message |
| BgZ-2b-trans-03 | Afhandelen notificatie-create-request | De GtK-ontvanger is in staat een binnenkomend notificatie-create-request af te handelen en een passende response te versturen | Verplicht | Validatie | Transactie 3 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.1 | Twiin-01 | Send Notification Task | id 10.3.1|Twiin 01|SendNotificationTask Response message |
| BgZ-2b-trans-04 | Versturen notificatie-create-request bij updates | De GtK-verzender is in staat een notificatie-create-request te versturen wanneer de dataset van de verwijzing is geüpdatet | Verplicht | Validatie | Transactie 4 van Z1.2.1.1 | BgZ - data interactions Specificatie:10.5.1 | Twiin-01 | Send Notification Task | id 10.3.1|Twiin 01|SendNotificationTask Request message |
| BgZ-2b-trans-05 | Afhandelen notificatie-create-request bij updates | De GtK-ontvanger is in staat een naar aanleiding van een geüpdatete dataset binnenkomend notificatie-create-request af te handelen en een passende response te versturen | Verplicht | Validatie | Transactie 5 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.1 | Twiin-01 | Send Notification Task | id 10.3.1|Twiin 01|SendNotificationTask Response message |
| BgZ-2b-trans-06 | Versturen annulering | De GtK-verzender is in staat een notificatie-update-request te versturen wanneer GtK-verzender de notificatie wil annuleren of intrekken. | Optioneel | Validatie | Transactie 6 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.2 | Twiin-02 | Cancel Notification Task | id 10.3.2|Twiin 02|CancelNotificationTask Request message |
| BgZ-2b-trans-07 | Afhandeling annulering | GtK-ontvanger is in staat een binnenkomend notificatie-update-request af te handelen en een passende response te versturen. | Verplicht | Validatie | Transactie 7 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.2 | Twiin-02 | Cancel Notification Task | id 10.3.2|Twiin 02|CancelNotificationTask Notification response |
| BgZ-2b-trans-08.read | Uitvoeren read-operaties | De GtK-ontvanger is in staat read-operaties uit de notificatie-taak uit te voeren op het resource-endpoint van GtK-verzender. | Verplicht | Validatie | Transactie 8 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.5 | Twiin-05 | Retrieve Resource De read-operaties zijn opgenomen in de notificatie-task onder Task.input:read-available-resources. |
| BgZ-2b-trans-09.read | Afhandelen read-requests | GtK-verzender is in staat binnenkomende read-requests af te handelen en een passende response te versturen. | Verplicht | Validatie | Transactie 9 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.5 | Twiin-05 | Retrieve Resource |
| BgZ-2b-trans-08.search | Uitvoeren search-operaties resource-endpoint | GtK-ontvanger is in staat search-operaties uit de notificatie-taak uit te voeren op het resource-endpoint van GtK-verzender. | Verplicht | Validatie | Transactie 8 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.4 | Twiin-04 | Search Resource(s) De search-operaties zijn opgenomen in de notificatie-task onder Task.input:query-available-resources. |
| BgZ-2b-trans-09.search | Afhandelen search-requests resource-endpoint | GtK-verzender is in staat binnenkomende search-requests af te handelen en een passende response te versturen. | Verplicht | Validatie | Transactie 9 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.4 | Twiin-04 | Search Resource(s) |
| BgZ-2b-trans-10 | Uitvoeren read-operatie ophalen workflow-task | De GtK-ontvanger is in staat een read-operatie voor het ophalen van de Workflow-task uit te voeren op het resource-endpoint van GtK-verzender. | Verplicht | Validatie | Transactie 10 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.3 | Twiin-03 | Get Workflow Task De indicator voor de aanwezigheid van een workflow-task is opgenomen in de notificatie-task onder Task.input:get-worflow-task.valueBoolean (waarde is true). |
| BgZ-2b-trans-11 | Afhandelen read-operatie workflow-task | De GtK-verzender is in staat een binnenkomende read-request op de workflow-task af te handelen en een passende response te versturen. | Verplicht | Validatie | Transactie 11 van Z1.2.1.1 | BgZ - data interactions |
| BgZ-2b-trans-12.read | Uitvoeren read-operatie uit workflow-task | GtK-ontvanger is in staat read-operaties uit de workflow-taak uit te voeren op het resource-endpoint van GtK-verzender. | Verplicht | Validatie | Transactie 12 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.5 | Twiin-05 | Retrieve Resource De read-operaties zijn opgenomen in de workflow-task onder Task.input:read-available-resources. |
| BgZ-2b-trans-13.read | Afhandelen read-request | GtK-verzender is in staat binnenkomende read-requests af te handelen en een passende response te versturen. | Verplicht | Validatie | Transactie 13 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.5 | Twiin-05 | Retrieve Resource |
| BgZ-2b-trans-12.search | Uitvoeren search-operaties op resource-endpoint | GtK-ontvanger is in staat search-operaties uit de workflow-taak uit te voeren op het resource-endpoint van GtK-verzender. | Verplicht | Validatie | Transactie 12 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.4 | Twiin-04 | Search Resource(s) De search-operaties zijn opgenomen in de workflow-task onder Task.input:query-available-resources. |
| BgZ-2b-trans-13.search | Afhandelen search-operaties op resource-endpoint | GtK-verzender is in staat binnenkomende search-requests af te handelen en een passende response te versturen | Verplicht | Validatie | Transactie 13 van Z1.2.1.1 | BgZ - data interactions Specificatie: 10.5.4 | Twiin-04 | Search Resource(s) |
Adresseringseisen¶
| Eis | Titel | Omschrijving/Toelichting/Uitleg/Implicaties | Prescription Level/Type | Toetsing | Transactie/verwijzing |
|---|---|---|---|---|---|
| BgZ-2a-TANP-04 / BgZ-2a-TANP-05 | Publiceren adresinformatie endpoints | De GtK-ontvanger en GtK-verzender dienen de technische adressen van het resource-endpoint, het notificatie-endpoint en het token-endpoint kenbaar te maken aan de Twiin Beheerorganisatie. De wijze waarop technische adressen tussen GtK-verzender en GtK-ontvanger worden gecommuniceerd is (nog) niet gebonden aan normatieve eisen. De Twiin Beheerorganisatie publiceert de endpoints en technische adressen in ZORG-AB. Om de technische adressen van een andere partij te achterhalen kan er worden gekozen om ZORG-AB te raadplegen (10.6.5 | Addressing - ZORG-AB Transacties) maar dit is niet verplicht. GtK-verzender en GtK-ontvanger kunnen bijvoorbeeld ook onderling afspraken maken over de wijze waarop technische adressen worden gecommuniceerd. | Verplicht | n.v.t. | De procedures hiervoor moeten nog worden opgesteld. |
Identificatie en authenticatie-eisen¶
| Eis | Titel | Omschrijving/Toelichting/Uitleg/Implicaties | Prescription Level/Type | Toetsing | Transactie/verwijzing |
|---|---|---|---|---|---|
| Id-01 | Zorgverleners dienen geïdentificeerd te worden op basis van een uniek ID | UZI of een ander uniek tot één persoon te herleiden nummer. Wanneer een eigen id wordt gebruikt moet dit een unieke combinatie van persoons-id en organisatie-id opleveren en dat dit herleidbaar blijft (ook na, bijvoorbeeld, vertrek van zorgverlener), uitgegeven op het op het juiste betrouwbaarheidsniveau | Verplicht | Validatie | alle Twiin-transacties |
| Auth-01 | Zorgverlener/gebruiker (van het GtK) dienen (lokaal) geauthentiseerd 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. | Verplicht | Validatie | alle Twiin-transacties |
| BgZ-2a-AA-01 / BgZ-2a-AA-02 | Opzoekbaar maken publieke sleutel gebruikt voor ondertekening | GtK-verzender en GtK-ontvanger dienen de publieke sleutel(s) die zij gebruiken voor de ondertekening van JWT's via kid opzoekbaar te maken voor GtK-ontvanger. De wijze waarop de uitwisseling van publieke sleutels tussen GtK-verzender en GtK-ontvanger plaatsvindt is (nog) niet gebonden aan normatieve eisen. GtK-verzender en GtK-ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de wijze van uitwisseling van publieke sleutels. |
Verplicht | Validatie | Z1.2.1.2 | BgZ: Authentication & Authorization |
| BgZ-2a-AA-03 | Aanmaken client assertion | GtK-verzender is in staat een client assertion in de vorm van een authentication_grant aan te maken die voldoet aan de specificaties |
Verplicht | Validatie | Specificaties: 10.4.2 | TTA FHIR - Authorization | id 10.2.5 | TTA FHIR Authentication & Authorization Client authentication |
| BgZ-2a-AA-05 | Identifiers GtK | GtK-verzender en GtK-ontvanger dienen gebruik te maken van dezelfde identifiers voor de systemen die opereren als autorisatie-servers (authorization server token endpoints) Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan landelijke normatieve eisen. GtK-verzender en GtK-ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de te gebruiken identifiers van systemen. Voor de BgZ is nu afgestemd dat de systeem identifiers zelf gekozen moeten zijn, maar de vorm van een FQDN of OID mogen hebben. | Verplicht | Validatie | Zie aud-velden in Twiin-07 | Token Request |
Autorization-eisen¶
| Eis | Titel | Omschrijving/Toelichting/Uitleg/Implicaties | Prescription Level/Type | Toetsing | Transactie/verwijzing |
|---|---|---|---|---|---|
| BgZ-2a-AA-04 | Systeem identifiers autorisatie-clients | GtK-verzender en GtK-ontvanger dienen gebruik te maken van dezelfde identifiers voor de systemen die opereren als autorisatie-clients (OAuth clients). Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan normatieve eisen. GtK-verzender en GtK-ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de te gebruiken identifiers van systemen. | Verplicht | Validatie | Zie iss-velden in Z1.2.1.2 | BgZ: Authentication & Authorization |
| BgZ-2a-AA-04 | Systeem identifiers autorisatie-servers | GtK-verzender en GtK-ontvanger dienen gebruik te maken van dezelfde identifiers voor de systemen die opereren als autorisatie-servers (authorization server token endpoints). Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan landelijke normatieve eisen. GtK-verzender en GtK-ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de te gebruiken identifiers van systemen. Voor de BgZ is nu afgestemd dat de systeem identifiers zelf gekozen moeten zijn, maar de vorm van een FQDN of OID mogen hebben | Verplicht | Validatie | Zie aud-velden in Z1.2.1.2 | BgZ: Authentication & Authorization |
| BgZ-2a-AA-13 | Aanmaken access token request voor resource endpoint | De GtK-ontvanger is in staat conform de specificaties een access token request voor toegang tot het resource-endpoint aan te maken en aan GtK-verzender te versturen. Eventueel inclusief een eerder van GtK-verzender ontvangen authorization_grant, welke de digitale representatie van de veronderstelde toestemming (authorization_base) bevat. |
Verplicht | Validatie | Specificaties: Z1.2.1.2 | BgZ: Authentication & Authorization | Access token request Twiin-07 | Token Request | Authorization grant Twiin-07 | Token Request | Authorization base |
| BgZ-2a-AA-14 | Aanmaken access token request voor resource endpoint | GtK-verzender is in staat conform de specificaties een access token request van GtK-ontvanger voor toegang tot het resource server endpoint af te handelen. | Verplicht | Validatie | Specificaties: Z1.2.1.2 | BgZ: Authentication & Authorization | Access token request |
Netwerkbeveiligingseisen¶
| Eis | Titel | Omschrijving/Toelichting/Uitleg/Implicaties | Prescription Level/Type | Toetsing | Transactie/verwijzing |
|---|---|---|---|---|---|
| 5.010 / BgZ-2a-NS-02 | Authenticeren met PKI | Om zich te kunnen authenticeren, kunnen alle systemen betrokken bij transacties in het kader van Twiin een geldig PKIo-certificaat overleggen. Gebruikte PKIo-certificaten dienen te zijn uitgegeven onder de CA "Staat der Nederlanden Private Services CA – G1". Deze omvatten: • UZI-servercertificaat of • PKIoverheid Private Services CA – G1 certificate Het betreft de systemen in de rol van token-server en -client, notification-server en -client en resource-server en -client. Zie 10.4.7 | Network level security | Verplicht | Validatie | |
| 5.020 | mTLS | Alle transacties in het kader van Twijn zijn beveiligd met Mutual Transport Layer Security (mTLS). | Verplicht | Validatie | |
| 5.030 / BgZ-2a-NS-03 | Volgen TLS-richtlijnen NCSC | GtK-verzender en GtK-ontvanger maken gebruik van TLS versies en -algoritmen die zijn geclassificeerd als beveiligingsniveau "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), 2025-5 van het NCSC: Verplicht gebruik van de volgende cryptografische algoritmes: • Certificate Verification: ECDSA, RSA en EdDSA* • Key exchange: ECDHE* is afgewaardeerd van goed naar voldoende. Met X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 zijn er alternatieven, maar deze algoritmes zijn (relatief) nieuw en maken nog geen deel uit van de TLS standaarden. ECDHE moet daarom nog gebruikt worden. • Bulk encryption: AES-256-GCM of ChaCha20-Poly1305 • Hash functions: SHA-512 of SHA-384 of SHA-256 Het is verplicht om alle** algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd. Hiermee wordt er voor gezorgd dat wanneer onverhoopt een algoritme in veiligheidsniveau daalt er andere alternatieven overblijven van niveau goed. *Deze algoritmen zijn afgewaardeerd naar beveiligingsniveau 'voldoende'. Maar zijn geen (beschikbare) varianten die geclassificeerd is met beveiligingsniveau 'goed'. Hierdoor is het noodzakelijk om ook deze algoritmen op het niveau 'voldoende' te gebruiken. **Er geldt een uitzondering voor ChaCha20-Poly1305. Voor bulk encryptie wordt door sommige partijen de keuze gemaakt voor AES-256-GCM en niet voor ondersteuning van ChaCha20-Poly1305. De laatste is namelijk niet compliant met de eisen (Federal Information Processing Standards) die het Amerikaanse NIST (National Institute of Standards and Technology) stelt. Het is voor een GtK-server niet verboden om ook andere algoritmen en TLS-versies te ondersteunen van een lager niveau dan goed. De rationale hierachter is dat hard- en software waar de GtK-server gebruik van maakt ook voor andere use cases buiten het Twiin Afsprakenstelsel ingezet kan worden. De GtK-verzender MOET in het kader van Twiin echter wel altijd de door Twiin beschreven algoritmen en TLS-versie bij de GtK-ontvanger aanbieden. | Verplicht | Validatie | ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 |
| 5.040 | Versleuteling volgens TLS | Transacties in het kader van Twiin worden versleuteld volgens TLS, zoals bedoeld in eis 5.020. | Verplicht | Validatie | |
| 5.050 / BgZ-2a-NS-04 | Controleren geldigheid TLS-certificaat | GtK-verzender en GtK-ontvanger controleren minimaal ieder uur door middel van CRL of OCSP de geldigheid van de certificaten van systemen waarmee transacties plaatsvinden. | Verplicht | Validatie | |
| 5.060 / BgZ-2a-NS-05 | CPS van het UZI-register | Systemen die de geldigheid van het UZI-servercertificaat van de andere Systemen dienen te controleren, voldoen aan de verplichting van het Certification Practice Statement (CPS) UZI-register. | Conditioneel Verplicht | Validatie | Zie https://www.zorgcsp.nl/certification-practice-statement-cps , artikel 4.5.2 CRL's: https://www.zorgcsp.nl/certificate-revocation-lists-crl-s |
| BgZ-2a-NS-06 | CPS van PKIo | Wanneer GtK-verzender en GtK-ontvanger de geldigheid van een PKIo-servercertficaat controleren, doen zij dit op basis van de afspraken in het Certification Practice Statement (CPS) PKIoverheid. | Verplicht | Validatie | Zie https://cps.pkioverheid.nl/pkioverheid-cps-unified-v5.4.html , hoofdstuk 2 |
| 5.070 | Gebruik CRL of OSCP | Systemen die de geldigheid van het PKIo-servercertificaat van de andere Systemen dienen te controleren, doen dit door middel van de meest recent gepubliceerde Certificaten Revocatie Lijst (CRL) of via het Online Certificate Status Protocol (OCSP), minimaal ieder uur. | Verplicht | Validatie | Zie https://cps.pkioverheid.nl/pkioverheid-cps-unified-v5.4.html , paragraaf 2.2. |
| 5.080 | Ondertekening volgens DNSSEC | GtK zijn in hun rol als DNS Server moet er voor zorgen dat de name records behorende bij de hostnames van GtK'en zijn ondertekend volgens DNSSEC. (proudly copied from MedMij (core.dns.300)) | Verplicht | Validatie | |
| 5.090 | Controleren ondertekenning DNSSEC | Elke GtK, in zijn rol als DNS resolver in het Domain Name System, controleert of de ontvangen name records zijn voorzien van ondertekening volgens DNSSEC en valideert deze volgens DNSSEC. Indien deze controle en validatie niet beide slagen, ziet hij af van verbinding met de betreffende hostname. Het gebruik van DNSSEC vermindert de kwetsbaarheid van het Domain Name System voor bijvoorbeeld DNS spoofing. | Verplicht | Validatie | (proudly copied from MedMij (core.dns.301)) |