Inhoudsopgave

Hoe richt ik wijzigingsbeheer in?

Praktijkvraag 8

Hoe richt ik wijzigingsbeheer in?

De leverancier van medische informatietechnologie kan periodiek nieuwe versies van zijn software uitbrengen. Het is van belang om vooraf goede afspraken vast te leggen over het wel of niet doorvoeren van nieuwe versies en de bijbehorende consequenties voor de service en aansprakelijkheid.

Wat verwachten we van de leverancier?

De leverancier van medische informatietechnologie kan periodiek nieuwe versies van zijn software uitbrengen. Dit kunnen versies met vernieuwde functionaliteit zijn (upgrade), maar ook met oplossingen voor risicovolle of zelfs gevaarlijke problemen (update). Een leverancier kan in dat geval de gebruiker

verplichten de nieuwe versie van de software in gebruik te nemen. Als een nieuwe versie alleen een nieuwe functionaliteit toevoegt die niet van belang is voor de gebruiker, dan kan de gebruiker ervoor kiezen om de update niet door te voeren. Dit moet uiteraard wel gebeuren in overleg met de eigenaar/ verantwoordelijke afdelingen, bijvoorbeeld IT, Medische Techniek of Klinische Fysica. Ook moeten hierbij wel de risico’s worden afgewogen en moet de leverancier de huidig gebruikte versie nog wel ondersteunen.

 

Het is daarom van belang om vooraf goede afspraken vast te leggen over het wel of niet doorvoeren van nieuwe versies en de bijbehorende consequenties voor de service en aansprakelijkheid.

 

De leverancier heeft zelf verplichtingen bij het ontwikkelen en updaten van zijn software, zoals het uitvoeren van een risicoanalyse, het vastleggen van wijzigingsverzoeken en het informeren over problemen. Het kan echter raadzaam zijn om als gebruiker de leverancier hierover te bevragen om een beeld te krijgen van diens betrouwbaarheid. Maak afspraken dat zonder formele toestemming binnen de eigen organisatie, de leverancier geen softwarewijzigingen mag doorvoeren (bijvoorbeeld gedurende het onderhoud) en leg dit in de inkoopvoorwaarden vast. Bij wijzigingen is het belangrijk om de leverancier te vragen naar mogelijke veranderingen in toepassingsgebied, de intended use. Vraag onder andere naar release notes, beslissing over wijziging, testen en vrijgave, en noodzaak voor trainingen.

Een nieuwe versie, wat doen we nu?

In het geval van het doorvoeren van een update of upgrade van de software moet de fase van ingebruikname opnieuw worden doorlopen. De PRI, die tijdens de aanvankelijke ingebruikname is uitgevoerd, moet worden getoetst met daarbij ook eventueel nieuwe informatie van de leverancier over de risico’s. Het kan bijvoorbeeld zijn dat de risicoklasse is gewijzigd, waardoor (ook vanuit de leverancier) een veel uitgebreidere risicoanalyse nodig is.

 

De aangepaste versie moet in de verschillende beschikbare omgevingen (Ontwikkel, Test, Acceptatie en Productie; OTAP) worden geïmplementeerd en getest. Deze testen kunnen zowel technisch als functioneel van aard zijn. Functioneel gaat het dan om de werking en het gebruik van de software zelf. Technisch moet je denken aan het testen van koppelingen en de integratie met andere systemen, performancetesten en veiligheidstesten. Er moeten daarnaast (nood)procedures ingericht zijn voor het geval van een calamiteit, zowel technisch als functioneel. Voor technische procedures zijn dit bijvoorbeeld back upsystemen of het redundant uitvoeren van een systeem. Een functionele procedure is meer gericht op de toepassing binnen het zorgproces, bijvoorbeeld op welke pc staat het back-upsysteem en hoe haal ik daar de relevante gegevens vandaan bij een calamiteit?

ITIL, ASL of iets anders?

Bij het inrichten van een OTAP-omgeving hoort ook een proces om gedurende de levensduur wijzigingen van de medische informatietechnologie goed te borgen. Om dit proces binnen een organisatie goed in te richten geven bijvoorbeeld de procesraamwerken ITIL

 

(Information Technology Infrastructure Library) en ASL (Application Services Library) een aantal handvatten. ITIL is vooral IT-technisch beheer en ASL is meer voor applicatiebeheer. Beide methodes hebben hun eigen voor- en nadelen, wij adviseren om zoveel mogelijk bij de al in de organisatie aanwezige IT-processen aan te sluiten. Voor ITIL en ASL bestaat diverse literatuur en er zijn specifieke trainingen beschikbaar. Kies vooral een niveau dat binnen de organisatie past. Zie het als een raamwerk en niet als een strikte of letterlijke manier om je processen in te richten.

Binnen het beheerproces worden rollen en verantwoordelijkheden vastgelegd. Dit kan voor de specifieke taken of activiteiten in deze processen bijvoorbeeld gedaan worden met behulp van de RACI-methode (in het Nederlands VERI). Meestal wordt deze uitwerking in tabelvorm vastgelegd, zie voor voorbeelden Praktijkvraag 4.

