医疗器械软件设计验证和过程确认

有趣的永 2015-11-20

展开全文

本文主要针对国家局最新发布的《医疗器械软件注册技术指导原则》并结合软件相关的国家及行业标准，介绍医疗器械软件的定义及分类、设计开发过程验证及确认、风险管理的要求。

一医疗器械软件术语定义及分类

1、独立软件：预期本身用作医疗器械而开发的软件，即：作为医疗器械或其附件的软件；

2、软件组件：在被开发医疗器械内的已开发的软件，即：作为医疗器械或其部件、附件组成的软件

注1：嵌入式系统 < 可编程医用电气系统 = 软件组件；

注2：医疗器械软件 < 医用软件（医疗软件）；

注3：软件组件管理类别与医疗器械产品相同。

3、独立软件应同时具备以下三个特征：具有一个或多个医疗用途，无需医疗器械硬件即可完成预期用途，运行于通用计算平台，包括如下：

1）独立软件包括通用型软件和专用型软件，其中通用型软件基于通用数据接口与多个医疗器械产品联合使用，如：PACS、中央监护软件等；

2）专用型软件基于通用、专用的数据接口与特定医疗器械产品联合使用，如Holter数据分析软件、眼科显微镜图像处理软件等。

4、软件组件应同时具备以下两个特征：具有一个或多个医疗用途，控制（驱动）医疗器械硬件或运行于专用（医用）计算平台。软件组件包括嵌入式软件和控制型软件，如下：

1）嵌入式软件（即固件）运行于专用（医用）计算平台，控制（驱动）医疗器械硬件，如心电图机所含软件、脑电图机所含软件等；

2）控制型软件运行于通用计算平台，控制（驱动）医疗器械硬件，如CT图像采集工作站软件、MRI图像采集工作站软件等。

5、软件组件也可兼具处理功能。专用型独立软件可单独注册（作为 6870 软件），也可随医疗器械产品注册，此时视为软件组件，软件组件注册一般会作为其它器械分类，如：6821 医用电子仪器设备。

图1 软件对应的标准关系

图2 独立软件与软件组件的区别

二软件类型及架构

1、软件的类型判定

图3 软件的类型判定

2、软件的体系结构

图4 软件的体系结构

3、软件硬件关系

三软件设计开发

1、软件开发过程包括需求分析、设计、编码、集成、测试(临床验证) 等活动，YY/T 0664 给出了软件开发过程和活动的示意图，这些过程与 Y Y/ T 0287 标准“ 7．3 设计和开发 ” 的对应关系, 具体见以下：

序号	YY/T 0287体系条款	对应软件过程	相关内容	形成的技术文档（举例）
1	7.3.1 设计和开发策划	软件开发策划	需求分析、设计和开发、编码、集成、测试、验收等各项活动的输入、输出、验证、管理和支持等需求分析、设计和开发、编码、集成、	可行性分析报告（FAR）
				软件开发计划（SDP）
2	7.3.2 设计和开发确认	软件需求分析	可由功能、性能、质量、相关的安全要求和系统设计限制来确定，或由原型等技术导出等	软件需求规格说明（SRS）
				数据需求说明（DRD）
				接口需求规格说明（IRS）
3	7.3.3 设计和开发输出	软件结构设计	应当按照预定的或选定的方法予以定义并形成文档。	软件结构设计说明（SDD)
		软件详细设计		软件详细设计说明（SDD）
		软件单元实现		接口设计说明（IDD)
		软件集成		数据库（顶层）设计说明（DBDD)
				开发进度月报（DPMR）
				项目开发总结报告（PDSR）
				软件用户手册（SUM）
4	7.3.4 设计和开发评审	评审	应当考虑可行性、安全性、编程规则以及可测试等准则	评审记录
5	7.3.5 设计和开发验证	单元测试	可包括对设计和开发输出的评审、分析、演示。	软件测试计划（STP）
		集成测试		软件测试说明（STD）
		系统测试		软件测试报告（STR）
