Medische software: wanneer krijg je te maken met de MDR en ISO 13485?

Software speelt een steeds grotere rol in de zorg. Denk aan apps die patiënten monitoren, software die medische gegevens analyseert of toepassingen die zorgprofessionals ondersteunen bij een diagnose of behandeling. Maar wanneer wordt software eigenlijk een medisch hulpmiddel? En wanneer krijg je te maken met de Medical Device Regulation (MDR) en ISO 13485?

Niet iedere zorgapp of softwaretoepassing valt automatisch onder de MDR. Wat de software doet én waarvoor je deze op de markt brengt, zijn belangrijke uitgangspunten. Valt jouw software wel onder de MDR? Dan krijg je te maken met eisen rondom onder andere classificatie, risicomanagement, technische documentatie en kwaliteitsmanagement.In dit artikel leggen we uit wanneer software een medisch hulpmiddel is, welke rol de MDR en ISO 13485 spelen en waar je als ontwikkelaar of fabrikant rekening mee moet houden.

Software kan onder de MDR vallen wanneer deze bedoeld is om, zelfstandig of in combinatie met andere producten, voor een medisch doel te worden gebruikt.

Denk bijvoorbeeld aan software voor:

Het feit dat software binnen een ziekenhuis of andere zorgomgeving wordt gebruikt, betekent dus niet automatisch dat het een medisch hulpmiddel is. Een eenvoudige app waarin iemand zelf bloeddrukwaarden invoert en vervolgens alleen terugkijkt, hoeft bijvoorbeeld niet als medisch hulpmiddel te kwalificeren. Analyseert software patiëntspecifieke gegevens en wordt de uitkomst gebruikt voor een diagnose of behandelbeslissing? Dan kan dat anders liggen.

Het intended purpose, het beoogde doel, is daarom een belangrijk vertrekpunt.

Medical Device Software (MDSW) is software die zelfstandig of in combinatie met andere producten een medisch doel heeft en als medisch hulpmiddel kwalificeert. Dat kan bijvoorbeeld een medische app, desktopapplicatie of cloudoplossing zijn. Maar software kan ook onderdeel zijn van een ander medisch hulpmiddel.

Zodra jouw software onder de MDR valt, moet je als fabrikant kunnen aantonen dat je aan de toepasselijke eisen voldoet. Het is daarom slim om al vroeg in het ontwikkelproces drie vragen te beantwoorden:

Zo weet je waar je aan toe bent en voorkom je dat je later processen, software of documentatie opnieuw moet inrichten.

Als jouw software een medisch hulpmiddel is, moet je vervolgens de juiste MDR-risicoklasse bepalen. De MDR kent vier risicoklassen:

Voor veel medische software is regel 11 uit bijlage VIII van de MDR belangrijk. Software die informatie levert waarop beslissingen voor diagnostische of therapeutische doeleinden worden gebaseerd, valt in beginsel in klasse IIa. Kunnen verkeerde beslissingen ernstigere gevolgen hebben? Dan kan een hogere classificatie van toepassing zijn.

Welke klasse geldt, hangt dus af van de specifieke functionaliteit, het intended purpose en de mogelijke gevolgen wanneer er iets misgaat. Dat maakt een juiste classificatie belangrijk. De klasse heeft namelijk invloed op onder andere de conformiteitsbeoordeling, eventuele betrokkenheid van een Notified Body, het kwaliteitsmanagementsysteem en de technische documentatie.

Dat software technisch goed werkt, betekent nog niet automatisch dat je aan de MDR voldoet. Als fabrikant moet je kunnen aantonen dat de software beheerst is ontwikkeld en dat veiligheid en prestaties voldoende zijn geborgd. Afhankelijk van jouw product krijg je bijvoorbeeld te maken met:

En die onderdelen staan niet los van elkaar. Pas je bijvoorbeeld iets aan in de software? Dan kan dat ook gevolgen hebben voor je risicoanalyse, technische documentatie en klinische onderbouwing. Komen er vanuit klachten of Post-Market Surveillance nieuwe risico’s naar voren? Dan moet je mogelijk weer aanpassingen doen aan je software.

MDR-compliance is dus geen eenmalig project. Je moet het onderdeel maken van de manier waarop je software ontwikkelt, beheert en verbetert.

Daar komt ISO 13485 in beeld. ISO 13485 is de internationale norm voor kwaliteitsmanagement binnen de medische-hulpmiddelensector. De norm kijkt niet alleen naar je product, maar juist ook naar de organisatie en processen waarmee je de kwaliteit en veiligheid van dat product beheerst. Voor een ontwikkelaar of fabrikant van medische software gaat het bijvoorbeeld om:

ISO 13485 helpt je dus om kwaliteit niet pas aan het einde te controleren, maar structureel onderdeel te maken van je organisatie en ontwikkelproces.

De MDR en ISO 13485 worden vaak in één adem genoemd, maar zijn niet hetzelfde.

Heel simpel gezegd: De MDR bepaalt wat je moet aantonen. ISO 13485 helpt je om een belangrijk deel daarvan structureel te organiseren.

Niet iedere fabrikant van medische software is automatisch wettelijk verplicht om een ISO 13485-certificaat te behalen. De MDR stelt wel eisen aan het kwaliteitsmanagementsysteem van fabrikanten. ISO 13485 biedt hiervoor een belangrijk internationaal erkend kader. Welke eisen precies voor jouw organisatie gelden, hangt onder andere af van je software, MDR-classificatie en de conformiteitsroute. Begin daarom niet alleen met de vraag: Moeten wij ISO 13485 gecertificeerd zijn? Een betere eerste vraag is: Wat moeten wij voor onze medische software aantoonbaar beheersen? Vanuit dat antwoord kun je bepalen welke stappen nodig zijn.

Naast ISO 13485 kunnen bij medische software nog andere normen relevant zijn. Zo richt ISO 14971 zich op risicomanagement voor medische hulpmiddelen. IEC 62304 biedt een kader voor het beheerst ontwikkelen en onderhouden van Medical Device Software. IEC 62366-1 richt zich op usability engineering en risico’s die kunnen ontstaan door het gebruik van een medisch hulpmiddel. Ook informatiebeveiliging kan een rol spelen. Medische software verwerkt immers regelmatig gevoelige informatie. Vanuit dat perspectief kunnen bijvoorbeeld ISO 27001 en NEN 7510 relevant zijn. Maar dat betekent niet dat je automatisch al deze normen moet implementeren.

Kijk eerst naar je eigen product:

Zo voorkom je dat je allerlei processen optuigt die voor jouw situatie misschien helemaal niet nodig zijn.

Bij medische software komen techniek, wetgeving en kwaliteitsmanagement samen. Dat kan behoorlijk complex worden. Een duidelijke volgorde helpt.

Zo werk je niet alleen toe naar de juiste documentatie, maar zorg je dat kwaliteit en compliance onderdeel worden van de dagelijkse praktijk.