医疗器械软件标准及测试 

发布时间：2007-8-15 浏览次数：190次
本文作者任海萍女士，博士、国家食品药品监督管理局中检所医疗器械质量监督检验中心;奚廷斐先生，主任、研究员、博士生导师，中国生物医学工程学会常务理事、生物材料分会主任委员，人工器官分会副主任委员，全国医疗器械生物学评价标准化技术委员会主任委员;汤京龙先生，助理研究员; 王硕先生、王建宇先生，实习研究员; 陆颂芳女士，主任技师。

关键词: 医疗器械 软件标准 测试

一 概述

随着计算机技术的发展，越来越多的医用电气设备中使用了计算机软件技术，其安全性是非常重要的，而它的复杂性超过了那些单纯的治疗和/或诊断医用电气设备。同时，越来越多的软件被用于在医疗监视下对患者进行诊断、治疗或监护。医疗器械的许多重要功能，越来越多地依靠软件进行控制，因此，医疗器械中软件错误导致的后果可能非常严重。而软件产品可能在六个月内就已经过时了。从而，在医疗器械生产企业和管理部门之间存在着矛盾: 生产企业必须尽快使新的含软件器械上市，但同时，管理部门必须保护公众免受与软件相关的器械故障造成的危害。
2003年开始，我国国家食品药品监督管理局将相关软件纳入了医疗器械管理。软件质量已成为大家共同关注的焦点。由于我国目前医疗器械管理的技术基础主要是产品的安规网黑名单测试，因此，软件测试是否充分、有效，直接影响到软件产品的质量，也影响着是否能够对医疗器械软件进行有效管理。但是，由于软件产品的特殊性，我国至今尚未形成医疗器械软件产品测试的国家标准和行业标准。本文通过对美国FDA的医疗器械软件管理、软件工程以及软件测试情况的介绍，希望能为我国加强医疗器械软件的管理、尽快制定技术标准提供参考。

二 软件的特殊性

美国FDA对于作为医疗器械组件、部件或附件的软件、本身就是医疗器械的软件(例如模拟重建血管系统软件)、加工制造医疗器械时使用的软件(例如加工器械时使用的逻辑控制程序)以及器械制造商在质控系统中所使用的软件(例如记录和保存器械历史记录的软件)都根据其特定的使用要求进行验证。
软件与硬件的特性非常不同。其中的一个不同点就是几乎所有的软件问题都是在软件开发过程中的错误造成的。软件错误在本质上是系统性的，而不是随机的。软件本身不会因为磨损而导致运行失败，从安装开始，就包含了那些导致失败的所有错误。软件的质量问题事实上是设计问题，一般来说不是生产问题。

软件与硬件的第二个不同点就是软件的复杂性。由于软件对于不同的输入执行不同的语句(路径)，因此，即使对一个简单程序，测试其全部可能的执行路径都是不切合实际的。所以，几乎不可能确定该软件是否完全没有错误。故此，软件的质量不能够单单通过测试衡量。

软件和硬件的第三个不同之处在于软件的灵活性。在开发周期的后继阶段，软件的改变会更容易一些。这提供了更多的灵活性，使得人们可以更好地根据硬件的要求以及开发中出现的其他问题的要求进行工作。由于软件可以比较容易地进行更改，可能造成人们误认为软件的错误也非常容易改正。事实上，对软件的某个部分进行改动，即使是对那些看起来很不合理的部分进行改动，都可能导致其他部分的意外错误。美国FDA对1992至1998年之间认证的3140个医疗器械软件系统进行了回顾性分析，在这3140例中，有242例(7.7%)软件系统失效，而其中192例(79%)是由于对软件最初版本进行修改后导致软件系统出现缺陷并造成软件系统失效的。
软件组成虽然不象硬件组成那样有一定的标准和可替代品，但在其开发中，开发者常常使用某些单元开发工具和技术。目标定项方法和现有软件单元的使用将会加快软件开发速度，降低软件开发费用。然而，基本单元需要在集成过程中更加小心谨慎，在集成之前，要全面定义、扩展可重复应用软件代码，全面理解现有单元的作用。

因此，设计合理有效的软件、编程实现它，并确保进行的改动是完全且正确的，这需要一个系统性的方法。这就是软件工程。软件的测试已经超越了对最终产品的传统测试和评价，还包括了对其生产过程的要求，在风险管理、风险防范和开发生命周期的基础上，从软件工程角度对软件进行管理、测试和评价。美国FDA“General Principles of Software Validation; Final Guidance for Industry and FDA Staff”和IEC 60601-1-4“Medical electrical equipment-Part 1-4: General requirements for safety-collateral standard: Programmable electrical medical systems”都是从这个角度来讨论对于医疗器械软件的管理的。

三 软件管理和标准

