Skip to main content
Skip table of contents

Functioneel ontwerp (v0.4)


PGO-koppelvlak is bedoeld om dataportabiliteit mogelijk te maken tussen PGO’s. De volgende requirements en user stories zijn vastgesteld om dit mogelijk te maken.

Zie waarom en voor wie doen we dit voor de uitgebreide scope en doelstelling van het project. Uitwisseling over het koppelvlak is zinvol wanneer een PGO zowel de rollen van beschikbaarstellend als raadplegend implementeert (bron en doel). Alle PGO’s in de aanbesteding moeten daarom aan het eind van het proces verplicht kunnen ontvangen en delen.

Requirements

Functionele requirements

 

ID

Aspect

Als….

Wil ik …..

Zodat …..

Afspraak

PGOK-FR001

Authenticatie en Autorisatie

Gebruiker

mij kunnen authenticeren via een door MedMij goedgekeurde methode

mijn gegevens veilig zijn en alleen ik toegang heb

A 9.4.1 Beperking toegang to informatie

PGOK-FR002

Authenticatie en Autorisatie

Gebruiker

dat alleen ik als eigenaar van het dossier toestemming kan geven voor de overdracht

mijn medische gegevens niet zonder mijn goedkeuring gedeeld worden.

 

AVG artikel 6,7,9

(jur.avg.201)

PGOK-FR011

Toestemming en Logging

Gebruiker

expliciet toestemming geven voor de gehele overdracht

 

ik volledige controle heb over mijn gegevens.

 

AVG artikel 6,7,9

(jur.avg.201)

PGOK-FR012

Toestemming en Logging

Gebruiker

dat mijn toestemming eenmalig is voor de specifieke transactie en niet hergebruikt kan worden

 

ik niet ongewenst gegevens deel. 

 

PGOK-FR013

Toestemming en Logging

MedMij

dat toestemming wordt gelogd inclusief tijdstip en details

 

de transactie auditbaar en compliant is met de wetgeving en NEN7510/7513.

 

A 12.4.1 Gebeurtenissen registreren

PGOK-FR021

Gegevensformaat en Interoperabiliteit

DVP

het dossier uitwisselen in een door MedMij gespecificeerd formaat 

 

het interoperabel is met andere PGO’s.

 

PGOK-FR022

Gegevensformaat en Interoperabiliteit

Gebruiker

dat mijn gegevens volledig en correct worden overgezet

 

ik geen informatie verlies

 

PGOK-FR023

Gegevensformaat en Interoperabiliteit

MedMij

dat de bron-DVP gekwalificeerd is als aanbieder voor de betreffende gegevensdienst

 

alleen vertrouwde partijen gegevens verwerken

 

Overeenkomsten en rechtsrelaties

PGOK-FR024

Gegevensformaat en Interoperabiliteit

MedMij

dat de bron-DVP geregistreerd is in de ZAL

 

de gegevensuitwisseling betrouwbaar en gecontroleerd is.

 

PGOK-FR031

End-to-End Encryptie

Gebruiker

dat de overdracht plaatsvindt via een beveiligd kanaal (TLS 1.2 of hoger)

 

mijn gegevens niet kunnen worden onderschept

 

Functies en gegevens/Beveiliging

PGOK-FR032

End-to-End Encryptie

MedMij

dat data in transit en data-at-rest versleuteld zijn volgens MedMij-normen

 

de privacy en veiligheid gewaarborgd blijft

 

A 10.1.1 Beleid inzake encryptie

PGOK-FR041

Dataminimalisatie

Gebruiker

dat alleen de door mij geselecteerde gegevens worden overgedragen

 

ik controle houd over wat er gedeeld wordt

 

PGOK-FR042

Dataminimalisatie

DVP

geen onnodige gegevens meesturen

 

de overdracht voldoet aan het principe van dataminimalisatie (conform AVG).

 

jur.avg.106

PGOK-FR051

Bevestiging en Fallback-mogelijkheid

Gebruiker

een bevestiging na een succesvolle overdracht

 

ik weet dat mijn gegevens correct zijn overgezet.

 

