医疗器械GMP附录解读 |独立软件之设计开发部分

fireworks
fireworks 这家伙很懒,还没有设置简介

0 人点赞了该文章 · 734 浏览

2019年7月5日为加强独立软件类医疗器械生产监管,规范独立软件生产质量管理,根据《医疗器械监督管理条例》(国务院令680号)、《医疗器械生产监督管理办法》(国家食品药品监督管理总局令第7号),国家药品监督管理局组织起草了《医疗器械生产质量管理规范附录独立软件》,本文将其中的设计开发部分内容进行解读。

01 范围和原则

本附录适用于独立软件,软件组件参照执行。

意味着不仅是独立软件,软件组件的生产企业也要考虑梳理管理体系包含研发文件,参考相关内容进行完善。

02 医疗器械独立软件和软件组件

独立软件:

法规:作为医疗器械或附件的软件,可单独注册;

技术:具有医疗用途、无需医疗器械硬件即可完成自身预期用途、运行于通用计算平台。

软件组件:

法规:作为医疗器械或部件、附件组成的软件,随医疗器械注册;

技术:具有医疗用途、控制/驱动医疗器械硬件或运行于医用计算平台。

03 设计开发

应当结合软件生存周期模型特点建立软件生存周期过程控制程序并形成文件,确定软件开发策划、软件需求分析、软件设计、软件编码、验证与确认、软件更新、风险管理、 缺陷管理、可追溯性分析、配置管理、文件与记录控制、 现成软件使用、网络安全保证、软件发布、软件部署、软件停运等活动要求。

04 软件生存周期过程

• 过程—活动—任务

• 基本过程

– 软件开发:开发策划、需求分析、设计、编码、测试

– 软件维护:软件更新/软件变更

– 风险管理:基于损害严重度分析,保证软件已知剩余缺

陷风险均可接受

– 配置管理:识别配置项,控制变更

– 缺陷管理:软件缺陷修复属于设计变更

– 符合标准YY/T 0664-2008 医疗器械软件 软件生存周期过程(IEC 62304:2006)

05 软件风险管理

• 概述

– 软件本身不是危害,但会引发危害处境

– 软件风险管理通常基于损害严重度实施

– 软件失效表现为随机性,但实为系统性

– 软件组件孤立进行风险管理是不合适的

– 风险管理应贯穿于软件生存周期全过程

– 软件确认应保证软件已知剩余缺陷风险均可接受

• 常用方法

– 故障树分析(FTA)

– 失效模式和效应分析(FMEA)

06 软件可追溯性分析

• 定义

– 追踪软件需求、软件设计、源代码、软件测试、软件风

险管理之间的关系,分析已识别关系的正确性、一致性、

完整性和准确性

• 活动

– 需求分析:软件需求—风险管理、软件需求—产品需求

– 设计:软件设计—软件需求

– 编码:源代码—软件设计、源代码—测试用例

07 软件测试及验证

08 软件确认

• 定义

– 通过提供客观证据认定软件满足用户需求和预期目的

• 软件确认活动

– 软件验证活动

– 软件可追溯性分析

– 用户测试

– 临床评价

– 评审

09 软件更新

-软件更新涵盖从计划、方案、测试、风险管理等整个过程的文件进行更新;

-软件版本变更应符合管理文件,保留更新记录。

-软件更新后根据更新的类型、内容和程度进行验证和确认。

10 缺陷管理

-软件缺陷管理应当形成文件,确定软件缺陷评估、软件缺陷修复、回归测试、风险管理、配置管理、评审等活动要求,形成软件缺陷分析报告以供评审。

使用缺陷管理工具保证软件质量,并贯穿于软件生存周期全过程,保存相关记录。

发布于 2024-01-23 12:52

免责声明:

本文由 fireworks 发布于 质量人 ,著作权归作者所有。

登录一下,更多精彩内容等你发现,贡献精彩回答,参与评论互动

登录! 还没有账号?去注册

暂无评论