FDA使用“测试水平”来评价设备出现潜在危险、设计失误，或者使用该医疗器械软件可能对病人或操作者产生直接或间接伤害的程度。如果软件对设备的操作可能直接使病人和/或操作者致死或重伤，或由软件的错误或信息的滞后而间接引起的死亡或重伤，该软件的测试水平为高。如果软件对设备的操作可能直接使病人和/或操作者非严重伤害，或由软件的错误或信息的滞后而间接引起的非严重伤害，该软件测试水平为中。如果软件的运行错误或设计问题并不引起任何对病人和操作人员的伤害，该软件测试水平为低。软件上市前测试过程的范围和危险管理都是与其测试水平相对应的。

如果生产上可以证明某个医疗器械的软件是使用很好的软件工程过程实现的，那么，对此器械的上市前审查就可以集中于与器械相关的风险以及如何最好地管理这些风险。FDA不对软件开发过程进行审查，这使得上市前审查更加快捷，一致性更强。

软件标准要求对构成软件工程工作的各部分进行详细的文件描述和定义。
表1是FDA软件标准技术小组解释的各种不同水平软件标准。其中，国内比较熟悉的有IEC在1996年5月发布的“IEC 60601-1-4并行标准: 可编程医用电气系统”标准。此标准要求生产商遵循某过程，该过程包括风险分析和开发活动，要求生产商建立该过程的记录以支持使用可编程电子子系统的医用电气设备的安全性声明。IEC 60601-1-4标准作为医疗设备系统的风险管理标准是非常有用的，遵循此标准非常有益。不过，IEC 60601-4是作为一个风险管理标准而起草的，并没有计划阐述软件有效性; 该标准只涵盖了产品生命周期中的设计部分，并没有阐述软件的维护和报废; 该标准阐述了系统水平的风险分析，但是较少阐述软件的规划; IEC 60601-1-4没有涵盖FDA管理的所有医疗器械(如单机软件)。
四 软件的测试

软件的测试应当是在其整个生命周期进行的，V模型是其较常用的测试模型之一。我们必须清楚，并不存在某一种测试模型或者测试方法可以确保对某一个特定软件进行彻底的测试。对所有的程序功能进行测试也不意味着对整个程序进行了测试。测试一个程序的所有代码也不意味着对程序中所有必须的功能进行了测试。即使测试了所有程序的功能和所有程序代码也不代表程序就是100%正确的。一般来说，常见的软件测试可分为白盒测试、黑盒测试和灰盒测试。

白盒测试是基于译码的测试，又被称为结构测试，这项测试的参数是根据源代码提供的信息、设计说明书和其它相关文件得到的。白盒测试一般分为静态测试和动态测试，静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估，而动态测试需要在Host环境或Target环境中实际运行软件，并使用设计的测试用例去探测软件漏洞。静态测试包括代码检查、静态结构分析、代码质量量度等。动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

黑盒测试是指事先计划或规定的测试，又被称为功能测试，它是通过使用整个软件或某种软件功能来严格地进行测试，没有通过检查程序的源代码，或者测试人员并不是很清楚地了解该软件或某种软件功能的源代码程序具体是如何设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。其测试参数是根据软件产品(不管是单元模块还是一个完整的程序)事先设计好的软件用途来确定的。目前常用的测试工具有TeamTest、Robot、QACenter、WebLoad、WebStress等。
灰盒测试就像黑盒测试一样是通过用户界面测试，但是测试人员已经对该软件或某种软件功能的源代码程序具体是如何设计的有所了解，甚至还读过部分源代码，这样，测试人员就可以有的放矢地进行某种确定条件或功能的测试。
虽然软件的安规网黑名单测试并不能完全说明软件没有错误，但是它还是为比较客观地评价软件质量提供了强有力的依据。由于生产商常常不能或出于保密目的不愿意提供源代码，一般安规网黑名单测试都是采用黑盒测试方法。
ISO/IEC 12119-1994(等同于GB/T 17554-1998“信息技术 软件包 质量要求和测试”)规定了对软件包的质量要求，并规定了测试细则，特别是安规网黑名单测试。由于我国目前对医疗器械软件的管理仍然是基于安规网黑名单测试，同时又没有专门适用的测试标准，GB/T 17554就成了目前大多数医疗器械注册产品标准所引用的技术标准。
GB/T 17554从产品描述、用户文档以及程序和数据三个方面规定了软件的质量要求。其中，产品描述的要求包括内容的一般要求、标识和指示、功能说明、可靠性说明、易用性说明、效率说明、可维护性说明、可移植性说明; 用户文档的要求包括完整性、正确性、一致性、易理解性、易浏览性; 程序和数据要求包括功能性、可靠性、易用性、效率、可维护性、可移植性。同时，该标准还描述了测试细节，描述了功能测试(黑盒测试)，没有包括结构测试。

五 结论

医疗器械软件的质量标准比其它医疗器械产品更加复杂，同时，其质量标准的量化也是世界性难题。我国在此类器械的管理、技术标准制定方面需要进行深入的研究和探讨。如何尽快制定标准、形成规范，是摆在我们面前的一个重要课题。


