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

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

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

3、98共召回3140个，软件失效242个，占总数7.7%其中软件变更导致召回192个，占软件失效79.3%19992005共召回3771个，软件失效425个，占总数11.3%其中内含软件器械共召回1261个，占总数33.4%，软件失效占内含软件器械召回33.7%1.2 FDA召回分析麻醉类：麻醉机、呼吸机心脏类：起搏器、除颤仪通用类：监护仪、输液泵诊断类：生化仪、病理仪时期时期麻醉类麻醉类心脏类心脏类通用类通用类诊断类诊断类影像类影像类手术类手术类其他类其他类1983199710%21%10%19%30%3%7%199920051.2%8.1%12.7%34.9%33.2%1.1%8.8%200

4、92.8%5.6%11.3%14.1%60.6% 5.6%影像类：X射线类（诊断、治疗）、磁共振、超声手术类：电刀、激光类其他类：含妇产科和眼科1.2 案例与召回软件失效足以致命，且所占比例较高软件失效增速高于医疗器械整体情况内含软件器械召回1/3与软件失效有关软件变更是导致软件失效的主要原因影像类器械的软件失效问题最为突出2 软件与软件工程概述软件概述软件工程概述 软件质量概述2.1 软件概述定义软件是程序、数据和文档的集合程序 = 算法 + 结构分类（GB/T 13702-1992）系统软件：操作系统、实用程序、网络系统支持软件：开发工具、管理工具、数据库管理系统应用软件：数据图像、控制类

5、、辅助类、安全保密基本特点复杂性：不同输入不同执行路径，人为因素无处不在灵活性：同一需求多种实现方式，后续变更容易快速2.1 算法概述定义在有限步骤内解决问题的一系列明确指令特征输入项：一个算法必须有零个或多个输入输出项：一个算法必须有一个或多个输出明确性：算法每一步骤必须有确切的定义 有限性：算法必须在有限步骤内完成任务有效性：每一步骤可分解为基本运算步骤复杂度时间复杂度、空间复杂度2.1 软硬件差异硬件是物理实体，软件是逻辑关系硬件变更周期长，软件变更容易快速硬件有磨损现象，软件虽无磨损，但有退化现象硬件质量取决于设计、开发和生产，软件质量取决于设计和开发，与生产基本无关硬件失效先有征兆再

6、发生，软件失效没有征兆突然发生，软件失效率远高于硬件（100：1）硬件部件可以标准化，软件组件标准化较为复杂细微变更对硬件影响有限，对软件影响可能严重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 软件文档阶段相应文档开发策划开发计划、质量管理计划、风险管理计划、配置管理计划、文档计划需求分析需求规格、初步测试计划设计设计规格、

9、各级测试计划编码代码规范、问题解决程序测试各级测试报告、问题解决程序发行安装说明书运行维护维护计划、问题解决程序2.2 软件与软件工程2.3 软件质量概述名称Bug、缺陷、错误、故障、失效、异常异常根源软件若超过169行可执行代码无法确保完全正确软件测试由于时间和成本限制不能遍历所有路径属性软件缺陷与生俱来，不可避免，也无法根除现有已知方法不能保证任何软件100% 质量原则尽早测试、重点测试、全面测试2.3 复杂度与测试公式软件复杂度 = NIOPN为软件类型，I为输入次数，O为输出次数，P为指数举例假设N=1，P=2，输入2个参数，输出2个参数，每个参数均为8位数据，执行一次测试耗时1毫秒，

10、则测试所有参数组合耗时为： 282（282）2/（103360024365）8925年假设用户名为10位数字和字母组合，字母区分大小写，测试一个用户名耗时1纳秒，则测试所有用户名耗时为： （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 影响因素计划和资源语言工具和方法文档复杂性环境人员培训组织形式需求转换

11、和可追溯性测试方法维护现有软件原型现有类似软件质量特征设计参数折中2.3 质量度量分类产品度量：用于描述产品特征和质量水平项目度量：用于描述项目特性和执行状态过程度量：用于开发和维护过程的优化改进过程度量需求分析度量：功能点度量设计度量：形态度量、界面度量源代码度量：规模度量规模度量、Halstead度量测试度量：DRE度量维护度量：SMI度量2.3 生存周期质量2.3 质量体系与模型质量体系ISO 90003（GB/T 19003）CMM / CMMISPICE（ISO/IEC 15504）质量模型Boehm模型：功能要求、可维护性、可移植性McCall模型：产品运行、产品修改、产品转移IS

