Vera Lagerburg, Michelle van den Boorn, Reinier F Crane, Koen Welvaars, Jaap M Groen
{"title":"Applying and validating a quality management system for in-house developed medical software.","authors":"Vera Lagerburg, Michelle van den Boorn, Reinier F Crane, Koen Welvaars, Jaap M Groen","doi":"10.3389/fdgth.2025.1461107","DOIUrl":null,"url":null,"abstract":"<p><strong>Introduction: </strong>The legislation regarding in-house development of medical devices has changed substantially with the introduction of the Medical Device Regulation (MDR) in 2021. Practical guidelines regarding the implementation of a quality management system for in-house developed medical software are scarce. In this article, we describe our experience with fulfilling the requirements of the MDR for an in-house developed prediction model, qualified as medical software.</p><p><strong>Methods and materials: </strong>Our quality management system (QMS) is based on the ISO13485:2016. It is a workflow consisting of elements subdivided in subelements, which consist of procedures, work instructions and/or formats. Within the data science team procedures regarding the process and documentation of software development were already in place. The existing procedures and documentation were compared with the procedures of the QMS and where possible, integrated into the workflow. The gap between the existing procedures regarding software development and the procedures of the QMS was defined. Existing documentation and procedures were used as much as possible. If there was a gap, additional documentation was written.</p><p><strong>Results: </strong>The majority of the (sub)elements was considered to be applicable for our software development project beforehand. Only in 6 out of 32 cases (19%), the (sub)element was deemed not applicable. For 32% of the applicable elements the documentation of the data scientists team was sufficient and additional information was not needed. For 23% the documentation was incomplete and we decided to add relevant information to fulfil the requirements of the MDR and for 45% the documentation was completely lacking and the standard formats were used.</p><p><strong>Conclusion: </strong>We showed in this article that it is possible to use a QMS developed with physical medical products in mind for medical software and thus comply with applicable legislation and regulations. This can be done without too much effort when there is already some structured form of software development methodology in place.</p>","PeriodicalId":73078,"journal":{"name":"Frontiers in digital health","volume":"7 ","pages":"1461107"},"PeriodicalIF":3.2000,"publicationDate":"2025-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"https://www.ncbi.nlm.nih.gov/pmc/articles/PMC11996894/pdf/","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Frontiers in digital health","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.3389/fdgth.2025.1461107","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"2025/1/1 0:00:00","PubModel":"eCollection","JCR":"Q1","JCRName":"HEALTH CARE SCIENCES & SERVICES","Score":null,"Total":0}
引用次数: 0
Abstract
Introduction: The legislation regarding in-house development of medical devices has changed substantially with the introduction of the Medical Device Regulation (MDR) in 2021. Practical guidelines regarding the implementation of a quality management system for in-house developed medical software are scarce. In this article, we describe our experience with fulfilling the requirements of the MDR for an in-house developed prediction model, qualified as medical software.
Methods and materials: Our quality management system (QMS) is based on the ISO13485:2016. It is a workflow consisting of elements subdivided in subelements, which consist of procedures, work instructions and/or formats. Within the data science team procedures regarding the process and documentation of software development were already in place. The existing procedures and documentation were compared with the procedures of the QMS and where possible, integrated into the workflow. The gap between the existing procedures regarding software development and the procedures of the QMS was defined. Existing documentation and procedures were used as much as possible. If there was a gap, additional documentation was written.
Results: The majority of the (sub)elements was considered to be applicable for our software development project beforehand. Only in 6 out of 32 cases (19%), the (sub)element was deemed not applicable. For 32% of the applicable elements the documentation of the data scientists team was sufficient and additional information was not needed. For 23% the documentation was incomplete and we decided to add relevant information to fulfil the requirements of the MDR and for 45% the documentation was completely lacking and the standard formats were used.
Conclusion: We showed in this article that it is possible to use a QMS developed with physical medical products in mind for medical software and thus comply with applicable legislation and regulations. This can be done without too much effort when there is already some structured form of software development methodology in place.