Samenvatting

Waarom is deze RFC nodig?	In 2017 zijn er twee documenten geïntroduceerd welke de Governance en Eisen van het koppelvlak van standaarden aan het Afsprakenstelsl vormen: genaamd het MedMij Stelsel van Standaarden. Deze documenten zijn inmiddels verouderd en maken de werking van het stelsel onnodig gecompliceerd. Deze RFC voor het MedMij Afsprakenstelsel vormt een aanpassing welke parallel wordt voorgesteld aan een gevraagd besluit aan Stichting MedMij. Het doorvoeren van de wijziging geeft de ruimte om te leren van opgedane ervaring, belangen van Deelnemers centraal te zetten in besluitvorming voor de definitie van een Gegevensdienst en nauwer aan te sluiten bij het MedMij Afsprakenstelsel. Daarbij vormt het een versimpeling en verheldering van Governance, zonder impact op (kandidaat-)deelnemers.
Oplossingsrichting	In het gegevensdienstenbeleid zal een verwijzing naar het Eisen-document worden opgenomen. De inhoud van dit document vormt het toetsingskader. Opname hiervan in het gegevensdienstenbeleid van de Afsprakenset geeft (kandidaat-)deelnemers heldere verwachtingen aan welke eisen de standaarden zijn getoetst. Opname als beleid geeft ruimte om in de afweging de volwassenheid van de context, het stelsel en onderliggende informatiestandaarden mee te wegen.
Aanpassing van	Beleid en processen
Impact op rollen	Vooralsnog betreft de wijziging de Afsprakenset en heeft het zijn betrekking op Deelnemers. Het geeft hen een helder beeld aan wat voor een toetsingskader is onderliggend standaarden voldoen, wanneer deze als gegevensdienst voor hen beschikbaar zin.
Impact op beheer	Nee.
Impact op RnA	Nee.
Impact op Acceptatie	Geen
Gerelateerd aan (Andere RFCs, PIM issues)	RFC0023, de wijziging van het Gegevensdienstenbeleid worden gezamenlijk vormgegeven in de uitwerking.
Eigenaar	Mischa Tol (Unlicensed)
Implementatietermijn	1.3.0
Motivatie verkorte RFC procedure (patch)

Goedkeuring

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

Uitwerking

Introductie

Schrappen van de regels "Coördinatie standaarden MedMij - Eisen" en "Coördinatie standaarden MedMij - Governance" op de Introductiepagina.

Gegevensdienstenbeleid

Gegevensdienstenbeleid vervangen door:

Gegevensdiensten en de Catalogus

Deelnemers ontsluiten via MedMij gestandaardiseerde diensten voor gegevensuitwisseling, de zogeheten Gegevensdiensten. Deze Gegevensdiensten die zijn toegestaan binnen MedMij worden opgenomen in de Catalogus.

Een Gegevensdienst wordt gevormd uit een verzameling Systeemrollen en één use case uit het MedMij Afsprakenstelsel. Een Systeemrol is een verzameling verantwoordelijkheden voor de elektronische uitwisseling van gegevens. De verantwoordelijkheden worden gedefinieerd in de bij de Systeemrol behorende onderdelen van een Informatiestandaard.

De Gegevensdiensten worden uitgewisseld via bijbehorende use cases uit de architectuur van het MedMij Afsprakenstelsel. Zolang nieuwe Gegevensdiensten passen binnen de bestaande use cases, kunnen ze onafhankelijk van een release worden toegevoegd aan de Catalogus. Mocht voor een Gegevensdienst (een) nieuwe use case nodig zijn, dan dient eerst deze nieuwe use case te worden toegevoegd volgens het reguliere change- en releaseproces. Pas daarna kan ook deze nieuwe Gegevensdienst worden toegevoegd aan de Catalogus.

