Belangrijke aspecten van IEC 62304

Totdat de verwachte wijzigingen zijn aangebracht voor kunstmatige intelligentie (AI) in software voor medische hulpmiddelen, wordt de huidige versie van IEC 62304 als state-of-the-art beschouwd. In feite dekt het een aantal aspecten die een aanvulling vormen op ISO 13485 voor kwaliteitsmanagementsystemen (QMS) voor medische hulpmiddelen:

1. Het proces van softwareontwikkeling

2. Een risicoclassificatiesysteem

3. Risicomanagement gedurende de gehele life cycle van het product

4. Verificatie- en validatieactiviteiten

5. Configuratie van softwarebeheer en onderhoud

In wezen zou een organisatie die medische hulpmiddelen met softwarecomponenten ontwikkelt, moeten voldoen aan zowel ISO 13485 als IEC 62304. ISO 13485 bepaalt het bredere kwaliteitsmanagementkader voor de hele organisatie, inclusief de ontwikkeling van software, terwijl IEC 62304 gedetailleerde richtlijnen biedt over de specifieke processen en activiteiten die verband houden met de ontwikkeling, het onderhoud en het risicomanagement van software voor medische hulpmiddelen. Voor meer informatie over ISO 13485 kunt u terecht bij een eerdere blog.

1. Plan voor het ontwikkelingsproces

IEC 62304 helpt u bij het definiëren van het lifecycle framework voor de ontwikkeling van software voor medische hulpmiddelen. Dit begint met een plan, op basis waarvan u een reeks geplande en gedocumenteerde fasen kunt opbouwen, waaronder ontwerp, ontwikkeling, verificatie en validatie.

Als onderdeel van deze stappen worden acceptatiecriteria gedefinieerd, zodat u op basis van vooraf bepaalde resultaten weet wanneer u klaar bent om door te gaan naar de volgende fase. Dit bevat zaken als het finaliseren van de architectuur en het ontwerp, en het gereed en goedgekeurd hebben van een testplan. Zodra het volledige plan is uitgevoerd, is uw dossier gereed voor vrijgave aan een Notified Body.

2. Een extra classificatielaag

De norm IEC 62304 heeft een ander risicoclassificatiesysteem dan de MDR, waardoor een extra laag risicobescherming voor uw software wordt toegevoegd. Er zijn drie klassen:

Klasse A – het kan geen kwaad

Klasse B – er is een kleine kans op schade

Klasse C – er bestaat een risico op overlijden

Schade hoeft niet fysiek te zijn; het kan bijvoorbeeld te maken hebben met onjuiste gegevens die de besluitvorming rond diagnose of behandeling van een patiënt beïnvloeden. Net als bij de MDR bepaalt de risicoklasse het type documentatie dat vereist is. Hoe hoger de risicoklasse, hoe meer documentatie er nodig is. Of het nu standalone software is of geïntegreerd in een apparaat, het beoogde gebruik van de software definieert de potentiële risico's en daarmee de risicoklasse van uw software.

Onze ervaring leert dat geen enkele software als medisch hulpmiddel in klasse A mag worden gecategoriseerd. Dat komt omdat er altijd een kans bestaat dat er iets misgaat. Van potentiële datalekken tot verkeerde interpretatie van de gegevens: het kennen van de potentiële gevaren is van cruciaal belang. Om die reden beginnen we voor onze eigen software – en voor onze klanten – altijd bij Klasse B. Ook is er ruimte voor discussie rond de bijbehorende risicoklasse onder de MDR.

3. Manage risico’s gedurende de gehele life cycle van het product

Risicomanagement is een continu proces, waarbij zowel bekende als potentiële risico's aan de orde komen. De risico's van software zijn heel anders dan die van fysieke apparaten. Ze kunnen bijvoorbeeld last hebben van incompatibiliteit met gerelateerde software of de besturingssystemen (OS) waarop ze draaien.

Het is ook absoluut noodzakelijk om het risico dat gepaard gaat met het gebruik van software op specifieke servers of hardware te minimaliseren.

De normatieve standaard ISO 14971 biedt het overkoepelende raamwerk voor het managen van risico’s die verband houden met medische hulpmiddelen, terwijl IEC 80002-1 zich richt op de manier waarop dit raamwerk specifiek kan worden toegepast op software in medische hulpmiddelen. Deze integratie is van cruciaal belang voor het waarborgen van de veiligheid en effectiviteit van medische apparaten waarin softwarecomponenten zijn verwerkt. Om deze reden raden wij IEC 80002-1 aan voor risicomanagement richtlijnen voor software als medisch apparaat, omdat deze zich richt op software specifieke risico's en problemen. Hierdoor kunt u veiligheid en beveiliging by design realiseren, waarbij u problemen vermijdt zoals de voortdurende laadcyclus die bekendstaat als ‘de oneindige lus’ – die van invloed zou kunnen zijn op de patiëntenzorg. Het is ook een goede gewoonte om een ‘veiligheidstoestand’ te definiëren die gebruikers kan waarschuwen, zodat ze maatregelen kunnen nemen. Door deze benadering van ontwikkeling te volgen, bent u op de goede weg naar een beter softwareproduct.

