3.9 Ontwerpkeuzes
1. Waarom gekozen voor SMART on FHIR App Launch
Het gekozen mechanisme voor het starten van een aanbiedermodule is gebaseerd op de internationale standaard SMART on FHIR.
Deze standaard wordt ook in de Europese regelgeving – waaronder de European Health Data Space (EHDS) – genoemd als basis voor veilige en gestandaardiseerde toegang tot gezondheidsdata.
Interoperabiliteit: door gebruik te maken van een wereldwijd erkende standaard kunnen modules eenvoudig samenwerken met zowel MedMij- als Koppeltaal-ecosystemen.
Beveiliging: SMART on FHIR gebruikt de OAuth 2.0 / OpenID Connect-flows, waarmee gecontroleerde token-uitgifte en scope-beperking mogelijk is.
Toekomstbestendigheid: de Europese harmonisatie rond EHDS stelt juist dit type authenticatie- en autorisatie-kaders verplicht; aansluiten hierop voorkomt later herontwerp.
2. Waarom Token Exchange (RFC 8693) wordt toegepast
De toevoeging van Token Exchange zorgt ervoor dat een module alleen toegang krijgt binnen de context van een specifieke handeling (zoals een Taak).
Contextgebonden beveiliging: een launch_token beperkt het bereik van het uiteindelijke access-token tot de juiste DVA en module.
Privacy-bescherming: de gebruiker wordt niet indirect geïdentificeerd via de PGO, maar rechtstreeks bij de DVA namens de ZA, in lijn met de privacy-principes van de AVG en (aankomende) EHDS.
Governance en rol van de DVA onder verantwoordelijkheid van de ZA: de DVA handelt onder verantwoordelijkheid van de Zorgaanbieder en identificeert en autoriseert modules namens de ZA. Daarmee blijven plichten en wettelijke eisen tussen ZA ↔ module belegd bij/vertegenwoordigd door de DVA (en dus niet bij PGO of MedMij), passend bij MedMij-afspraken en toekomstige Europese trust-frameworks.
3. Waarom her-identificatie door de DVA
Bij gevoelige modules kan het nodig zijn de gebruiker opnieuw te identificeren, zelfs al is deze via de PGO al ingelogd.
Juridisch kader: bepaalde uitwisselingen vereisen een aantoonbare identificatie binnen de context van de data-aanbieder.
Vertrouwensketen: de DVA moet kunnen garanderen dat de gebruiker dezelfde persoon is als de oorspronkelijke PGO-gebruiker.
Risicobeperking: voorkomt dat tokens uit andere sessies of apparaten worden hergebruikt.
4. Waarom een gecontroleerde terugkeer (return_uri) is toegevoegd
Een vaste return_uri maakt het mogelijk dat de gebruiker veilig en herkenbaar terugkeert naar de PGO of app, zonder verlies van context.
Gebruikerservaring: de gebruiker komt intuïtief terug in dezelfde sessie.
Veiligheid: alleen vooraf geregistreerde URI’s worden geaccepteerd, zodat open-redirect-risico’s worden voorkomen.
Compatibiliteit met mobiele apps: via ‘deep’ links of app-links kan ook een native app na afronding van een module direct worden heropend op het juiste scherm.
5. Waarom het procesdiagram leidend is
Het toegevoegde procesdiagram biedt een uniform overzicht van de interacties tussen PGO, DVA en module.
Communiceerbaar: inzichtelijk voor zowel technische als beleidsmatige stakeholders.
Traceerbaar: elke stap in het diagram correspondeert met beveiligingsmaatregelen en logging-eisen uit het MedMij-afsprakenstelsel.
Uitbreidbaar: nieuwe modules of Europese profielen kunnen worden toegevoegd zonder het basispatroon te wijzigen.
6. Waarom dit aansluit op Europese regelgeving
De Europese Health Data Space en de European Accessibility Act vragen beide om digitale gezondheidsdiensten die veilig, interoperabel én toegankelijk zijn.
Het gekozen ontwerp anticipeert op die regelgeving door te werken met open standaarden (FHIR, SMART on FHIR, OAuth 2.0).
Het ondersteunt ook toegankelijkheid: modules draaien browser-gebaseerd en kunnen voldoen aan WCAG 2.1 AA, zodat ze gebruiksvriendelijk zijn voor alle burgers.