Samenvatting

Goedkeuring

Principe's

Uitwerking

Taken

• Architectuur en technische specificaties voorzien van nieuwe pagina-indeling.
  • Pagina-indeling opzetten. 
  • Platen en beschrijvingen van het nieuwe rollenmodel toevoegen.
  • Functies overnemen van 1.4.0
  • Verantwoordelijkheden overnemen van 1.4.0
  • Verantwoordelijkheden herschrijven. Verwijzingen naar oude rollen verwijderen.
• Coördinatie, regie en uitwisseling herschrijven. Verwijzingen naar oude rollen verwijderen.
• Authenticatie en Autorisatie lostrekken als functie en zo ook beschrijven in de verantwoordelijkheden.
• Principes nalopen op de rollen uit 1.4.0.
  • Principe 16 verwijst naar Uitgever, Bron en Lezer.
• Schermen aanpassen met de nieuwe rolbenamingen (bijvoorbeeld NaamAanbieder ipv NaamZorgaanbieder).
• Alle linkjes nalopen
  • Eigenaar MedMij
  • MedMij Beheer
  • Deelnemer
  • Persoon
  • Dienstverlener Persoon
  • Dienstverlener Aanbieder
  • Dienstverlener Authenticatie
  • Aanbieder
  • MedMij Registratie
  • User Agent
  • DVP Server
  • Resource Server
  • Authorization Server
  • Authorization Client
  • Authentication Client
  • OAuth Resource Owner
  • OAuth Client
  • OAuth Resource Server
  • OAuth Authorization Server
  • Subscription Server
  • Notification Client
  • Frontchannel Node
    
  • Backchannel Node
  • Notification Server
  • Authentication Service
  • Verzamelen
  • Delen
  • Abonneren
  • Notificeren

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.

Bijlagen