Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Samenvatting

Waarom is deze RFC nodig?

Het MedMij Afsprakenstelsel past een scheiding toe tussen enerzijds de rollen en functionaliteit waarmee de Persoon *afspraken* maakt met een Zorgaanbieder over de uitwisseling van gezondheidsinformatie en anderzijds de *uitvoering* van die afspraken door middel van het uitwisselen van die gezondheidsinformatie. Met deze scheiding zorgt MedMij ervoor dat de Persoon altijd helder kan hebben wanneer hij afspraken aan het maken is (bijvoorbeeld: toestemming geeft of een abonnement aangaat) en ook altijd overzicht kan hebben over welke afspraken hij gemaakt heeft, met wie, en wat de status daarvan is. Zo kan de Persoon goed regie voeren. 

Deze scheiding is wel op meerdere plaatsen aanwezig in het MedMij Afsprakenstelsel (in de fasering van UC(I) Verzamelen en Delen, en in de beschikbaarheids-/ontvankelijkheidsvoorwaarde), maar niet op één plaats gedefinieerd, noch expliciet zichtbaar in de rest van het MedMij Afsprakenstelsel. Nu abonneren en notificeren ook opgenomen gaat worden in het MedMij Afsprakenstelsel, gaat dit knellen en dreigt deze scheiding onscherp te worden. Deze RFC stelt voor hoe deze scheiding expliciet wordt gemaakt in het MedMij Afsprakenstelsel en gaat dienen als uitgangspunt voor allerlei ontwerpkeuzes, waaronder voor RFC0005.

Op de niveaus Processen en Informatie en Applicatie er naast regie en uitwisseling is er nog een derde soort functionaliteit: coördinatie (beheer, publicatie en ophalen van lijsten en Catalogus). 

Deze RFC geeft met name ook invulling aan principes P1 en P16.

Oplossingsrichting
  • Er komt een plaats vooraan in de architectuur van het MedMij Afsprakenstelsel waar een aanzet tot een "business architectuur" komt te staan, waarin op dit moment:
    • de bedrijfsfuncties Regie, Uitwisseling en Administratie, en hun relaties;
    • een aantal architectuurprincipes, zoals:
      • Regie bestuurt Uitwisseling, Administratie maakt en Regie en Uitwisseling mogelijk;
      • de standaarden voor (implementatie van) Regie zijn sector-onafhankelijk, die voor Uitwisseling (vooral de Gegevensdiensten) mogen sector-afhankelijk zijn;
      • de Beheerorganisatie is operationeel niet betrokken in Regie en niet in Uitwisseling;
      • ...
    • ...

Image Removed

  • In de beschrijving van de rest van de architectuur op de Proces en Informatie-laag en de Applicatie-laag:
    • wordt bij rollen en functionaliteit aangegeven of het om Regie, Uitwisseling of Administratie gaat.
    • wordt als beleid worden gehanteerd dat interfaces en (bepaalde soorten) rollen altijd geheel Regie, geheel Uitwisseling of geheel Administratie betreffen;
    • ...
  • ...
Zie uitwerking.
Aanpassing van
Impact op rollen

Zie bij oplossingsrichting.

Impact op beheer

geen

Gerelateerd aan (Jira issues)

veel

Eigenaar

Paul Oude Luttighuis

Implementatietermijn

Release 1.2.0

Motivatie verkorte RFC procedure (patch)

n.v.t.

...

Nieuwe pagina maken, onder Architectuur en technische specificaties, met de titel: Coördinatie, Regie en Uitwisseling. Deze vervangt het blok "Regie en uitwisseling" op Architectuur en technische specificaties.

===

Scheiding tussen Regie, Uitwisseling en Coördinatie

Het MedMij Afsprakenstelsel onderkentscheidt, op de Processen-en-Informatie-laag en op de Applicatie-laag, drie hoofdfuncties: Regie, Uitwisseling en Coördinatie. Al het gedrag van de betrokken rollen op deze lagen hoort bij één van deze drie hoofdfuncties.

