Performance

Toepassingsbereik performance-eisen

De beschreven performance-richtlijnen in dit hoofdstuk zijn van toepassing uitsluitend op DVA’s en zorgaanbieders die de gegevensdienst Taken ondersteunen. De reden is dat de grootste performance-problemen bij het verzamelen van de taken door de DVA bij de achterliggende bronsystemen liggen.

De ambitie voor Aanbiedermodules is om gebruikers gebruikersvriendelijke responsetijden te bieden. Daarom zijn de gewenste responsetijden strenger dan de tijden die momenteel in het MedMij‑afsprakenstelsel staan. De onderstaande performance-eisen zijn bedoeld als richtlijnen. In de projecten wordt onderzocht in hoeverre deze doelen haalbaar zijn. Na de projecten wordt afgestemd of deze responsetijden voor Aanbiedermodules ook kunnen worden opgenomen in het MedMij‑afsprakenstelsel.

Ondersteuning voor deze gegevensdienst blijkt uit een geldige registratie in de MedMij Zorgaanbiederlijst, waarin de zorgaanbieder is gekwalificeerd voor de betreffende gegevensdienst.
Alleen DVA’s die als zodanig zijn geregistreerd, worden geacht de FHIR-interacties en bijbehorende performance-verwachtingen voor Taken te ondersteunen.

Performance-eisen voor FHIR-interacties

Om snelle en voorspelbare gebruikerservaring te garanderen, gelden de volgende richtlijnen:

Standaard FHIR-read (GET) requests (per resource)

Gemiddelde response: ≤ 600 ms
95e percentiel: ≤ 1500 ms
99e percentiel: ≤ 3 s

Write-operaties (POST/PUT/PATCH)

Gemiddeld: ≤ 1000 ms
95e percentiel: ≤ 2500 ms
FHIR transaction bundles: ≤ 5 s

Deze normen zijn richtinggevend voor DVA’s en maken het PGO mogelijk om binnen acceptabele tijd taken op te halen bij meerdere zorgaanbieders.

FHIR search – paginering en omvang

Paginering is een verplicht onderdeel van de FHIR-standaard (STU3+) en de DVA MOET paginering ondersteunen.
De DVP MOET elke FHIR search-query pagineren, ongeacht het verwachte aantal resultaten.
De PGO MOET _count gebruiken om de gewenste paginagrootte aan te geven.
De DVA MAG een kleinere paginagrootte hanteren dan gevraagd.
De PGO MOET Bundle.link[relation="next"] volgen als cursor.
De PGO MAG NIET aannemen dat offsets of paginanummers beschikbaar zijn.
De DVP MOET er vanuit gaan dat alle resultaten pas ontvangen zijn als er geen Bundle.link[relation="next"] meer aanwezig is in de response.

Aanbevolen paginagrootte

Aanbevolen maximum: ≤ 50 resources per pagina
Absolute bovengrens: ≤ 100 resources per pagina (alleen indien server dit ondersteunt)

Performance FHIR search (bundel):

Gemiddelde response (<20 resources): ≤ 1 s
95e percentiel: ≤ 2 s
99e percentiel: ≤ 5 s

Uitgeschreven voorbeeld (Task search met paginering)

1) Eerste pagina opvragen

CODE

GET https://dva.example.org/fhir/Task?status:not=completed&code=90XX&_count=50
Authorization: Bearer eyJ...
Accept: application/fhir+json

Voorbeeldresponse (ingekort)

CODE

{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 134,
  "link": [
    {
      "relation": "self",
      "url": "https://dva.example.org/fhir/Task?status:not=completed&code=90XX&_count=50"
    },
    {
      "relation": "next",
      "url": "https://dva.example.org/fhir/Task?_getpages=9c2f...&_getpagesoffset=50&_count=50"
    }
  ],
  "entry": [
    { "resource": { "resourceType": "Task", "id": "t1", "...": "..." } }
    // ... totaal 50 entries ...
  ]
}

Belangrijk: die next.url-parameters (zoals _getpages...) zijn server-specifiek. Je volgt de URL exact; je bouwt niet zelf “pagina 2”, zie: Bundle - FHIR v4.0.1.

