医疗器械软件申报基本要求.ppt

《医疗器械软件申报基本要求.ppt》由会员分享，可在线阅读，更多相关《医疗器械软件申报基本要求.ppt（128页珍藏版）》请在三一文库上搜索。

1、医疗器械软件申报基本要求,审评一处 彭亮 2011.8,内容摘要,失效案例与召回分析 软件与软件工程概述 软件主要标准介绍 软件监管情况综述 软件申报资料要求 软件申报注意事项,1 失效案例与召回分析,软件失效案例 FDA召回分析,1.1 软件失效案例,直线加速器 19851987年，Therac-25加速器因软件失效导致6人受到超剂量辐射，其中3人死亡，1人截肢 2001年，加速器因软件和操作错误导致巴拿马5人死亡 起搏器和ICD 起搏器典型代码行数为80000行 19902000年， 起搏器召回的41%与软件失效有关 19972003年，美国至少有212人因ICD失效而死亡 2008年，美

2、国约使用350000个起搏器和140000个ICD,1.1 软件失效案例,输液泵 输液泵典型代码行数为170000行 1997年，Gish公司输液泵因软件逻辑错误引起吗啡过量输入，导致1人死亡 2006年，Cardinal公司静脉输液泵因软件设计缺陷引起输液过量，导致2人死亡，其中1人是出生仅16天的婴儿，被注入了44.8ml营养液，而处方仅为4.8ml 20052009年，FDA收到约56000条输液泵抱怨记录，其中710人死亡 I级召回 2007年，FDA有3例I级召回与软件失效有关（共23例） 2009年，2例手术导航和1例镇痛泵因软件失效I级召回,1.2 FDA召回分析,1983199

3、1 共召回2792个，软件失效165个，占总数5.9% 19921998 共召回3140个，软件失效242个，占总数7.7% 其中软件变更导致召回192个，占软件失效79.3% 19992005 共召回3771个，软件失效425个，占总数11.3% 其中内含软件器械共召回1261个，占总数33.4%，软件失效占内含软件器械召回33.7%,1.2 FDA召回分析,麻醉类：麻醉机、呼吸机 心脏类：起搏器、除颤仪 通用类：监护仪、输液泵 诊断类：生化仪、病理仪,影像类：X射线类（诊断、治疗）、磁共振、超声 手术类：电刀、激光类 其他类：含妇产科和眼科,1.2 案例与召回,软件失效足以致命，且所占比例

4、较高 软件失效增速高于医疗器械整体情况 内含软件器械召回1/3与软件失效有关 软件变更是导致软件失效的主要原因 影像类器械的软件失效问题最为突出,2 软件与软件工程概述,软件概述 软件工程概述 软件质量概述,2.1 软件概述,定义 软件是程序、数据和文档的集合 程序 = 算法 + 结构 分类（GB/T 13702-1992） 系统软件：操作系统、实用程序、网络系统 支持软件：开发工具、管理工具、数据库管理系统 应用软件：数据图像、控制类、辅助类、安全保密 基本特点 复杂性：不同输入不同执行路径，人为因素无处不在 灵活性：同一需求多种实现方式，后续变更容易快速,2.1 算法概述,定义 在有限步骤

5、内解决问题的一系列明确指令 特征 输入项：一个算法必须有零个或多个输入 输出项：一个算法必须有一个或多个输出 明确性：算法每一步骤必须有确切的定义 有限性：算法必须在有限步骤内完成任务 有效性：每一步骤可分解为基本运算步骤 复杂度 时间复杂度、空间复杂度,2.1 软硬件差异,硬件是物理实体，软件是逻辑关系 硬件变更周期长，软件变更容易快速 硬件有磨损现象，软件虽无磨损，但有退化现象 硬件质量取决于设计、开发和生产，软件质量取决于设计和开发，与生产基本无关 硬件失效先有征兆再发生，软件失效没有征兆突然发生，软件失效率远高于硬件（100：1） 硬件部件可以标准化，软件组件标准化较为复杂 细微变更对