PGOK-FR052

Bevestiging en Fallback-mogelijkheid

Gebruiker

een herstelmechanisme bij falen

 

ik een nieuwe poging kan doen of instructies krijg bij een foutmelding

 

Non-functionele requirements

ID

Aspect

Als….

Wil ik …..

Zodat …..

Afspraak

PGOK-NFR001

Veiligheid

MedMij

dat de overdracht voldoet aan de AVG en NEN 7510-standaarden

de privacy en veiligheid gewaarborgd zijn

Beleid voor informatiebeveiliging

PGOK-NFR002

Veiligheid

MedMij

dat authenticatie- en encryptiemethoden regelmatig worden geüpdatet

de beveiliging up-to-date blijft

Beleid encryptie

PGOK-NFR011

Betrouwbaarheid

Gebruiker

dat de overdracht geen gegevensverlies veroorzaakt

mijn medische informatie volledig blijft

PGOK-NFR012

Betrouwbaarheid

MedMij

dat eventuele fouten worden gelogd en beheerd via een incidentmanagementproces

problemen snel worden opgelost

Beheer van technische kwetsbaarheden

PGOK-NFR021

Prestaties

Gebruiker

dat de overdracht binnen een redelijke tijd wordt voltooid (bijv. max. 10 seconden voor een standaarddossier)

ik niet onnodig hoef te wachten

PGOK-NFR022

Prestaties

Gebruiker

dat de service een uptime van 99,9% garandeert

de beschikbaarheid gewaarborgd is

A 12.3.1 Capaciteitsbeheer

PGOK-NFR031

Auditability & Logging

MedMij

dat alle transacties gelogd worden voor auditdoeleinden

naleving gecontroleerd kan worden

A 12.4.1 Gebeurtenissen registreren

PGOK-NFR032

Auditability & Logging

MedMij

dat logs minimaal 5 jaar worden bewaard conform MedMij-richtlijnen

historische gegevens beschikbaar blijven voor audits

A 12.4.1 Gebeurtenissen registreren

PGOK-NFR041

Gebruiksvriendelijkheid

Gebruiker

dat de overdracht eenvoudig uit te voeren is via een intuïtieve gebruikersinterface

zonder moeite mijn gegevens kan overzetten

PGOK-NFR042

Gebruiksvriendelijkheid

Gebruiker

duidelijke feedback krijgen over de status van de overdracht

ik weet wat de voortgang is.

PGOK-NFR050

Portabiliteit

Gebruiker

dat documenten een toekomstbestendig formaat (PDF/A) volgen zonder licentiebeperkingen (lettertypen, huisstijl)

ik documenten in mijn dossier altijd mag inzien, kopiëren, downloaden, meenemen en delen.

PDF/A met minimale compliance

Use cases

Doel-PGO haalt een dossier (PDF) op bij bron-PGO volgens MedMij-richtlijnen

Stap 1: Initiëren van de aanvraag in doel-PGO

  • De gebruiker logt in op doel-PGO met 2-factor en kiest de optie "Dossier ophalen bij een andere PGO".

  • Doel-PGO toont een lijst van gekwalificeerde PGO’s.

  • De gebruiker selecteert bron-PGO als bron.

Stap 2: Authenticatie en toestemming

  • Doel-PGO stuurt de gebruiker door naar bron-PGO voor authenticatie met de inlogmethode van bron.

  • De gebruiker logt in op beschikbaarstellend bron-PGO en krijgt een algemeen toestemmingsverzoek te zien waarin staat dat doel-PGO gegevens wil ophalen. Er is geen optie voor langdurige toestemming.

  • De gebruiker geeft expliciet toestemming, waarna de gebruiker terugkeert naar doel-PGO met een code. Doel-PGO wisselt de code in voor een token en heeft daarmee toestemming gekregen om een lijst van documenten op te halen met tenminste één PDF/A-document langs gegevensdienst 51.