12、O 9126模型：功能性、可靠性、易用性、效率、维护性、可移植性2.3 质量特性与测试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系列）

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

14、the application of ISO 14971 to medical device softwareIEC 82304-1Healthcare software systems - Part 1: General requirementsIEC 62366：2007Medical devices - Application of usability engineering to medical devices3.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级：可能死亡或严重伤害严重伤害具体要求制造商应赋予每个软件系统一个安全性级别并形成文档软件系统如分解为软件项，软件项应继承原有安全性级别，除非制造商以文件形式给出理由每个软件系统被赋予安全性级别之前均应按照C级要

17、求安全性分级方案不期望与YY/T 0316的风险分级相一致3.2 安全性级别软件系统C级软件项B级软件项C级软件项B级软件项C级软件项A级软件单元B级软件单元A级软件单元C级软件单元B级软件单元A级软件单元A级软件单元A级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）、其他以计算机为基础的装置（智能传感器、变送器、执行器）可编程医用电气系统包含一个或多个可编程电子子系统的医用电气设备或医用电气系统，简称PEMS3.3 嵌入式系统定义IEEE定义：嵌入式系统是用于控制、监视或者辅助装备、机器或设备运行的装置嵌入式系统是以应用为中心，以计算机技术为基础，软件与

21、硬件可剪裁，以满足对功能、可靠性、成本、体积和功耗等要求的专用计算机系统 嵌入式软件是基于嵌入式系统而设计的软件，同样分为系统软件、支持软件和应用软件 特征特点：专用性、实时性、可靠性、可剪裁性、可约束性优势：体积小、功耗低、功能强、性价比高、操作简便3.3 可编程医用电气系统3.3 标准比较相同之处风险管理、生存周期、过程标准差异之处YY/T 0708YY/T 0664对通用标准的补充适用于PEMS开发生存周期包含安全性确认与其他标准共同使用适用于医疗器械软件开发和维护生存周期不覆盖医疗器械确认3.3 标准比较YY/T 0708YY/T 066452.201 文件4.1 质量管理体系，4.2

22、 风险管理52.202 风险管理计划4.1 质量管理体系，4.2 风险管理5.1.7 软件风险管理策划52.203 开发生存周期5.1.1 软件开发计划9 软件问题解决过程 52.204 风险管理过程4.2 风险管理，4.3 安全性级别7 软件风险管理过程52.205 人员资格4.1 质量管理体系52.206 需求规格说明5.2 软件需求分析，7.2 风险控制措施52.207 体系结构5.3 软件体系结构设计3.3 标准比较YY/T 0708YY/T 066452.208 设计和实现5.4 软件详细设计5.5 软件单元实现和验证52.209 验证5.5 软件单元实现和验证5.6 软件集成和集成

23、测试5.7 软件系统测试52.210 确认4.1 质量管理体系52.211 修改6 软件维护过程7.4 软件更改风险管理8 软件配置管理过程9 软件问题解决过程52.212 评定4.1 质量管理体系3.3 独立软件与软件组件内容独立软件软件组件结构组成系统子系统开发策划软件系统医疗器械需求分析市场客户医疗器械设计软件软硬件结合编码软件软件单元测试软件软件集成测试软件软硬件结合系统测试软件软硬件结合发行软件系统医疗器械3.4 GB/T 25000.51介绍范围适用于商业现货（COTS）软件产品仅涉及向用户提供产品置信度，不涉及生产过程和供方质量体系内容COTS软件产品的质量用于测试COTS软件产

24、品的文档要求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 标准比较GB/T 25000.51第5章GB/T 17544第3章差异内容5.1.3.5 法律或行政要求5.1.3.6 最大并发用户数5.1.3.8 特定软件和硬件5.1.4