Hoe gaat dit bij een samengesteld systeem, bijvoorbeeld een medisch alarmeringssysteem (MA)?

Elke wijziging van een onderdeel van het systeem kan direct invloed hebben op de andere onderdelen en de samenwerking van de onderdelen. In het geval van een MA is een wijziging van software van een medisch apparaat bijvoorbeeld van invloed op de communicatie of het uitsturen van alarmen. Als een wijziging ervoor zorgt dat bijvoorbeeld meer of minder alarmen uitgestuurd worden door het apparaat, moeten de verschillende partijen deze wijziging beoordelen op wenselijkheid. Vervolgens moeten de risico’s in kaart gebracht worden. Als het licht dan nog steeds op groen staat, kan de wijziging doorgevoerd worden voor één apparaat en vervolgens met de testomgeving van het MA getest worden. Zodra dit akkoord is, kan de wijziging definitief worden gemaakt en bij eventueel andere apparaten doorgevoerd worden. Scholing van het personeel kan noodzakelijk zijn. Ook is het belangrijk dat al deze wijzigingen gedocumenteerd worden in een systeemdossier bij de betreffende component. Vaak moeten veel verschillende partijen de wijziging beoordelen voordat die doorgevoerd kan worden, zoals de afdelingen Medische Techniek, Klinische Fysica, Klinische Informatica, Infra en IT (vaak diverse organen binnen de IT-afdeling). Maar ook leverancier A, leverancier B, gebruikers/eigenaar afdeling I, gebruikers/eigenaar afdeling II, et cetera.

 

Naast softwarewijzigingen is het bij samengestelde systemen belangrijk om ook infrastructurele wijzigingen te beoordelen. Deze wijzigingen zijn vaak onvoldoende in het vizier. Denk bijvoorbeeld aan het veranderen van het type access points voor wifi, andere servers of switches. Bij aanschaf en installatie is het van belang dat alle partijen aangeven wat de vereisten zijn voor de infrastructuur. Dit moet vastgelegd worden in het systeemdossier (CMDB). Bij wijzigingen aan de infrastructuur moet duidelijk worden of en welke consequenties dit heeft voor het systeem. Een toetsing bij de leveranciers van deze aanpassingen is een must.

 

Alle componenten van het systeem hebben periodiek onderhoud nodig. Deze periodes liggen helaas niet allemaal gelijk. Het is belangrijk om dit onderhoud zoveel mogelijk te coördineren zodat het zorgproces zo min mogelijk hinder ondervindt. Het is volstrekt onaanvaardbaar als een kritisch systeem zoals het MA in week 1 ‘plat ligt’ door onderhoud aan component A, in week 2 door onderhoud aan component B en in week 3 door wijziging van softwarecomponent C. Een coördinerende rol om deze werkzaamheden op elkaar af te stemmen ligt doorgaans bij één partij in de zorginstelling. 

 

Na elke wijziging die doorgevoerd wordt aan het systeem moet een standaard testplan uitgevoerd worden. Een voorbeeld van een testplan voor het MA staat in tabel 4.8.2.

Hoe moet ik wijzigingsbeheer invoeren als ik zelf software ontwikkel?

In Praktijkvraag 1 staat in welke mate ‘in huis’ ontwikkelde software moet voldoen aan de MDR vanaf 2020. Hierin is de tweedeling beschreven, ofwel volledig voldoen aan de MDR, ofwel gedeeltelijk. Hoewel er op dit moment onder de MDD geen duidelijkheid is aan welke voorwaarden moet worden voldaan, is het voor het wijzigingsbeheer raadzaam al rekening te houden met de toekomstige verplichtingen van de MDR. Voor zelfontwikkelde software die volgens het bovengenoemde artikel gedeeltelijk onder de MDR valt, staat het een zorginstelling vrij om dit volledig binnen de eigen wijzigingsbeheeromgeving op te nemen.

Het is nu wel de verplichting van de zorginstelling om een periodieke risicoanalyse uit te voeren, wijzigingsverzoeken en beslissingen hierover vast te leggen, release notes te documenteren, gebruikers te informeren over problemen met de software en test- en vrijgaveprocedures vast te leggen. Bij wijzigingen is het belangrijk om na te gaan of de intended use verandert en of de gebruikers aanvullende training nodig hebben. 

 

Voor updates geldt de hier eerder genoemde informatie onder het kopje ‘Een nieuwe versie, wat doen we nu?’ 

 

Als de software toch op alle punten aan de MDR moet voldoen, bijvoorbeeld omdat er al een vergelijkbaar product op de markt is, moeten er aanvullende maatregelen genomen worden. In het softwareontwikkelplan wordt dan het wijzigingsbeheerproces beschreven. Voor verdere details en uitwerking van dit plan, zie het eerdergenoemde artikel en IEC 62304.

Tabel 4.8.2.Voorbeeld van een testplan alarmen na onderhoud