Digital Health: Omgaan met updates in medische software en apps

Zodra software op de markt komt, zijn software-updates onvermijdelijk. Er worden voortdurend nieuwe al dan niet kritische kwetsbaarheden op het gebied van beveiliging ontdekt of geïntroduceerd die updates vereisen. Maar updates zijn veelal ook nodig om de gebruikerservaring te verbeteren, om softwarebugs te verhelpen (100% foutvrije softwarecode bestaat immers niet) of om de compatibiliteit met apparatuur of andere software te kunnen blijven garanderen. En natuurlijk om nieuwe functionaliteiten te introduceren. Als gebruikers van smartphones, computers en andere slimme gadgets zijn we hier al zo gewend aan geraakt dat we deze updates automatisch (laten) installeren en er eigenlijk niet of nauwelijks meer iets van merken. Met medische apps is dit niet veel anders en worden updates vaak argeloos geïnstalleerd.

Met meer complexe medische software ligt dit vanzelfsprekend anders en verlopen updates via de IT-beheerorganisatie. Zeker in de wereld van medische software is een meer kritische blik geen overbodige luxe. Zonder updates blijven kwetsbaarheden bestaan en kan de veiligheid van patiënten of patiëntgegevens in gevaar komen. Maar de updates zelf kunnen ook nieuwe kwetsbaarheden introduceren. Bij de steeds verdergaande digitalisering van de zorg roept dit de vraag op hoe eigenlijk met updates van medische software moet worden omgegaan. In deze bijdrage gaan wij daar nader op in. 

Achtergrond: regelgeving inzake medische hulpmiddelen

De regels voor het in de handel brengen van medische software zijn neergelegd in de Richtlijn inzake medische hulpmiddelen 93/42/EEG (“Richtlijn“) en daarop gebaseerde Nederlandse wet- en regelgeving. Als software kwalificeert als medisch hulpmiddel,[1] dan moet een conformiteitsbeoordelingsprocedure worden doorlopen voordat de verplicht gestelde CE-markering[2] mag worden aangebracht. Pas daarna mag het product op de markt worden gebracht. 

Welke stappen genomen moeten worden bij het doorlopen van de conformiteitsbeoordelingsprocedure is afhankelijk van de risicoklasse waarin het hulpmiddel valt (I, IIa, IIb of III). Indeling vindt plaats aan de hand van het risico: hoe hoger het risico voor de patiënt als het medisch hulpmiddel faalt, hoe hoger de risicoklasse. Nadat de risicoklasse van het medisch hulpmiddel is vastgesteld, moet een beoordelingsroute worden vastgesteld.[3] Afhankelijk van de risicoklasse kan de fabrikant zelf een route kiezen. Voor sommige (hogere) risicoklassen moet altijd een externe partij, een zogenaamde ‘aangemelde instantie‘ worden betrokken bij de conformiteitsbeoordeling. 

Maar wat nu als de conformiteitsbeoordelingsprocedure is doorlopen en de software rechtmatig op de markt is gebracht en de producent wenst wijzigingen aan te brengen? Regelmatig zijn bijvoorbeeld securitypatches nodig en worden er updates doorgevoerd. Dit roept de vraag op of dan de hele procedure opnieuw moet worden doorlopen. 

Regels voor het aanbrengen van wijzigingen in medische software

In de Richtlijn en nadere wet- en regelgeving over medische hulpmiddelen worden geen duidelijke regels gegeven voor wijzigingen in goedgekeurde en op de markt gebrachte hulpmiddelen. Voor sommige beoordelingsroutes is bepaald dat voor wijzigingen een aanvullende goedkeuring moet worden verstrekt door de aangemelde instantie als die wijzigingen van invloed kunnen zijn op de overeenstemming van het ontwerp met de essentiële eisen van de Richtlijn (deze staan in Bijlage I) en of de gebruiksvoorschriften.[4] Bij andere routes is ter zake niets geregeld. 

