3.3 Verzamelen aanbiedertaken
Persoon logt in bij een PGO en vraagt het gezondheidsinformatie te verzamelen.
Voor MedMij-deelnemers introduceert solution design een gegevensdienst in catalogus,
Verzamelen aanbiedertaken die de gangbare uitwisseling volgt met bijbehorende beveiligingseisen.
Processtappen
De processtappen voor het verzamelen van gegevensdiensten zijn geïmplementeerd bij deelnemers. Voor de volledigheid een overzicht met voorbeeld. Na toestemming verzamelt PGO takenlijsten bij de DVA van gekozen Zorgaanbieders. Bij langdurige toestemming kan dit zonder opnieuw inloggen.
Processtap | Toelichting |
|---|---|
1. Inloggen met DigiD | Persoon identificeert bij DVA met DigiD, Inloggen met DigiD. |
2. Toestemming verlenen | Persoon geeft bij DVA toestemming aan DVP om gegevens uit te wisselen langs functie Verzamelen. Zie: toestemming verlenen. Expliciet vraagt de verklaring om het optioneel Starten van aanbiedertaken. DVP ontvangt een access-token langs OAuth2 authorization code flow. |
3. Verzamelen takenlijst | DVP gebruikt token om gezondheidsgegevens te verzamelen. DVA met aanbiedertaken voor Persoon geeft deze terug als lijst. |
4. Presenteren taken | DVP toont taken van Zorgaanbieder volgens weergaverichtlijn. Uit de inleidende tekst begrijpt Persoon dat het openen van een taak tot interactie leidt met en bij de Zorgaanbieder (of een partij die namens de Zorgaanbieder functioneert). |
Procesdiagram
Procesdialoog
Toestemming verlenen en het verkrijgen van een token voor Verzamelen Aanbiederstaken volgt de bekende Authorization-interface en Token-interface in MedMij Afsprakenstelsel (RFC6749 OAuth2).
1. Authorization code flow (frontend, auth-endpoint)
HTTP 302 GET https://dva/auth
?response_type=code
&client_id=pgo
&redirect_uri=https://pgo/auth_callback
&scope=dva
&state=xcoivjuywkdkhvusuye3kch
&MedMij-Request-ID=57510be1-73e6-4a75-9db8-ee005cced48f
&X-Correlation-ID=c0e7b545-9606-4eef-bea7-75d8addaa54b
2. Toestemmingsverklaring afgeven
- Identificeren met DigiD
- Toestemmingsverklaring met optie voor refresh_token (6 maanden)
- Redirect browser Persoon naar https://pgo/auth_callback
1. Authorization code flow (backend, token-endpoint)
HTTP POST https://dva/token
Content-Type: application/x-www-form-urlencoded
X-Correlation-ID: c0e7b545-9606-4eef-bea7-75d8addaa54b
MedMij-Request-ID: 57510be1-73e6-4a75-9db8-dd004ccee67a
grant_type=authorization_code&code=jhgRtpO12D3qR5tU9&
client_id=pgo&
redirect_uri=https://pgo/auth_callback
200 OK
Content-Type: application/json
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"token_type": "Bearer",
"expires_in": 900
"scope": "pgo"
}
Het verzamelen van de takenlijst met aanbiederstaken is mogelijk met een selectie op type ….
3. Verzamelen takenlijst
Auhorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
GET https://dva/fhir/Task?code=
//compleet met filteren op niet voltooide taken
Auhorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
GET https://dva/fhir/Task?status:not=completed&code=
Selectiecode op Task-queries voor aanbiedertaken bekend in komende versie (?code=).
Filteren
De zoekparameter status op Task is van type token (Search - FHIR v4.0.1) en is optioneel. Er mag op meerdere waarden comma-gescheiden doorgeven (OR). Of parameters herhalen (AND) – precieze AND/OR-ondersteuning is per server. Voor token-parameters ondersteunt FHIR (https://www.hl7.org/fhir/R4/task-definitions.html ) de :not modifier. Voorbeeld:
Alles behalve
completed:
GET [base]/Task?status:not=completedMeerdere uitsluitingen (OR binnen één parameterwaarde):
GET [base]/Task?status:not=completed,cancelledEfficiënte synchronisatie (ETag en _lastUpdated)
Een PGO hoeft niet bij elke sessie alle taken opnieuw op te halen. Dit kan leiden tot onnodige belasting van zowel de FHIR-server als de PGO zelf (veel dataverkeer, langere wachttijden).
In plaats daarvan kan de PGO de ETag-waarde of de lastUpdated-tijdstempel van een resource opslaan en gebruiken bij een volgende synchronisatie. Een PGO is dan ook vrij om de taken zelf op te slaan in hun eigen ecosysteem en bij het inloggen van de gebruiker de ‘laatst gewijzigde’ taken op te halen. Dit kan op 2 manieren, met E-Tags en filteren met zoekparameters.
Let op: E-tags zijn resources-based en dus PER resource. Filteren gaat over een hele bundel, en dus voor lijsten het meest toepasselijk.
ETag
Een FHIR-server levert meestal per resource een ETag header (bijv. ETag: W/"2") en een Last-Modified header terug.
De PGO kan deze waarden lokaal bewaren en bij een volgende oproep een conditional GET uitvoeren met If-None-Match of If-Modified-Since.
Voorbeeld (alleen ophalen als er iets gewijzigd is):
GET [base]/Task?status:not=completed
If-None-Match: W/"2"Als de resource niet gewijzigd is, retourneert de server:
HTTP 304 Not ModifiedDaarnaast kan de PGO periodiek enkel gewijzigde taken ophalen met de _lastUpdated parameter en dus zonder E-Tags:
GET [base]/Task?_lastUpdated=gt2025-10-01T00:00:00ZZo worden enkel taken opgehaald die na 1 oktober 2025 gewijzigd zijn.
Door deze aanpak worden performanceproblemen en onnodig dataverkeer vermeden, terwijl de PGO altijd up-to-date blijft.
Samenvatting:
Een PGO mag taken lokaal opslaan (in cache of database).
Bij iedere nieuwe inlogsessie kan de PGO de datum/tijd van de laatste succesvolle synchronisatie gebruiken met
_lastUpdated.Alleen nieuw toegevoegde of gewijzigde taken worden dan opgehaald.
Dit voorkomt overbelasting van de FHIR-server en verbetert de prestaties van de PGO aanzienlijk.
Processdiagram
Aanvullende uitleg
Het verzamelen van gegevensdiensten gebeurt na toestemming voor uitwisseling waarbij de Persoon bij Dienstverleneraanbieder zich identificeert met DigiD en daar DienstverlenerPersoon kortdurende (15 min) of langdurige toestemming geeft (6 maanden) om gezondheidsinformatie te Verzamelen.
MedMij-deelnemers verbinden met elkaar langs adressen vastgelegd in Register. Uitwisseling beperkt zich tot servers gepubliceerd in de lijsten (o.a. Whitelist). In het netwerkverkeer identificeren en versleutelen deelnemers met een PKIoverheid-certificaat. Zorgaanbiederlijsten tonen welke aanbieders specifieke gegevensdiensten voor uitwisseling ondersteunen. PGO-gebruikers selecteren hieruit de hun bekende zorgaanbieders en gegevens die zij willen ophalen.
Ondersteuning voor de gegevensdienst is vastgelegd in zorgaanbiederlijsten (ZAL en ZKL) onder gegevensdienstnummer 90XX. Dienstverlenerpersoon biedt aan deze informatie te verzamelen.