6、硬件影响有限，对软件影响可能严重,2.2 软件危机,对开发进度和成本的估计常常很不准确 用户对交付软件不满意的现象常常发生 软件产品质量往往靠不住 软件常常是不可维护的 软件没有合适的文档资料 软件成本占计算机总成本的比例逐年上升 软件生产率增速远远跟不上硬件性能增速,2.2 软件工程基本原理,用分阶段的生存周期过程严格管理 坚持进行阶段审评 实行严格产品控制 采用现代程序设计技术 结果应能清楚审评 开发小组人员应少而精 承认不断改进软件工程实践的必要性,2.2 软件生存周期,体系结构设计,详细设计,系统测试,需求分析,集成测试,编码,运行维护,废弃,发行安装,开发策划,配置管理 缺陷管理,单

7、元测试,2.2 生存周期模型,瀑布模型,增量模型,2.2 生存周期模型,快速原型模型,螺旋模型,2.2 生存周期模型,V模型,W模型,2.2 软件测试,分类 黑盒测试、白盒测试（静态测试、动态测试） 单元测试、集成测试、系统测试 内部测试、用户测试、第三方测试 方法 白盒测试：代码检查、静态结构、静态质量、基本路径覆盖、逻辑覆盖（语句、判定、条件、多条件） 黑盒测试：等价类、边界值、场景法、因果图、正交试验、判定表、随机测试、功能分解、错误推测,2.2 软件测试,系统测试 安装性测试、兼容性测试 功能测试 性能测试、负载测试、压力测试、并发性测试、配置测试、接口测试、可靠性测试、恢复性测试 可

8、用性测试、界面测试 安全性测试 回归测试 用于确定软件更改没有产生不良影响或没有引入新缺陷 软件如有变更均需进行适当且足够的回归测试,2.2 软件维护,分类 完善型：提高软件功能、性能的变更 纠正型：纠正软件缺陷的变更 适应型：改变软件运行环境的变更 统计数据 完善型5066%、纠正型1721%、适应型1825% 维护费用占软件生存周期总成本的5080% 具体要求 软件维护应进行适当且足够的回归测试 工作量取决于变更的组件、类型和运行环境 工作量也取决于原有开发文档的详尽程度,2.2 软件文档,2.2 软件与软件工程,2.3 软件质量概述,名称 Bug、缺陷、错误、故障、失效、异常 根源 软件

9、若超过169行可执行代码无法确保完全正确 软件测试由于时间和成本限制不能遍历所有路径 属性 软件缺陷与生俱来，不可避免，也无法根除 现有已知方法不能保证任何软件100% 质量 原则 尽早测试、重点测试、全面测试,2.3 复杂度与测试,公式 软件复杂度 = NIOP N为软件类型，I为输入次数，O为输出次数，P为指数 举例 假设N=1，P=2，输入2个参数，输出2个参数，每个参数均为8位数据，执行一次测试耗时1毫秒，则测试所有参数组合耗时为： 282（282）2/（103360024365）8925年 假设用户名为10位数字和字母组合，字母区分大小写，测试一个用户名耗时1纳秒，则测试所有用户名耗

10、时为： （10+262）10/（109360024365）26年,2.3 缺陷来源,2.3 统计数据,时间比例 需求设计1/3，编码1/6，测试1/2 起源阶段 需求54%，设计25%，编码15%，其他6% 修正成本 设计：编码：测试：发布=1：6.5：15：60100 退化现象 每修正25个缺陷就会产生1个新缺陷 群集现象 “80%”的缺陷集中于“20%”的程序,2.3 影响因素,计划和资源 语言 工具和方法 文档 复杂性 环境 人员培训 组织形式,需求转换和可追溯性 测试方法 维护 现有软件原型 现有类似软件 质量特征 设计参数折中,2.3 质量度量,分类 产品度量：用于描述产品特征和质量

11、水平 项目度量：用于描述项目特性和执行状态 过程度量：用于开发和维护过程的优化改进 过程度量 需求分析度量：功能点度量 设计度量：形态度量、界面度量 源代码度量：规模度量、Halstead度量 测试度量：DRE度量 维护度量：SMI度量,2.3 生存周期质量,2.3 质量体系与模型,质量体系 ISO 90003（GB/T 19003） CMM / CMMI SPICE（ISO/IEC 15504） 质量模型 Boehm模型：功能要求、可维护性、可移植性 McCall模型：产品运行、产品修改、产品转移 ISO 9126模型：功能性、可靠性、易用性、效率、维护性、可移植性,2.3 质量特性与测试,