Stap 3: Genereren van een accesstoken

  • Bron-PGO controleert of het opgevraagde dossier voor ingelogde gebruiker beschikbaar is.

  • Bron-PGO genereert een unieke, tijdelijke auth-code met beperkte geldigheidsduur (bijv. 15 minuten).

  • Bron-PGO stuurt de gebruiker met een redirect terug naar het return-url van Doel-PGO. Op het terugkeeradres is als query-parameter de code opgenomen of een een foutmelding.

  • Doel-PGO gebruikt de code om bij het token-endpoint van bron-PGO in te wisselen. Het token-endpoint is beschikbaar in MedMij-register zorgaanbiederlijst.

  • Bron-PGO deelt een accesstoken met doel-PGO.

  • Beide PGO’s loggen de transactie inclusief tijdstip, IP-adres en de gevraagde bestanden in een auditlog.

Stap 4: Ophalen van het bestand door doel-PGO

  • Doel-PGO gebruikt het accesstoken om toegang te verkrijgen tot medische patiëntinformatie in het dossier. Het dossier is versleuteld in opslag. In deze uitwisseling gaat het om het opvragen van een of meerdere documenten in het dossier of een document dat gegenereerd wordt op basis van informatie in het dossier. De informatie is steeds versleuteld in opslag en tijdens transport bij bron en doel.

  • Bron-PGO valideert de accesstoken, geneert optioneel een document en een gevraagde documentenlijst en het documentbestand versleuteld naar doel-PGO via een beveiligde verbinding.

  • Doel-PGO controleert de integriteit van het bestand via een hashcontrole indien aangeboden.

  • Als de controle slaagt, wordt het bestand opgeslagen in de omgeving van doel-PGO.

Stap 5: Bevestiging en afronding

  • De gebruiker krijgt een melding dat het dossier is overgenomen of een foutmelding als dit niet lukte.

  • De gebruiker kan het bestand in doel-PGO openen en eventueel delen met een zorgverlener.

Risico’s en uitdagingen in het ontwerp

In het ontwerp en de implementatie ervan zien wij verschillende risico’s die MedMij tijdens voorbereiding en validatie probeert te beheersen.

Bekende risico’s

Risico: toestemming afgeven kan een uitdaging zijn

Autorisatie voor het uitwisselen van gegevens is essentieel voor een koppelvlak waarin PGO’s patiëntgebruikersinformatie delen met ander PGO’s. Dit kan een uitdaging zijn, want toestemming bevragen bij gebruikers is nieuw voor beschikbaarstellende PGO’s.

Deelnemers zijn volledig bekend met de gehanteerde afspraken in MedMij Core, gebaseerd op OpenID Connect, maar PGO’s implementeerden tot nu toe alleen de bevragende clientzijde die overgaat op tokenuitwisseling, nog niet de flow op aanbiederskant die de gebruiker door consent leidt voor de gevraagde scope voor delen.

Verwachting is dat vrijwel alle PGO’s een softwareopzet hebben voor het inloggen van gebruikers die in de basis compatibel is met OpenID Connect en authorization code flows. De implementatie ervan is echter zeer specifiek per PGO. In gesprekken en tests met deelnemers moet duidelijk worden hoeveel werk dit is voor individuele ontwikkelteams. Kennis zal beschikbaar zijn en eenmaal uitgewerkt voor het koppelvlak is autorisatie herbruikbaar. Een formele acceptatietest is vereist om veilige uitwisseling te garanderen.

Risico: resourceserver mogelijk niet beschikbaar

Beschikbaar stellen van gegevens langs een gegevensdienst binnen het afsprakenstelsel volgt doorgaans uitwisseling langs HL7 FHIR-standaarden. Dit impliceert het aanbieden van een FHIR-server waarop deelnemers verzamelen. Sommige DVP’s en DVA’s kiezen er echter voor om in de uitwisseling gebruik te maken van FHIR zonder een volledige FHIR-server. Niet alle PGO’s zullen dus een FHIR-server aanbieden, weinig PGO’s hebben een FHIR-server openstaan voor extern bevragen en het combineren van een server voor interne en externe bevraging kan vaak tegen beperkingen aanlopen in het beheersen van toegang.

