Document toolboxDocument toolbox

RFC0003 Releasemanagement (Versiebeheer)

Owned by Former user (Deleted)
Last updated: Jan 22, 2020
5 min read

Samenvatting

Waarom is deze RFC nodig?

Om zonder 'big bangs' nieuwe releases uit te kunnen rollen met/tijdens een doorlopende uitwisseling, zijn er afspraken nodig over releasemanagement. Deze wijziging is dusdanig groot/complex dat deze een eigen RFC heeft gekregen (Voorheen onder kopje 'Versiebeheer').

Oplossingsrichting

Vanaf release 1.2.0 gaan er twee grote wijzigingen plaats vinden rond het release proces en de acceptaties:

MedMij gaat werken met twee major releases van het Afsprakenstelsel per jaar op 'vaste momenten' (april, oktober). Een nieuwe versie wordt eerst gepubliceerd en pas na enige tijd 'geldend'.

De implementatie van koppelvlakken verloopt op een ‘dakpansgewijze’ wijze op basis van de  major releases, waarbij er deelnemers de tijd krijgen om hun koppelvlakken aan te passen aan de nieuwe eisen. 

Op het moment dat een nieuwe release wordt gepubliceerd:

  • is deze meest recente versie optioneel; de koppelvlak-specificatie kan ingebouwd en toegepast worden in productie
  • daarvoor gepubliceerde versie wordt de geldige; deelnemers moeten de koppelvlak-specificatie van deze versie geïmplementeerd hebben en in productie toepassen
  • de tot dit moment geldige versie vervalt en mag NIET meer toegepast worden.

In de praktijk van januari 2020 betekent dit:

  • Versie 1.2.0 wordt gepubliceerd en mag gebruikt worden voor uitwisselingen.
  • De ‘vorige’ release, in dit geval 1.1.2, wordt de geldige;
  • Aangezien dit de eerste keer is dat we met deze aanpak werken, is er geen 'vervallende' versie.


Het acceptatie proces zal naar een ‘APK’ model gaan, waarbij deelnemers zelf bepalen wanneer zij ge-her-accepteerd worden. Waarbij geldt dat een acceptatie een jaar geldt en de deelnemer een geldige acceptatie dient te hebben. De acceptatie wordt in overleg ingepland en in samenspraak tussen deelnemer en acceptatieteam wordt er gekozen tegen welke versie van het stelsel er geaccepteerd gaat worden.


Aanpassing van

Afsprakenstelsel

Impact op rollen

Alle

Impact op beheer

RnA

Gerelateerd aan (Jira issues)


Eigenaar

Arjan

Implementatietermijn

1.2.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

BeoordelaarDatumReactieToelichting
Productmanager


Ontwerpteam


?


Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Neutraal

11 Stelselfuncties worden vanaf de start ingevuld

Positief

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

Positief

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

Positief

9 De dienstverleners zijn deelnemers van het afsprakenstelsel

Positief

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

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

Op pagina Change- en releasebeleid aanpassen:


Op pagina Testbeleid moet worden aangepast:

Onder Testbeleid:

Wanneer moet er getest worden? We onderscheiden de volgende situaties:

  1. De deelnemer wil erkend worden als ontsluiter van een Gegevensdienst;
  2. Wijzigingen aan de Architectuur en technische specificaties (verplichte hertest volgt in dat geval uit de implementatieparagraaf, zie Change- en releasebeleid);Verlopen (of het voorkomen daarvan) van de geldigheid van de geldigheid van de testresultaten
  3. Twijfel over de naleving van de afspraken;
  4. Hertoetreding als bedoeld in artikel 14.3 van de Deelnemersovereenkomst.

Op pagina Testbeleid moet worden toegevoegd boven Siuatie 2 t/m 4:

Situatie 2: De deelnemer wil haar testresultaten vernieuwen

Deelnemers zijn (met uitzondering van situaties 3 en 4) zelf verantwoordelijk voor het inplannen van testen om de geldigheid van hun implementatie vast te stellen. Deelnemers moeten jaarlijks aantonen dat hun implementatie voldoet aan de eisen van het stelsel door het opnieuw doorlopen van de testen. De testen bepalen of de deelnemer nog steeds voldoende geëquipeerd is om de afspraken uit de architectuur en technische specificaties waar te maken en de gegevensdiensten op de juiste manier te gebruiken. Stichting MedMij toetst niet de volledige implementatie, maar richt zich op risico’s, interoperabiliteit tussen deelnemers en cruciale maatregelen voor het vertrouwen in MedMij.