12、3 软件标准介绍,软件标准概述 YY/T 0664介绍 YY/T 0708介绍 GB/T 25000.51介绍 DICOM与HL7简介,3.1 软件标准概述,IEC 62304：2006（ YY/T 0664-2008） IEC 60601-1-4：2000（YY/T 0708-2009） IEC 61508系列7标准（GB/T 20438系列） IEC 62274：2005（YY 0721-2009） ISO/IEC 9126系列4标准（GB/T 16260系列） ISO/IEC 14598系列6标准（GB/T 18905系列） ISO/IEC 25051：2006（GB/T 25000.5

13、1-2010） ISO/IEC 12119:1994（GB/T 17544-1998） DICOM与HL7,3.1 软件标准概述,IEC 80001-1：2010 Application of risk management for IT-networks incorporating medical devices - part 1: roles, responsibilities and activities IEC/TR 80002-1：2009 Medical device software - Part 1: Guidance on the application of ISO 149

14、71 to medical device software IEC 82304-1 Healthcare software systems - Part 1: General requirements IEC 62366：2007 Medical devices - Application of usability engineering to medical devices,3.2 YY/T 0664介绍,背景 测试本身不足以确保软件运行的安全性 没有已知方法可保证任何软件100%安全性 目的 规定医疗器械软件的生存周期要求 通过规定过程、活动和任务，为医疗器械软件生存周期过程建立共同框架

15、作用 通过对设计、测试和验证的详尽严格的要求来增强医疗器械软件的可靠性 增强医疗器械软件的安全性和有效性,3.2 YY/T 0664介绍,范围 医疗器械软件的开发和维护 包括未知来源软件（SOUP） 医疗器械软件 在被开发医疗器械内的已开发的软件系统 预期本身用作医疗器械而开发的软件系统 未知来源软件 已经开发且通常可以得到的，并且不是用以包含在医疗器械内而开发的软件 以前开发的、不能得到其开发过程足够记录的软件,3.2 YY/T 0664介绍,要求 质量管理、风险管理和软件工程相结合 实施本标准确定的过程、活动和任务 本标准要求生成任务文件 本标准要求建立生存周期模型 注意事项 不为制造商规

16、定组织结构 不规定任务文件的特定格式 不规定特定的生存周期模型,3.2 安全性级别,严重伤害 直接或间接导致下列结果的伤害或疾病： 危及生命 造成人体功能的永久性损害或者人体结构的永久性损坏 需要内科或外科介入以防止人体功能的永久性损害或人体结构的永久性损坏 永久性 人体功能或结构的不可恢复的损害或损坏，微不足道的损害或损坏除外,3.2 安全性级别,安全性级别 A级：不可能对健康有伤害和损坏 B级：可能有不严重的伤害 C级：可能死亡或严重伤害 具体要求 制造商应赋予每个软件系统一个安全性级别并形成文档 软件系统如分解为软件项，软件项应继承原有安全性级别，除非制造商以文件形式给出理由 每个软件系

17、统被赋予安全性级别之前均应按照C级要求 安全性分级方案不期望与YY/T 0316的风险分级相一致,3.2 安全性级别,3.2 生存周期过程,过程 软件开发过程 软件维护过程 软件风险管理过程 软件配置管理过程 软件问题解决过程 过程分类 实施于所有医疗器械软件，标记为A、B、C级 实施于选定的软件项，标记为B、C级或C级,3.2 生存周期过程,开发策划,需求分析,体系结构设计,详细设计,单元实现和验证,集成和集成测试,系统测试,软件发行,制定维护 计划,问题和 修改分析,修改实施,软件危害 处境分析,风险控制 措施,软件更改 风险管理,风险控制 措施验证,配置标识,更改控制,状态记录,准备问题

18、报告,研究问题,通知相关方,应用更改程序,保持记录,分析问题趋势,验证问题解决,测试文档内容,制定维护 计划,问题和 修改分析,修改实施,制定维护 计划,问题和 修改分析,3.2 风险管理,概述* 软件本身不是危害，但会引发危害处境 软件表现为随机失效，但实为系统性失效 软件失效概率难以计算，通常基于损害严重度分析（失效概率假定为100%） 要求 软件风险管理是整个医疗器械风险管理的组成部分，孤立分析是不合适的 ISO14971没有特别阐述软件的风险控制和软件生存周期过程的风险控制，本标准对软件的风险控制提供了附加要求,3.2 风险管理,失效模式与影响分析（FMEA） 自下而上的标准的可靠性分

