To do:

• uniform woordgebruik
• controleren overeenkomen tabellen en afbeeldingen
• zins- en taalgebruik

Koppelingen

Wijzigingsverzoek

...

Probleem

...

We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:

• slechts twee keer per jaar een

...

• release plaats

...

• vindt,
• dat dankzij het dakpanmodel al een halfjaar van tevoren vast ligt wat wordt opgenomen in het afsprakenstelsel en
• dat nu het release moment de ontwikkelplanning bepaalt

er gezamenlijk voor zorgen dat wij een anderhalf jaar tot een jaar van tevoren al vastleggen wat er gewijzigd gaat worden. correcties zijn.

Ten gevolge hiervan treden verschillende kleinere problemen op namelijk:

1. Eventuele wijzigingen die alsnog op korte termijn buiten de twee releasemomenten doorgevoerd moeten worden worden nu doorgevoerd als correcties terwijl dit eigenlijk geen correcties zijn.
2. Als er geen onderwerpen zijn om te releasen dan kunnen we alleen óf de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie óf de release kan worden uitgesteld.
3. Bij versiewijzigingen moet veel administratief werk verricht worden omdat er een volledige koppeling is met de code van de R&A en de in de R&A vastgelegde endpoints.

Bovenstaande problemen kunnen niet los van elkaar worden opgepakt, omdat de oplossing voor het eerste probleem en de uitwerking van versioning impact hebben op het tweede probleem.

Doordat we nu anderhalf jaar van tevoren bepalen wat er gereleased wordt kunnen we onvoldoende inspringen op de veranderende vraag uit het dynamische zorg ICT landschap en de wijzigingen binnen de VZVZ zelf.

Probleemstelling

Met de huidige release cycle kunnen we niet dynamisch inspringen op de veranderende vragen vanuit de praktijk.

De huidige methode van versienummering sluit niet aan bij de major-, minor- en patch nummering waardoor de traceability van wijzigingen moeilijk te herleiden is

Doordat we foutief gebruik van oplopende versienummers combineren met twee gepubliceerde versies van het afsprakenstelsel, kunnen wij major en minor wijzigingen niet zomaar doorvoeren.

Doel:

...

1. Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
2. Zijn de geplande onderwerpen niet volledig uitgewerkt voor het eerst volgende release moment, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld, dit is onwenselijk omdat:
   a.  het voor bepaalde onderwerpen belangrijk is om deze op korte termijn op te nemen in het afsprakenstelsel. Als deze onderwerpen dus niet tijdens het geplande releasemoment gepubliceerd worden dan betekent dat een vertraging van minimaal een halfjaar.
   b. het de betrouwbaarheid van MedMij richting de deelnemers kan ondermijnen. Als wij beloven bepaalde stukken op te nemen in de optionele versie van het afsprakenstelsel en vervolgens leveren wij dit niet op dan kan dat de relatie van MedMij met de deelnemers schaden.
3. Deelnemers geven aan dat de termijn van een halfjaar tussen het opnemen in de optionele en het opnemen in de verplichte versie te kort is om impactvolle wijzigingen in het afsprakenstelsel door te voeren. 

Probleemstelling

Met huidige de vorm van release cycle management kunnen we onvoldoende inspringen op de veranderende vraag uit het dynamische Zorg ICT landschap en de wijzigingen binnen de MedMij zelf.

Doel:

Meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van deelnemers stakeholders voor majors.
Daarnaast willen we de deelnemers

Subdoelen

• Deelnemers en MedMij medewerkers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.

Aannames

• De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.

• Op de verplichte stelselversie publicatie worden geen major aanpassingen doorgevoerd tenzij... (bijvoorbeeld o.b.v. security, regelgeving of major bug-fix)
• Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

Definities

• Patches: Kleine wijzigingen die geen invloed hebben op de functionaliteit en wel backwardscompatible zijn.
• Minors: Wijzigingen die wel invloed hebben op de functionaliteit en die wel backwardscompatible zijn. De impact van een minor kan dusdanig groot zijn dat besloten wordt deze als major te behandelen. In de voorbespreking wordt bepaald of dit het geval is.
  
• Majors: Wijzigingen die wel invloed hebben op de functionaliteit en die niet backwards compatible zijn. Een major kan ook wel backwards compatible zijn, maar dat de impact van deze wijziging dusdanig groot is dat deze als major behandeld wordt. In de voorbespreking wordt bepaald of een wijziging als major geclassificeerd wordt.

Gewenste situatie

...

• Pas de opname in het afsprakenstelsel plannen als het onderwerp al is uitgewerkt en daarmee de betrouwbaarheid richting deelnemers verhogen.

Definities

Aannames

• De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.

• Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

Gewenste situatie

We willen meer releasemomenten per jaar mogelijk maken om zo de flexibiliteit omtrent de releases van minors en patches verhogen. Wij stellen voor om op regelmatige basis een stakeholder overleg in te plannen waar stakeholders inspraak hebben over de planning voor uitwerkingen van onderwerpen en de planning van releases. 

...