6	7.3.6 设计和开发确认	系统测试	在提交顾客验收之前，按规定预期用途对软件的运行进行确认。	STP、STD、STR
		验收测试		验收报告
		临床验证		临床评价或验证报告
7	7.3.7 设计和开发更改的控制	回归测试	————	STP、STD、STR
		配置管理		变更记录
				软件版本说明（SVD)

四、医疗器械软件设计验证及确认

1、通过提供客观证据来认定软件某开发阶段的输出符合该阶段全部输入要求

注：包括正式技术评审、可追溯性分析、单元测试、集成测试、系统测试、回归测试等活动医疗器械软件设计确认；

2、通过提供客观证据来认定软件符合用户需求和预期用途；

注：主要指用户测试（真实或模拟使用环境测试），也包括质量管理、风险管理和软件工程等活动；

A级：系统测试、用户测试的测试计划和报告摘要；

B级：系统测试、用户测试的测试计划和报告摘要，概要介绍开发各阶段的验证活动，其中单元测试应描述覆盖率，集成测试应描述集成策略；

C级：在B级基础上提供系统测试、用户测试的测试计划和报告全文。

注意：

①验证活动可与生存周期合并描述；

②如必要应提供可追溯性分析报告；

③软件维护升级只有回归测试报告。

3、软件的测试贯穿于软件的生存周期（见图7），按阶段可分为单元测试、集成测试、配置项测试、系统测试和验收测试，企业可根据软件的规模、类型、完整性和安全性级别来选择执行的测试类别。软件测试过程一般包括测试策划、测试设计、测试执行和测试总结四项活动。GB/T 15532 标准规定了软件的测试方法、过程和准则，GB/T 9386 标准规定了软件测试文档的格式和要求，企业在进行软件测试时，应符合标准的要求。

4、医疗器械软件测试

1）单元测试

a）静态测试：代码检查、结构分析；

b）动态测试：逻辑覆盖（语句、判定、条件、多条件等）

2) 集成测试

a）自顶向下、自底向上、混合方式；

3) 系统测试

a）安装测试、配置测试；

b）功能测试；

c）性能测试、负载测试、压力测试、并发性测试、兼容性测试、接口测试、可靠性测试、恢复性测试；

d）界面测试、可用性测试；

e）安全性测试。

4）回归测试

a) 用于确定软件更改没有产生不良影响或没有引入新缺陷；

b) 软件如有变更均需进行适当且足够的回归测试。

5、软件验证与确认

验证是指通过提供客观证据认定软件某开发阶段的输出满足输入要求，包括代码检查、设计评审、测试等质量保证活动。确认是指通过提供客观证据认定软件满足用户需求和预期用途，通常是指在真实或模拟使用环境进行的用户测试。可追溯性分析是指追踪需求规范、设计规范、源代码、测试、风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。

A级提供系统测试、用户测试的计划和报告摘要，描述测试的条件、工具、方法、通过准则和结果。

B级提供系统测试、用户测试的计划和报告，概述开发各阶段的验证活动，描述所用的工具、方法和任务。

C级在B级基础上提供可追溯性分析报告（追溯需求规范、设计规范、测试、风险管理的关系表）。

系统测试和用户测试的计划和报告另附原始文件。测试报告关于测试记录的内容可以提供一个测试记录样例和完整的测试记录清单。验证活动也可提交制造商软件质量保证计划文件，用于替代相应描述。

6、生存周期：开发各阶段的质控措施与安全性级别是否匹配，可参考YY/T 0664-2008中附录A系统测试报告：首先关注需求规格是否经过全部测试，其次关注核心功能的测试情况用户测试报告：用户反馈的问题，软件可用性可追溯性分析报告：关注需求、设计、测试、风险是否匹配且完整。

图7 医疗器械软件生存周期过程图

7、软件质控原则

① 过程质控与产品质控相结合；

