Samenvatting

Waarom is deze RFC nodig?	In het kader van meer gebruiksvriendelijkheid in de toekomst moet het mogelijk zijn als gebruiker om met 1 x autoriseren meerdere gegevensdiensten bij meerdere aanbieders bij verschillende DVA's op te halen.
Oplossingsrichting	De rollen Resource Server en Authorization Server worden van elkaar gescheiden. De processen worden apart beschreven.
RACI	Responsible: Lead architect Accountable: Product management Consulted Ontwikkelteam (ontwikkeling@medmij.nl) Security Management (secmgt@medmij.nl) Acceptatie (acceptatie@medmij.nl) Stelselregie Deelnemers (Expertgroepsessie) Informed Communicatie Loket (info@medmij.nl) Leveranciersmanagement
Aanpassing van	Processen los van elkaar beschrijven in versie 1.6
Impact op rollen	DVA
Impact op beheer	N.v.t.
Impact op RnA	N.v.t.
Impact op Acceptatie	N.v.t.
PIA noodzakelijk	N.v.t.
Gerelateerd aan (Andere RFCs, PIM issues)
Implementatietermijn	AF 1.6
Motivatie verkorte RFC procedure (patch)	N.v.t.

2. Uitwerking epic

3. Wijzigingen afsprakenstelsel

Huidige inhoud	Nieuwe inhoud
Functies en gegevens, Core, H2 Beschikbaarheids- en ontvankelijkheidsvoorwaarde	H2 geheel weglaten
Verzamelen	Verzamelen
Delen	Delen
Abonneren	Abonneren
Notificeren	Notificeren
-	Authenticeren
-	Autoriseren
Authorization interface	RFC0069 Authorization interface (rij 8 is veranderd)
Token interface	Token interface ( rij 8 is veranderd)
Resource interface	Resource interface (rij 5 is veranderd)
MedMij extensies	MedMij extensies
Extensie Abonneren	Extensie abonneren
Architectuur en technische specificaties	Architectuur en technische specificaties (RFC 0069)
Coördinatie, regie en uitwisseling	Coördinatie, regie en uitwisseling
MedMij Core	MedMij Core
Functies en gegevens, Core	Functies en gegevens, Core
Functies en gegevens, Vertegenwoordiging	Functies en gegevens, Vertegenwoordiging
Verantwoordelijkheden, Zorg

. 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
3 Dienstverleners concurreren op de functionaliteiten		13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
4 Dienstverleners zijn aanspreekbaar door de gebruiker		14 Uitwisseling is een keuze
5 De persoon wisselt gegevens uit met de zorgaanbieder		15 Het MedMij-netwerk is gebruiksrechten-neutraal
6 MedMij spreekt alleen af wat nodig is		16 De burger regisseert zijn gezondheidsinformatie als uitgever
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener		17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
9 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

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

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen

6. Bijlagen

	Bestand	Views	Gewijzigd

Nog geen bestanden gedeeld hier.

Sleep hier je bestanden naartoe of bladeren

7. Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

Samenvatting

Waarom is deze RFC nodig?	In het kader van meer gebruiksvriendelijkheid in de toekomst moet het mogelijk zijn als gebruiker om met 1 x autoriseren meerdere gegevensdiensten bij meerdere aanbieders bij verschillende DVA's op te halen.
Oplossingsrichting	De rollen Resource Server en Authorization Server worden van elkaar gescheiden. De processen worden apart beschreven.
RACI	Responsible: Lead architect Accountable: Product management Consulted Ontwikkelteam (ontwikkeling@medmij.nl) Security Management (secmgt@medmij.nl) Acceptatie (acceptatie@medmij.nl) Stelselregie Deelnemers (Expertgroepsessie) Informed Communicatie Loket (info@medmij.nl) Leveranciersmanagement
Aanpassing van	Processen los van elkaar beschrijven in versie 1.6
Impact op rollen	DVA
Impact op beheer	N.v.t.
Impact op RnA	N.v.t.
Impact op Acceptatie	N.v.t.
PIA noodzakelijk	N.v.t.
Gerelateerd aan (Andere RFCs, PIM issues)
Implementatietermijn	AF 1.6
Motivatie verkorte RFC procedure (patch)	N.v.t.

2. Uitwerking epic

3. Wijzigingen afsprakenstelsel

Huidige inhoud	Nieuwe inhoud
Functies en gegevens, Core, H2 Beschikbaarheids- en ontvankelijkheidsvoorwaarde	H2 geheel weglaten
Verzamelen	Verzamelen
Delen	Delen
Abonneren	Abonneren
Notificeren	Notificeren
-	Authenticeren
-	Autoriseren
Authorization interface	RFC0069 Authorization interface (rij 8 is veranderd)
Token interface	Token interface ( rij 8 is veranderd)
Resource interface	Resource interface (rij 5 is veranderd)
MedMij extensies	MedMij extensies
Extensie Abonneren
Architectuur en technische specificaties	Architectuur en technische specificaties (RFC 0069)
Coördinatie, regie en uitwisseling	Coördinatie, regie en uitwisseling
MedMij Core	MedMij Core
Functies en gegevens, Core	Functies en gegevens, Core
Functies en gegevens, Vertegenwoordiging	Functies en gegevens, Vertegenwoordiging
Verantwoordelijkheden, Zorg

. 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
3 Dienstverleners concurreren op de functionaliteiten		13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
4 Dienstverleners zijn aanspreekbaar door de gebruiker		14 Uitwisseling is een keuze
5 De persoon wisselt gegevens uit met de zorgaanbieder		15 Het MedMij-netwerk is gebruiksrechten-neutraal
6 MedMij spreekt alleen af wat nodig is		16 De burger regisseert zijn gezondheidsinformatie als uitgever
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener		17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
9 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

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

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen

6. Bijlagen

	Bestand	Views	Gewijzigd

Nog geen bestanden gedeeld hier.

Sleep hier je bestanden naartoe of bladeren

7. Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

MedMij Change Management

RFC0069 Losse functiebeschrijvingen voor authenticeren en autoriseren

Analytics

Samenvatting

2. Uitwerking epic

3. Wijzigingen afsprakenstelsel

. Principe's

5. Risico's

6. Bijlagen

7. Goedkeuring

Samenvatting

2. Uitwerking epic

3. Wijzigingen afsprakenstelsel

. Principe's

5. Risico's

6. Bijlagen

7. Goedkeuring

Related content