25、.4 软件组件选项版本5.1.6.6 可访问性规定标示5.1.10 使用质量陈述5.2.5 易学性5.2.6 可操作性3.1.2 h）要交付项3.1.5 e）使用效率和用户满意度3.2.5 可浏览性3.3.3 c）可操作性3.4 标准比较GB/T 25000.51第5章GB/T 17544第3章细化内容5.1.7 效率陈述5.1.8 维护性陈述5.1.9 可移植性陈述5.2.1 完备性3.1.6 效率说明3.1.7 可维护性说明3.1.8 可移植性说明3.2.1 完整性调整内容5.1.9.2 配置条件5.1.9.3 安装规程3.1.2 f）要求的系统3.1.2 i）安装3.4 标准比较GB/T

26、 25000.51第6章GB/T 17544第4章6.1 一般要求6.2 测试计划要求（方法、准则、环境、进度）6.3 测试说明要求（测试用例说明、测试规程）6.4 测试结果要求（执行报告、异常情况报告、结果评估）4.1 测试预要求4.2 测试活动4.3 测试记录4.4 测试报告4.5 跟踪测试3.4 标准关系框图软件组件独立软件GB/T 25000.51相应产品标准YY/T 0664YY/T 0708生存周期过程产品确认3.5 DICOM简介全称医学数字成像与通信标准目的医学图像的传输概况由美国放射学会ACR和美国电子制造商协会NEMA制定1985年1.0版，1988年2.0版，1993年3

27、.0版目前由九部分内容组成，扩展部分正在讨论认证通过DICOM符合性声明自我认证 详细描述产品满足的DICOM内容3.5 HL7简介全称卫生信息交换标准 目的医学文本信息的传输概况成立于1987年，1994成为美国国家标准局ANSI所授权的标准开发组织1987年1.0版，2000年2.4版，现已开发3.0版由触发事件、消息、段和字段组成 认证非正式的自我声明3.5 DICOM与HL74 软件监管情况综述FDA软件监管综述欧盟软件监管综述FDA与欧盟的比较我国软件监管现状4.1 FDA软件监管综述基本原则基于风险分级管理，不同级别不同要求所有软件统一要求，不再区分软件类型过程与结果相结合，质量体

28、系与确认并重关注重点质量体系软件确认现成软件网络安全4.1 FDA指南与要求质量体系设计控制（820.30：1997）、人因工程（1996）采购控制（820.50）、纠正与预防措施（820.100）AAMI SW68：2001 = IEC 62304：2006通用指南医疗器械软件通用指南（1998 & 1997 = 2005）医疗软件确认基本原则（1997 = 2002）医疗器械使用现成软件指南（1997 = 1999）内含现成软件医疗器械网络安全指南（2005）产品指南医疗影像管理器械指南（1983 = 2000）4.1 设计控制指南820.30（a）所有III类和II类医疗器械均应进行设计

29、控制部分I类医疗器械应进行设计控制 （i）软件操控的医疗器械；（ii）820.30（g）设计确认应包含软件确认和风险分析820.30（j）每个制造商应对每类产品建立和维护DHFDHF应包含或引用开发符合计划和需求的必要记录4.1 设计控制指南评审通过文档化、全面的、系统的检查来评估需求的适当性和设计符合需求的能力 ，并识别问题验证通过检查和提供客观证据来认定规定需求已得到满足确认通过检查和提供客观证据来认定特定预期用途的需求已得到满足 过程确认：通过客观证据确立一个过程能始终产出符合预期规格的结果或产品设计确认：通过客观证据确立器械规格符合用户需求和预期用途4.1 设计控制指南4.1 软件确认

30、指南背景由于复杂性，软件开发过程比硬件更应严格控制软件工程比硬件工程需要更高级别的监管和控制适用范围作为医疗器械组件、部件或附件的软件本身是医疗器械的软件用于医疗器械生产的软件用于质量体系管理的软件典型活动质量策划、需求、设计、编码、内部测试内部测试、用户测试用户测试、维护变更4.1 软件确认指南文档化的软件需求规格是软件确认的基线软件测试的能力是有限的，却是必须的软件确认需要时间和精力，应当尽早准备软件确认应在软件生存周期过程中进行软件确认需要通过计划来定义和控制软件确认是通过一系列工作程序来实现的软件变更均应进行确认分析，并需回归测试确认范围取决于软件的复杂度和风险水平确认应坚持“评审独立

