Rollen, Functies en verantwoordelijkheden Aanbiedermodule

Architectuur

Hieronder staat de high-level architectuur, waarbij de componenten die nieuw zijn en nodig zijn voor Module gebruik, beschreven zijn.

Het doel van de Aanbiedermodules is om zorgaanbieder en persoon te helpen om verantwoordelijk de modules te gebruiken. De functionaliteiten worden aangeboden in de Aanbiedersmodules die buiten de PGO's staan, maar die wel werken volgens de standaarden die beschreven worden in het MedMij afsprakenstelsel. Daarmee kunnen de aanbieder modules bouwen op het vertrouwen en de interoperabiliteit die MedMij borgt.

Bij het gebruik van een module wordt gebruik gemaakt van een framework (SMART on FHIR App Launch) waarmee derde-partij applicaties (de Aanbiedermodules) veilig verbinding kunnen maken met de PGO om van daaruit functionaliteit te bieden aan de persoon.

Rollen

Voor het gebruiken van een Aanbiedersmodule vanuit het PGO zijn diverse rollen nodig. De rollen die een rol spelen zijn: De Persoon, de DVP en de DVA.

Persoonsdomein

Business

In het Persoonsdomein is er naast de rol Dienstverlener persoon ook de rol Persoon. Hoewel Dienstverlener persoon namens Persoon handelt, kan Persoon niet ongenoemd blijven in de afspraken op deze en onderliggende lagen. Dat komt doordat Persoon niet enkel de gebruiker van Dienstverlener persoon is, maar allereerst het onderwerp van de gezondheidsinformatie die Deelnemers ter beschikking moet stellen; daarvoor is authenticatie en autorisatie nodig. In de architectuur van het afsprakenstelsel heeft Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer.

Application

In het persoonsdomein zijn twee rollen onderscheiden: de User Agent en de DVP Server. Dat is nodig om de verbinding te kunnen leggen met de rollen volgens OAuth. User Agent is de front-end-rol voor de DVP Server, en kan bijvoorbeeld in een browser zijn geïmplementeerd. Zoals ook elders in het MedMij Afsprakenstelsel gaat het hier om rollen, om setjes verantwoordelijkheden dus, niet om implementatiecomponenten.

Aanbiedersdomein

Business

In het Aanbiedersdomein is er naast de rol Dienstverlener Aanbieder ook de rol Aanbieder en module. Deze rollen worden operationeel geheel vertegenwoordigd door de Dienstverlener aanbieder.

Application

Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Aanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Serveren en FHIR Resource Server. Bij Module gebruik zal een achterliggend systeem (de Aanbiedermodule) worden betrokken, voor het MedMij Afsprakenstelsel is dat geen kwestie. Het is voldoende om bij de Authorization Server en FHIR Resource Server de eindverantwoordelijkheid neer te leggen (black box).

De genoemde servers treden op namens alle Modules in het Aanbiedersdomein. Die achterliggende complexiteit is een black box. Hoezeer ook alle eindverantwoordelijkheden gedragen worden door de Dienstverleners die deelnemer zijn in het MedMij Afsprakenstelsel, zij kunnen ervoor kiezen de uitvoering van die verantwoordelijkheden deels of zelfs geheel uit te besteden. In een mogelijke systeemarchitectuur maken meerdere FHIR Resource Server-systemen gebruik van eenzelfde (al dan niet uitbesteed) Authorization Server-systeem. Het is mogelijk dat die FHIR Resource Server-systemen samen onder de eindverantwoordelijkheid van één Dienstverlener Aanbieder vallen, met de uitvoering al dan niet uitbesteed.

De architectuur heeft zo maximale ruimte aan de eigen businessmodellen en architecturen van Dienstverlener Aanbieder willen geven zonder daarbij de interoperabiliteit en strakke eindverantwoordelijkheden geweld aan te doen.

De rollen, nodig voor Module gebruik staan hieronder uitgewerkt in drie lagen van een Enterprise Architectuur, namelijk Business, Application en Technologie.

