Alpha-ontwerp PGO-koppelvlak (v0.5)
Titel | Solution design op overdracht langs PGO-koppelvlak |
Auteurs | Team Afsprakenstelsel |
Datum | 08 juli 2025 |
Versie | 0.5 |
Revisies | Wijzigingen opgenomen in ontwerpversie 0.5:
|
Waarom en voor wie doen we dit
Context
Binnen MedMij is primair beschreven hoe gebruikers van PGO's informatie met de PGO kunnen verzamelen en hoe zij weer informatie kunnen delen naar de zorgaanbieder. Het initiatief ligt daarbij telkens bij de PGO-(gebruiker). Het delen van informatie kan daarbij gezien worden als een push en gaat dus niet uit van databeschikbaarheid. Er zijn verschillende toepassingen in databeschikbaarheid waarbij de PGO als de bron wel gewenst is:
Inzage PGO door zorgverlener: De PGO gebruiker bepaalt wat een een zorgaanbieder mag zien, de zorgverlener raadpleegt enkel wat relevant is
EHDS: De PGO wordt als een EPD-systeem gezien in de context van de EHDS en zal daarom de verschillende geprioriteerde gegevens beschikbaar moeten kunnen stellen
Externe applicaties: Er kunnen applicaties aan een PGO gekoppeld worden die gebruik maken van de data in de PGO en er ook weer gegevens in terugschrijven.
Secundair gebruik: Voor wetenschappelijk onderzoek het gepseudonimiseerd beschikbaar stellen van gegevens.
Dataportabiliteit: Bij het overstappen tussen PGO’s, of het gelijktijdig gebruik van meerdere PGO’s de in een PGO vastgelegde informatie op een veilige wijze beschikbaar krijgen in een ander PGO.
Probleemdefinitie en doelen
De meest eenvoudig te realiseren usecase is die van dataportabiliteit tussen PGO’s aangezien daar enkel PGO’s iets voor hoeven te doen en daarbij al deelnemer zijn in MedMij Afsprakenstelsel. Daarbij zijn PGO’s al volledig ingericht als afnemende partij in de functie Verzamelen van het afsprakenstelsel waarbij ze voor het opvragen van informatie slechts een beperkte inspanning hoeven te verrichten.
Dit project voorziet in:
Een duurzame inrichting van een koppelvlak om data vanuit een PGO uit te wisselen.
Uitwisseling van (een vereenvoudigde subset/deel van de) data in een PGO naar een ander PGO.
Waarde: Personen kunnen na het uitvoeren van dit project hun gezondheidsgegevens of een deel vanuit één PGO naar een ander PGO overzetten.
Zijdoel: Ontwikkeling van een MVP binnen MedMij
Dit project functioneert ook als een voorbeeld van een minimale aanpassing die waarde oplevert in het kader van de transitie van MedMij naar een agile werkstijl. Naast voordelen voor de gebruiker voegt dit project dus ook waarde toe voor interne stakeholders.
Betrokkenen
Voor dit project zijn enkel DVP's nodig om de functionaliteit te realiseren. Wel wordt hier onderscheid gemaakt tussen een afnemende partij en een beschikbaar stellende partij. Het commitment verloopt via het proces dat daarvoor is voorzien in de aanbesteding en mag daarmee verondersteld worden. Hiervoor zijn dus geen aparte activiteiten nodig.
Kaders
Randvoorwaarden
Er zijn geen randvoorwaarden op andere projecten geïdentificeerd binnen MedMij Architectuur.
Juridische analyse
Zie de bijlage met beknopte juridische analyse waarin de voorwaarden worden geïdentificeerd:
Bijdrage doelen en kernresultaten (aansluiting MedMij Roadmap)
Doelen (thema's) | Jaardoelen 2025 (iets bereiken) | Kernresultaten 2025 (uitkomstgericht in cijfers) | Concrete bijdrage van dit initatief |
---|---|---|---|
PGO's zijn gebruiksvriendelijk en bevatten begrijpelijke informatie. | PGO's zijn multifunctioneel. | Gebruikers communiceren op 10 manieren via MedMij met aanbieders. | De PGO wordt ook een aanbieder waarmee een extra manier van communiceren mogelijk wordt. |
MedMij zorgt voor een veilig en betrouwbaar netwerk. | Het ontwikkelproces is voorspelbaar. | 80% van nieuwe functionaliteiten is binnen een jaar ontwikkeld (verkenning - releasekandidaat). | Eerste resultaat dat waarde toevoegt in één kwartaal gerealiseerd. |
Scope
Omdat we het doel hebben met dit project snel waarde te leveren, houden we de scope klein.
Voor de leesbaarheid gebruiken we in het vervolg van dit document doel-PGO om de ontvanger aan te duiden (raadplegend PGO, DVP) en bron-PGO (beschikbaarstellend PGO, APD) om de aanbieder aan te duiden. PGO’s implementeren functionaliteit voor beide rollen, die van bron- en doelsysteem.
In scope:
Onderzoeken van welke implementatie op korte termijn de meeste waarde oplevert.
Implementeren van de gekozen uitwisseloplossing in de PGO’s die de aanbesteding hebben gewonnen voor eenmalige migratie van gegevens van bron-PGO naar doel-PGO en een eenvoudige toestemmingsvraag (alle aanbestede PGO’s moeten onderling kunnen zenden en ontvangen).
Testen van de uiteindelijke implementatie door middel van een patiëntenpanel.
Niet in scope:
Onderzoeken van alternatieve methoden van data-uitwisseling.
Onderzoeken van datakluizen.
Langdurige toestemming voor uitwisseling tussen PGO’s en beheren toestemmingen.
Uitwisseling eHealth-applicaties.
Live gegevensdeling.
Granulaire toestemmingen (individuele scopes per datapunt/gegevensdienst) tussen PGO’s.
Productontwerp
Om data over te kunnen dragen tussen DVP’s moet er worden gekozen voor een uitwisselmethode. Vanuit eerder onderzoek door Proves zijn daarbij drie opties geïdentificeerd:
Endpoint-endpoint: we voegen extra functionaliteit toe aan het afsprakenstelsel om de huidige uitwisseling tussen DVAs ook beschikbaar te maken voor DVP naar DVP.
Via device: de data wordt bij het bron PGO geëxporteerd naar een bestand en dan handmatig geüpload bij de ontvangende PGO.
Via derde partij: PROVES identificeert ook nog een derde optie, via een neutrale derde partij. Deze optie is hierna niet meer meegenomen.
Uitwisselmethode
We hebben door middel van prototyping en brainstorming de voor en nadelen van de endpoint-endpoint and via device opties uitgewerkt.
Endpoint-endpoint (gekozen optie)
De uitwisseling vindt direct plaats tussen de DVP’s, op eenzelfde manier als tussen DVA en DVP.
eenvoudig voor de gebruiker
veilig
bestaande structuur in het afsprakenstelsel
biedt de basis voor andere use-cases langs het koppelvlak (interfaces)
DVP moet minimale autorisatie en Resource Server implementeren
Via device
De data wordt geëxporteerd naar het apparaat van de gebruiker en daarna geïmporteerd in een ander PGO.
eenvoudig te implementeren
minder eenvoudig voor de gebruiker
security afhankelijk van het apparaat van de gebruiker
biedt enkel een oplossing voor deze specifieke usecase, maar voldoet niet aan het doel om een basis te leggen voor verdere uitwisselingen
Hierbij zijn aan beide kanten grote minpunten geïdentificeerd, zo had endpoint-endpoint niet de voorkeur van deelnemers, omdat ze hiervoor extra infrastructuur moesten opzetten. Dit staat echter wel tegenover het toekomstperspectief van deze methode: via device is niet geschikt voor verdere uitbouw en lost nu alleen deze specifieke usecase op.
Conclusie uitwisselmethode: Omdat endpoint-endpoint communicatie ook bijdraagt aan de langere termijndoelen is dit de beste investering van de tijd van deelnemers. Ook de via device methode kost tijd, maar daarop is minder rendement te verwachten in de toekomst. Daarom gaan we in dit project verder met de endpoint-endpoint uitwisselmethode.
Uitwisselgegevens
Naast de uitwisselmethode, zijn er ook verschillende manieren om de data van één PGO naar een andere over te dragen. In de prototypingfase (Prototyping & uitwerking opties uitwisselgegevens (Q125-PGOK)) zijn daaruit de volgende opties geïdentificeerd:
PDF/A
Uitwisseling van een PDF met samenvatting van de gegevens van de patiënt in de PGO.

Geen wijzigingen afsprakenstelsel nodig
Geen parsing nodig bij het ontvangende PGO, enkel weergeven van de PDF
PGO’s hebben vrije format keuze, ze kunnen alles weergeven zoals het in de PGO stond
Geen gestructureerde informatie
Niet mogelijk om alle data over te dragen
Heeft niet de voorkeur van deelnemende PGO’s, omdat het maken van de PDF ingewikkeld is
FHIR Client Query
Ontvangend PGO voert een FHIR search query uit en vraagt daarmee (gefaseerd) het hele dossier op in FHIR resources.

Alle data is gestructureerd overgedragen in 1 actie/bundel
Versionering van FHIR resources kan dit op termijn lastig maken en niet ondersteunde gegevensdiensten bij de ontvanger leiden tot dataverlies bij overdraging
DVP’s moeten alle resources in FHIR format beschikbaar hebben (of bij request omzetten)
Implementatie in FHIR servers mogelijk ingewikkeld
Er zijn veel verschillen tussen FHIR servers voor de implementatie van de $everything operator, waardoor een custom Operation nodig is.
FHIR Server Document
Ontvangend PGO vraagt via een FHIR operation de bron PGO om een document/composition op te stellen met het hele patientdossier.

Alle data is gestructureerd overgedragen in 1 actie/bundel
Bron PGO krigjt vrijheid om intern allerlei queries efficient uit te voeren om het document samen te stellen
Overdracht bevat ook platte tekst om problemen van FHIR Client Query te ondervangen
Signature & datum: rapport geeft volledige momentopname voor bewaring
Meest ingewikkelde implementatie van alle opties
Bestaande gegevensdiensten
We sluiten gefaseerd ook de PGO’s aan op de huidige gegevensdiensten, waarbij ze per gegevensdienst optreden als aanbieder.

Datastructuur en versioning FHIR is al bepaald in de gegevensdienst, de verwachting is dus duidelijk voor beide kanten
Gedeeltelijke data ophalen is mogelijk
Enorm lang proces voordat alle DVPs voor alle gegevensdiensten kwalificeren met enorm veel proces-overhead
Dataoverdracht vereist misschien wel honderden calls om alle verschillende gegevensdiensten na elkaar uit te vragen
Veel duplicaten in de data - meerdere gegevensdiensten bieden dezelfde resources aan
Deze resultaten zijn overlegd in de Expertsessie van 26 februari 2025 en met de deelnemers doorgesproken. Daaruit, en uit het overleg van het team, is gekozen om verder te gaan met de optie PDF/A.

Conclusie uitwisselgegevens: Optie PDF/A wordt verder uitgewerkt in het laatste prototype van de Prototyping status en daarna in de Alpha, Beta en bij succes gepubliceerd als RC.
Wat is er al
Context: datakluizen
Het implementeren van het principe van ‘datakluizen’ zou een alternatief kunnen vormen voor verdere ontwikkelingen in dit onderwerp. Hiermee zou de rol van een DVP in twee worden gesplitst:
een rol voor de aanbieder van een ‘kluis’, waar de data van de zorggebruiker wordt opgeslagen en waar hij de toegang tot die data kan beheren;
een 'applicatie'-rol voor de aanbieder van een applicatie die van die data gebruik maakt. Dat kan een PGO zijn, maar ook een andere applicatie voor patiënten (en eventueel zorgaanbieders).
In deze situatie is er dus geen sprake van een direct PGO-koppelvlak, maar van het koppelen van datakluizen op het Afsprakenstelsel, mogelijk als derde rol naast DVP en DVA. Ook DVA-aanbieders, of zelfs derden, zouden dan een datakluis aan kunnen bieden, bijvoorbeeld op basis van OpenEHR.
Voordelen
Niet elke leverancier van DVP-applicaties hoeft de data zelf op te slaan, waardoor de data op minder verschillende plekken hoeft te leven en de beschikbaarheid, kwaliteit en herbruikbaarheid van de data een stuk beter wordt.
Het probleem van datakwaliteit is grotendeels ondervangen, omdat het mogelijk wordt om alle data centraal te bewaren, er is dus geen dataverlies bij een goede implementatie.
Nadelen
Het alternatief ‘datakluis’ is een veel ingrijpender alternatief dan het mogelijk maken van dataportabiliteit in de DVP rol door middel van hergebruik van de bestaande usecase ‘verzamelen van gegevens’ voor DVA's.
Eerder onderzoek naar Overstapservice door PROVES
Er is eerder onderzoek gedaan, waarbij dit eindrapport is opgeleverd:
20220105 Eindrapportage PoC Overstapservice 1.0_0.pdf
Patiëntreis
Zie Functioneel ontwerp (v0.5) voor user stories.
Deliverables
Prototype
De volgende deliverables worden opgeleverd in de prototypefase:
Functioneel ontwerp door middel van user stories en clickable demo.
Technisch ontwerp door middel van een uitwerking van de genoemde opties tot sequence-diagrams.
Korte tests en basisprototypes voor alle genoemde opties.
Volledig prototype met uitwisseling op ontwerpdocument.
Testplan voor het testen van de eindoplossing met Interoplab en deelnemers.
Acceptatiecriteria en proces
Inspraak patiënten
In iedere fase bekijken we of we het patiëntenpanel kunnen betrekken, conform de gepresenteerde wensen vanuit managementteam (MT). Het gaat hier echter om een technische oplossing met weinig gebruikersinteractie. Het voordeel van eenvoudig kunnen overzetten van een patiëntdossier naar een andere PGO is evident.
Inspraak deelnemers
Een koppelvlak voor uitwisseling tussen PGO’s heeft grote invloed op de systemen en software die PGO’s beschikbaar moeten stellen. In expertsessies, demo-reviews en tests met gecontracteerde deelnemers verzamelen en we feedback en sturen daarop in aanpassingen op het ontwerp.