In antwoorden op een vragenlijst gaven enkele PGO’s aan dat zij geen FHIR-server beschikbaar willen stellen. In het ontwerp vereist PGO-koppelvlak dit niet, wel moet het mogelijk zijn een endpoint aan te bieden dat wordt geregistreerd in de Zorgaanbiederslijst waarop andere PGO kunnen bevragen. Het gaat dan om het ondersteunen van één of enkele queries, dit ontwerp probeert dit zoveel mogelijk te beperken door bijvoorbeeld eenmaal documentreferenties (zonder documentmanifests) uit te wisselen. Verwachting is dat een dergelijke minimale implementatie goed haalbaar is voor deelnemers, aangezien uitwisseling over FHIR al plaats vindt en deze kennis bij alle ontwikkelteams ligt.

Risico: opleveren patiëntinformatie in PDF

Uitwisselen van patiëntinformatie gebeurt voor het eerst in document langs een ongestructureerd PDF/A-formaat. Enkele PGO’s hebben een dergelijke exportfunctie wellicht al geïmplementeerd, voor de meeste PGO’s is het uitdrukken van medische gegevens in FHIR en HTML een meer natuurlijke keuze.

PGO kan een uitdanging hebben om patiëntdossier als PDF te exporteren. In het prototype en voorbeelden stellen we voor en laten we zien hoe dit bereikt kan worden met algemeen vrijbeschikbare exportsoftware. Werkbaar en in testfase willen we meer informatie verzamelen over hoe PGO’s dit aanpakken.

De keuze voor PDF/A als uitwisselbaar exportformaat volgt uit een afweging om waarde op te leveren aan patiëntgebruikers waar volledig gestructureerde overdracht op gegevensdiensten in expertsessie als een erg grote stap werd gezien met veel implementatierisico. Een document uitwisselen beperkt risico’s.

Risico: exporteren in PDF kan veel tijd nemen

Een opgebrachte zorg is dat het genereren van een export op een volledig medisch overzicht bij een PGO kan leiden tot timeouts bij de raadplegende PGO. Immers, de onderliggende infrastructuur met database wordt bevraagd, gegevens worden samengevoegd zoals bij het tonen van meerdere webpagina’s in PGO en daarop een document gegenereerd.

In het ontwerp nemen we de optie mee voor uitwisselen langs asynchronous-respons om timeouts te voorkomen. Dit werkte goed in een validatie met prototype, daar ontstonden overigens geen timeouts. Tests met deelnemers moet uitwijzen of een gevuld patiëntendossier in de praktijk inderdaad langer dan bijvoorbeeld 20 seconden neemt. Blijkt dat PGO’s snel kunnen uitleveren, dan is async-respons overbodig.

Uitdagingen en oplossingen

Andere risico’s, uitdagingen en oplossing nog onderwerp van gesprek, concept ontwerp na overleg met deelnemers en stelselarchitecten.

Uitdaging

Voorgestelde oplossing

Authenticatie: Hoe voorkomen we ongeoorloofde toegang?

(tick) De gebruiker moet 2-factor inloggen bij bron-PGO en expliciet toestemming geven.

Integriteit: Wat als het bestand onderweg beschadigd raakt?

(warning) Hash-validatie en versleutelde overdracht voorkomen dataverlies. Omdat we werken met gegenereerde documenten langs uitgesteld verzamelen (asynchronous pattern) is de hash niet vooraf bekend bij het ophalen van de lijst met DocumentReference.

Size en hash zijn vooraf niet te berekenen voor documenten die op een later moment gegenereerd worden. Bij inline-data zou dat wel mogelijk zijn, maar de verwachting is dat deelnemers nauwelijks inline data meesturen. We bespreken dit met deelnemers.

Geldigheid van de accesstoken: Wat als verloopt?

(tick) De gebruiker moet binnen een bepaalde tijd het bestand ophalen, anders de aanvraag herhalen.

Privacy: Hoe wordt de overdracht gelogd?

(tick) Beide PGO’s loggen de transactie in hun auditlogs voor AVG en NEN7510-compliance.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.