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

Non-functionele requirements

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.