Samenvatting

Waarom is deze RFC nodig?	In het eerst kwartaal van 2021 deed zich een vraagstuk voor, doordat verschillende leveranciers verschillende incompatibele gegevensdiensten ondersteunden. Als deel-oplossing is destijds aangedragen om een mechanisme te introduceren genaamd het dakpansgewijs releasen. Deze RFC bevat een uitwerking op welke manier dit, in het MedMij Afsprakenstelsel gebruikte mechanisme, kan worden toegepast op de Gegevensdiensten in de MedMij Catalogus.
Oplossingsrichting	De huidige dakpansgewijze releasemethodiek in het change- en releasebeleid van het MedMij Afsprakenstelsel bevat uitspraken over een aantal onderdelen: Dakpansgewijze releases Totstandkoming van de releases Typen releases Besluitvorming omtrent releases Verantwoordelijkheden ten aanzien van releases Implementatie van de releases Totstandkoming van de releaseplanning Deze onderdelen beschrijven de wijze waarop releases van het MedMij-afsprakenstelsel plaatsvinden en de bijbehorende rollen en verantwoordelijkheden van betrokkenen. Dakpanmodel bij opvolging geldige gegevensdienst (eerste stap) Met uitbreiding van het huidige gegevensdienstenbeleid kan het dakpansgewijs releasen relatief eenvoudig geïmplementeerd worden tav gegevensdiensten: Indien deze 2 gegevensdiensten elkaar opvolgen treedt het volgende mechanisme in werking: Eén geldige Gegevensdienst in de Actuele Catalogus vormt de basis voor het ontsluiten van die gegevens op het MedMij netwerk. Eén aankomende Gegevensdienst heeft een toekomstige ingangsdatum van de geldigheid. Met het ingaan van de geldigheid zal deze de Gegevensdienst in de Actuele Gegevensdienst vervangen. Een Aankomende Gegevensdienst kan tot de ingangsdatum niet ontsloten worden op het MedMij Netwerk. Let wel: onderliggende transacties zijn niet aan het dakpansgewijs releasen gebonden en kunnen reeds beschikbaar zijn. Rolverdeling conform dakpanmodel (toekomst) Het introduceren van het dakpanmodel irt opvolging is een eerste stap. Na het succesvol implementeren zal het proces van het tot stand komen van een gegevensdienstenrelease en bijbehorende onderdelen met rollen en verantwoordelijkheden nader onder de loep genomen moeten worden. Dit is tav release 1.5.0 niet te realiseren.
Aanpassing van	Catalogus, Afsprakenstelsel
Impact op rollen	DVP, DVZA
Impact op beheer	Inrichten van releasemechanisme gegevensdiensten conform MedMij.
Impact op RnA	Nvt
Impact op Acceptatie	Nvt
PIA noodzakelijk
Gerelateerd aan (Andere RFCs, PIM issues)
Eigenaar	Mischa Tol (Unlicensed) Former user (Deleted)
Implementatietermijn	1.5.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		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

Uitwerking

Boven kop 'Implicaties voor NEN-certificering' op pagina Change- en releasebeleid toevoegen:

Dakpansgewijze aanpak

Op Gegevensdiensten is tevens dakpansgewijs releasen van toepassing. Dit staat beschreven in het Gegevensdienstenbeleid.

Op pagina Gegevensdienstenbeleid onder de kop 'Gegevensdiensten en de Catalogus' aanpassen:

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.
Deelnemers ontsluiten via MedMij gestandaardiseerde diensten voor gegevensuitwisseling, de zogeheten Gegevensdiensten. Deze Gegevensdiensten die zijn toegestaan binnen MedMij worden opgenomen in de /wiki/spaces/MMCatalogus/overview.

Een Gegevensdienst wordt gevormd uit een verzameling Systeemrollen en één of meer use case(-s) 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 ontsloten 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 van het MedMij Afsprakenstelsel 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.

Op pagina Gegevensdienstenbeleid onder de kop 'Creatie van Gegevensdiensten' aanpassen:

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).
Een Gegevensdienst wordt gevormd uit een verzameling Systeemrollen en één of meer use case(-s) uit het MedMij Afsprakenstelsel. Stichting MedMij, de beheerder van het MedMij Afsprakenstelsel en de beheerder(s) van de Informatiestandaarden waarvan Systeemrollen tot de Gegevensdienst zouden gaan behoren stemmen dit af. Daarbij zijn de eigenschappen die een Gegevensdienst verkrijgt in de Catalogus (ook) 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).
Indien de creatie van een Gegevensdienst bedoeld is als opvolging van een geldige Gegevensdienst gebeurt dit dakpansgewijs. Dat betekent dat er maximaal 2 Gegevensdiensten zijn opgenomen in de Catalogus op basis van dezelfde Transactienaam. De actuele Catalogus bevat een Gegevensdienst die op dat moment geldig is en de basis vormt voor ontsluiting op het MedMij Netwerk. De creatie van de zogenaamd aankomende Gegevensdienst zal plaatsvinden in het daarvoor bestemde onderdeel van de Catalogus. Deze Gegevensdienst krijgt een toekomstige ingangsdatum van de geldigheid die overeenkomt met de releasedatum van het MedMij Afsprakenstelsel. Hier kan worden van afgeweken indien een situatie daarom vraagt, een dergelijk besluit wordt genomen door het bestuur van Stichting MedMij.

Op pagina Gegevensdienstenbeleid onder de kop 'Mutaties van Gegevensdiensten' aanpassen:

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.~~
Het wijzigen van de Vereist relatie.
De concepten zijn precies gedefinieerd in het metamodel.

Op pagina Gegevensdienstenbeleid onder de kop 'Uitfaseren van Gegevensdiensten' aanpassen:

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;~~
Een aankomende Gegevensdienst geldig wordt die de Gegevensdienst Vervangt;
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.
Het moment van uitfaseren van een Gegevensdienst wordt kenbaar gemaakt door een einddatum van de betreffende gegevensdienst op te nemen in de /wiki/spaces/MMCatalogus/overview.

Op pagina Gegevensdienstenbeleid onder de kop 'Gegevensdiensten die elkaar vereisen of vervangen' aanpassen:

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.
Stichting MedMij kan in de /wiki/spaces/MMCatalogus/overviewaangeven 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.
Indien een aankomende Gegevensdienst een geldige Gegevensdienst vervangt, dan komen de ingangsdatum van de geldigheid en de Einddatum van de te vervangen Gegevensdienst overeen, tenzij er zwaarwegende redenen zijn om hiervan af te wijken.

Op pagina Gegevensdienstenbeleid onder de kop 'Erkenning van Deelnemer als ontsluiter van een Gegevensdienst' aanpassen:

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

Geen impact voorzien op foutmeldingen.

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

	File	Modified

No files shared here yet.

Browser not supported