/
Raadplegen

Raadplegen

Owned by Dennis de Gouw
Last updated: Jan 20, 2025
3 min read

status:VERSIE: 17-01-2025 status:STATUS: definitief

Incrementele implementatie
Het iWlz-netwerkmodel wordt incrementeel geïmplementeerd aan de hand van het afsprakenstelsel iWlz-netwerkmodel. Dit artikel is kaderstellend voor alle implementatiestappen.

Dit artikel beschrijft de dienst Raadplegen. Deze dienst wordt door bronhouders aangeboden aan (toekomstige) afnemers.

1. Inleiding

De volledige validatie flow voor het raadplegen van een register is beschreven in het artikel nID netwerkstelsel en verloopt in de basis op dezelfde wijze als Notificeren.

Het gaat bij het raadplegen van een register om:

  1. Valideren autorisatie verzoek door de autorisatieserver

  2. Valideren autorisatie door de PEP

  3. Valideren ingediende GraphQL-query door de PDP

image-20250116-142823.png
@startuml Raadplegen toets ' !pragma teoz true skinparam ParticipantPadding 20 skinparam BoxPadding 10 box "Deelnemer"     participant "Client" as Client end box box "nID"     participant "autorisatieserver" as AuthzServer     participant "PEP" as PEP     participant "PDP" as PDP end box box "Register"     participant "Resource-Server" as resourceserver end box activate Client     Client -> AuthzServer: **[1] - Aanvragen van autorisatie**\n"scope": "registers/resource:read"\n Authenticatiemiddel     activate AuthzServer         note right of AuthzServer: volledige validatie zie nID netwerkstelsel         AuthzServer --> Client --: 200 Response (JWT Access-Token)     deactivate AuthzServer deactivate Client Client -> PEP: **[2] - GraphQL Request**\nAuthenticatiemiddel + JWT Access-Token + Query activate Client     activate PEP     note right of PEP: volledige validatie zie nID netwerkstelsel     PEP -> PDP: **[3] - Query met policy valideren**         activate PEP #LightGray             activate PDP                 PDP -> PDP: Valideer query                 PDP -> PEP: Query allowed             deactivate PDP             PEP -> resourceserver: GraphQL Request         deactivate PEP         activate resourceserver             resourceserver --> PEP: 200 Response (GraphQL)         deactivate resourceserver         PEP --> Client: 200 Response (GraphQL)     deactivate PEP deactivate Client @enduml

Dit artikel gaat over wat er nodig is voor de succesvolle validatie van een raadpleging door de PDP.

2. Policy’s en PDP

In de stap 3 - Query met policy valideren door de PDP, toetst de PDP of de ingediende GraphQL-query is toegestaan voor de indiener en of de query juist is opgesteld.

Het Informatiemodel iWlz dat te vinden is via de website: Informatiemodel beschrijft voor elke register de toegangsregels voor een deelnemer op dat register. Per register zijn er voor de huidige deelnemers van het netwerk autorisatieregels en bijbehorende autorisatiematrix opgesteld die beschrijven welke informatie mag worden geraadpleegd.

De combinatie van deze autorisatieregels en autorisatiematrix zijn voor automatische toetsing vertaald naar policy’s. De policy’s zijn de machine-leesbare vertalingen van autorisatieregels en autorisatiematrix. Met de policy’s kan de PDP beoordelen of een ingediende GraphQL query voldoet.

De samenhang tussen de policy en de ingediende GraphQL-query luistert zeer nauw daarom zijn er query-templates beschikbaar gesteld.

3. GraphQL query-templates

De GraphQL query-templates beschrijven het template hoe een raadpleger vanuit zijn rol informatie kan raadplegen die is toegestaan voor die raadpleger. Deze templates volgen altijd het GraphQL-schema maar moet op bepaalde momenten aan vaste patronen voldoen vanwege de geldende autorisatie voor die raadpleger op dat moment. Gaat een raadpleger buiten dit patroon dan zal de query worden afgekeurd en krijgt de raadpleger geen inzicht in de data.

Voor elk register worden deze beschikbaar gesteld. Deze zijn te raadplegen via het betreffende uitwisselprofiel van het register.

3.1 Voorbeeld raadplegen Indicatieregister

Benodigde scope: registers/wlzindicatieregister/indicaties:read

Deze scope staat toe om een indicatie op te vragen uit het Indicatieregister. De autorisatieserver heeft bij het aanvragen van de autorisatie-token gecontroleerd of de deelnemer hiertoe is gemachtigd. Daarna mag de deelnemer een GrapqhQL query opsturen. 

Wat en hoe de raadpleger met een GraphQL query mag raadplegen wordt bepaald door bijbehorende policy.

Voorbeeld: Opvragen indicatie door het initieel verantwoordelijke zorgkantoor. 

Het zorgkantoor moet hierbij verplicht zowel de eigen uzovi-code als het ID van de te raadplegen Wlz-indicatie meesturen. Als een van deze ontbreekt, wordt de query niet uitgevoerd. het PDP controleert of beide aanwezig zijn en beoordeelt ook welke gegevens worden opgevraagd. Alleen als er een gegeven wordt aangevraagd waarvoor het zorgkantoor geen toegang heeft (meer dan is toegestaan volgens de query-template), zal het PDP de query afkeuren.

# QIR-0001-ZKi.graphql # Query voor initieel Verantwoordelijk Zorgkantoor op Indicatieregister # Verplichte input: # - wlzIndicatieID = te raadplegen WlzIndicatie # - uzovicode zorgkantoor = eigen uzovicode raadpleger # versie 1.0.0 - 2024-10-04 query WlzIndicatie( $wlzIndicatieID: UUID! $initieelVerantwoordelijkZorgkantoor: String! ) { wlzIndicatie( where: { wlzindicatieID: {eq: $wlzIndicatieID} initieelVerantwoordelijkZorgkantoor: {eq: $initieelVerantwoordelijkZorgkantoor} } ) { wlzindicatieID bsn besluitnummer soortWlzindicatie afgiftedatum ingangsdatum ... grondslag { grondslagID grondslag volgorde } geindiceerdZorgzwaartepakket { geindiceerdZorgzwaartepakketID zzpCode ingangsdatum ... } ... }

(De volledige query-template is te vinden op:  GitHub - iStandaarden/iWlz-indicatie: Koppelvlak specificatie Indicatieregister )

Let op: Of het raadplegende zorgkantoor uiteindelijk gegevens ontvangt, hangt er ook van af of de combinatie van initieelVerantwoordelijkZorgkantoor en wlzIndicatieID daadwerkelijk in het register voorkomt.

 

Related content