19、析工具 用于部件设计、部件制造和用户使用的失效分析 故障树分析（FTA） 自上而下的可靠性与安全性分析工具 采用逻辑门符号对顶事件进行图解分析 危害分析与关键控制点（HACCP） 一种识别、评价和控制危害的系统性方法 基于FDA的HACCP应用指南的七个原则,3.2 配置管理与问题解决,配置管理 内容：确定配置项，建立基线，形成文档 作用：标识软件项，控制变更，提供状态报告 问题解决 内容：分析问题，评估影响，提出变更请求 作用：解决开发、运行和维护所发现的异常,3.3 YY/T 0708介绍,背景 GB 9706.1通用标准的并列标准 基于风险管理和开发生存周期 目的 规定了可编程医用电气系

20、统设计过程的要求 作为专用标准要求的基础，包括作为降低和管理风险的安全要求指南 范围 带有可编程电子子系统的医用电气设备或医用电气系统,3.3 YY/T 0708介绍,可编程电子子系统 基于一个或多个中央处理单元的系统，包括软件和接口，简称PESS 举例（GB/T 20438.4-2006）：微处理器、微控制器、可编程控制器、专用集成电路（ASIC）、可编程逻辑控制器（PLC）、其他以计算机为基础的装置（智能传感器、变送器、执行器） 可编程医用电气系统 包含一个或多个可编程电子子系统的医用电气设备或医用电气系统，简称PEMS,3.3 嵌入式系统,定义 IEEE定义：嵌入式系统是用于控制、监视或

21、者辅助装备、机器或设备运行的装置 嵌入式系统是以应用为中心，以计算机技术为基础，软件与硬件可剪裁，以满足对功能、可靠性、成本、体积和功耗等要求的专用计算机系统 嵌入式软件是基于嵌入式系统而设计的软件，同样分为系统软件、支持软件和应用软件 特征 特点：专用性、实时性、可靠性、可剪裁性、可约束性 优势：体积小、功耗低、功能强、性价比高、操作简便,3.3 可编程医用电气系统,3.3 标准比较,相同之处 风险管理、生存周期、过程标准 差异之处,3.3 标准比较,3.3 标准比较,3.3 独立软件与软件组件,3.4 GB/T 25000.51介绍,范围 适用于商业现货（COTS）软件产品 仅涉及向用户提

22、供产品置信度，不涉及生产过程和供方质量体系 内容 COTS软件产品的质量 用于测试COTS软件产品的文档要求 COTS软件产品的符合性评价细则 对安全或业务攸关COTS软件产品的建议,3.4 标准比较,结构变化 GB/T 25000.51：共7章3附录1参考文献 GB/T 17544：共4章3附录（含参考文献） 内容变化 新版第5章与老版第3章基本一致，不过与GB/T 16260的关系更为紧密 新版第6章与老版第4章变化较大，新版删除了老版测试活动的内容，增加了测试文档的要求 新版增加了第2章“符合性”和第7章“符合性评价细则”,3.4 标准比较,3.4 标准比较,3.4 标准比较,3.4 标

23、准关系框图,软 件 组 件,独 立 软 件,GB/T 25000.51,相应产品标准,YY/T 0664,YY/T 0708,生存周期过程,产品确认,3.5 DICOM简介,全称 医学数字成像与通信标准 目的 医学图像的传输 概况 由美国放射学会ACR和美国电子制造商协会NEMA制定 1985年1.0版，1988年2.0版，1993年3.0版 目前由九部分内容组成，扩展部分正在讨论 认证 通过DICOM符合性声明自我认证 详细描述产品满足的DICOM内容,3.5 HL7简介,全称 卫生信息交换标准 目的 医学文本信息的传输 概况 成立于1987年，1994成为美国国家标准局ANSI所授权的标准

24、开发组织 1987年1.0版，2000年2.4版，现已开发3.0版 由触发事件、消息、段和字段组成 认证 非正式的自我声明,3.5 DICOM与HL7,4 软件监管情况综述,FDA软件监管综述 欧盟软件监管综述 FDA与欧盟的比较 我国软件监管现状,4.1 FDA软件监管综述,基本原则 基于风险分级管理，不同级别不同要求 所有软件统一要求，不再区分软件类型 过程与结果相结合，质量体系与确认并重 关注重点 质量体系 软件确认 现成软件 网络安全,4.1 FDA指南与要求,质量体系 设计控制（820.30：1997）、人因工程（1996） 采购控制（820.50）、纠正与预防措施（820.100）