② 尽早质控与重点质控相结合；

③ 变更管理与缺陷管理相结合。

8、软件工程

① 生存周期：需求、设计、编码、测试、维护（见图7）；

② 阶段审评：正式评审、测试、可追溯性分析（见图8）；

③ 产品控制：配置管理、缺陷管理、风险管理（见图9）。

图8 可追溯性分析

图9 软件管理缺陷流程图

9、医疗器械设备（软件组件）验证

医疗器械软件组件类验证主要包括三个重要部分：Installation Qualification（安装确认）、Operation Qualification（运行确认）、Performance Qualification（性能确认）

1）安装确认（IQ)。

所有设备确认都始于安装确认，安装确认保证加工组件或器械的设备被正确安装，并符合工厂电气和环境控制的要求。安装确认要求在适合的地点下必须正确安装设备，适合的地点条件包括齐全的水电供应以及足够设备操作的空间，同时附属条件还包括设备对所在的环境的适应能力、设备操作人员的专业技术水平、设备验证是否确认更新、设备验证参数是否完成校准等等。当逐项完成检查后，则说明安装确认已经完成。同时，必须在安装确认的后部分工作时，给出一份含有设备参数检验的信息表的培训表给到操作人员。

2）运行确认(OQ)。

设备安装完成后，下一步就是运行确认，安装确认后所进行的运行确认要求必须在验证过程中找到参数区间，其必须是连续、稳定地符合检验的目标产品的预定参数区间（不能采用参数点。因为对于一般所使用的设备，其时间、温度、压力及其它因素都对设备运行结果产生影响，故运行确认是包装验证的核心环节。

3）性能确认(PQ)。

性能确认通常要求运行3个批次。性能确认应采用运行确认（OQ）所确定的参数，这些参数经过100%验证性能确认对Design Of Experiment所选用的参数区间的要求是：Design Of Experiment必须保证其在大规模的生产医疗器械时能够连续且稳定地生产出合格的产品。从另一层意义上来说，性能确认就像是一个专门控制目产品的质量稳定的部分。通常工作人员是将连续生产出来的前3个批次的产品，按照预定的样品量和AQL取出样本并按照运行确认的检测方法以及检测项目进行监测工作，得出性能确认报告，最后为整个设备的验证是否合格提供了判断依据。

五、软件风险管理

1、软件安全性级别：

A级：不可能对健康有伤害或损害；

B级：可能有不严重的伤害；

C级：可能死亡或严重伤亡；

2、软件安全性级别应结合软件的预期用途、使用环境和核心功能（软件在预期使用环境完成预期用途所必需的功能）进行判定。其中预期用途主要考虑软件的临床用途（如诊断、治疗、监护、筛查等）和重要程度（如重要作用、辅助作用、补充作用等），使用环境主要考虑软件的使用场所（如医院、家庭等）、疾病类型（如严重性、紧迫性、传染性等）、患者人群（如成人、儿童、老年、女性等）和用户类型（如专业用户、普通用户、患者等），核心功能主要考虑软件的功能类型（如控制驱动、处理分析等）、实现方法（如CT图像重建采用滤波反投影算法还是迭代算法，异常识别采用常规图像处理算法还是人工智能算法等）和复杂程度（如算法规模、参数数量、运算速度等）。

3、软件安全性级别也可根据风险管理所确定的风险等级进行判定，软件安全性级别与风险等级的分级可以不同，但二者存在对应关系，因此可根据风险等级来判定软件安全性级别。

制造商应在采取风险缓解措施之前判定软件安全性级别，并结合质量管理体系要求，建立与软件安全性级别相匹配的软件生存周期过程，包括软件开发过程、软件维护过程、配置管理过程、风险管理过程和问题解决过程。同时，制造商可采用良好软件工程实践完善质量管理体系要求，保证软件质量。另外，制造商应保证软件自身的信息安全，确保健康数据的保密性、完整性和可得性。

图10 软件安全性级别