Uitwerking

Door te voeren wijzigingen

Locatie

Change- en releasebeleid

Oude tekst

Change- en releasebeleid

Het MedMij Afsprakenstelsel ontwikkelt zich voortdurend. Ontwikkelingen binnen en rondom MedMij kunnen aanleiding geven om afspraken uit het stelsel te wijzigen.

Releasecyclus

De wijzigingen aan het stelsel vinden zoveel mogelijk plaats aan de hand van een vaste releasecyclus. De release cyclus bevat 12 release slots per jaar, waarvan er twee release slots (in april en oktober) voor majors en minors zijn gealloceerd. Stichting MedMij speelt hierbij een aanjagende en faciliterende rol met een aantal verantwoordelijkheden, namelijk:

• het samenstellen van samenhangende releases,

• het ophalen van input bij belanghebbenden,

• het uitvoeren van impactanalyses,

• het organiseren van de besluitvorming en de informatievoorziening eromheen en

• het bewaken van relevante ontwikkelingen (bijvoorbeeld veranderende wetgeving).

Ook is Stichting MedMij voortdurend alert op wijzigingen in gebruikte normen en standaarden en heroverweegt in z'n geval het hergebruik.

Jaarlijks stelt Stichting MedMij samen met de verschillende belanghebbenden een release roadmap op. De roadmap bevat een overzicht van geplande releases voor de periode van een jaar en geeft aan wat de belangrijkste voorgenomen wijzigingen zijn per release. Wijzigingen betreffende de inhoud van het afsprakenstelsel moeten passen binnen deze roadmap. De roadmap moet op haar beurt weer passen binnen de strategische kaders. Het bestuur van Stichting MedMij stelt de roadmap op.

Dakpansgewijze releases

Om het ritme van de voortdurende ontwikkeling van het MedMij Afsprakenstelsel voor Deelnemers zo voorspelbaar mogelijk te maken, en Deelnemers daarbinnen ruimte te geven voor een proactief of reactief implementatiebeleid, kunnen er twee gepubliceerde versies van het MedMij Afsprakenstelsel zijn. Er is altijd een verplichte versie van het MedMij Afsprakenstelsel. Dat wil zeggen dat alle Deelnemers deze versie moeten ondersteunen. De andere actieve release heet de release candidate. Naast de verplichte versie kan ook een optionele versie worden gepubliceerd. Implementatie daarvan is niet verplicht, maar wel toegestaan binnen het operationele MedMij-netwerk. Omdat de Interfaces, Gegevensuitwisseling, Core in het MedMij Afsprakenstelsel geversioneerd zijn, kunnen de verplichte en optionele versie tegelijkertijd actief zijn. De optionele versie van het MedMij Afsprakenstelsel is de opvolger van de verplichte. Elke Deelnemer kiest zelf wanneer hij de optionele versie implementeert, desgewenst naast de verplichte. 

Bij één actieve versie van het MedMij Afsprakenstelsel

Wanneer er geen ‘nieuwe optionele versie’ is dan:

• wordt de ‘tot op dat moment optionele versie” van het MedMij Afsprakenstelsel verplicht.

• De 'tot dan toe verplichte versie’ krijgt de status verouderd, wat wil zeggen dat dezeversie niet meer actief is. De verouderde versie wordt verwijderd en deelnemers mogen deze niet meer ondersteunen.

In het daaropvolgend major release moment blijft de verplichte versie gelijk en (mits er een ‘nieuwe optionele versie’ is) wordt de ‘nieuwe optionele versie’ gepubliceerd in de MM Optioneel. Daarna wordt het reguliere release beleid weer gevolgd.

Bij twee actieve versies van het MedMij Afsprakenstelsel

Op het moment dat een nieuwe versie van het MedMij Afsprakenstelsel gepubliceerd wordt terwijl er nog twee gepubliceerde versies zijn dan:

• krijgt de 'tot dan toe verplichte versie” de status verouderd, wat wil zeggen dat deze niet meer actief is;

• overschrijft de ‘nieuwe optionele versie' de 'tot op dat moment optionele versie’;

• wordt de ‘tot op dat moment optionele versie’ verplicht.

Steeds schuift dus de nieuwste release (de optionele) als een nieuwe dakpan half bovenop de (dan) verplichte. Alleen de bovenste twee dakpannen zijn actief. Hun overlap symboliseert het tegelijkertijd actief zijn op het MedMij-netwerk. Omdat MedMij een vast release-ritme hanteert (van eens per half jaar), is die overlap een halve dakpan groot. Onder de verplichte release liggen de verouderde releases, als inactieve geschiedenis van het MedMij Afsprakenstelsel.

Dakpansgewijze aanpak

Ook op de Gegevensdiensten is dakpansgewijs releasen van toepassing. Dit staat beschreven in het Gegevensdienstenbeleid. 