...

Regie en Uitwisseling worden, conform principe 10, alleen uitgevoerd door partijen die onder de volledige verantwoordelijkheid vallen van een Dienstverlener Persoon of Dienstverlener Zorgaanbieder. MedMij kent een decentrale uitvoering. MedMij is zelf niet betrokken in de uitvoering van Regie of Uitwisseling. Toch is een rol van MedMij nodig in het tot stand brengen van vertrouwen tussen de Dienstverleners Persoon enerzijds en de Dienstverleners Zorgaanbieder anderzijds, zodat zij van elkaar kunnen weten wat zij kunnen en mogen. Daarvoor is de derde hoofdfunctie: Coördinatie, die wordt uitgevoerd met een Catalogus, die zegt welke Gegevensdiensten op enig moment op het MedMij-netwerk van kracht zijn, en vier lijsten (GegevensdienstnamenlijstOAuthclientlistWhitelist en Zorgaanbiederslijst), die zeggen wat de Deelnemers kunnen en mogen.

Image Added


Processen-en-Informatie-laag

Op deze laag zijn worden de drie hoofdfuncties door de volgende rollen uitgevoerd.

hoofdfunctie

Persoonsdomein

MedMij-domein

Zorgaanbiedersdomein

CoördinatieUitgeverMedMij Beheer

Bron

Lezer

Regie

Zorggebruiker

Uitgever

-

Bron

Lezer

Uitwisseling

Zorggebruiker

Uitgever

-

Bron

Lezer


Op deze laag worden de drie hoofdfuncties in de volgende UC's uitgevoerd.

hoofdfunctie

Persoonsdomein

MedMij-domein

Zorgaanbiedersdomein

Coördinatie

UC Opvragen GNL

UC Opvragen ZAL

UC Opvragen GNL

UC Opvragen ZAL

UC Opvragen OCL

UC Opvragen GNL


UC Opvragen OCL

Regie

UC Verzamelen (eerste twee fasen)

UC Delen (eerste twee fasen) 

-

UC Verzamelen (eerste twee fasen)

UC Delen (eerste twee fasen)

Uitwisseling

UC Verzamelen (laatste fase)

UC Delen (laatste fase)

-

UC Verzamelen (laatste fase)

UC Delen (laatste fase)


De beschikbaarheids- en ontvankelijkheidsvoorwaarde zijn een Regie-aangelegenheid en moeten om precies die reden in de Regie-fase van de UC Verzamelen en UC Delen worden uitgevoerd. Vanwege implementatiebeperkingen biedt het MedMij Afsprakenstelsel momenteel niettemin de ruimte om de beschikbaarheidsvoorwaarde uiterlijk aan het begin van de Uitwisselingsfase te regelen.


Applicatielaag

Op deze laag zijn worden de drie hoofdfuncties door de volgende rollen uitgevoerd.

hoofdfunctie

Persoonsdomein

MedMij-domein

Zorgaanbiedersdomein

CoördinatiePGO ServerMedMij Registratie

Authorization Server

Regie

PGO Gebruiker

PGO User Agent

PGO Server

OAuth Resource Owner

OAuth User Agent

OAuth Client

Authentication User Agent


Authorization Server

OAuth Authorization Server

Authentication Client

Authentication Service

Subscription Server

Uitwisseling

PGO Gebruiker

PGO User Agent

PGO Server

OAuth Resource Owner

OAuth User Agent

OAuth Client


Resource Server

OAuth Resource Server


Op deze laag worden de drie hoofdfuncties op de volgende interfaces uitgevoerd.

hoofdfunctie

Persoonsdomein

Coördinatie

GNL interface

OCL interface

ZAL interface

Regie

user interface (Verklaringen)

authorization interface

token interface

subscription interface

subscription alert interface

Uitwisseling

resource interface

notification interface

===

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.

...