ISO 13485 software: wat geldt voor softwarebedrijven?
Als je softwarebedrijf software maakt met een medische toepassing, verwacht je klant vaak een ISO 13485-systeem. Dat geldt vooral voor software als medisch hulpmiddel (SaMD, Software as a Medical Device), zoals een app die een diagnose ondersteunt of een dosering berekent. De norm zelf is van ISO . Of jouw software onder de Europese verordening medische hulpmiddelen (MDR) valt en in welke klasse, leg je vast volgens de MDR-risicoklassen, met regel 11 als belangrijkste regel voor software. Hoe je dat in een ISO 13485 handboek en de rest van je kwaliteitssysteem (QMS) borgt, staat verderop.
ISO 13485 maakt je software niet veilig en is geen CE-markering. Het is het managementsysteem waarmee je aantoont hoe je ontwikkelt, test en wijzigt. De wet bepaalt wat je moet aantonen.
Twee kanten van software en ISO 13485
Het woord “software” kan twee dingen betekenen binnen ISO 13485. Ze vragen om verschillende aanpakken:
- Software als medisch hulpmiddel: de software zelf is het product. Dan gelden ontwerp- en ontwikkelcontroles, risicomanagement en validatie voor het product.
- Software die je QMS ondersteunt: je gebruikt een tool voor documenten, CAPA of klachten. Die tool moet je valideren voor het gebruik. Die kant bespreken we op QMS-software kiezen.
Veel softwarebedrijven hebben beide. Begin met de eerste kant: die bepaalt wat je klant echt wil zien.
Welke eisen zijn voor softwarebedrijven het zwaarst?
De norm is technologie-neutraal, maar bij software komen een paar onderdelen sterker terug:
- Ontwerp- en ontwikkelcontrole (paragraaf 7.3): je legt ontwerpeisen vast, verifieert ze en valideert het eindresultaat.
- Risicomanagement volgens ISO 14971: softwarefouten kunnen direct schade veroorzaken, dus de risicoanalyse hoort bij elke release.
- Wijzigingsbeheer: elke codewijziging die het medische gedrag raakt, krijgt een beoordeling en een record.
- Validatie van de software die je zelf gebruikt: ook je build-, test- en QMS-tools moeten passend gevalideerd zijn.
- Traceerbaarheid van eisen naar tests: een auditor wil van een eis naar een test en terug kunnen.
Voor het ontwikkelproces van medische software wordt vaak IEC 62304 gebruikt als aanvullende norm (IEC 62304:2006 met amendement A1:2015). Die beschrijft de levenscyclus van software. Gebruik die als werkmethode; ISO 13485 vraagt om het bewijs dat je het ook echt doet.
Stap voor stap: van idee naar een auditklaar softwareproces
Bepaal het beoogd gebruik en de klasse
Schrijf in één alinea wat de software doet, voor wie, in welke situatie en met welk risico. Die tekst is de basis van alles. Zonder een helder beoogd gebruik kun je de klasse niet bepalen.
Leg de ontwerpeisen vast
Maak een lijst van eisen die uit het beoogd gebruik volgen. Denk aan nauwkeurigheid, beschikbaarheid, gebruiksfouten en koppelingen met andere systemen. Elke eis krijgt een nummer.
Koppel eisen aan verificatie en validatie
Verificatie vraagt: bouwen we het goed, volgens de eisen? Validatie vraagt: bouwen we het juiste, voor de gebruiker? Leg per eis vast welke test bewijst dat hij is gehaald.
Richt wijzigingsbeheer in
Elke wijziging in de code die het gedrag van het hulpmiddel kan raken, gaat langs een beoordeling. Lichte wijzigingen, zoals een tekst in de interface, vragen minder. Leg vooraf vast wat je licht en wat zwaar noemt.
Beheer de release
Een release heeft een versie, een release-record, de testresultaten en een besluit van een bevoegde persoon. Zonder dat record kan een auditor niet vaststellen welke software bij welke klant is geleverd.
Voorbeeld: een wijziging in een symptoomchecker
Een fictief voorbeeld. Een softwarebedrijf maakt een app die op basis van klachten aangeeft of een patiënt snel naar de huisarts moet. Het team wil de drempelwaarde voor een bepaald symptoom aanpassen.
| Stap | Wat leg je vast? | Wie beslist? |
|---|---|---|
| Beschrijving wijziging | Oude en nieuwe drempelwaarde, reden, bron van de aanpassing | Productowner |
| Risicobeoordeling | Welke extra fout-negatieven of fout-positieven zijn mogelijk | Kwaliteit en klinisch adviseur |
| Testplan | Testcases die de nieuwe drempel en de grenswaarden dekken | Testlead |
| Validatie | Testresultaten en afwijkingen, met besluit | Kwaliteitsverantwoordelijke |
| Release | Versie, releasenotes, besluit tot uitrol | Bevoegde directie |
Zie je in deze tabel geen rol voor kwaliteit, dan is er een gat. De auditor vraagt precies daar door.
Veelgemaakte fouten bij softwarebedrijven
- Een agile proces zonder bewijs. Snelle sprints zijn prima, maar elke sprint moet records opleveren die de eisen en tests koppelen.
- Geen onderscheid tussen medisch en niet-medisch gedrag. Als een functie het medisch gedrag raakt, valt die onder het systeem, ook als hij klein lijkt.
- Validatie van tools vergeten. De CI-pipeline (de automatische bouw- en testomgeving) en het ticketsysteem tellen mee als je ze gebruikt om de release te beslissen.
- Risicoanalyse als eenmalig document. Bij elke wijziging hoort een herziening.
- Te laat beginnen. Veel teams bouwen eerst en documenteren later. Bij een auditor kost dat vaak maanden.
Begin klein en kies de juiste volgorde
Een klein softwareteam hoeft niet alles in één keer te regelen. Begin met het beoogd gebruik, de klasse en de eisen. Daarna komen risicomanagement en wijzigingsbeheer. Het QMS-systeem bouw je eromheen. Voor het minimale systeem bij een beginnend bedrijf lees je ISO 13485 voor medtech startups.
Onder regel 11 valt beslissingsondersteunende software meestal minimaal in klasse IIa. Dan beoordeelt een notified body (een aangewezen keuringsinstantie) je technische dossier. Zie notified body kiezen voor de keuze en de kosten van een beoordeling.