31、性”的原则制造商可以选择确认活动，但应付最终责任4.1 软件通用指南适用范围固件或其他基于软件控制的医疗器械独立的应用软件安装在通用计算机的软件专用的硬件/软件医疗器械包含软件或为独立软件的医疗器械附件适用类型预上市通告（510K），包括传统、专用和简易方式 预上市批准申请（PMA）研究器械豁免（IDE）人道主义器械豁免（HDE），包括修订和补充4.1 软件通用指南验证通过提供客观证据来认定某开发阶段的输出符合该阶段所有输入需求包括走查、静态分析、动态分析、代码检查、文档检查、单元测试、集成测试确认通过提供客观证据来认定软件符合用户需求和预期用途 仅限于设计确认，不包括过程确认软件在真实或模拟

32、使用环境中正确运行的检查，也包括质量策划、验证、可追溯性分析、配置管理等活动4.1 软件通用指南可追溯性名称：可追踪性、可跟踪性定义：在开发过程中两个或多个产品之间能建立关联的程度，特别是存在前后和主次关系的产品之间可追溯性分析追踪（1）软件需求规格与系统需求规格、（2）软件设计规格与软件需求规格、（3）源代码与软件设计规格之间的关系，分析已识别关系的正确性、一致性、完整性和准确性软件确认指南要求进行系统需求、软件需求、软件设计、源代码、软件测试和风险分析之间的可追溯性分析可追溯性矩阵记录两个或多个产品之间关系的矩阵 4.1 软件通用指南伤害严重伤害：定义与IEC 62304基本相同轻微伤害：

33、不是严重伤害严重伤害的任何伤害关注水平严重关注：失效或潜在设计缺陷可能直接或者通过错误或延迟信息间接造成患者或操作者死亡或严重伤害中等关注：失效或潜在设计缺陷可能直接或者通过错误或延迟的信息间接造成患者或操作者轻微伤害轻微关注：失效或潜在设计缺陷不太可能对患者或操作者造成任何伤害4.1 软件通用指南内容要求内容要求轻微关注轻微关注中等关注中等关注严重关注严重关注关注水平关注水平陈述关注水平并描述确定理由软件描述软件描述概述软件特征和软件运行环境设备危害分析设备危害分析 列明已识别的硬件和软件危害，包括严重度评估和减缓措施软件需求规格软件需求规格SRS功能需求概要完整的SRS文件体系结构图体系结

34、构图无需提交*详述功能单元和软件模块，可以包含状态图和流程图软件设计规格软件设计规格无需提交软件设计规格文件可追溯性分析可追溯性分析 需求、规格、已识别危害及减缓、验证与确认的可追溯性*4.1 软件通用指南内容要求内容要求轻微关注轻微关注中等关注中等关注严重关注严重关注开发环境开发环境无需提交概述软件生存周期开发计划，包括配置管理和维护活动的概述概述软件生存周期开发计划，开发过程生成的控制文件列表，包括配置管理和维护计划文件验证与确认验证与确认软件功能测试计划、通过准则和结果单元、集成和系统级VV活动描述。系统测试协议，包括通过准则和结果单元、集成和系统级VV活动描述。单元、集成和系统测试协议

35、，通过准则、测试报告、摘要和结果修订历史修订历史修订历史日志，包括发布的版本号和日期*未解决异常未解决异常无需提交剩余软件异常列表，附注对安全性或有效性的影响说明，包括操作者使用和人为因素4.1 现成软件指南定义通常可得到的且制造商未进行完整生存周期控制的软件包含系统软件、支持软件、应用软件要求轻微关注轻微关注中等关注中等关注严重关注严重关注危害分析基础文档危害消减危害分析基础文档危害消减剩余风险描述危害分析基础文档危害消减剩余风险描述专用文档4.1 现成软件指南基础文档现成软件描述现成软件计算机规格要求终端用户正确使用保证措施现成软件功能和用途现成软件正常工作确认现成软件可追溯性分析专用文档

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