Besluiten over de creatie, wijziging en beëindiging van een Gegevensdienst en de wijze waarop een Gegevensdienst wordt opgenomen in de Catalogus worden genomen door het bestuur van Stichting MedMij.

Creatie van Gegevensdiensten

Een Gegevensdienst wordt samengesteld in overleg tussen Stichting MedMij en de beheerder(s) van de Informatiestandaarden waarvan Systeemrollen tot de Gegevensdienst zouden gaan behoren. Daarbij zijn de eigenschappen die een Gegevensdienst verkrijgt in de Catalogus onderwerp van gesprek.

De Systeemrollen worden voorafgaand aan de opname in een Gegevensdienst beoordeeld aan de hand van een serie eisen. Deze eisen dienen als hulpmiddel bij het beoordelen van de geschiktheid van de Systeemrollen. Ze zijn niet uitputtend (er zijn ook andere afwegingsgronden) en niet blokkerend (het niet voldoen aan een eis betekent niet als vanzelf dat de Systeemrol ongeschikt is).

Mutaties van Gegevensdiensten

Mutaties van Gegevensdiensten door Stichting MedMij zijn toegestaan, met uitzondering van:

Het wijzigen van de Systeemrolverzameling of de daarin opgenomen Systeemrollen.
Het wijzigen van de Usecase.
Het wijzigen van het GegevensdienstId.
Het wijzigen van de verzameling Gegevensdiensten die wordt Vereist.

De concepten zijn precies gedefinieerd in het metamodel.

Uitfaseren van Gegevensdiensten

Een Gegevensdienst kan worden uitgefaseerd.

De volgende triggers kunnen leiden tot het uitfaseren van Gegevensdiensten:

De Systeemrollen worden niet langer als geschikt beoordeeld;
Er is een Gegevensdienst beschikbaar gekomen die als opvolger dienst kan doen;
De Gegevensdienst is niet langer compatibel met de operationeel bruikbare versies van het MedMij Afsprakenstelsel.

Hoe lang de oude Gegevensdienst(en) nog bruikbaar is/zijn, wordt besloten door het bestuur van Stichting MedMij. Bij dit besluit houdt het bestuur in het bijzonder rekening met de belangen van de Deelnemers. Het moment van uitfaseren van een gegevensdienst wordt kenbaar gemaakt door een einddatum van de betreffende gegevensdienst op te nemen in de Catalogus.

Gegevensdiensten die elkaar vereisen of vervangen

Stichting MedMij kan in de Catalogus aangeven dat de ene Gegevensdienst de andere vereist wanneer Zorgaanbieders die de ene Gegevensdienst aanbieden, verplicht worden om ook de andere aan te bieden. Dit is vaak het geval als de Gegevensdiensten samen een proces vormen, zoals het verzamelen en delen van gegevens. Vereisen hoeft geen wederzijdse relatie te zijn, maar dat kan wel.

Erkenning van Deelnemer als ontsluiter van een Gegevensdienst

Deelnemers ontsluiten Gegevensdiensten via het MedMij-netwerk voor en namens gebruikers. Voordat een Deelnemer in deze rol wordt erkend, dient zij aan te tonen de Gegevensdienst op de juiste manier te ondersteunen. In de Catalogus staat per Gegevensdienst beschreven welke relevante Systeemrollen uit de bijbehorende Informatiestandaard en welke use case uit de Architectuur en technische specificaties ondersteund dienen te worden. Ook geeft de Catalogus aan welke andere Gegevensdiensten vereist. Indien een Deelnemer nog niet over een erkenning voor een vereiste Gegevensdienst beschikt, dan dient deze partij eerst deze erkenning te behalen. In het Testbeleid staat verder beschreven hoe de ondersteuning van de Gegevensdienst en, indien nodig, de use case, kan worden aangetoond. Stichting MedMij ziet erop toe dat aan alle voorwaarden wordt voldaan, alvorens erkenningen wordt afgegeven.

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

Bijlagen

Browser not supported