25、 AAMI SW68：2001 = IEC 62304：2006 通用指南 医疗器械软件通用指南（1998 & 1997 = 2005） 医疗软件确认基本原则（1997 = 2002） 医疗器械使用现成软件指南（1997 = 1999） 内含现成软件医疗器械网络安全指南（2005） 产品指南 医疗影像管理器械指南（1983 = 2000）,4.1 设计控制指南,820.30（a） 所有III类和II类医疗器械均应进行设计控制 部分I类医疗器械应进行设计控制 （i）软件操控的医疗器械；（ii） 820.30（g） 设计确认应包含软件确认和风险分析 820.30（j） 每个制造商应对每类产品建立和

26、维护DHF DHF应包含或引用开发符合计划和需求的必要记录,4.1 设计控制指南,评审 通过文档化、全面的、系统的检查来评估需求的适当性和设计符合需求的能力 ，并识别问题 验证 通过检查和提供客观证据来认定规定需求已得到满足 确认 通过检查和提供客观证据来认定特定预期用途的需求已得到满足 过程确认：通过客观证据确立一个过程能始终产出符合预期规格的结果或产品 设计确认：通过客观证据确立器械规格符合用户需求和预期用途,4.1 设计控制指南,4.1 软件确认指南,背景 由于复杂性，软件开发过程比硬件更应严格控制 软件工程比硬件工程需要更高级别的监管和控制 适用范围 作为医疗器械组件、部件或附件的软件

27、 本身是医疗器械的软件 用于医疗器械生产的软件 用于质量体系管理的软件 典型活动 质量策划、需求、设计、编码、内部测试、用户测试、维护变更,4.1 软件确认指南,文档化的软件需求规格是软件确认的基线 软件测试的能力是有限的，却是必须的 软件确认需要时间和精力，应当尽早准备 软件确认应在软件生存周期过程中进行 软件确认需要通过计划来定义和控制 软件确认是通过一系列工作程序来实现的 软件变更均应进行确认分析，并需回归测试 确认范围取决于软件的复杂度和风险水平 确认应坚持“评审独立性”的原则 制造商可以选择确认活动，但应付最终责任,4.1 软件通用指南,适用范围 固件或其他基于软件控制的医疗器械 独

28、立的应用软件 安装在通用计算机的软件 专用的硬件/软件医疗器械 包含软件或为独立软件的医疗器械附件 适用类型 预上市通告（510K），包括传统、专用和简易方式 预上市批准申请（PMA） 研究器械豁免（IDE） 人道主义器械豁免（HDE），包括修订和补充,4.1 软件通用指南,验证 通过提供客观证据来认定某开发阶段的输出符合该阶段所有输入需求 包括走查、静态分析、动态分析、代码检查、文档检查、单元测试、集成测试 确认 通过提供客观证据来认定软件符合用户需求和预期用途 仅限于设计确认，不包括过程确认 软件在真实或模拟使用环境中正确运行的检查，也包括质量策划、验证、可追溯性分析、配置管理等活动,4.

29、1 软件通用指南,可追溯性 名称：可追踪性、可跟踪性 定义：在开发过程中两个或多个产品之间能建立关联的程度，特别是存在前后和主次关系的产品之间 可追溯性分析 追踪（1）软件需求规格与系统需求规格、（2）软件设计规格与软件需求规格、（3）源代码与软件设计规格之间的关系，分析已识别关系的正确性、一致性、完整性和准确性 软件确认指南要求进行系统需求、软件需求、软件设计、源代码、软件测试和风险分析之间的可追溯性分析 可追溯性矩阵 记录两个或多个产品之间关系的矩阵,4.1 软件通用指南,伤害 严重伤害：定义与IEC 62304基本相同 轻微伤害：不是严重伤害的任何伤害 关注水平 严重关注：失效或潜在设计

