1. Bij welke updates moet een leverancier het product opnieuw laten beoordelen en certificeren door de notified body? Wat zijn hiervoor de regels?

CEtool.nl is een website waar u dit gemakkelijk voor uw software kunt onderzoeken.

Grote software aanpassingen (upgrades) leiden tot een verandering in UDI-DI: het type/modelgebonden kenmerk van de UDI-code. Aangezien de UDI-DI op het productcertificaat en de conformiteitsbeoordeling staat, is deze niet meer geldig voor het gewijzigde hulpmiddel. Via de notified body moet een nieuwe beoordelingsprocedure gestart worden.

Kleine software aanpassingen (updates) leiden tot een verandering in de UDI-PI: het hulpmiddelspecifieke kenmerk van de UDI-code. Deze is in beheer van de leverancier. Het certificaat en de conformiteitsbeoordeling zijn dan nog steeds geldig. De kleine aanpassing wordt doorgevoerd binnen de regels van het eigen kwaliteitssysteem.

De notified body hoeft niet alle kleine aanpassingen te zien, maar wel het systeem waarbinnen die worden doorgevoerd. Dit wordt uitgevraagd in de conformiteitsbeoordeling. Het is aan te bevelen om het ontwerpproces in te richten volgens de IEC 62304, waarin change management ook expliciet wordt uitgevraagd en uitgewerkt.

Bijlage VI van zowel de MDR als IVDR bieden meer aanknopingspunten om te kunnen bepalen welke wijzigingen (software-aanpassingen) leiden tot een nieuwe UDI-DI.

Een grote aanpassing is een wijziging in een van de volgende elementen:
a) de oorspronkelijke prestaties;
b) de veiligheid of het beoogde gebruik van de software;
c) de interpretatie van gegevens.

Deze veranderingen behelzen het volgende: nieuwe of gewijzigde algoritmes, databankstructuren, besturingsplatformen, architecturen of nieuwe gebruikersinterfaces of nieuwe kanalen voor interoperabiliteit.

Geringe software-aanpassingen hebben in het algemeen te maken met foutcorrecties, het verhogen van de gebruiksvriendelijkheid (niet uitgevoerd met het oog op veiligheidsdoeleinden), beveiligingsaanpassingen of operationele efficiëntie.

Geringe software-aanpassingen moeten worden aangegeven met een fabrikantspecifieke vorm van identificatie (UDI-PI).

Significante wijzigingen zoals we die kenden in de MDD komen niet terug in de MDR en IVDR. Het begrip “significante wijziging” komt nog wel terug in de overgangsbepalingen voor MDD en IVDD gecertificeerde hulpmiddelen. Het MDD certificaat blijft geldig tot 27 mei 2025, mits er geen significante wijziging wordt gedaan in ontwerp of intended use (Artikel 120, lid 3). Dit is verder uitgewerkt in EU guidance MDCG 2020-3*. Het IVDD certificaat blijft geldig tot 27 mei 2024 (Artikel 110, lid2).

*Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD

2. Software aanpassen? Is er dan een onderscheid tussen configuratie en customisatie?

Configuratie is het inrichten van de software zodat deze aansluit bij de behoefte van de gebruiker / organisatie waarin het gebruikt moet worden. De configuratie settings zijn flexibel aan te passen door de gebruiker (of de supportafdeling van de gebruikersorganisatie). De verschillende settings zijn uitvoerig getest door de fabrikant. De configuratie valt binnen de intended use van de software. De instructies van de software laten configuratie toe. Het is van belang dat de configuratie gevalideerd wordt en vrijgegeven wordt voor gebruik in de kliniek.

Customisatie is het aanpassen van de code. Dit gebeurt altijd door de leverancier. Indien de customisatie ingrijpend is, moet de leverancier met de update terug naar de notified body voor een nieuwe conformiteitsbeoordeling en UDI-code.

3. In aansluiting op bovenstaande: als je zelf 'wijzigt' (configureert) word je dan zelf 'leidend' in het bepalen of een LIS een SaMD is? En zo ja, wat is dan de aard van die wijziging? Neem je die aanpassingen op in het productdossier of in het (latere) beheerdossier?

Over het algemeen is LIS zo opgebouwd dat nieuwe modules / functionaliteiten toegevoegd kunnen worden.

Wanneer deze geïnterpreteerd kunnen worden als ‘software als medisch hulpmiddel’ volgens de definities van de MDR of IVDR, moet de ontwikkeling "state of the art” zijn. We adviseren LIS-beheerders te werken volgens de IEC-62304.