01范围和原则

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

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

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

独立软件：

法规：作为医疗器械或附件的软件，可单独注册；

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

软件组件：

法规：作为医疗器械或部件、附件组成的软件，随医疗器械注册；

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

03设计开发

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

04软件生存周期过程 

• 过程—活动—任务 

• 基本过程 

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

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

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

陷风险均可接受 

– 配置管理：识别配置项，控制变更 

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

– 符合标准YY/T 0664-2020 医疗器械软件 软件生存周期过程（IEC 62304:2015）

05软件风险管理 

• 概述

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

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

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

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

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

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

• 常用方法 

– 故障树分析（FTA） 

– 失效模式和效应分析（FMEA）

06软件可追溯性分析 

• 定义 

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

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

完整性和准确性 

• 活动 

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

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

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

07软件测试及验证

08软件确认  

• 定义 

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

• 软件确认活动 

– 软件验证活动 

– 软件可追溯性分析 

– 用户测试 

– 临床评价 

– 评审

09软件更新

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

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

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

10缺陷管理

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

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