出版日期：2004年12月

顶一下

FDA 对于医疗器械的软件/韧体的风险评估,有其自有的 Guidance,
并不完全采用IEC60601-1-4

顶一下

Quote:

引用第2楼2iso于2008-10-11 05:33发表的  :
FDA 对于医疗器械的软件/韧体的风险评估,有其自有的 Guidance,
并不完全采用IEC60601-1-4

请教下：医疗器械对于软件到底是如何确定其适用范围的呢，比如常规意义上的软件通过电脑安装使用来控制器械那属于医疗器械软件范围应该没问题；如果是该软件或程序代码只是固化或写入到产品里面（芯片上）的，那这个算不算软件的范畴？

楼上说的是啊  不过咨询公司说 固化的程序，属于产品的一部分，只要产品没问题就可以了 
我们现在也在关心软件的问题

以FDA的观点来看,固化的程序也是软件管辖的范围内,产品测试没问题并不代表固化软件没问题,
因很多问题是出在程序的错误,这很难于正常操作中发现到问题,所以要做使用软件的风险分析,
而一般制造商多将固件委外制作,有时并没有源码可供了解与管制,这在以后更换代工厂时,
就有可能发生源码重写后不确定风险存在了.

我的客户就曾经因代工厂的故化软件版本控管有问题,烧录到旧版本,而全面回收过,
这如果不是自己烧录的话,很难防范,所以应该要有软件验证的程序.

于医疗器械的质量体系,就有规定对于制程,质量检验所用到的软件,第一次使用时要做验证,
于产品设计阶段的软件,可参考 IEC60601-1-4 或 FDA guidance做软件验证, 一个严谨的医疗器械厂,
会将韧体上的固化软件也验证,同时做好版本控管.

固化的软件也适用于“IEC 60601-1-4并行标准: 可编程医用电气系统”标准吗？

实务上,申请CE时,多是软件才用 IEC60601-1-4, 固化软件其实也适用,总比不用好,
只是大家都想省事,所以能省则省,被认证单位要求时,才做.

在Fda的規範下, 每種軟件需要的文件是不同的, 分為三種:majoy, moderate and minor.
公司最近請了個part-time的顧問, 他以前是510(K) reviewer, 審過的產品包含majoy, moderate and minor三種, 為了賺多點威望金币, 有問題我可以代問唄~

依据 FDA
Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices - Guidance for Industry and FDA Staff

所谓的软体适用范围如下,已包含 firmware.

Scope

For the purposes of this document, we refer to devices that contain one or more software components, parts, or accessories, or are composed solely of software as “software devices,” including:

    * firmware and other means for software-based control of medical devices
    * stand-alone software applications
    * software intended for installation in general-purpose computers
    * dedicated hardware/software medical devices.
    * accessories to medical devices when those accessories contain or are composed of software.

FDA 已采认  IEC  60601-1-4:2000 标准, (Effective Date: 07/31/2008)
IEC  60601-1-4:2000, Medical electrical equipment - Part 1: General requirements for safety - 4 - Collateral standard: Programmable electrical medical systems, edition 1.1. (General) ,

但也提出若干要求与但书:
Extent of Recognition:
IEC 60601-1-4 specifies basic requirements for the process by which programmable electrical medical systems are designed. The standard provides basic risk management processes that may be applied to the development and qualification of programmable electrical medical systems.

Portions of this standard related to risk estimation do not appropriately address failures of a systematic nature (hardware design failures and all software failures). The risk associated with a random failure is assessed by considering both the severity of the hazard caused by the failure and the rate of its occurrence. Unlike for random failure, however, the probability or likelihood of systematic failure is impossible to predict. Consequently, hazards associated with risk-related functions subject to systematic failure should be managed based on the severity of the hazard resulting from failure and the assumption that the failure will occur. Hazard management should focus on the mitigation or elimination of hazards that adversely affect patient safety. Hazard analysis should begin with the identification of system requirements and continue throughout the product life cycle. Where applicable, design features should be incorporated that prevent single component failures from adversely affecting patient safety.

When reviewing programmable electrical medical systems, reviewers may request documentation from the risk management file described in IEC 60601-1-4, for example, system requirement specifications, hazard analysis, hazard mitigation features, and validation reports. In addition, because conformity to the IEC 60601-1-4 standard may not be sufficient for purposes of demonstrating safety for regulatory submissions, manufacturers should be encouraged to contact the appropriate ODE reviewing group to determine the applicability of this standard for a specific medical device.
Related CFR Citations and Product Codes:

Other:
This standard is relevant for all programmable electrical medical systems

Relevant Guidance:
Guidance for Industry and FDA Staff - Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices, May 11, 2005

General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002

Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices; Final, September 9, 1999

好主题，关注中。

学习了