30、缺陷可能直接或者通过错误或延迟信息间接造成患者或操作者死亡或严重伤害 中等关注：失效或潜在设计缺陷可能直接或者通过错误或延迟的信息间接造成患者或操作者轻微伤害 轻微关注：失效或潜在设计缺陷不太可能对患者或操作者造成任何伤害,4.1 软件通用指南,4.1 软件通用指南,4.1 现成软件指南,定义 通常可得到的且制造商未进行完整生存周期控制的软件 包含系统软件、支持软件、应用软件 要求,4.1 现成软件指南,基础文档 现成软件描述 现成软件计算机规格要求 终端用户正确使用保证措施 现成软件功能和用途 现成软件正常工作确认 现成软件可追溯性分析 专用文档 开发者所用的开发方法是适当且充分的 验证与确

31、认的程序和结果是适当且充分的 已建立后续维护与支持活动的保障机制,4.2 欧盟软件监管综述,指令 93/42/EEC（医疗器械）：操控医疗器械的软件自动与医疗器械归为一类 90/385/EEC（有源植入）：设计和制造必须特别注意程序和控制系统，包括软件的正常运行 98/79/EEC（体外诊断）：含有软件的医疗器械必须在设计上确保有效性、可靠性和可重复性 07/47/EEC（修订）：软件被明确定义为有源医疗器械，无论是独立软件还是软件组件，软件确认都是基本要求 质量体系 全面质量体系：ISO9001:94/ISO13485:96/EN46001:96 生产质量体系：ISO9002:94/ISO1

32、3488:96/EN46002:96 产品质量体系：ISO9003:94/EN46003:96,4.2 欧盟软件监管概述,标准 IEC 62304：2006 IEC 60601-1-4：2000 IEC 80001-1：2010 IEC/TR 80002-1：2009 IEC 62366：2007 建议书（NB-MED/2.2/Rec4） 本身是医疗器械或是医疗器械附件的软件应标记“CE”，软件组件无需标记“CE” 推荐ISO/IEC 12119:1994（GB/T 17544-1998）,4.3 FDA与欧盟比较,4.3 FDA与欧盟比较,4.3 FDA与欧盟比较,4.3 FDA与欧盟比较,

33、4.3 FDA与欧盟比较,相同之处 质量管理、风险管理和软件工程相结合 测试不足以确保安全性，必须进行过程控制 基于风险水平分级管理，不同级别不同要求 软件风险分级和内容要求相互对应基本一致 差异之处 体制差异：FDA上市申报，欧盟协调标准 类型差异：FDA统一要求，欧盟区分要求,4.4 我国软件监管现状,业内认识不足，对软件问题不重视 法规相对滞后，与软件发展不匹配 质量体系缺失，相关标准难以落实 检测实力欠缺，对软件评价不到位 审评范围有限，对软件要求不全面 处于起步阶段，缺乏经验需要摸索,4.4 软件审评工作思路,国外经验与我国国情相结合 专家研讨和企业调研相结合 逐步完善软件申报资料要

34、求 制定软件技术审评指导原则,5 软件申报资料要求,原则范围 申报要求 现成软件 FDA比较,5.1 基本原则,扩大软件审评范围，所有软件均统一要求 申报详尽程度取决于安全性级别与复杂度 申报内容均源自开发过程生成的软件文档 通用要求，其他指导原则如未规定均适用,5.1 适用范围,适用范围 独立软件：本身是医疗器械或附件的软件 软件组件：作为医疗器械、部件或附件组成部分的软件 专用软件：其他有特定用途的软件,5.2 文档内容,基本信息 产品标识、安全性级别、结构功能、硬件关系、运行环境、适用范围、禁忌症、上市历史 实现过程 开发综述、风险管理、需求规格、生存周期、验证与确认、缺陷管理、修订历史

35、、临床评价 核心算法 列明核心算法的名称、原理、用途和类型,5.2 申报要求,5.2 申报要求,5.2 申报要求,5.2.1 产品标识与安全性级别,产品标识 软件的名称、型号、版本号 制造商的名称、生产地址 安全性级别 说明软件安全性级别（A、B、C） 详述安全性级别确定理由 包括直接影响和间接影响 与管理类别没有对应关系,5.2.1 结构功能,体系结构图 图示软件组成模块之间、组成模块与外部接口的关系，应包含足够且必要的注释 功能描述 依据体系结构图描述软件的组成模块、模块功能、模块关系、模块与外部接口关系、用户界面内容与相互关系 组成模块如为选装应注明，如有版本号也应注明 外部接口 必备软