Bij het aanvragen en inplannen van de hernieuwde test stelt de deelnemer in overleg met de beheerorganisatie vast tegen welke geldende versie van het afsprakenstelsel de test zal worden uitgevoerd (zie VERSIEBEHEER). 

Deelnemers hebben daarmee de verantwoordelijkheid om hun eigen ontwikkel- en release- kalender :

  • af te stemmen op de releasemomenten van het afsprakenstelsel
  • het afgesproken (her)acceptatie moment.

Bij het succesvol doorlopen van de testen geeft de beheerorganisatie een verklaring uit die de status van de deelnemer bevestigd. Deze verklaring blijft een jaar geldig.


Op pagina Testbeleid moet worden aangepast:

Situaties 2 t/m 4 3 en 4

Voor situaties 2 t/m 4 3 en 4 geldt dat er per situatie wordt bekeken wat er opnieuw getest moet worden. De geldigheid van eerdere positieve testresultaten kunnen in deze situaties vervallen.

 Op pagina /wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136158276 moet worden aangepast/toegevoegd:

Proces her-acceptatie van deelnemer 

  • Doel: Het proces heeft als doel vast te stellen dat de deelnemer voldoet aan de afspraken van een geldende versie van het Afsprakenstelsel.
  • Initiatie: Deelnemer wil zijn deelname aan het stelsel continueren .
  • Afspraken over het proces:
    • Stichting MedMij en de deelnemer bepalen in overleg welke geldende versie van het Afsprakenstelsel als norm voor de her-acceptatie wordt gehanteerd.
    • Deelnemer levert bewijs aan voor het voldoen aan: (A) de relevante use cases uit de Architectuur en technische specificaties, (B) de algemene verantwoordelijkheden uit de Architectuur en technische specificaties en (C) de ondersteuning van systeemrollen uit aangeboden Gegevensdienst(en)
    • Stichting MedMij bepaalt of aanvullende toetsing op functionaliteit uit de Architectuur en technische specificaties benodigd is. Indien het geval, dan dient de deelnemer de ondersteuning van de aanvullende functionaliteit middels een toets te laten zien (zie Testbeleid).
  • Resultaat: Stichting Medmij stelt vast en verklaart dat deelnemer voldoet aan de gestelde eisen. De verklaring heeft een geldigheid van één jaar.
  • Uitzonderingen: Deelnemer voldoet niet aan de vereisten; Stichting MedMij en deelnemer treden in overleg over vervolgstappen.

Op pagina Testbeleid toevoegen/aanpassen:

https://vzvz.atlassian.net/wiki/display/PUBLIC/Testbeleid

Wanneer moet er getest worden? We onderscheiden de volgende situaties:

  1. De deelnemer wil erkend worden als ontsluiter van eenGegevensdienst;
  2. Wijzigingen aan de Architectuur en technische specificaties (verplichte hertest volgt in dat geval uit de implementatieparagraaf, zie Change- en releasebeleid);
  3. Twijfel over de naleving van de afspraken;
  4. Hertoetreding als bedoeld in artikel 14.3 van de Deelnemersovereenkomst.
  5. Her-acceptatie op initiatief van de Deelnemer.

Op pagina Testbeleid toevoegen:

Situatie 5

In situatie 5 moet op grond van het Gegevensdienstenbeleid worden aangetoond dat: <XXX>

Op pagina Toetredingsproces aanpassen:

Afspraken over het proces: 


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 KansImpactMaatregelen
Deelnemer 'breekt' netwerk door niet op tijd de verplichte release te implementeren.LL/HDe L/H impact geeft aan dat dit voor de deelnemer en haar personen (DVP) of zorgaanbieders (ZA) een grote impact heeft (zij kunnen niet meer uitwisselen) en als het marktaandeel van een deelnemer groot is, kan dit een Hoge impact voor het hele netwerk betekenen. Maatregelen (die nog ingevoerd moeten worden) zijn het monitoren van de doorontwikkeling en de her-acceptaties van deelnemers. 
(Beheer)organisatie niet op tijd klaar voor ondersteuning.MMBidden

Bijlagen



BestandGewijzigd




Nog geen bestanden gedeeld hier.