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.

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 een eigen gegevensdienstnummer, zoals gespecificeerd in de specificatie van de Gegevensdienst. Dienstverlenerpersoon biedt aan deze informatie te verzamelen.

Proces sequencediagram

Processtappen

De processtappen voor het verzamelen van gegevensdiensten zijn geïmplementeerd bij deelnemers. Voor de volledigheid een overzicht met voorbeeld. Na toestemming verzamelt PGO taken bij de DVA van gekozen Zorgaanbieders. Bij langdurige toestemming kan dit zonder opnieuw inloggen.

Filteren op basis van status

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=completed

• Meerdere uitsluitingen (OR binnen één parameterwaarde):

GET [base]/Task?status:not=completed,cancelled

Verzamelen door Aanbiedermodule

De Aanbiedermodule haalt de Taak op bij de DVA en hierin zit de Task.status. De Aanbiedermodule MOET Task.status uitlezen en aan de hand daarvan alleen acties ondernemen die in overeenstemming zijn met het state machine diagram. Zie FHIR standaard en 3.7 Wijzigen Task Status Module voor meer infromatie.

Wanneer de gebruiker vanuit de PGO een taak opent, MOET de Aanbiedermodule altijd uitgaan van de actuele taakstatus bij de zorgaanbieder en de Task behandelen volgens.

Zie ook Terugkeer naar PGO naar aanleiding van Task.status in 3.8.

Beperken van belasting voor DVA

Door gebruik van _lastUpdated en ETag-mechanismen:

• vraagt de PGO alleen gewijzigde taken op,

• blijft serverbelasting bij DVA’s laag,

• blijft synchronisatie snel,

• en wordt netwerkverkeer beperkt.

Efficië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.

E-tags worden vooralsnog niet toegepast in het project Persoonsgerichte Hybride Netwerkzorg. In de ketentesten en pilot gaan we evalueren of er performance problemen zijn en of het nodig is om E-tags toe te gaan passen. Als het blijkt dat dit nodig is, worden E-tags toegevoegd.

Processdiagram verzamelen met filter

Uitleg 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 Modified

Daarnaast 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:00Z

Zo 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.

Nachtelijke of achtergrondsynchronisatie

Optioneel mag een DVP een nachtelijke of achtergrondsynchronisatie uitvoeren. Deze is alleen zinvol wanneer het PGO zelf notificaties verstuurt (bijv. push-meldingen bij nieuwe taken). In alle andere gevallen is synchronisatie bij inloggen met filters voldoende.

Omgaan met verouderde status (“stale data”)

Wanneer een PGO taken ophaalt en presenteert aan de gebruiker, kan het voorkomen dat de getoonde taakstatus verouderd raakt (“stale data”). Dit kan bijvoorbeeld optreden wanneer:

• de gebruiker dezelfde taak in een andere browser of tabblad opent, of

• de taakstatus door de zorgaanbieder of module wordt gewijzigd terwijl de takenlijst al is geladen.

Dit is inherent aan webapplicaties en niet volledig te voorkomen. Een PGO kan client-side maatregelen nemen, bijvoorbeeld met periodiek verversen of een “laatst bijgewerkt”-indicatie, maar frequente polling leidt tot extra belasting bij DVA’s en is daarom niet wenselijk.

Samenvatting

• Een PGO MAG taken lokaal opslaan, zoals 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.

Aanbevelingen

Ophalen bij inloggen (met langdurige toestemming)

Indien een gebruiker langdurige toestemming heeft afgegeven, wordt aanbevolen om bij elke inlogsessie taken opnieuw op te halen via:

• _lastUpdated (filteren op gewijzigd sinds laatste sync), of

• ETag (alleen opnieuw ophalen bij gewijzigde versie).

Hierdoor blijft de taakweergave actueel zonder een volledige her-synchronisatie.

User interactie

Als nog niet alle DVA’s gereageerd hebben op de GET Request:

• mag de PGO de reeds opgehaalde taken direct tonen,

• en visueel aangeven dat overige bronnen nog bezig zijn (spinner, teller, “X van Y gereed”).

Dit voorkomt dat gebruikers het gevoel krijgen dat de applicatie vastloopt.

Zie ook https://medmij.atlassian.net/wiki/x/GYBrJQ

Progress-indicatie (gebruikersfeedback)

De PGO MOET duidelijke feedback geven, zoals:

• “Gegevens ophalen bij uw zorgaanbieders…”

• teller of percentage van afgeronde DVA-requests

• badges of iconen die “synchronisatie bezig” weergeven

Dit verhoogt transparantie en gebruiksgemak.

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.example.org/auth
  ?response_type=code
  &client_id=pgo 
  &redirect_uri=https://pgo.example.org/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.example.org/auth_callback


1. Authorization code flow (backend, token-endpoint)

HTTP POST https://dva.example.org/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.example.org/auth_callback

200 OK
  Content-Type: application/json
  {
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "token_type": "Bearer",
    "expires_in": 900
    "scope": "pgo"
  }

Het verzamelen van de taken met de gegevensdienst aanbiederstaken is mogelijk met een selectie op het type dat hoort bij de Gegevensdienst van de taken. De precieze waarde van type is te vinden in de specificatie van de Gegevensdienst.

3. Verzamelen takenlijst
zie: https://hl7.org/fhir/R4/bundle.html#search

Auhorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
GET https://dva.example.org/fhir/Task?code=

response:
HTTP/1.1 200 OK
Content-Type: application/fhir+json
{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 2,
  "entry": [
    {
      "fullUrl": "https://dva.example.org/fhir/Task/task-001",
      "resource": {
        "resourceType": "Task",
        "id": "task-001",
        "status": "requested",
        ...
        }
    },
    {
      "fullUrl": "https://dva.example.org/fhir/Task/task-002",
      "resource": {
        "resourceType": "Task",
        "id": "task-002",
        "status": "in-progress",
        ...
      }
    }
  ]
}

//compleet zonder entries
GET /fhir/Task?status:not=completed&code=
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "resourceType": "Bundle",
  "id": "f5a1062c-8df8-4901-8b5e-cd6962cf13e9",
  "meta": {
    "lastUpdated": "2026-01-12T10:10:55.815+00:00"
  },
  "type": "searchset",
  "total": 0,
  "link": [
    {
      "relation": "self",
      "url": "https://dva-aanbiedersmodules.test.medmij.nl/hapi/fhir/Observation"
    }
  ]
}


//compleet met filteren op niet voltooide taken
Auhorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
GET https://dva.example.org/fhir/Task?status:not=completed&code=