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 | |
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.
| (jur.avg.201) |
PGOK-FR011 | Toestemming en Logging | Gebruiker | expliciet toestemming geven voor de gehele overdracht
| ik volledige controle heb over mijn gegevens.
| (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.
| |
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
| |
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
| |
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
| |
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).
| |
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 | |
PGOK-NFR002 | Veiligheid | MedMij | dat authenticatie- en encryptiemethoden regelmatig worden geüpdatet | de beveiliging up-to-date blijft | |
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 | |
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 | |
PGOK-NFR031 | Auditability & Logging | MedMij | dat alle transacties gelogd worden voor auditdoeleinden | naleving gecontroleerd kan worden | |
PGOK-NFR032 | Auditability & Logging | MedMij | dat logs minimaal 5 jaar worden bewaard conform MedMij-richtlijnen | historische gegevens beschikbaar blijven voor audits | |
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. |
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? |
|
Integriteit: Wat als het bestand onderweg beschadigd raakt? |
|
Geldigheid van de accesstoken: Wat als verloopt? |
|
Privacy: Hoe wordt de overdracht gelogd? |
|