Implicaties voor NEN-certificering

Met de publicatie van een nieuwe versie van het Afsprakenstelsel komt er ook een nieuw aanvullend normenkader beschikbaar. Om een balans te hebben tussen de benodigde tijd die deelnemers nodig hebben voor het maken van aanpassingen enerzijds, en het (te) lang moeten wachten met het verscherpen van de normen rond beveiliging anderzijds, wordt een periode van vier maanden in acht gehouden voordat de nieuwe versie van het aanvullende normenkader toegepast wordt in de NEN certificatie. Dit betekent dat de gepubliceerde versie van het  aanvullend normenkader eerder verplicht en algemeen wordt dan de overige delen van het Afsprakenstelsel.

Totstandkoming releases

Alle belanghebbenden, waaronder in ieder geval de deelnemers, gebruikers en Stichting MedMij, kunnen invloed uitoefenen op (de totstandkoming van) wijzigingen in het afsprakenstelsel. Dit doen zij door een wens (nieuw of aanpassing) per e-mail te sturen naar Product Management. Stichting MedMij doet een eerste beoordeling van ingediende wens door deze te toetsen aan de vigerende wet- en regelgeving, architectuur en grondslagen, strategische koers, het jaarplan en het ontwikkelportfolio.  Hierbij wordt onder andere beoordeeld of het daadwerkelijk gaat om een wijziging, of de wijziging niet al eerder is ingediend en wat de urgentie is. Stichting MedMij voert vooronderzoeken uit, laat wijzigingsverzoeken uitwerken, brengt de benodigde expertise en vertegenwoordiging bij elkaar, kanaliseert de afstemming met partijen rondom het stelsel en onderzoekt de impact van een wijziging op het stelsel en de deelnemers. Ook controleert zij of de voorgestelde oplossing vrij en kosteloos voor de deelnemers te gebruiken is.

In principe mogen betrokkenen bij het ontwikkelproces ontwikkelinformatie vrij met elkaar delen zonder aanvullende bescherming. Alleen voor informatie over kwetsbaarheden geldt dat verspreiding beperkt is tot de direct betrokkenen en alleen mag plaatsvinden met extra bescherming (zie Informatieclassificatiebeleid). Mochten belanghebbenden gedurende het change- en releaseproces bijdragen aan de uitwerking van een wijziging, dan ziet Stichting MedMij erop toe dat zij over de juiste auteursrechten komt te beschikken om de documentatie te kunnen publiceren (zie Intellectueel eigendomsbeleid).

Het afsprakenstelsel bestaat uit een samenhangende set van producten (juridisch kader, overeenkomsten, architectuur en technische specificaties, etc.) met veel onderlinge afhankelijkheden. Aanpassing van een van de onderdelen vraagt altijd om een impactanalyse op de rest van de producten. Het afsprakenstelsel wordt daarom altijd in haar geheel gereleaset. Deze releases bestaan uit een consistente set van RFC's en kunnen daarnaast verbeteringen van niet-inhoudelijke aard bevatten.

Versienummering van releases

Vanuit de NEN 7522-2021 wordt gesteld dat bij de release van een nieuwe versie van het afsprakenstelsel (artefact) deze een unieke identificatie krijgt. De door het ontwikkelteam geclassificeerde wijzigingen bepalen de unieke identificatie van de release. Voor deze unieke identificatie hanteren we SemVer versienummering. Dit is in lijn met het Nictiz gegevensdienstversienummer beleid. 

Definitie compatibiliteit:

Twee versies van het MedMij Afsprakenstelsel zijn compatible met elkaar als een implementerend systeem kan overstappen van de ene naar de andere versie of gegevens kan uitwisselen met een systeem dat de andere versie implementeert, zonder dat er aanpassingen nodig zijn en zonder dat er problemen ontstaan door de wijzigingen in de nieuwe versie.

• Als een nieuwe versie compatible is met een eerdere versie, dan wordt er gesproken over backward compatibility.

Algemene Versioneringsregels

Bij het uitwerken van de wijziging wordt een analyse gemaakt om de impact van de wijziging vast te stellen.
Een uitgewerkte wijziging wordt geclassificeerd als major, minor of patch o.b.v. de onderstaande onderdelen:

• of het de uitwisseling beïnvloedt en daarmee niet backward compatible is met het huidige afsprakenstelsel

• of en hoe het de functionaliteit beïnvloedt.

• Het alleen een tekstuele wijziging is zonder functionele invloed.

Een release volgt de wijziging met de hoogste classificatie;

• Een incompatibele wijziging leidt ALTIJD tot een major publicatie

• Een compatibele wijziging KAN, met valide reden, ook tot een major publicatie leiden. (bijvoorbeeld door major impact op de uitwisselingsketen) 