37、002:94/ISO13488:96/EN46002:96产品质量体系：ISO9003:94/EN46003:964.2 欧盟软件监管概述标准IEC 62304：2006IEC 60601-1-4：2000IEC 80001-1：2010IEC/TR 80002-1：2009IEC 62366：2007建议书（NB-MED/2.2/Rec4）本身是医疗器械或是医疗器械附件的软件应标记“CE”，软件组件无需标记“CE”推荐ISO/IEC 12119:1994（GB/T 17544-1998）4.3 FDA与欧盟比较 FDA软件关注水平IEC 62304安全性级别轻微关注：失效或潜在设计缺陷不太可

38、能造成任何伤害A级：不可能对健康有伤害和损坏中等关注：失效或潜在设计缺陷可能直接或间接造成轻微伤害B级：可能有不严重的伤害严重关注：失效或潜在设计缺陷可能直接或间接造成死亡或严重伤害C级：可能死亡或严重伤害4.3 FDA与欧盟比较 FDA软件通用指南 IEC 62304 关注水平4.3 软件安全性级别 软件描述5.2 软件需求分析 设备危害分析7.1 促成危害处境的软件分析软件需求规格5.2 软件需求分析 体系结构图5.3 软件体系结构设计4.3 FDA与欧盟比较 FDA软件通用指南 IEC 62304 软件设计规格5.4 软件详细设计可追溯性分析贯穿全程，包括5.1.1，5.2.6，5.7.

39、4，7.3.3，8.2.4开发环境5.1 软件开发策划 验证与确认贯穿全程，包括5.2.6，5.3.6，5.4.4，5.5.5，5.6.3，5.6.7，5.7.5，7.3.1，9.7，9.8 修订历史8.3 配置状态记录未解决异常9.5 保持记录4.3 FDA与欧盟比较 FDA软件确认指南IEC 62304 5.2.1 质量策划5.1 软件开发策划 5.2.2 需求5.2 软件需求分析 5.2.3 设计 5.3 软件体系结构设计5.4 软件详细设计 5.2.4 编码 5.5 软件单元实现和验证5.2.5 内部测试5.5 软件单元实现和验证5.6 软件集成和集成测试5.7 软件系统测试5.2.6

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

41、相结合逐步完善软件申报资料要求制定软件技术审评指导原则5 软件申报资料要求原则范围申报要求现成软件FDA比较5.1 基本原则扩大软件审评范围，所有软件均统一要求申报详尽程度取决于安全性级别与复杂度申报内容均源自开发过程生成的软件文档通用要求，其他指导原则如未规定均适用5.1 适用范围基本类型安装形式医疗器械硬件关系核心功能独立软件处理型通用计算机处理数据型通用计算机通信处理软件组件嵌入式医疗器械硬件操控操控（处理）控制型通用计算机操控操控（处理）适用范围独立软件：本身是医疗器械或附件的软件软件组件：作为医疗器械、部件或附件组成部分的软件专用软件：其他有特定用途的软件5.2 文档内容基本信息产品

42、标识、安全性级别、结构功能、硬件关系、运行环境、适用范围、禁忌症、上市历史实现过程开发综述、风险管理、需求规格、生存周期、验证与确认、缺陷管理、修订历史、临床评价核心算法列明核心算法的名称、原理、用途和类型5.2 申报要求内容内容A级（轻微）级（轻微）B级（中等）级（中等）C级（严重）级（严重）产品标识产品标识描述软件名称、型号、版本号、制造商和生产地址安全性级别安全性级别描述软件安全性级别，并详述安全性级别确定理由结构功能结构功能依据体系结构图，描述软件的组成模块、模块功能、模块关系、外部接口和用户界面硬件关系硬件关系依据物理拓扑图，描述软件、通用计算机和医疗器械硬件的连接关系运行环境运行环

43、境描述软件运行所需的硬件配置、软件环境和网络条件适应范围适应范围描述软件的适用范围和适用人群禁忌症禁忌症描述软件的禁忌症和不适用人群上市历史上市历史描述软件在中国、原产国等主要国家地区的上市时间、版本号和管理类别5.2 申报要求内容内容A级（轻微）级（轻微）B级（中等）级（中等）C级（严重）级（严重）开发综述开发综述描述开发语言、工具、方法、模型、人员、时间、工作量、代码行数和控制文档数风险管理风险管理提供风险管理资料需求规格需求规格需求规格的功能、性能要求需求规格全文，包含硬件、功能、性能、输入输出、接口界面、警示信息、保密安全、数据与数据库、文档和法规的要求生存周期生存周期开发生存周期计划