36、件：软件运行所必需的应用软件 选配软件：与软件配套使用的应用软件 硬件：通用计算机或医疗器械硬件 现成软件 如有，列明名称、版本号、制造商和类型,5.2.1 结构功能,5.2.1 硬件关系,物理拓扑图 图示软件、通用计算机、医疗器械硬件之间的物理连接关系，应包含足够且必要的注释 关系描述 独立软件：说明通用计算机的类型和功能，如需与医疗器械硬件联合使用应说明名称、型号、规格和制造商 软件组件：说明医疗器械硬件的名称、型号和规格，如需与通用计算机联合使用应说明类型和功能,5.2.1 硬件关系,5.2.1 运行环境,安装于通用计算机的软件 硬件配置 CPU、内存、硬盘、显示器、显卡和IO设备 软件

37、环境 系统软件、支持软件、必备软件、选配软件和杀毒软件 名称、版本号和补丁号（如有） 网络条件 网卡、类型（局域网、广域网）和架构（CS、BS） CS架构：服务器端、客户端 BS架构：服务器端、客户端、浏览器,5.2.1 运行环境,安装于医疗器械硬件的软件 硬件配置 处理器、存储器、外设器件、IO设备 软件环境 系统软件、支持软件、必备软件、 选配软件和杀毒软件 名称、版本号和补丁号（如有） 网络条件 网络接口（如有）,5.2.1 适用范围与禁忌症,适用范围 独立软件：软件的适用范围和适用人群 软件组件：医疗器械产品的适用范围和适用人群 禁忌症 独立软件：软件的禁忌症和不适用人群 软件组件：医

38、疗器械产品的禁忌症和不适用人群,5.2.1 上市历史,中国情况 实质首次注册：依据医疗器械分类目录及后续分类界定通知说明管理类别 实质重新注册：列明在中国所有上市产品的版本号和产品注册证号 国外情况 列明软件在原产国、美国、日本和欧盟首次上市的时间、版本号和管理类别，无需提供各国上市批书 软件组件 描述医疗器械产品的上市历史,5.2.2 开发综述,开发技术 语言：C、C+、C#、Java、XML 工具：支持软件（含开源软件）和应用软件，描述开发工具、管理工具、产品工具的名称、版本号和制造商，其中产品工具还应简述功能和用途 方法：面向对象、基于构件、虚拟机、CS架构 生存周期模型：瀑布、增量、渐

39、进、V模型 度量数据 开发人员数量、开发时间、工作量（人月数） 代码行总数、控制文档总数,5.2.2 风险管理,风险管理报告 名称、严重度、原因、减缓措施和结果 现成软件 如有，所有级别软件均应进行风险管理 实施情况可另附说明文档,5.2.2 需求规格,A级 软件需求规格功能和性能的要求 B级和C级 软件需求规格全文 包含硬件、功能、性能、输入输出、接口界面、警示信息、保密安全、数据与数据库、文档和法规的要求 现成软件 如有，B级和C级软件应要求 需求规格可另附说明文档,5.2.2 生存周期,A级 软件开发生存周期计划摘要 描述开发策划、需求分析、设计（体系结构设计、详细设计）、编码和测试（单

40、元、集成、系统、用户）各阶段的任务、内容和结果 B级 在A级基础上提供配置管理计划和维护计划摘要，描述相应过程的工具、流程和要求,5.2.2 生存周期,C级 在B级基础上列明各阶段输入输出控制文档 现成软件 如有，B级和C级的软件应在开发生存周期计划、配置管理计划和维护计划中说明相应要求 实施情况可另附说明文档 YY/T 0664-2008或YY/T 0708-2009核查表,5.2.2 验证与确认,验证 通过提供客观证据来认定某开发阶段的输出符合该阶段所有输入需求 包括质量管理计划、正式技术评审、可追溯性分析、白盒测试（静态和动态）、黑盒测试、回归测试 确认 通过提供客观证据来认定软件符合用

41、户需求和预期用途 用户测试（真实或模拟使用环境测试），也包括质量管理、风险管理和软件工程等活动,5.2.2 验证与确认,A级 系统测试、用户测试的测试计划和报告摘要（条件、工具、方法、通过准则和结果） B级 系统测试、用户测试的测试计划和报告摘要 概要介绍开发各阶段的验证与确认活动（工具、方法、内容和结果），其中单元测试应描述覆盖率要求，集成测试应描述集成策略,5.2.2 验证与确认,C级 系统测试、用户测试的测试计划和报告全文 概要介绍开发各阶段的验证与确认活动（工具、方法、内容和结果），其中单元测试应描述覆盖率要求，集成测试应描述集成策略 现成软件 如有，所有级别软件均应进行验证与确认 系