2) Volgende pagina opvragen (cursor volgen)

CODE

GET https://dva.example.org/fhir/Task?_getpages=9c2f...&_getpagesoffset=50&_count=50
Authorization: Bearer eyJ...
Accept: application/fhir+json

Response bevat opnieuw eventueel link.next, totdat de laatste pagina is bereikt (dan ontbreekt relation="next").

Parallel ophalen van taken

Een PGO MOET verzoeken richting verschillende DVA’s parallel uitvoeren (async, concurrent).
Dit zorgt ervoor dat de totale wachttijd bepaald wordt door de traagste DVA.

Voorbeeld:

Scenario	Tijd
Serieel: 10 DVA’s × 2 s	20 seconden
Parallel: max. responstijd van de langzaamste DVA	~2–3 seconden

Concretisering van de ambitie

Om de ambitie rondom het verzamelen van aanbiederstaken concreet te maken, worden hieronder representatieve gebruiksscenario’s beschreven. Deze scenario’s dienen ter illustratie van de verwachte werking en gebruikerservaring.
De onderliggende technische specificaties en interfaces blijven in alle gevallen ongewijzigd, ongeacht het aantal zorgaanbieders of taken.

Scenario A — Verzamelen van één taak bij één zorgaanbieder

Context
De gebruiker heeft langdurige toestemming afgegeven en logt in bij de PGO. Er is één zorgaanbieder geselecteerd die één openstaande aanbiedertaak heeft.

Transacties

PGO → DVA: FHIR search (Task?status:not=completed&code=…)
DVA → PGO: Bundle met één Task

Verantwoordelijkheden

DVA: levert de taak volgens FHIR R4 search, eventueel in één pagina
PGO/DVP: toont taak direct aan gebruiker
Module: wordt pas gestart na expliciete actie van de gebruiker

Scenario B — Verzamelen van meerdere taken bij één zorgaanbieder

Context
De gebruiker heeft meerdere openstaande taken bij één zorgaanbieder (bijv. meerdere vragenlijsten of acties).

Transacties

PGO → DVA: FHIR search met paginering
DVA → PGO: één of meerdere Bundles (via link.next)

Verantwoordelijkheden

DVA: past paginering toe bij grotere resultsets
PGO/DVP: verwerkt resultaten pagina-voor-pagina en kan tussentijdse resultaten tonen
Module: identiek gedrag per individuele taak

Scenario C — Verzamelen van taken bij meerdere zorgaanbieders

Context
De gebruiker selecteert meerdere zorgaanbieders in de PGO. Iedere zorgaanbieder heeft nul, één of meerdere openstaande taken.

Transacties

PGO → meerdere DVA’s: parallelle FHIR search-requests per DVA
DVA’s → PGO: onafhankelijke Bundles per zorgaanbieder

Verantwoordelijkheden

PGO/DVP
- voert verzoeken parallel uit
- combineert resultaten per zorgaanbieder
- toont voortgang (“taken ophalen bij zorgaanbieders”)
DVA
- levert taken onafhankelijk van andere DVA’s
- hoeft geen kennis te hebben van andere zorgaanbieders
Module
- wordt per taak gestart
- heeft geen kennis van het aantal zorgaanbieders

Belangrijke duiding

Het aantal zorgaanbieders beïnvloedt alleen het aantal parallelle transacties, niet:
- het FHIR-profiel
- de search-parameters
- de beveiliging
- de autorisatie-flow
Elke DVA is volledig autonoom en wordt afzonderlijk bevraagd.
De PGO is verantwoordelijk voor coördinatie, aggregatie en gebruikerservaring.

Samenvatting

Het verzamelen van aanbiederstaken is technisch identiek voor één of meerdere zorgaanbieders. De FHIR-interfaces, zoekparameters en beveiligingsmechanismen blijven ongewijzigd. Het verschil zit uitsluitend in de orkestratie aan PGO-zijde, waar meerdere DVA’s parallel worden bevraagd en resultaten worden samengevoegd. Door deze scenario’s expliciet te benoemen wordt de beoogde gebruikerservaring concreet gemaakt, zonder de technische specificaties te verzwaren of te wijzigen.