应用和验证内部开发的医疗软件的质量管理体系。

IF 3.2 Q1 HEALTH CARE SCIENCES & SERVICES
Frontiers in digital health Pub Date : 2025-04-01 eCollection Date: 2025-01-01 DOI:10.3389/fdgth.2025.1461107
Vera Lagerburg, Michelle van den Boorn, Reinier F Crane, Koen Welvaars, Jaap M Groen
{"title":"应用和验证内部开发的医疗软件的质量管理体系。","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":"{\"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}","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

摘要

导言:随着2021年医疗器械法规(MDR)的引入,有关医疗器械内部开发的立法发生了重大变化。关于内部开发的医疗软件实施质量管理体系的实用指南很少。在本文中,我们描述了我们为内部开发的预测模型(合格的医疗软件)满足MDR要求的经验。方法和材料:我们的质量管理体系(QMS)基于ISO13485:2016。它是一个工作流,由细分为子元素的元素组成,子元素由过程、工作指令和/或格式组成。在数据科学团队中,关于软件开发过程和文档的程序已经到位。将现有的程序和文件与质量管理体系的程序进行比较,并在可能的情况下集成到工作流程中。定义了现有软件开发程序与质量管理体系程序之间的差距。尽可能使用现有的文件和程序。如果存在空白,则编写额外的文档。结果:大多数(子)元素被认为是预先适用于我们的软件开发项目的。只有在32个案例中的6个(19%)中,(子)元素被认为不适用。对于32%的适用元素,数据科学家团队的文档就足够了,不需要额外的信息。对于23%的文档不完整,我们决定添加相关信息以满足MDR的要求,对于45%的文档完全缺乏,并使用标准格式。结论:我们在本文中表明,在医疗软件中使用物理医疗产品开发的质量管理体系是可能的,因此符合适用的法律法规。当已经有一些结构化的软件开发方法时,这可以不需要太多的努力就可以完成。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
Applying and validating a quality management system for in-house developed medical software.

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.

求助全文
通过发布文献求助,成功后即可免费获取论文全文。 去求助
来源期刊
CiteScore
4.20
自引率
0.00%
发文量
0
审稿时长
13 weeks
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术官方微信