Skip to end of banner
Go to start of banner

RFC0046 Herstructureren afsprakenstelsel

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

Samenvatting

Waarom is deze RFC nodig?

MedMij wil Personen regie geven op hun gezondheid. Het MedMij afsprakenstelsel is opgezet als één groot geheel, waarbij de focus ligt op gegevensuitwisseling in het zorgdomein. Hierbij wordt de gegevensuitwisseling uitgevoerd volgens de usecases verzamelen en delen, waarbij benodigde rollen en verantwoordelijkheden zijn uitgewerkt op verschillende niveaus van het interoperabiliteitsmodel van Nictiz.

Nu wordt duidelijk dat de huidige opzet van het afsprakenstelsel voor uitdagingen zorgt:

  1. Deelnemers geven aan dat het een zoektocht is naar de juiste informatie, om te weten aan welke eisen ze moeten voldoen. Informatie staat over verschillende onderdelen van het afsprakenstelsel verspreid en moet bij elkaar gezocht worden.
  2. Het aansluiten van andere domeinen kan niet zomaar worden uitgevoerd, doordat er op veel plekken in het afsprakenstelsel concreet naar zorg word verwezen. Mede hierdoor moest in 1.4.0 een addendum toegevoegd worden, betreffende aanbieder zonder behandelrelatie.
  3. De huidige structuur van het afsprakenstelsel is gebaseerd op het interoperabiliteitsmodel van Nictiz. Alles wordt in de basis geschreven vanuit de niveaus processen, applicaties en netwerk. Onderwerpen zijn opgedeeld over de verschillende lagen, waarop de informatie van verschillende onderwerpen wordt gecombineerd. Hierdoor kunnen nieuwe (optionele) onderwerpen niet als losse eenheid worden toegevoegd. Vanuit verschillende kanten (deelnemers en MedMij collega's) wordt aangegeven dat dit als onoverzichtelijk wordt ervaren. Dit begint bij het rollenmodel.
  4. Bij nieuwe onderwerpen horen vaak ook nieuwe rollen, met bijbehorende relaties. Door deze toe te voegen aan de huidige opzet, wordt het (rollenmodel) er niet duidelijker op. Vrijwillige vertegenwoordiging is hierbij een goed voorbeeld. De bedoeling is dit toe te voegen als optioneel onderwerp, zodat partijen kunnen kiezen of ze dit willen ondersteunen. Nieuwe rollen (vertegenwoordiger en vertegenwoordigde) moeten worden toegevoegd aan het rollenmodel. Echter, door alle relaties die dan toegevoegd worden, lijkt het dat personen altijd een rol als vertegenwoordiger of vertegenwoordigde invullen. Dit is niet de bedoeling.
  5. Naast gegevensuitwisseling moeten ook functionaliteiten aan de gebruikers worden aangeboden. Dit (modules) is een voorbeeld van onderwerp dat los van gegevensuitwisseling beschreven moet worden, omdat er andere eisen voor gelden.

Hoewel deze RFC een grote wijziging van het stelsel betreft, verandert het niets aan de posities van de huidige Deelnemers en Zorgaanbieders in het stelsel. Het betreft een wijzigingen in de structuur, maar geen nieuwe of gewijzigde verplichtingen. Rollen worden weliswaar aangepakt, maar de huidige verplichtingen worden herschreven, zodat deze blijven gelden.

Relatie met

RFC0021 Herfundering van de Aanbieders-rol

RFC0026 Modules

RFC0039 Toestemming voor meerdere diensten van één aanbieder

RFC0051 Herschikking en herfundering van rollen

RFC0054 Langdurige en offline autorisatie van DVP

Oplossingsrichting

Deze RFC pakt een aantal zaken aan:

  • Om de uitbreidbaarheid te verhogen wordt het afsprakenstelsel opgedeeld in de MedMij Core en verschillende onderwerpen. De Core bevat de basis waarvan alle onderwerpen gebruik van maken, de onderdelen zijn uitbreidingen op de Core.
  • Om de leesbaarheid en bruikbaarheid van het afsprakenstelsel te verhogen wordt de architectuur gedraaid. Zaken worden in de basis beschreven vanuit rollen, functies & gegevens en verantwoordelijkheden. Daarbinnen wordt gebruikgemaakt van de lagen van het interoperabiliteitsmodel.
  • Het grote overzicht van rollen en functies wordt uit elkaar getrokken. De Core beschrijft de rollen en functies die voor het gehele afsprakenstelsel van toepassing zijn. 
    • In de verschillende onderwerpen worden bijbehorende rollen beschreven, waarbij nieuwe rollen specialisaties zijn op bestaande Core rollen. Alleen de Core kan rollen op de hoogste laag (Organisatie) beschrijven.
    • Voor de verschillende functies wordt in het overzicht vastgelegd welke rol verantwoordelijk is voor de levering van de functie. Pas in de uitwerkingen van de usecases worden de andere rollen beschreven, met bijbehorende verantwoordelijkheden.

De structuur van het afsprakenstelsel wordt opnieuw opgezet, waarbij rekening wordt gehouden met de huidige rollen en verantwoordelijkheden. De wijzigingen hebben een zo klein mogelijke impact op de bestaande deelnemers. De deelnemers in hun implementaties houden rekening met de huidige rollen en verantwoordelijkheden, dit moet zo min mogelijk worden aangetast.

De nieuwe structuur richt zich op het opzetten van een algemene basis met onderwerpen als mogelijke uitbreidingen. Vanuit de in de basis vastgestelde rollen zijn specialisaties mogelijk voor de verschillende onderwerpen, met de daarbij behorende verantwoordelijkheden. Hierbij is het mogelijk optionele en verplichte onderwerpen te ondersteunen.

De verwachting is dat door deze wijzigingen de leesbaarheid, bruikbaarheid en uitbreidbaarheid van het afsprakenstelsel verbeteren, waardoor deelnemers beter weten wat er van hen verwacht wordt en nieuwe onderwerpen zonder problemen kunnen worden toegevoegd.

Aanpassing van

Deze RFC raakt nagenoeg alle delen van het afsprakenstelsel

Impact op rollen

DVZA (mogelijk), DVP (ZAL interface)

Impact op beheer


Impact op RnA

wijziging ZAL

Impact op Acceptatie


PIA noodzakelijk
  •  
Gerelateerd aan (Andere RFCs, PIM issues)

Deze RFC betreft een subset /wiki/spaces/PROJECT/pages/131898160

RFC0044 Introductie aanbieder zonder behandelrelatie

Eigenaar

Bouke de Boer, Casper van der Harst

Implementatietermijn

1.5.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

  •  
11 Stelselfuncties worden vanaf de start ingevuld
  •  
2 Dienstverleners zijn transparant over de gegevensdiensten 
  •  
12 Het afsprakenstelsel is een groeimodel
  •  
Dienstverleners concurreren op de functionaliteiten
  •  
13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
  •  
Dienstverleners zijn aanspreekbaar door de gebruiker
  •  
14 Uitwisseling is een keuze
  •  
De persoon wisselt gegevens uit met de zorgaanbieder
  •  
15 Het MedMij-netwerk is gebruiksrechten-neutraal
  •  
MedMij spreekt alleen af wat nodig is
  •  
16 De burger regisseert zijn gezondheidsinformatie als uitgever
  •  
De persoon en de zorgaanbieder kiezen hun eigen dienstverlener
  •  
17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
  •  
De dienstverleners zijn deelnemers van het afsprakenstelsel
  •  
18 Afspraken worden aantoonbaar nageleefd en gehandhaafd
  •  
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling
  •  
19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat
  •  
Toelichting



Uitwerking

Taken

Presentatie

Onderwerpen in de nieuwe structuur

  • Afsprakenset
    • Architectuur en technische specificaties
      • Core
      • Beveiliging
        • Authenticatie
        • Autorisatie
          • Persoonsdomein
          • Aanbiederdomein
        • Informatiebeveiliging
      • Gegevensuitwisseling
        • Verzamelen
        • Delen
        • Abonneren & Notificeren
      • Domeinen
        • Zorg
        • Publiek
      • Modules
        • DVP modules
        • Aanbiedermodules
        • Externe modules

MedMij Core

De MedMij Core bestaat uit algemene onderwerpen die gelden voor alle deelnemers van MedMij. Hierbij worden generieke rollen beschreven, die als basis dienen voor een verdere verdieping binnen de verschillende onderwerpen. Zo wordt op dit niveau bijvoorbeeld gesproken over Aanbieder en Dienstverlener Aanbieder. Van de bestaande regels wordt bepaald welke in de MedMij Core beschreven worden en welke onderdeel uitmaken van één van de onderliggende onderwerpen.

Voor een aantal regels is het noodzakelijk in de MedMij Core af te dalen tot-en-met de technische laag. Bijvoorbeeld het gebruik van TLS en certificaten worden beschreven hierin beschreven en geldt voor alle deelnemers. De verwachting is dat op de verschillende architectuurlagen regels geplaatst moeten worden.

De algemene rollen zijn als in het diagram weergegeven.

De MedMij eigen rollen worden allen in de Core uitgewerkt. Vanuit de verschillende rollen worden deze gebruikt. De verwachting is dat er geen specialisaties nodig zijn.

Opvallende verschillen met het huidige model:

  • De rol gebruiker wordt toegekend aan een persoon in het persoonsdomein. De huidige definitie zegt dat zorgaanbieders ook gebruikers zijn, namelijk van het afsprakenstelsel. Hoewel dit logisch lijkt, wordt de rol toch direct aan een persoon gegeven. Daarom is aanbieder in het nieuwe model afgeleid van een rol die nog gedefinieerd moet worden. Organisatie?
  • Dienstverlener Zorgaanbieder wordt Dienstverlener aanbieder. Vanuit de verschillende onderwerpen kan hierop gespecialiseerd worden.
  • Op de applicatielaag is duidelijk onderscheid gemaakt tussen client en server in beide domeinen.
  • In de Netwerklaag zijn de rollen Internet Browser, MedMij Frontchannel Node en MedMij Backchannel Node toegevoegd. Andere nodes, meer op het domein gespecialiseerd zijn juist weggelaten. De verwachting is dat de nieuwe nodes dusdanig generiek opgezet kunnen worden, dat alle hoger gelegen rollen hiermee een relatie kunnen hebben.

Authenticatie

Het verkrijgen van regie door een persoon valt en staat bij een correcte authenticatie. Hoe weet een deelnemer dat de persoon daadwerkelijk is wie hij zegt te zijn? In versie 1.4.0 van het afsprakenstelsel is authenticatie direct gekoppeld aan de DVP, de DVZA en de zorgaanbieder. Mede door de verschillen in mogelijkheden tussen de twee domeinen (persoonsdomein en zorgdomein), moet een gebruiker op twee momenten geauthenticeerd worden. De twee domeinen kennen verschillende eisen. Toch is het met het oog op de toekomst gewenst authenticatie als los onderwerp te behandelen in de nieuwe structuur. Er wordt bijvoorbeeld gezocht naar mogelijkheden voor Single Identity. In combinatie met bijvoorbeeld langdurige machtigingen kan dit voor veel gebruikersgemak zorgen, maar de beveiliging moet natuurlijk wel van een gewenst niveau blijven.

Rollen die hierbij horen zijn:

In de processen worden veel Core rollen gebruikt. Er worden drie rollen toegevoegd. In de laag Processen & informatie is de Dienstverlener identiteiten (DVAuthN) een specialisatie van Dienstverlener. In de applicatielaag krijgt de DVAuthN de rol van Authentication Provider, welk wordt opgedeeld in een Frontend en een Backend. DVP en DVA krijgen allebei de rol van Authentication Client, welke ook opgedeeld wordt in een frontend en een backend. Beide frontends hebben een relatie met de rol MedMij Frontchannel Node en de backends met de rol MedMij Backchannel Node.

Autorisatie

Net als bij authenticatie zijn de in versie 1.4.0 van het afsprakenstelsel bestaande rollen zelf verantwoordelijk voor de autorisatie, waarbij gebruikgemaakt wordt van OAuth2.0. Vanuit RFC0039 Toestemming voor meerdere diensten van één aanbieder en RFC0054 Langdurige en offline autorisatie van DVP wordt onderzocht of MedMij op een andere manier met autorisatie om kan gaan. Hierbij zijn wellicht nieuwe rollen noodzakelijk, die losstaan van de bekende DVP, DVZA en (zorg)aanbieder. Om dit goed te borgen, wordt dit als apart onderdeel beschreven in het afsprakenstelsel.

Het mogelijke rollenmodel voor autorisatie:

Standaard rollen van OAuth2 krijgen een plek in het rollenmodel. Resource Owner, (Authorization) Client, Resource Server en Authorization Provider (Server) worden benoemd. Hierbij is Authorization Provider de rol van een Dienstverlener Autorisaties (DVAuthZ), welke wordt opgedeeld in een frontend en een backend.

Gegevensuitwisseling

Veel van de huidige regels zijn gericht op gegevensuitwisseling en kunnen overgenomen worden. Huidige rollen worden opnieuw bekeken vanuit RFC0051 Herschikking en herfundering van rollen, waarbij rekening wordt gehouden met een aanpassing van de rollen Uitgever, Bron en Lezer. Het afsprakenstelsel is gebaseerd op het transactiemodel, waarbij rollen Service Provider en Service Consumer meer aansluiten. Hoewel anders kan lijken, is de DVP bij de huidige vormen van gegevensuitwisseling altijd de Service Consumer. De DVP maakt gebruik van een service om gegevens te verzamelen of te delen. En ook bij abonneren wordt gebruikgemaakt van een notificatieservice.

Er zou ook gekozen kunnen worden voor een model waarbij verzender en ontvanger worden gebruikt, dan worden de rollen per usecase wel bij een andere partij gelegd.

Domeinen

Domeinspecifieke regels worden(als deze er al zijn) geplaatst in aparte onderdelen van het afsprakenstelsel. Zo kent versie 1.4.0 het zorgdomein, met daarnaast het publieke domein als addendum. In de nieuwe opzet kunnen deze domeinen los van elkaar worden beschreven en per domein kunnen de rollen en verantwoordelijkheden worden vastgelegd. Per regel wordt bepaald of deze in de MedMij Core beschreven wordt, of toch in het onderdeel domeinen. Domeinen worden alleen uitgeschreven als daar domeinspecifieke rollen en/of verantwoordelijkheden bij horen.

Modules

Naast gegevensuitwisseling wil MedMij ook functionaliteiten laten aanbieden vanuit de PGO. Functionaliteiten die vooral buiten de PGO bestaan en worden aangeboden door aanbieders van modules. Een heel nieuw onderwerp dat beschreven wordt in RFC0026 Modules, waarbij nieuwe rollen en verantwoordelijkheden ontstaan. Hierbij kunnen de modules nog onderverdeeld worden in 3 verschillende types. Bij één van deze types is een de rol van Dienstverlener Moduleaanbieder nodig, om zo gegevens te kunnen verzamelen en delen.

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

DreigingKansImpactDreigingsID (intern)Maatregelen





Bijlagen

  File Modified
No files shared here yet.


  • No labels