Het antwoord op onze vraag kan daarom worden gevonden in een door de Europese Commissie gepubliceerde leidraad over de Europese productvoorschriften (“Blauwe Gids“).[5] In dit document is bepaald dat ‘nieuwe producten’ aan een volledige conformiteitsbeoordeling moeten worden onderworpen. Een product kan als nieuw worden beschouwd als dat in belangrijke mate is gewijzigd of gereviseerd met het oog op het veranderen van zijn oorspronkelijke prestaties, doel of type.[6] 

Onderhoudswerkzaamheden worden buiten de scope van de regelgeving beschouwd voor zover de oorspronkelijke prestaties van een product worden gewijzigd binnen het beoogd gebruik, prestatie- en onderhoudsbereik zoals tijdens de ontwerpfase bedoeld. Op voorwaarde dat het in de handel gebrachte product niet zodanig wordt gewijzigd dat het niet meer voldoet aan de toepasselijke eisen, kunnen software-updates en reparaties met onderhoudswerkzaamheden worden gelijkgesteld. 

Conclusie

Uit het voorgaande kan worden geconcludeerd dat, afhankelijk van de vraag of een software update de medische software niet zodanig wijzigt dat het niet meer voldoet aan de toepasselijke eisen, deze als ‘onderhoudswerkzaamheden’ kwalificeren en voor zover deze onderhoudswerkzaamheden de oorspronkelijke prestaties van een product slechts wijzigen binnen het beoogd gebruik, prestatie- en onderhoudsbereik zoals tijdens de ontwerpfase bedoeld, is geen nieuwe conformiteitsbeoordeling vereist. 

De meeste software updates en security patches zullen als onderhoudswerkzaamheden kwalificeren die het beoogd gebruik niet wijzigen. Hiervoor is dus geen nieuwe conformiteitsbeoordeling vereist. Bij updates die bijvoorbeeld functionaliteit aan de software toevoegen is dit minder evident. Wij adviseren twijfelgevallen voor te leggen aan de aangemelde instantie. 

Kanttekeningen

Bij de voorgaande conclusie moeten twee kanttekeningen worden geplaatst. Ten eerste betreft de Blauwe Gids een niet-juridisch bindende mededeling van de Europese Commissie. Bindende interpretatie van EU-wetgeving is de exclusieve bevoegdheid van het Hof van Justitie van de Europese Unie (“HvJ“) en het HvJ heeft zich tot nu toe niet uitgelaten over wijzigingen in medische software. 

Ten tweede is op 5 april 2017 verordening (EU) 2017/745 (“Verordening“) aangenomen. De Verordening vervangt onder andere Richtlijn en is van toepassing met ingang van 26 mei 2020.[7] Het is de vraag of de Blauwe Gids, die niet is toegeschreven op de Verordening, ook gebruikt kan worden bij de uitleg daarvan, of dat de Europese Commissie een nieuwe versie van dit document zal publiceren. 

De Verordening introduceert daarnaast een Unique Device Identification (“UDI“) systeem op grond waarvan alle medische software moet worden voorzien van een UDI Device Identifier (“UDI-DI“[8]), en een UDI Product Identifier (“UDI-PI“[9]).[10] De UDI moet worden toegekend aan het hulpmiddel zelf of aan de verpakking ervan.[11] 

Een nieuwe UDI-DI is vereist wanneer zich een wijziging voordoet in (a) de oorspronkelijke prestaties, (b) de veiligheid of het beoogde gebruik van de software of (c) de interpretatie van gegevens.[12] Voor geringe software-aanpassingen is enkel een nieuwe UDI-PI, en geen nieuwe UDI-DI, vereist. Voor wat betreft geringe software-aanpassingen verwijst de Verordening naar foutcorrecties, het verhogen van de gebruiksvriendelijkheid (niet uitgevoerd met het oog op veiligheidsdoeleinden), beveiligingsaanpassingen of operationele efficiëntie.[13] 

Meer weten?

Ons Digital Health team heeft ruime ervaring op het gebied van ICT-contracten, privacy, financiering en relevante zorg wet- en regelgeving. Neem contact op met Dimitri van Hoewijk, Louis Jonker of Lars Leemeijer.