44、摘要开发生存周期计划、配置管理计划和维护计划的摘要开发生存周期计划、配置管理计划和维护计划的摘要，列明各阶段输入输出文档验证与验证与确认确认系统测试和用户测试的计划与报告摘要概述开发各阶段的验证活动，系统测试和用户测试的计划与报告摘要概述开发各阶段的验证活动，系统测试和用户测试的计划与报告5.2 申报要求内容内容A级（轻微）级（轻微）B级（中等）级（中等）C级（严重）级（严重）缺陷管理缺陷管理描述缺陷总数和剩余缺陷数描述缺陷总数和剩余缺陷数，列明剩余缺陷的严重度、处理措施和处理时间修订历史修订历史描述版本号命名规则，列明本次修订的版本号、类型和日期描述版本号命名规则，列明本次修订的版本号、类型

45、和日期，详述本版与前版的变更内容描述版本号命名规则，列明本次和以往修订的版本号、类型和日期，详述本版与前版的变更内容临床评价临床评价提供临床评价资料核心算法核心算法公认成熟算法列明名称，全新算法列明名称、原理和用途公认成熟算法列明名称、原理和用途，全新算法除列明名称、原理和用途外，还应提供安全性与有效性的验证资料5.2.1 产品标识与安全性级别产品标识软件的名称、型号、版本号制造商的名称、生产地址安全性级别说明软件安全性级别（A、B、C）详述安全性级别确定理由包括直接影响和间接影响与管理类别没有对应关系5.2.1 结构功能体系结构图图示软件组成模块之间、组成模块与外部接口的关系，应包含足够且必

46、要的注释功能描述依据体系结构图描述软件的组成模块、模块功能、模块关系、模块与外部接口关系、用户界面内容与相互关系组成模块如为选装应注明，如有版本号也应注明外部接口必备软件：软件运行所必需的应用软件选配软件：与软件配套使用的应用软件硬件：通用计算机或医疗器械硬件现成软件如有，列明名称、版本号、制造商和类型5.2.1 结构功能5.2.1 硬件关系物理拓扑图图示软件、通用计算机、医疗器械硬件之间的物理连接关系，应包含足够且必要的注释关系描述独立软件：说明通用计算机的类型和功能，如需与医疗器械硬件联合使用应说明名称、型号、规格和制造商软件组件：说明医疗器械硬件的名称、型号和规格，如需与通用计算机联合使

47、用应说明类型和功能5.2.1 硬件关系5.2.1 运行环境安装于通用计算机的软件硬件配置CPU、内存、硬盘、显示器、显卡和IO设备软件环境系统软件、支持软件、必备软件、选配软件和杀毒软件名称、版本号和补丁号（如有）网络条件网卡、类型（局域网、广域网）和架构（CS、BS）CS架构：服务器端、客户端BS架构：服务器端、客户端、浏览器5.2.1 运行环境安装于医疗器械硬件的软件硬件配置处理器、存储器、外设器件、IO设备软件环境系统软件、支持软件、必备软件、 选配软件和杀毒软件名称、版本号和补丁号（如有）网络条件网络接口（如有）5.2.1 适用范围与禁忌症适用范围独立软件：软件的适用范围和适用人群软件

48、组件：医疗器械产品的适用范围和适用人群禁忌症独立软件：软件的禁忌症和不适用人群软件组件：医疗器械产品的禁忌症和不适用人群5.2.1 上市历史中国情况实质首次注册：依据医疗器械分类目录及后续分类界定通知说明管理类别实质重新注册：列明在中国所有上市产品的版本号和产品注册证号国外情况列明软件在原产国、美国、日本和欧盟首次上市的时间、版本号和管理类别，无需提供各国上市批书 软件组件描述医疗器械产品的上市历史5.2.2 开发综述开发技术语言：C、C+、C#、Java、XML工具：支持软件（含开源软件）和应用软件，描述开发工具、管理工具、产品工具的名称、版本号和制造商，其中产品工具还应简述功能和用途方法：

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

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