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

医疗器械软件申报基本要求审评一处彭亮2011.8内容摘要失效案例与召回分析软件与软件工程概述软件主要标准介绍软件监管情况综述软件申报资料要求软件申报注意事项1失效案例与召回分析软件失效案例FDA召回分析1.1软件失效案例直线加速器1985～1987年，Therac-25加速器因软件失效导致6人受到超剂量辐射，其中3人死亡，1人截肢2001年，加速器因软件和操作错误导致巴拿马5人死亡起搏器和ICD起搏器典型代码行数为80000行1990～2000年，起搏器召回的41%与软件失效有关1997～2003年，美国至少有212人因ICD失效而死亡2008年，美国约使用350000个起搏器和140000个ICD1.1软件失效案例输液泵输液泵典型代码行数为170000行1997年，Gish公司输液泵因软件逻辑错误引起吗啡过量输入，导致1人死亡2006年，Cardinal公司静脉输液泵因软件设计缺陷引起输液过量，导致2人死亡，其中1人是出生仅16天的婴儿，被注入了44.8ml营养液，而处方仅为4.8ml2005～2009年，FDA收到约56000条输液泵抱怨记录，其中710人死亡I级召回2007年，FDA有3例I级召回与软件失效有关（共23例）2009年，2例手术导航和1例镇痛泵因软件失效I级召回1.2FDA召回分析1983～1991共召回2792个，软件失效165个，占总数5.9%1992～1998共召回3140个，软件失效242个，占总数7.7%其中软件变更导致召回192个，占软件失效79.3%1999～2005共召回3771个，软件失效425个，占总数11.3%其中内含软件器械共召回1261个，占总数33.4%，软件失效占内含软件器械召回33.7%1.2FDA召回分析麻醉类：麻醉机、呼吸机心脏类：起搏器、除颤仪通用类：监护仪、输液泵诊断类：生化仪、病理仪时期麻醉类心脏类通用类诊断类影像类手术类其他类1983～199710%21%10%19%30%3%7%1999～20051.2%8.1%12.7%34.9%33.2%1.1%8.8%20092.8%5.6%11.3%14.1%60.6%—5.6%影像类：X射线类（诊断、治疗）、磁共振、超声手术类：电刀、激光类其他类：含妇产科和眼科1.2案例与召回软件失效足以致命，且所占比例较高软件失效增速高于医疗器械整体情况内含软件器械召回1/3与软件失效有关软件变更是导致软件失效的主要原因影像类器械的软件失效问题最为突出2软件与软件工程概述软件概述软件工程概述软件质量概述2.1软件概述定义软件是程序、数据和文档的集合程序=算法+结构分类（GB/T13702-1992）系统软件：操作系统、实用程序、网络系统支持软件：开发工具、管理工具、数据库管理系统应用软件：数据图像、控制类、辅助类、安全保密基本特点复杂性：不同输入不同执行路径，人为因素无处不在灵活性：同一需求多种实现方式，后续变更容易快速2.1算法概述定义在有限步骤内解决问题的一系列明确指令特征输入项：一个算法必须有零个或多个输入输出项：一个算法必须有一个或多个输出明确性：算法每一步骤必须有确切的定义有限性：算法必须在有限步骤内完成任务有效性：每一步骤可分解为基本运算步骤复杂度时间复杂度、空间复杂度2.1软硬件差异硬件是物理实体，软件是逻辑关系硬件变更周期长，软件变更容易快速硬件有磨损现象，软件虽无磨损，但有退化现象硬件质量取决于设计、开发和生产，软件质量取决于设计和开发，与生产基本无关硬件失效先有征兆再发生，软件失效没有征兆突然发生，软件失效率远高于硬件（100：1）硬件部件可以标准化，软件组件标准化较为复杂细微变更对硬件影响有限，对软件影响可能严重2.2软件危机对开发进度和成本的估计常常很不准确用户对交付软件不满意的现象常常发生软件产品质量往往靠不住软件常常是不可维护的软件没有合适的文档资料软件成本占计算机总成本的比例逐年上升软件生产率增速远远跟不上硬件性能增速2.2软件工程基本原理用分阶段的生存周期过程严格管理坚持进行阶段审评实行严格产品控制采用现代程序设计技术结果应能清楚审评开发小组人员应少而精承认不断改进软件工程实践的必要性2.2软件生存周期体系结构设计详细设计系统测试需求分析集成测试编码运行维护废弃发行安装开发策划配置管理缺陷管理单元测试2.2生存周期模型瀑布模型增量模型2.2生存周期模型快速原型模型螺旋模型2.2生存周期模型V模型W模型2.2软件测试分类黑盒测试、白盒测试（静态测试、动态测试）单元测试、集成测试、系统测试内部测试、用户测试、第三方测试方法白盒测试：代码检查、静态结构、静态质量、基本路径覆盖、逻辑覆盖（语句、判定、条件、多条件）黑盒测试：等价类、边界值、场景法、因果图、正交试验、判定表、随机测试、功能分解、错误推测2.2软件测试系统测试安装性测试、兼容性测试功能测试性能测试、负载测试、压力测试、并发性测试、配置测试、接口测试、可靠性测试、恢复性测试可用性测试、界面测试安全性测试回归测试用于确定软件更改没有产生不良影响或没有引入新缺陷软件如有变更均需进行适当且足够的回归测试2.2软件维护分类完善型：提高软件功能、性能的变更纠正型：纠正软件缺陷的变更适应型：改变软件运行环境的变更统计数据完善型50～66%、纠正型17～21%、适应型18～25%维护费用占软件生存周期总成本的50～80%具体要求软件维护应进行适当且足够的回归测试工作量取决于变更的组件、类型和运行环境工作量也取决于原有开发文档的详尽程度2.2软件文档阶段相应文档开发策划开发计划、质量管理计划、风险管理计划、配置管理计划、文档计划需求分析需求规格、初步测试计划设计设计规格、各级测试计划编码代码规范、问题解决程序测试各级测试报告、问题解决程序发行安装说明书运行维护维护计划、问题解决程序2.2软件与软件工程2.3软件质量概述名称Bug、缺陷、错误、故障、失效、异常根源软件若超过169行可执行代码无法确保完全正确软件测试由于时间和成本限制不能遍历所有路径属性软件缺陷与生俱来，不可避免，也无法根除现有已知方法不能保证任何软件100%质量原则尽早测试、重点测试、全面测试2.3复杂度与测试公式软件复杂度=N×I×OPN为软件类型，I为输入次数，O为输出次数，P为指数举例假设N=1，P=2，输入2个参数，输出2个参数，每个参数均为8位数据，执行一次测试耗时1毫秒，则测试所有参数组合耗时为：28×2×（28×2）2/（103×3600×24×365）≈8925年假设用户名为10位数字和字母组合，字母区分大小写，测试一个用户名耗时1纳秒，则测试所有用户名耗时为：（10+26×2）10/（109×3600×24×365）≈26年2.3缺陷来源2.3统计数据时间比例需求设计1/3，编码1/6，测试1/2起源阶段需求54%，设计25%，编码15%，其他6%修正成本设计：编码：测试：发布=1：6.5：15：60～100退化现象每修正2～5个缺陷就会产生1个新缺陷群集现象“80%”的缺陷集中于“20%”的程序2.3影响因素计划和资源语言工具和方法文档复杂性环境人员培训组织形式需求转换和可追溯性测试方法维护现有软件原型现有类似软件质量特征设计参数折中2.3质量度量分类产品度量：用于描述产品特征和质量水平项目度量：用于描述项目特性和执行状态过程度量：用于开发和维护过程的优化改进过程度量需求分析度量：功能点度量设计度量：形态度量、界面度量源代码度量：规模度量、Halstead度量测试度量：DRE度量维护度量：SMI度量2.3生存周期质量2.3质量体系与模型质量体系ISO90003（GB/T19003）CMM/CMMISPICE（ISO/IEC15504）质量模型Boehm模型：功能要求、可维护性、可移植性McCall模型：产品运行、产品修改、产品转移ISO9126模型：功能性、可靠性、易用性、效率、维护性、可移植性2.3质量特性与测试3软件标准介绍软件标准概述YY/T0664介绍YY/T0708介绍GB/T25000.51介绍DICOM与HL7简介3.1软件标准概述IEC62304：2006（YY/T0664-2008）IEC60601-1-4：2000（YY/T0708-2009）IEC61508系列7标准（GB/T20438系列）IEC62274：2005（YY0721-2009）ISO/IEC9126系列4标准（GB/T16260系列）ISO/IEC14598系列6标准（GB/T18905系列）ISO/IEC25051：2006（GB/T25000.51-2010）ISO/IEC12119:1994（GB/T17544-1998）DICOM与HL73.1软件标准概述IEC80001-1：2010ApplicationofriskmanagementforIT-networksincorporatingmedicaldevices-part1:roles,responsibilitiesandactivitiesIEC/TR80002-1：2009Medicaldevicesoftware-Part1:GuidanceontheapplicationofISO14971tomedicaldevicesoftwareIEC82304-1Healthcaresoftwaresystems-Part1:GeneralrequirementsIEC62366：2007Medicaldevices-Applicationofusabilityengineeringtomedicaldevices3.2YY/T0664介绍背景测试本身不足以确保软件运行的安全性没有已知方法可保证任何软件100%安全性目的规定医疗器械软件的生存周期要求通过规定过程、活动和任务，为医疗器械软件生存周期过程建立共同框架作用通过对设计、测试和验证的详尽严格的要求来增强医疗器械软件的可靠性增强医疗器械软件的安全性和有效性3.2YY/T0664介绍范围医疗器械软件的开发和维护包括未知来源软件（SOUP）医疗器械软件在被开发医疗器械内的已开发的软件系统预期本身用作医疗器械而开发的软件系统未知来源软件已经开发且通常可以得到的，并且不是用以包含在医疗器械内而开发的软件以前开发的、不能得到其开发过程足够记录的软件3.2YY/T0664介绍要求质量管理、风险管理和软件工程相结合实施本标准确定的过程、活动和任务本标准要求生成任务文件本标准要求建立生存周期模型注意事项不为制造商规定组织结构不规定任务文件的特定格式不规定特定的生存周期模型3.2安全性级别严重伤害直接或间接导致下列结果的伤害或疾病：危及生命造成人体功能的永久性损害或者人体结构的永久性损坏需要内科或外科介入以防止人体功能的永久性损害或人体结构的永久性损坏永久性人体功能或结构的不可恢复的损害或损坏，微不足道的损害或损坏除外3.2安全性级别安全性级别A级：不可能对健康有伤害和损坏B级：可能有不严重的伤害C级：可能死亡或严重伤害具体要求制造商应赋予每个软件系统一个安全性级别并形成文档软件系统如分解为软件项，软件项应继承原有安全性级别，除非制造商以文件形式给出理由每个软件系统被赋予安全性级别之前均应按照C级要求安全性分级方案不期望与YY/T0316的风险分级相一致3.2安全性级别软件系统C级软件项B级软件项C级软件项B级软件项C级软件项A级软件单元B级软件单元A级软件单元C级软件单元B级软件单元A级软件单元A级