Alpha Ontwerp PGO-koppelvlak (v0.4)

Integraal Team Afsprakenstelsel

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 waarbij databeschikbaarheid waarbij de PGO de bron is 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 & 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 van het 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-statement: PGO gebruikers kunnen na het uitvoeren van dit project (een deel van hun) data 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 beknopte juridische analyse waarin de juridische voorwaarden worden geïdentificeerd:

Beknopte juridische analyse (v0.4)

Bijdrage doelen en kernresultaten (aansluiting MedMij Roadmap)

Stakeholders & Planning

Werkinformatie (Q125-PGOK)

Scope

Omdat we het doel hebben met dit project snel waarde te leveren, houden we de scope klein.

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

• 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. Daarbij zijn er, vanuit eerder onderzoek door Proves 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.

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:

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

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 het functioneel ontwerp voor user stories:

Functioneel ontwerp (publiek)

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.

Zie Werkproces > Locatie van documenten en Testen.

Acceptatiecriteria en proces

Inspraak patiënten

In iedere fase bekijken we of we het patiëntenpanel kunnen betrekken, conform de gepresenteerde wensen vanuit 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.

Risico’s en maatregelen

De volgende risico’s zijn vooraf geïdentificeerd in dit project.

Risico: datakwaliteit

PGO’s zijn niet de bron van de meeste data en bij omzetting naar andere interchange formats kan data verloren gaan (of zijn gegaan in het verleden). Mitigatie: datakwaliteit wordt meegenomen als voorwaarde in het kiezen voor de juiste data uitwisselingsmethode tijdens de uitvoer van het project.

Andere risico’s, uitdagingen en oplossingen

In het functioneel ontwerp een opsomming van risico’s en uitdagingen geïdentificeerd tijdens de ontwerp- en prototypefasen. Het ontwerp mitigeert deze risico’s, in testfases valideert het team de oplossingen.