42、统测试和用户测试可另附说明文档,5.2.2 缺陷管理,A级 描述缺陷管理的工具、流程和要求，列明测试阶段发现的缺陷总数和剩余缺陷数 B级和C级 在A级基础上列明剩余缺陷的严重度、处理措施和时间 现成软件 如有，B级和C级软件应列明剩余缺陷情况,5.2.2 修订历史,A级 描述软件版本号的命名规则 列明本版所有修订活动的版本号、类型和日期 B级 在A级基础上详述本版与前版的变更内容 C级 在B级基础上列明软件在原产国首次上市后历次修订且批准上市的版本号、类型和日期,5.2.2 临床评价,类型 文献资料 临床数据 临床试验报告 实施情况可另附说明文档,5.2.3 核心算法,核心算法 医学图像或数据

43、的后处理算法，通常会改变原始图像或数据，包括但不限于压缩、分割、配准融合、三维重建、量化分析和异常识别等功能 算法类型 公认成熟算法：公开文献专利标准、原理简单明确、上市超过四年且无不良事件 全新算法：源自科学研究和临床数据,5.2.3 核心算法,A级算法 公认成熟算法列明名称 全新算法列明名称、原理和用途 B级或C级算法 公认成熟算法列明名称、原理和用途 全新算法列明名称、原理和用途，并提供验证资料 注册类型 实质首次注册：所有核心算法 实质重新注册：新增核心算法,5.3 现成软件,名称 现成软件、现货软件、第三方软件、未知来源软件 定义 制造商未进行完整生存周期控制的软件 以前开发但不能得

44、到足够开发记录的软件 仅指应用软件，不包括系统软件和支持软件 包括外包*、成品、免费和遗留软件 要求 A级：描述结构功能、风险管理、验证与确认的要求 B级和C级：描述结构功能、需求规格、风险管理、生存周期、验证与确认、缺陷管理的要求,5.4 FDA比较,5.4 FDA比较,5.4 FDA比较,相同之处 监管体制类似，软件监管原则范围基本相同 基于风险水平分级管理，不同级别不同要求 软件风险分级和申报要求相互对应基本一致 差异之处 设计规格和可追溯性分析未做严格要求 引入软件规模度量要求并强化算法要求 A级略高于FDA，B级和C级与FDA相当 现成软件范围和内容的要求均低于FDA,6 申报注意事

45、项,申请表 产品标准 其他文件,6.1 申请表,产品名称应根据分类目录通用名称和产品核心功能确定，且中英文名称应保持一致 型号规格应注明软件版本号 结构组成应说明存储介质和体系结构 存储介质：类型、数量，如有加密装置应说明 体系结构：列明软件组成模块，组成模块如为选装应注明，如有版本号也应注明 适用范围和禁忌症应根据临床资料和产品核心功能确定，不应笼统描述,6.2 产品标准,产品分类 产品标识、型号规格、结构组成和运行环境 前三项应与申请表保持一致，运行环境应包括硬件配置、软件环境和网络条件 软件如需与医疗器械硬件联合使用，还应说明硬件的名称、型号、规格和制造商 软件组件 产品分类应注明软件版

46、本号,6.2 产品标准,要求 结合软件特点按照GB25000.51逐项描述，不应简单罗列标准条款内容 质量特性如适用提供证据，如不适用在编制说明中描述 功能 按照说明书顺序进行描述并保持一致，如为选装功能应注明，如有测量功能应注明精度 限制 根据产品特点进行说明，如输入数据范围、参数设置范围、图像最大处理量、用户最大并发数等,6.2 产品标准,效率 说明在何种运行环境下，处理、传输或显示图像或数据的最长时间 测试 说明测试条件和方法，应包含所有选装模块 编制说明 说明软件产品管理分类的依据和分类编号 列明GB25000.51不适用项，并说明理由,6.3 其他文件,检测报告 检测样品与标准结构组成的存储介质应保持一致，检测样品标签与标准产品标识应保持一致 说明书 产品如有选装功能说明书应注明，如有测量功能说明书应注明精度 其他文件 EC证书/声明、CFG证书、授权声明均应包含版本号 真实性声明应包含软件描述文档,Q&A,