Voor meer informatie over ISO 14971 kunt u terecht bij een eerdere blog.

4. Software verifiëren en valideren 

Wanneer software voor medische hulpmiddelen op de markt wordt gebracht, zijn verificatie en validatie misschien wel de belangrijkste fasen om het goed te doen. Na het documenteren van de resultaten brengen deze processen doorgaans verborgen problemen aan het licht die moeten worden opgelost voordat de software wordt vrijgegeven. Het is in dit stadium dat de risico's en vereisten die in uw planning zijn gedefinieerd, moeten worden geverifieerd om er zeker van te zijn dat de software hieraan voldoet, en gevalideerd zodat duidelijk aan het beoogde gebruik en de gebruikersbehoeften wordt voldaan.

Testen in de echte wereld kunnen u helpen de gebruiksvriendelijkheid en bruikbaarheid van uw software te verfijnen wanneer deze in handen is van mensen die er minder vertrouwd mee zijn – meestal patiënten en artsen. Hulpmiddelen met een hoger risico vereisen doorgaans klinische onderzoeken om de veiligheid en prestaties aan te tonen, terwijl hulpmiddelen met een lager risico een evaluatie van relevante state-of-the-art literatuur vereisen. In tegenstelling tot andere vormen van software die als Minimal Viable Product op de markt komen en waar vervolgens op wordt doorgebouwd, wordt software als medisch hulpmiddel in alle opzichten op de markt gebracht als een compleet product dat uitgebreid is getest. Dit weerspiegelt de behoefte aan veiligheid, maar ook aan bruikbaarheid – bijvoorbeeld door tekst en knoppen groter te maken voor gebruikers met een verminderd gezichtsvermogen.

5. Software configuratie en onderhoud

Verschillende gezondheidszorginstellingen vereisen mogelijk verschillende functionaliteiten of configuraties van uw softwareproduct, zodat het beter is afgestemd op hun systemen, praktijken, medisch personeel en patiënten. Het kan bijvoorbeeld nodig zijn dat uw software wordt aangepast om verbinding te maken met elektronische patiëntendossiers in de ene medische faciliteit en niet in de andere.

Kleine verschillen in de softwareconfiguratie kunnen grote problemen veroorzaken. Mocht er iets misgaan, dan weet u zonder goed configuratiebeheer misschien niet waarom. U kunt meerdere versies van dezelfde software maken – waardoor u minder controle over de software heeft en wat tot compatibiliteitsproblemen kan leiden – of u kunt de mogelijkheid inbouwen om bepaalde functionaliteiten naar behoefte in of uit te schakelen. Het is goed te vermelden dat het maken van meerdere softwareversies ook de werklast op het gebied van documentatie en testen zal verhogen.

Het documenteren van wijzigingen in de configuratie is van groot belang. Dat geldt ook voor het vastleggen van welke andere software u gebruikt om uw product te bouwen – meestal Open Source-softwarepakketten gemaakt door een derde partij en opgenomen in uw code, ook wel software van onbekende herkomst (Software of Unknown Provenance; SOUP) genoemd. De risico's van het gebruik van SOUP moeten in kaart worden gebracht en er moeten regelmatig controles worden uitgevoerd om op de hoogte te blijven van nieuwe releases van de toegepaste softwarepakketten.

IEC 62304 en de MDR

De MDR en IEC 62304 hebben een complementaire verhouding, en het is duidelijk dat de IEC 62304 waarde kan toevoegen aan het proces om uw software als medisch hulpmiddel op de markt te brengen en daar te houden.

De praktijk van softwareontwikkeling die is beschreven in IEC 62304 helpt ervoor te zorgen dat de softwarecomponenten van medische hulpmiddelen voldoen aan de veiligheids- en prestatie-eisen die zijn vastgelegd in de MDR. Over het algemeen vertelt de MDR u wat er nodig is om uw software te laten certificeren, en IEC 62304 biedt u een raamwerk voor de gehele life cycle van softwareontwikkeling.

Bij Peercode Regulatory Consultancy bieden we deskundige begeleiding en ondersteuning op het gebied van normen en regelgeving voor allerlei soorten medische hulpmiddelen, inclusief software. Praat vandaag nog met een specialist.