3.9 Ontwerpkeuzes en gebruikte standaarden

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 code 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 een gecontroleerde terugkeer (return_uri) is toegevoegd

Een vaste return_url 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.

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

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

Gebruikte standaarden

In het ontwerp is een reeks standaarden gebruikt. De meest belangrijke standaarden die specifiek voor dit ontwerp zijn, zijn hier nogmaals in onderstaande tabel weergegeven.

Last updated: June 10, 2026