Releases voor het afsprakenstelsel worden als volgt aangeduid:

1. Majors: wijzigingen die invloed hebben op de functionaliteit en niet backward compatible zijn. Deze releases worden opgenomen in de roadmap;

2. Minors: wijzigingen die invloed hebben op de functionaliteit en backward compatible zijn.

3. Patches: Wijzigingen die geen invloed hebben op de functionaliteit en backward compatible zijn

De (SemVer) aanduiding van release versienummer moet de structuur X.Y.Z. hebben, 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

Hierbij geldt dat de hoogst geclassificeerde wijziging het te wijzigen nummer bepaalt.

Een optionele versie bevat ten minste één major wijziging en eventueel ook minors en patches. De inhoud van de nieuwe optionele versie wordt samengesteld op basis van uitgewerkte wijzigingsvoorstellen. Majors worden enkel buiten de major release slots gepubliceerd indien noodzakelijk. Echter, in overleg met de belanghebbenden kunnen minors ook tussentijds doorgevoerd worden.

Patches kunnen in het MedMij Afsprakenstelsel worden opgenomen zonder dat deze leiden tot een nieuwe release. Voorbeelden van patches zijn het verwijderen van inconsistenties of het aanpassen van voorbeeldberichten. Een patch heeft geen invloed op de functionaliteit en is backward compatible. Wanneer blijkt dat een patch toch invloed heeft op de functionaliteit, dient de wijziging als minor of major geclassificeerd te worden en als dusdanig behandeld te worden.

Besluitvorming releases

Aan de hand van de roadmap worden wijzigingsstukken uitgewerkt. Maandelijks is er een publicatiemoment beschikbaar, hier kunnen uitgewerkte wijzigingen gepubliceerd worden. Is de wijziging geclassificeerd als patch, dan wordt deze direct doorgevoerd op de actieve optionele en de verplichte versie. Is de wijziging een minor of major, dan wordt tijdens de expertsessies bij de belanghebbenden consultatie gedaan voor de wijziging. Op basis van de bepaalde implementatietijden van de wijzigingen wordt een voorstel gedaan voor de volgende optionele versie.

Bij major wijzigingen legt Stichting MedMij de voorgestelde 'nieuwe optionele versie' eerst voor aan de deelnemersraad, die hierover een zwaarwegend advies afgeeft. Het bestuur is niet gehouden aan dit advies, maar dient het advies van de raad wel serieus te nemen en een afwijking te onderbouwen. De besluitvorming over de nieuwe release door het bestuur behoeft de goedkeuring van de eigenaarsraad. De eigenaarsraad dient hierbij geïnformeerd te worden over het advies van de deelnemersraad en eventueel over de motivatie van het bestuur om van dit advies af te wijken.

Indien het bestuur van Stichting MedMij minors eerder wil laten implementeren dan het beoogde major release slot, dan kan in overleg met het bestuur en de belanghebbenden worden besloten de minors op één van de reguliere release slots tussentijds door te voeren. Bij een minor release zijn goedkeuring van de eigenaarsraad en advisering van de deelnemersraad niet noodzakelijk.

Implementatie releases

Als Stichting MedMij besluit tot een nieuwe release van het afsprakenstelsel, dan bepaalt zij samen met de deelnemers en de eigenaren bepaalt welke aanpak de minste impact en verstoringen veroorzaakt. Ook maakt de stichting de afweging of releases in productie naast elkaar kunnen bestaan en of deelnemers op enig moment meerdere releases moeten ondersteunen. Voor de implementatie van de release zijn de data in de implementatieplanning bij de release leidend. Afhankelijk van het soort release kan een implementatietermijn van toepassing zijn.

Stichting MedMij is verantwoordelijk voor het uitvoeren van het change- en releaseproces volgens afspraak, het monitoren van de planning op risico's voor de afgesproken ingebruiknamemomenten, en waar nodig escalatie op het juiste niveau. Ook zorgt zij voor een gestructureerde doorvoering van aanpassingen in de documentatie en de publicatie van een nieuwe release van het afsprakenstelsel (minimaal in de vorm van een pdf voor de administratie van deelnemers).

Locatie:

Change- en releasebeleid

Nieuwe tekst

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.

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 2.1.0  => 2.1.1 

• Minor 2.1.0 => 2.2.0 

• Major 2.1.0 => 3.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.

In te voegen links

Intellectueel eigendomsbeleid → Intellectueel eigendomsbeleid

info@medmij.nl

changemanagement.medmij.nl →

NEN7522-2021 → NEN7522-2021.

Interfaces, Gegevensuitwisseling, Core  → Interfaces, Core

Gegevensdienstenbeleid→ Gegevensdienstenbeleid

Review

Zijn de volgende acties uitgevoerd?