# 5 Redenen waarom IEC 62304 essentieel is voor software als medisch hulpmiddel Bedrijven die software voor medische hulpmiddelen ontwikkelen, moeten rekening houden met zowel de eisen van de EU-verordening inzake medische hulpmiddelen (Medical Device Regulation; MDR) als de norm IEC 62304. Dat komt omdat de praktijk van softwareontwikkeling zoals beschreven in ‘IEC 62304 – Software voor medische hulpmiddelen: software life cycle processen’, helpen ervoor te zorgen dat op zichzelf staande software of softwarecomponenten die zijn ontworpen om naast of in combinatie met een medisch hulpmiddel te worden gebruikt, voldoen aan de veiligheids- en prestatie-eisen die zijn vastgelegd in de MDR. Hieronder is beschreven wat de norm essentieel maakt voor makers software voor medische hulpmiddelen. **Datum**29 augustus 2023 ### 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 risico classificatiesysteem 3\. Risicomanagement gedurende de gehele life cycle van het product 4\. Verificatie- en validatie activiteiten 5\. Configuratie van software beheer 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 kwaliteitsmanagement kader 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 kun je terecht bij onze eerdere [blog.](https://test.blub.company/publicatie/iso-13485-wat-is-het-en-waarom-doet-het-er-toe) ### 1. Plan voor het ontwikkelingsproces IEC 62304 helpt je bij het definiëren van het lifecycle framework voor de ontwikkeling van software voor medische hulpmiddelen. Dit begint met een plan, op basis waarvan je een reeks geplande en gedocumenteerde fasen kunt opbouwen, waaronder ontwerp, ontwikkeling, verificatie en validatie. Als onderdeel van deze stappen worden acceptatiecriteria gedefinieerd, zodat je op basis van vooraf bepaalde resultaten weet wanneer je 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 jouw dossier gereed voor vrijgave aan een Notified Body. ### 2. Een extra classificatie laag De norm IEC 62304 heeft een ander risico classificatiesysteem dan de MDR, waardoor een extra laag risicobescherming voor je 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 jouw 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 kun je veiligheid en beveiliging by design realiseren, waarbij je 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, ben je op de goede weg naar een beter softwareproduct. Voor meer informatie over ISO 14971 kun je terecht bij een eerdere [blog](https://test.blub.company/publicatie/iso-14971-en-de-relevantie-van-risicobeheer-voor-medische-hulpmiddelen). ### 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 je helpen de gebruiksvriendelijkheid en bruikbaarheid van jouw 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 jouw softwareproduct, zodat het beter is afgestemd op hun systemen, praktijken, medisch personeel en patiënten. Het kan bijvoorbeeld nodig zijn dat jouw 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 software configuratie kunnen grote problemen veroorzaken. Mocht er iets misgaan, dan weet je zonder goed configuratiebeheer misschien niet waarom. Je kunt meerdere versies van dezelfde software maken – waardoor je minder controle over de software hebt en wat tot compatibiliteitsproblemen kan leiden – of je 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 je gebruikt om jouw product te bouwen – meestal Open Source-softwarepakketten gemaakt door een derde partij en opgenomen in jouw 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 jouw 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 je wat er nodig is om je software te laten certificeren, en IEC 62304 biedt je een raamwerk voor de gehele life cycle van softwareontwikkeling. *Bij Dawn Regulatory Services 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*](https://test.blub.company/contact)*.* [Terug naar overzicht](/evenementen-publicaties) Link gekopieerd naar het klembord ### Ondersteuning nodig bij IEC 62304 of MDR-softwareeisen? Neem contact op. Wij helpen je veilige, conforme software te ontwikkelen en versnellen je route naar certificering. ## Nieuwsgierig naar onze laatste updates? Blijf up-to-date in het digitale landschap met onze nieuwsbrief. Schrijf je in en krijg het in je mail.