Business laag

De Persoon kiest expliciet uit de lijst die door Dienstverlener persoon wordt aangeboden de Aanbieder, bij wie hij module wenst te gebruiken en selecteert vervolgens een module .
De DVP initieert het gebruik van de module. Het verzoek gaat naar de passende Dienstverlener anbieder.
Wanneer de app wordt gestart, wordt de Persoon omgeleid naar de autorisatieserver van de Dienstverlener Aanbieder en wordt de Persoon gevraagd om in te loggen en de app te autoriseren om specifieke gegevens te benaderen.
De Persoon kan nu de Module gebruiken. Als de Persoon klaar is met het Module gebruik of het gebruik wil stoppen kan de persoon via de knop terug naar PGO de module verlaten en terugkeren naar zijn PGO.

Applicatie laag

De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren Modules van een zekere Aanbieder te gebruiken. Uit de Module Aanbiederslijst weet de DVP Server welke Modules door een Aanbieder aangeboden worden en of de Aanbieder gebruik maakt van één of meerdere Dienstverlener Aanbieders.
De Persoon maakt expliciet zijn selectie van de module van een aanbieder.
De DVP server stuurt een autorisatieverzoek naar DVA.
De Persoon wordt gevraagd om in te loggen. Indien er sprake is van langdurige toestemming hoeft de patient niet opnieuw in te loggen, maar wordt het refresh token gecontroleerd door de Authorization server.
Na authenticatie van de persoon, leidt de autorisatieserver de Persoon terug naar de DVP server met een autorisatiecode.
De DVP server launcht naar de Module. Het adres van de Module komt uit een lijst.
De module wisselt de autorisatiecode in voor een toegangstoken bij dea Authorization server van de DVA.
De respons bevat een toegangstoken dat de Module kan gebruiken om toegang te krijgen tot de FHIR-resource server. Dit stelt de module in staat om te werken met de gegevens van de patiënt binnen de toegestane scopes.
De Persoon gebruikt de module en na afsluiten van de module keert de persoon weer terug in zijn PGO.

Voor de launch naar de module wordt SMART on FHIR app Launch gebruikt.

Verantwoordelijkheden

SMART on FHIR-Configuratie

SMART on FHIR (Substitutable Medical Apps, Reusable Technologies) configuratie draait om het implementeren van gestandaardiseerde protocollen voor toegang tot gezondheidsgegevens.

Technische Requirements

FHIR-Compliance: Zowel de PGO als de aanbiedersmodule moeten voldoen aan de FHIR versie R4-STU4-standaarden (Fast Healthcare Interoperability Resources), inclusief de versies en profielen die gebruikt worden.
SMART on FHIR-Compatibiliteit: De aanbiedersmodule moet SMART on FHIR ondersteunen om contextinformatie te kunnen ontvangen en verwerken, zoals patiënt-ID en gebruikerscontext.
Interoperabiliteit: De systemen moeten naadloos met elkaar kunnen communiceren via gestandaardiseerde API’s (FHIR en OAuth 2.0).

Security & Privacy Requirements

OAuth 2.0 Het autorisatieproces moet gebaseerd zijn op OAuth 2.0 , zodat de identiteit van de gebruiker kan worden geverifieerd.
End-to-End Encryptie: Alle communicatie tussen de PGO, autorisatieserver en FHIR-server moet versleuteld zijn (HTTPS/TLS).
Sessieduur en Validiteit: De toegang tot de module moet beperkt zijn tot de duur van een sessie, met aandacht voor de geldigheid van tokens en sessie-afhandeling.

SMART on FHIR Launch

De PGO start de module door een request te sturen naar het module launch endpoint met het access token.

Request bevat:

Parameter	beschrijving
`iss`	De issuer van het access token (de DVA/FHIR-server).
`access_token`	Het OAuth 2.0 access token dat toegang geeft tot FHIR-data.
redirect_uri	De URI van de PGO waar de module naartoe moet omleiden na het annuleren of het voltooien van het gebruik van de module.