Het MedMij Afsprakenstelsel ontwikkelt zich voortdurend. Ontwikkelingen binnen en rondom MedMij kunnen aanleiding geven om afspraken uit het stelsel te wijzigen. Op de ontwikkeling van iedere release is het Intellectueel eigendomsbeleid van toepassing. Het staat iedereen vrij om wijzigingsvoorstellen (wensen) in te dienen bij Product Management van Stichting MedMij, dit kan via info@medmij.nl. Stichting MedMij zorgt ervoor dat wijzigingsvoorstellen worden uitgewerkt met aandacht voor de samenhang van het MedMij Afsprakenstelsel als geheel. Het afsprakenstelsel bestaat uit een samenhangende set van afspraken (juridisch kader, overeenkomsten, architectuur, diensten en technische specificaties, etc.) met veel onderlinge afhankelijkheden. Aanpassing van een van de onderdelen vraagt altijd om een impactanalyse op de rest van de onderdelen.
Bij wijzigingen wordt het MedMij Afsprakenstelsel altijd in haar geheel in een nieuwe versie gepubliceerd. Onderdeel van een nieuwe versie is een gestructureerde documentatie van alle wijzigingen in een Changelog. Zo’n nieuwe versie noemen we ook wel een release.
Wijzigingen worden volgens een vast proces behandeld. Zodra wijzigingen eenmaal in het afsprakenstelsel zijn doorgevoerd, volgen zij het dakpanmodel dat voor het afsprakenstelsel geldt (optionele of verplichte versie).
Wijzigingen van het afsprakenstelsel
Kleine wijzigingen worden direct op het afsprakenstelsel doorgevoerd, maar nieuwe onderwerpen volgen altijd de stappen binnen dit ontwikkelproces.
Alpha-fase
De eerste analyse van een onderwerp wordt uitgevoerd in de alpha-fase. Stichting MedMij kan op basis van deze analyse een Proof of Concept laten uitvoeren, om de praktische haalbaarheid van het onderwerp te bewijzen in testomgevingen. Hierbij worden zo veel als mogelijk deelnemers en andere (markt)partijen betrokken, maar ook de MedMij referentieimplementatie en de testomgevingen kunnen worden ingezet.
Bij de start van de alpha-fase wordt een stakeholder-analyse voor desbetreffend onderwerp uitgevoerd. De lijst van stakeholders kan worden gewijzigd gedurende het gehele ontwikkelproces.
Onderwerpen worden aan het eind van de alpha-fase, of eerder indien gewenst voor de uitvoering van een Proof of Concept, gepubliceerd op changemanagement.medmij.nl, zodat stakeholders vroegtijdig de uitwerkingen kunnen inzien. Ook worden de onderwerpen gepresenteerd aan en besproken met de stakeholders tijdens expertsessies.
Beta-fase
Na de alpha-fase kan Stichting MedMij de beta-fase plannen en starten. In de beta-fase wordt per onderwerp bepaald welke wijzigingen doorgevoerd moeten worden in het MedMij Afsprakenstelsel. Stichting MedMij kan op basis van de voorgestelde wijzigingen een pilot laten uitvoeren, om de haalbaarheid van het onderwerp te bewijzen in productieomgevingen. Hierbij worden zo veel als mogelijk deelnemers betrokken, maar ook andere (markt)partijen kunnen deelnemen aan de uitvoering van een pilot.
De voorgestelde wijzigingen worden aan het einde van de beta-fase, of eerder indien gewenst voor de uitvoering van een pilot, gepubliceerd op changemanagement.medmij.nl, zodat stakeholders vroegtijdig de voorgestelde wijzigingen kunnen inzien. Ook worden de onderwerpen gepresenteerd aan en besproken met de stakeholders tijdens expertsessies.
Release candidate
Na de beta-fase worden de wijzigingen, in de vorm van release candidates, klaargezet om doorgevoerd te worden in het MedMij Afsprakenstelsel. De release candidates, welke een set van wijzigingen per onderwerp bevatten, worden gepubliceerd op changemanagement.medmij.nl. Per onderwerp wordt de datum gepland waarop het onderwerp wordt doorgevoerd in het MedMij Afsprakenstelsel.
Compatibiliteit van wijzigingen
Als een wijziging compatible is met een eerdere versie, dan wordt er gesproken over backward compatibility. Compatible betekent hierbij dat systemen gegevens kunnen uitwisselen zonder dat er aanpassingen nodig zijn of zonder dat er problemen ontstaan door de verschillen tussen de releases.
Patches
Als de wijzigingen geen invloed hebben op de functionaliteit van de stakeholders en daarmee backward compatible zijn, kunnen deze worden doorgevoerd als patch. Patches kunnen betrekking hebben op de optionele en verplichte versie van het MedMij Afsprakenstelsel.
Minors
Als de wijzigingen wel invloed hebben op de functionaliteit van de stakeholders, maar wel backward compatible zijn, spreken we over minors. Minors kunnen betrekking hebben op de optionele en verplichte versie van het MedMij Afsprakenstelsel.
Majors
Als de wijzigingen wel invloed hebben op de functionaliteit van de stakeholders en niet backward compatible zijn, spreken we over majors. Een wijziging met de classificatie major resulteert altijd in een nieuwe major versie van het MedMij Afsprakenstelsel.
Release-cyclus
De wijzigingen aan het MedMij Afsprakenstelsel vinden zoveel mogelijk plaats aan de hand van een vaste release-cyclus. De release-cyclus bevat 12 release slots per jaar, namelijk de tweede dinsdag van iedere maand.
Indien noodzakelijk kan het bestuur van Stichting MedMij beslissen van deze release-cyclus af te wijken, maar alleen met voorafgaande raadpleging van Eigenaarsraad en Deelnemersraad.
Besluitvorming releases
Releases van het afsprakenstelsel worden, volgens de principes van SemVer, aangeduid met major.minor.patch.
De inhoud van iedere release is samengesteld op basis van uitgewerkte wijzigingsvoorstellen. Bij het uitwerken van wijzigingen analyseert Stichting MedMij de impact van de wijzigingen op de Persoon, de Dienstverlener persoon, de Dienstverlener aanbieder en de aanbieder. Een release volgt de wijziging met de hoogste classificatie.
Stichting MedMij behandelt ieder onderwerp met de classificatie minor of major tijdens een expertsessie, waarvoor in ieder geval alle Deelnemers worden uitgenodigd. Stichting MedMij nodigt desgewenst ook andere belanghebbenden uit.
Het bestuur van Stichting MedMij besluit over het vaststellen van nieuwe releases.
Patch releases
Het bestuur van Stichting MedMij besluit over het publiceren van patch releases zonder dat voorafgaande raadpleging van de deelnemersraad en/of goedkeuring van de eigenaarsraad nodig is. Is een release geclassificeerd als patch, dan kan deze in het eerstvolgende release slot worden doorgevoerd op de actieve optionele en de verplichte versie.
Minor releases
Het bestuur van Stichting MedMij kan besluiten een minor release te publiceren. Het bestuur van Stichting MedMij moet voorafgaand de Deelnemersraad om advies vragen en goedkeuring krijgen van de Eigenaarsraad betreffende de publicatiedatum.
De Deelnemersraad kan adviseren dat een onderwerp dat door Stichting MedMij als minor wordt geclassificeerd, toch een major is. Het bestuur van Stichting MedMij neemt het advies van deelnemersraad mee in besluit over uiteindelijk classificering.
Major releases
De publicatiedatum wordt door het bestuur van Stichting MedMij vastgesteld met voorafgaand advies van de deelnemersraad. Voorafgaande goedkeuring van de eigenaarsraad betreffende het publicatiemoment is vereist.
Tussen de publicatie van 2 major-versies van het afsprakenstelsel moet minimaal 6 maanden zitten. Het doel hiervan is om Deelnemers voldoende tijd te geven om de optionele versie te implementeren en te gaan gebruiken. Elke Deelnemer kiest zelf wanneer hij de optionele versie implementeert, maar doet dit wel voordat deze verplicht wordt.
Versienummering
Stichting MedMij hanteert SemVer versienummering. Hiermee zorgt Stichting MedMij voor deze unieke identificatie van iedere release conform NEN7522-2021. Dit is in lijn met het beleid voor gegevensdienstversienummers.
De (SemVer) aanduiding van release versienummer krijgt de structuur X.Y.Z., waar X, Y en Z een niet-negatief geheel getal zijn. Voorloopnullen mogen niet aanwezig zijn. X is de major, Y is de minor versie en Z is de patch-versie. Elk element moet numeriek ophogen. Bijvoorbeeld:
Patch 1.6.0 => 1.6.1
Minor 1.6.0 => 1.7.0
Major 1.7.0 => 2.0.0
De hoogst geclassificeerde wijziging bepaalt het versienummer van de nieuwe release.
Dakpansgewijze releases
Er is altijd minimaal één major versie van het afsprakenstelsel actief, namelijk de verplichte versie. Alle deelnemers moeten deze versie ondersteunen. Maar ook Stichting MedMij zelf moet deze versie ondersteunen, bijvoorbeeld bij de acceptatieregels, de stelselnode, de referentieimplementatie, de testomgevingen en de loggingscomponent.
Naast de verplichte versie kan er ook een optionele major versie zijn. De optionele versie van het MedMij Afsprakenstelsel is de versie die de actuele verplichte versie opvolgt. Implementatie van de optionele versie is niet verplicht, maar wel toegestaan binnen het operationele MedMij-netwerk. Voor de implementatie van de onderdelen van een nieuwe optionele versie kunnen Deelnemers gebruikmaken van de door Stichting MedMij gefaciliteerde testomgevingen. Hierbij moet het testbeleid gevolgd worden.
Deelnemers kunnen dus twee versies tegelijkertijd ondersteunen, maar zijn daartoe niet verplicht. De Interfaces, Gegevensuitwisseling, Core in het MedMij Afsprakenstelsel ondersteunen altijd de verplichte versie en daarnaast (indien aanwezig) de optionele versie.
Ook op de Gegevensdiensten is dakpansgewijs releasen van toepassing. Dit staat beschreven in het Gegevensdienstenbeleid.
Publicatie en verplichtstelling
Als een optionele versie van het MedMij Afsprakenstelsel verplicht wordt gesteld, krijgt de tot dat moment verplichte versie de status 'verouderd'. De verouderde versie is niet meer actief en mag niet meer door de deelnemers ondersteund worden.Verplichtstelling kan ook zonder publicatie van een nieuwe optionele versie.
Als een nieuwe optionele versie van het MedMij Afsprakenstelsel wordt gepubliceerd, krijgt de tot dat moment optionele versie de status 'verplicht'. Deelnemers moeten vanaf dit moment de nieuwe verplichte versie ondersteunen.
Als er geen optionele versie van het MedMij Afsprakenstelsel is op het moment dat een nieuwe optionele versie gepubliceerd wordt, is er ook geen nieuwe verplichte versie.
Implementatietermijn
Het bestuur van Stichting MedMij kan bepalen dat een implementatietermijn van toepassing is op (onderdelen van een) nieuwe release. Dat betekent dat een nieuwe release, of onderdelen hiervan, na een bepaalde termijn verplicht is voor de deelnemers. Een implementatietermijn op onderdelen van het afsprakenstelsel is aan de orde als dit nodig is om impact en verstoringen te voorkomen.