RFC0003 Releasemanagement (Versiebeheer)
- Former user (Deleted)
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:
In de praktijk van januari 2020 betekent dit:
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
| Beoordelaar | Datum | Reactie | Toelichting |
|---|---|---|---|
| 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:
- De deelnemer wil erkend worden als ontsluiter van een Gegevensdienst;
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- Twijfel over de naleving van de afspraken;
- 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 43 en 4Voor situaties
2 t/m 43 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:
- De deelnemer wil erkend worden als ontsluiter van eenGegevensdienst;
- Wijzigingen aan de Architectuur en technische specificaties (verplichte hertest volgt in dat geval uit de implementatieparagraaf, zie Change- en releasebeleid);
- Twijfel over de naleving van de afspraken;
- Hertoetreding als bedoeld in artikel 14.3 van de Deelnemersovereenkomst.
- 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:
- Potentiële deelnemer toont aan te voldoen aan de afspraken uit
de Afsprakenset release 1.1.2;een geldende versie van het Afsprakenstelsel (zie Change- en releasebeleid).
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 | Maatregelen |
|---|---|---|---|
| Deelnemer 'breekt' netwerk door niet op tijd de verplichte release te implementeren. | L | L/H | De 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. | M | M | Bidden |