Dit artikel is een vertaling en samenvatting van het artikel ‘Applying and validating a quality management system for in-house developed medical software’ dat is verschenen in Frontiers in Digital Health, 2025 Apr 1:7:1461107. doi: 10.3389/fdgth.2025.1461107 [1].
Met de invoering van de Europese Medical Device Regulation (MDR) in 2021 zijn de eisen voor in-huis ontwikkelde medische hulpmiddelen, waaronder medische software, aanzienlijk aangescherpt. Dit artikel beschrijft hoe een voorspelmodel, dat onder de MDR als medisch hulpmiddel wordt geclassificeerd, is ontwikkeld binnen een bestaand kwaliteitsmanagementsysteem (QMS) gebaseerd op de ISO 13485:2016. Het QMS was oorspronkelijk bedoeld voor fysieke medische hulpmiddelen. Door bestaande documentatie van de data science-afdeling, gebaseerd op de CRISP-DM methodologie, te combineren met het QMS, bleek het mogelijk om zonder veel extra inspanning te voldoen aan de MDR-eisen.
Inleiding
De wetgeving met betrekking tot de in-huis ontwikkeling van medische hulpmiddelen is ingrijpend gewijzigd met de invoering van de Medical Device Regulation (MDR) in 2021 [2]. Er is een speciaal artikel toegevoegd dat in-huis ontwikkeling reguleert, artikel 5.5. Dit artikel beschrijft aan welke eisen een in-huis ontwikkeld medisch hulpmiddel moet voldoen. Eén van de belangrijkste eisen is dat de productie en het gebruik van deze hulpmiddelen plaatsvinden onder een passend kwaliteitsmanagementsysteem (QMS). Wat precies een passend QMS inhoudt, wordt echter niet gespecificeerd.
De Medical Device Coordination Group heeft enkele richtlijnen opgesteld ter verduidelijking van de MDR [4]. Zij geven aan dat artikel 10(9) van de MDR als leidraad kan worden gebruikt voor het inrichten van een passend QMS. Ook verwijzen ze naar relevante normen. Zo is de ISO13485-norm een kwaliteitsstandaard die vaak wordt toegepast door bedrijven die medische hulpmiddelen ontwikkelen.
Praktische richtlijnen voor het implementeren van de MDR bij in-huis ontwikkelde medische hulpmiddelen — en in het bijzonder medische software — zijn schaars. De literatuur over bestaande QMS’en gaat doorgaans over systemen voor fysieke hulpmiddelen [5]. De QMS’en die in de literatuur voor medische software worden beschreven, zijn meestal theoretisch van aard [6].
Voor AI-gebaseerde medische software (AIMS) gelden extra uitdagingen. Een belangrijk kenmerk van AIMS is immers dat deze systemen zichzelf kunnen verbeteren gedurende de levensduur, wat het moeilijk maakt om vooraf een volledige validatie uit te voeren. In de praktijk wordt nu altijd een ‘freeze’ uitgevoerd voor validatie en certificering [7], [8], [9].
In ons ziekenhuis worden voornamelijk fysieke medische hulpmiddelen ontwikkeld. Er is daarom een QMS opgezet dat is gebaseerd op de eisen van de MDR en onze ervaring met de ontwikkeling van fysieke producten, maar met als doel het toepasbaar te maken voor alle typen medische hulpmiddelen, inclusief medische software.
Recentelijk zijn we gestart met de ontwikkeling van voorspelmodellen, die volgens de MDR kwalificeren als medisch hulpmiddel. Aangezien de meeste QMS’en zijn gericht op fysieke producten, besloten we ons bestaande QMS te testen en valideren op een in-huis ontwikkeld voorspelmodel.
In dit artikel beschrijven we onze ervaring met het voldoen aan de MDR-vereisten voor een voorspelmodel dat geclassificeerd is als medische software.
Methoden en Materialen
Kwaliteitsmanagementsysteem (QMS)
Binnen ons ziekenhuis is een QMS geïmplementeerd voor de in-huis ontwikkeling van medische hulpmiddelen, inclusief medische software. Dit systeem is gebaseerd op de ISO13485:2016.
Ons QMS is opgezet als een workflow bestaande uit hoofdonderdelen, onderverdeeld in subelementen. Elk (sub)element bevat, indien van toepassing, procedures, werkinstructies en formats. Twee voorbeelden van formats zijn te vinden in de bijlagen van het originele artikel [1]. De risicoanalyse-formats zijn opgesteld in overeenstemming met de ISO14971:2007-03 [10].
Softwareontwikkeling
In ons ziekenhuis wordt (medische) software ontwikkeld door het data science-team, dat werkt volgens de CRISP-DM-methodologie [11]. Deze methodologie, die al vóór de MDR werd ontwikkeld, biedt een pragmatische aanpak voor softwareontwikkeling.
Dit resulteert in meerdere documenten die verschillende aspecten van de software en het ontwikkelproces beschrijven. Deze documentatie wordt samengevat op een interne wiki-omgeving (Microsoft DevOps Wiki), zodat keuzes en aannames met terugwerkende kracht inzichtelijk blijven.
Praktische toepassing van het QMS
Tijdens de ontwikkeling van een voorspelmodel besloten we om het bestaande QMS toe te passen in combinatie met de documentatie die werd opgesteld via de CRISP-DM-methodiek. Zo wilden we toetsen of we hiermee konden voldoen aan de vereisten van de MDR.
Een multidisciplinair team bestaande uit een data scientist, twee artsen, een technisch geneeskundige en twee klinisch fysici ontwikkelde het voorspelmodel. Elk teamlid leverde input voor de documentatie, afhankelijk van zijn of haar expertise.
Na het bepalen van ieders verantwoordelijkheden met betrekking tot de documentatie, was de volgende stap om te bepalen welke elementen van het QMS toepasbaar waren op de ontwikkeling van medische software in het algemeen, en op dit voorspelmodel in het bijzonder. Dit gebeurde door met het team gezamenlijk per element te bespreken of het van toepassing was. Daarna werd bepaald wie verantwoordelijk was voor het aanleveren van de bijbehorende documentatie, op basis van expertise en rol binnen het project.
Binnen het data science-team waren al procedures/formats aanwezig voor softwareontwikkeling. Deze zijn als basis genomen voor de documentatie. Vervolgens werd de bestaande documentatie vergeleken met de vereisten uit het QMS en waar mogelijk geïntegreerd. Het verschil (de ‘gap’) tussen bestaande softwaredocumentatie en de QMS-eisen werd in twee stappen bepaald:
- Eerst werd gekeken of documentatie volgens CRISP-DM overeenkwam met wat het QMS vereiste. Ontbrak er iets, dan werd dit als “missend” genoteerd.
- Als de documentatie er wel was, werd beoordeeld of de inhoud voldeed aan de eisen uit het QMS.
Tijdens iedere stap in de ontwikkeling van het voorspelmodel werd de vereiste documentatie vastgelegd. Het model werd ontwikkeld in Azure Machine Learning Studio binnen de werkruimte van het ziekenhuis (OLVG). Na evaluatie werd het model geïmplementeerd in de ziekenhuisomgeving via het elektronisch patiëntendossier (Epic Hyperspace, Epic Systems Corporation). Hierbij werden de standaard ontwikkeltools van Epic gebruikt.
Externe audit
In een latere fase werd een externe MDR-expert uitgenodigd om een audit uit te voeren op het volledige QMS in binnen het ziekenhuis. Het doel was om de implementatie van het QMS te toetsen en te beoordelen of het systeem voldoet aan de ISO13485:2016-norm. Tijdens deze audit werden enkele technische dossiers bekeken, waaronder dat van het voorspelmodel. Dit leverde extra inzichten op over de toepasbaarheid van het QMS op medische software.
Resultaten
Het grootste deel van de 32 (sub)elementen van het QMS werd vooraf als toepasbaar beschouwd voor het softwareontwikkelingsproject. Slechts 6 van de 32 (19%) werden vooraf als niet van toepassing beoordeeld. Tijdens het verzamelen van de vereiste documentatie bleken nog vier andere subelementen niet van toepassing te zijn op dit specifieke softwareproject.
De standaarddocumentatie van het data science-team, gebaseerd op CRISP-DM, bevatte veel van de benodigde informatie, maar deze informatie was verspreid over meerdere documenten. We kozen ervoor om deze documenten niet om te zetten naar de standaard QMS-formats, maar controleerden of ze volledig waren en voldeden aan de MDR-eisen.
- Voor 32% van de benodigde documenten was de bestaande documentatie volledig en bruikbaar.
- Voor 23% was de documentatie onvolledig en werd aanvullende informatie toegevoegd.
- Voor 45% ontbrak de documentatie volledig, en werden standaardformats uit het QMS gebruikt.
Aangezien het model werd geïmplementeerd binnen Epic, waren sommige keuzes vooraf bepaald (zoals onderhoudsschema, weergave van het modelresultaat, en validatie na updates). Hiervoor was dus geen extra documentatie nodig.
De externe auditor concludeerde dat het technische dossier een goede basis vormde, en dat het gebruik van Epic een veilige ontwikkelomgeving bood. Wel werden vragen gesteld over de validatie van de software en de uitkomsten, omdat normen als IEC62304 en EN82304 niet waren gebruikt. De auditor erkende echter ook dat geharmoniseerde normen binnen de MDR nog beperkt zijn.
Discussie en conclusie
Over het algemeen bleek het QMS, bedoeld voor fysieke medische hulpmiddelen, ook geschikt voor medische softwareontwikkeling. Sommige onderdelen, zoals verpakking, etikettering en transport, zijn duidelijk bedoeld voor fysieke producten, maar het merendeel van de elementen (83%) is ook bruikbaar voor software.
Dit werd bevestigd tijdens én na het project. Slechts vier extra elementen bleken achteraf toch niet van toepassing. Twee daarvan hadden betrekking op training van ontwikkelaars; omdat zij al werkten binnen de Epic-omgeving en bekend waren met de werkwijze, werd extra training overbodig geacht.
Het voorspelmodel was het eerste medische softwareproject van het data science-team. De CRISP-DM-methodologie werd gebruikt voor ontwikkeling en documentatie. Veel van de stappen in CRISP-DM komen overeen met de eisen van ISO13485, al biedt deze norm een bredere organisatiebrede kwaliteitsaanpak. Daardoor ontbraken er nog documenten binnen het data science-team die wel vereist zijn door ISO13485.
Daarnaast legde de ontwikkelomgeving (Epic) beperkingen op: hoewel ontwikkeling en validatie buiten Epic gebeuren, wordt de implementatie bepaald door Epic-richtlijnen (zoals dataformaten en datastromen). Deze richtlijnen zijn opgenomen in de werkwijze van de data scientists.
De documentatie uit CRISP-DM/Epic week af van de QMS-formats, maar bevatte dezelfde informatie. Door deze niet om te zetten naar de standaardformats, werd het verzamelen van documentatie aanzienlijk makkelijker. Dit laat zien dat de inhoud belangrijker is dan de vorm. De MDR schrijft een passend QMS voor, maar definieert dat niet concreet — dat biedt ruimte voor maatwerk. Tegelijkertijd helpen formats om te waarborgen dat documentatie voldoet aan de regelgeving.
Bij het ontwikkelen van in-huis medische software is het belangrijk om eerst de beschikbare richtlijnen van de ontwikkelomgeving te checken. Zijn die er niet, dan moet het ziekenhuis eigen richtlijnen opstellen. Standaarden zoals ISO13485, IEC62304 en methoden zoals CRISP-DM bieden hiervoor houvast.
De externe auditor stelde vragen over validatie van zowel de software als de resultaten, omdat de IEC62304 niet was gebruikt. Deze norm is specifiek voor medische software, terwijl de ISO13485 breder toepasbaar is op alle medische hulpmiddelen. Echter, de elementen van IEC62304 zijn wél opgenomen in ISO13485 — zoals validatie van het hulpmiddel en de resultaten — en maken dus onderdeel uit van ons QMS.
Daarnaast is validatie ook een onderdeel van de evaluatiefase in de CRISP-DM-methodologie. Als ziekenhuis kozen we bewust voor één QMS voor alle in-huis ontwikkelde hulpmiddelen, in plaats van aparte systemen voor software en fysieke producten. Daarom onderzochten we of het bestaande, ISO13485:2016-gebaseerde QMS in combinatie met CRISP-DM zou volstaan — ook al biedt IEC62304 meer specifieke richtlijnen voor softwareontwikkeling. CRISP-DM voorziet echter in vergelijkbare ontwikkelstappen.
We hebben aangetoond dat het mogelijk is om een QMS, ontwikkeld voor fysieke medische producten, succesvol toe te passen op medische software — mits er een gestructureerde ontwikkelmethodiek wordt gebruikt. De CRISP-DM-methodologie alleen is niet voldoende om aan alle wet- en regelgeving voor medische software te voldoen. Afdelingen die software ontwikkelen met CRISP-DM moeten overwegen om daarnaast een QMS te implementeren dat is gebaseerd op relevante IEC- en/of ISO normen.
Literatuur
- [1] V. Lagerburg, M. van den Boorn, R. F. Crane, K. Welvaars, and J. M. Groen, “Applying and validating a quality management system for in-house developed medical software,” Front. Digit. Heal., vol. 7, no. April, 2025.
- [2] THE EUROPEAN PARLIAMENT AND THE COUNCIL OF THE EUROPEAN UNION, “Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC (Text with EEA relevance. ).” 05-Apr-2017.
- [3] THE COUNCIL OF THE EUROPEAN COMMUNITIES, “Council Directive 93/42/EEC of 14 June 1993 concerning medical devices.” 12-Jul-1993.
- [4] Medical Device Coordination Group, “MDCG 2023-1-Guidance on the health institution exception under Article 5(5) of Regulation (EU) 2017/745 and Regulation (EU) 2017/746 – January,” pp. 1–10, 2023.
- [5] K. Willemsen, R. Nizak, H. J. Noordmans, R. M. Castelein, H. Weinans, and M. C. Kruyt, “Challenges in the design and regulatory approval of 3D-printed surgical implants: a two-case series,” Lancet Digit. Heal., vol. 1, no. 4, 2019.
- [6] R. Bartels, J. Dudink, S. Haitjema, D. Oberski, and A. van ‘t Veen, “A Perspective on a Quality Management System for AI/ML-Based Clinical Decision Support in Hospital Care,” Front. Digit. Heal., vol. 4, 2022.
- [7] F. Zanca, C. Brusasco, F. Pesapane, Z. Kwade, R. Beckers, and M. Avanzo, “Regulatory Aspects of the Use of Artificial Intelligence Medical Software,” Seminars in Radiation Oncology, vol. 32, no. 4. 2022.
- [8] R. Beckers, Z. Kwade, and F. Zanca, “The EU medical device regulation: Implications for artificial intelligence-based medical device software in medical physics,” Phys. Medica, vol. 83, 2021.
- [9] E. Niemiec, “Will the EU Medical Device Regulation help to improve the safety and performance of medical AI devices?,” Digit. Heal., vol. 8, 2022.
- [10] Technical Committee : ISO/TC 210, “ISO 14971:2019 Medical devices — Application of risk management to medical devices.” Dec-2019.
- [11] A. A. Verma et al., “Implementing machine learning in medicine,” CMAJ, vol. 193, no. 34, 2021.
