医疗器械软件的风险控制措施

牛道森 刘晓东 刘阳

1 上海理工大学机械工程学院 （上海 200093）

2 上海出入境检验检疫局机电产品检测技术中心 （上海 200135）

0.引言

随着计算机技术的发展和广泛应用，包含软件的医疗器械也让人类享受到了高科技带来的便利。现在的医疗器械中，从大型的影像诊断设备到小型的监护仪、注射泵等都有软件的身影，软件在医疗器械中所起的作用越来越重要，因而其安全性也受到越来越多的关注。ISO/IEC 导则51:1999 定义安全性为“免除于不可接受的风险”。对于医疗器械软件 , 安全性是指该软件在医疗设备系统运行环境中不产生不可接受的风险。

根据美国FDA 报告，1983～1991 年期间，共有 2792 个医疗器械因质量问题被召回，其中 165 个产品与软件故障相关，约占总数的 6%；1992～1998 年间共召回医疗器械3140 起，其中242 起是由于医疗器械产品中软件失效而引起的，约占总数的7.7%；1999～2005 年期间共有3771 个产品被召回，其中由于软件故障而被召回的产品有 425 个，占全部被召回产品的11.3%。从这些数据可以看出，软件故障导致被召回的医疗器械数量呈比较明显的增长趋势。在国内，软件安全性的研究滞后于软件应用的研究，虽然没有医疗器械软件故障的确切统计数据，但目前，国内医疗器械软件质量、安全性评价方法和法律法规还比较欠缺，更需要引起我们对医疗器械软件的重视[1～3]。

1.医疗器械软件的特点和风险

1.1 医疗器械软件的特点

医疗器械软件是软件的特定应用，具有其他软件的类似特点[4～5]：

（1） 高度抽象性：医疗器械软件是一个具有高度抽象性和严密逻辑性的逻辑系统，人们可以把软件记录在纸上，保存在存储介质中，但却必须通过观察、分析、思考、比较、判断等方法去了解它。

（2） 极强隐藏性：不同于硬件的失效率遵循浴盆曲线，软件的失效往往会毫无征兆的出现，错误更为隐蔽，并且很多错误可能会在长期使用后才能被意识到。

（3） 测试无法充分：由于软件可能的输入范围大，可能的运行路径多，无法穷尽测试，无法全部覆盖，并且从不同角度看，软件的缺陷标准不同，导致软件测试困难重重。

因此，由于以上特点导致软件质量和可靠性问题成为制约软件产业发展的瓶颈，也是医疗器械软件风险无法消除的重要原因。

1.2 医疗器械软件的风险

针对医疗器械软件的风险，理解以下几点很重要[8]：

（1） 软件本身不是危害，但会引发危害处境。不同于热能、电能，软件本身不是危害（伤害的潜在源），接触软件不会受伤，但它可能引起人暴露在危害中，也就是说它会导致一个危害处境，从而造成伤害。

（2） 软件失效表现为随机失效，但实为系统性失效。由于软件没有硬件的老化过程，没有随机失效的问题，但设计错误或运行故障会导致系统失效。

（3） 软件失效概率难以计算，通常基于损害严重度分析。由于软件失效不是随机失效，通常基于软件异常造成伤害的严重度评价其风险。

（4） 软件风险管理是整个医疗器械风险管理的组成部分，孤立进行是不合适的。因为硬件失效、软件失效、硬件和软件风险控制措施的相互依赖。

（5） 一些潜在的软件因素。

• 不正确或不完整的功能规范；

• 应用的软件功能有瑕疵；

• 可能导致不可预测软件行为的硬件或软件失效；

• 合理的可预见的误用；

• 源于SOUP（Software of unknown provenance）的失效或不期望的结果。

2.医疗器械软件的风险控制措施

2.1 复杂系统风险控制方案的选择

医疗器械的风险控制是在风险分析和风险评价的基础上进行的。对于经判断为可接受的风险应当采取可行的措施将风险降到最低；对于经判断为不可接受的风险，应在设计开发阶段依次从以下几个方面进行风险控制方案分析，判定使用一个或多个风险控制措施，以把风险降低到可接受水平[6]。

（1） 用设计方法取得固有安全性（不嵌入瑕疵，发现并消除瑕疵）

• 消除特定的危害；

• 降低损害的发生概率；

• 降低损害的严重度。

固有安全设计是通过移除医疗器械不安全的特征，或改变设计以用一个更安全的方法实现，它是一种消除或最小化危害处境的方法。通常这种方法可以简化设计，使设计更容易实施，并且用户更容易操作。固有安全设计应用于软件的情况包括：

• 消除不必要的特征；

• 改变软件架构，以消除可以导致危害处境的事件序列；

• 简化用户界面，以减少人为使用错误的可能性；

• 规范的软件设计，以消除软件异常。如用静态存储器分配消除动态存储器分配出现的软件异常；用可编程语言的限制版本以消除很可能导致编程错误的结构。

（2） 在医疗器械本身或在制造过程中的防护措施

使用软件的医疗器械的防护措施可以用软件或硬件实现。保护措施的设计应表明防护措施独立于应用功能。当软件防护措施应用于硬件或者相反的情况相对容易实现。选择应用于软件失效的软件防护措施的情况下，要消除一个原因引起的多个失效。如果防护措施用于探测或阻止危害处境，制造商应证明防护措施和提供必要性能的软件之间充分的分离。比如，用于患者的治疗的软件和用于实施软件防护措施的软件运行在两个不同的处理器上。

（3） 安全性信息

• 在产品随附文件中给出警告、使用说明；

• 限制医疗器械的使用或限制使用环境；

• 对操作者进行培训。

医疗器械使用软件很可能导致用户界面更复杂，因此导致更加需要安全性信息，从简单的屏幕警告到复杂的用户手册和明确培训课程。好的用户界面设计可以减少它们的复杂性，用户界面的设计可参考IEC62366[7]。

2.2 风险控制方法

为了有效实施合适的风险控制措施，应详细考虑产品开发和软件生存周期过程。一些在设计初期很容易实施的风险控制措施，如果在开发的后期实施起来会造成费时费力且代价很大。此外，合理的实施风险管理可以把安全相关软件项减少到最小的范围，把风险控制的作用发挥到最需要的地方[8～10]。

2.2.1 容错架构

医疗器械的许多功能可能要求用于确保患者和使用者的安全。这样的功能包括临床不能中断或耽误的功能，以及实施保护性的风险控制措施的功能。

容错设计是改善医疗器械可靠性的很普遍的方法，容错设计的目的是确保安全相关功能在部件故障或软件异常时继续运行。容错设计通常使用冗余，它可能仅仅是备份一个关键部件用于一个部件失效时继续运行，或者由附加的部件组成，用于检测失效并转换到可选择的另一个模式。当容错用于软件失效情况下持续运行的关键功能时，简单的相同软件的多重备份冗余是不够的，由于相同的缺陷将在每一个软件备份中出现，此时，容错措施的多样性将是必要的，附加的软件应避免一个软件缺陷导致它们全部失效。当使用冗余时，信号通知用户很重要，否则医疗器械有可能是在冗余的安全上运行，这样就丧失了冗余本身的意义。当容错技术无法控制系统的故障时，为保证系统在最后的结果状态处于安全可接受的范围内，应采用故障安全技术完成该任务，避免造成灾难性后果。

2.2.2 有效隔离

软件缺陷有可能导致运行在相同硬件的不相关的软件出现错误，所以制造商应选一个方法将安全相关软件和非安全相关软件隔离，并且应表明隔离的有效性。软件项之间的有效隔离必须处理如下易于出现非预期影响的方面：

（1）软件项有可能共享硬件（如处理器、存储器和其他输入/输出器件）造成运行时间冲突，这将阻止软件在预定的时间运行。

（2）软件项在同一内存共存。这将导致一个软件项非预期的改变属于另一软件项的数据。

（3）软件项在共享变量时相互影响，包括全局变量，环境变量和操作系统参数。这将导致一个软件项存在的缺陷传递到另一个软件项。所以软件项直接的共享变量应尽可能的少。

最可靠的分离软件项的形式是让它们运行在分离的处理器上，然而，是否运行在单独的处理器，需要根据详细的结构设计确定一个合适的度。

有效的隔离应证明，在正常运行的情况下：

（a）数据流的破坏应阻止：非安全相关软件项不能修改安全相关软件项；

（b）控制流的破坏应阻止：

• 安全相关功能能在正确的时间执行，不被非安全相关软件项的动作影响；

• 非安全相关软件项不能修改安全相关软件项；

（c）执行环境的破坏应阻止：用于安全相关和非安全相关软件项的部件的破坏不应出现。2.2.3 降级运行

在一些情况下，安全性以牺牲部分功能为代价实现。在失效-安全的架构下，系统可以持续安全运行，但是需要降级运行（比如降容或延长响应时间等）。

2.2.4 及时阻止和通知危害处境

风险控制措施的分类可以有效提高阻止危害处境出现的概率。除了阻止危害处境的出现，还应考虑将检测到的故障及时通知用户，防止一系列风险控制措施失效最终导致伤害的出现。此外，还应考虑软件风险控制措施运行频率，以确保在失效引起伤害之前软件风险控制措施能够将失效检测出来。

2.2.5 过程作为一项风险控制措施

如果软件异常能导致一系列危害事件发生，很难设计采用一些风险控制措施阻止伤害发生，那么最好使用固有安全设计来解决。如果软件异常还得不到解决，一个有效的软件开发过程和风险管理过程将可能有助于减少软件异常出现的概率。一个普遍认可的观点是，软件开发过程和风险管理过程越严格，软件异常越少。虽然测试也能减少软件异常的数量，但是仅靠测试不足以建立软件置信度。

2.2.6 SOUP（Software Of Unknown Provenance）的考虑

SOUP 指已经开发且通常可得到的，并不是为用以包含在医疗器械内而开发的软件项（也通称为成品软件），或以前开发的、不能得到其开发过程足够记录的软件。当医疗器械包含SOUP 时，需要注意由于SOUP 的使用造成医疗器械的安全性打折。

2.2.7 软件独立第三方测试

软件独立第三方测试是独立软件验证与确认的一种形式，在包含安全相关软件的设备中，除了进行系统全面的软件测试，还应进行第三方独立测试。其目的是进一步加强软件开发的质量保证工作，进行第三方独立测试有以下优点：

（1） 发挥专业技术优势。通常确定进行独立测试的机构是一些权威性的、具有软件测试专业技术和丰富经验的机构，由他们进行独立测试能较有效地发挥专业技术优势。

（2） 发挥独立性优势。第三方测试机构相对独立于软件任务的交办方、承制方，可以比较客观地开展工作。

（3） 进一步促进承制方的工作。在承制方完成软件开发工作后，还要由第三方进行独立的验证与确认，无意会进一步促进承制方改进和加强其自身的质量保证工作。

总之，针对医疗器械软件的风险控制，在风险控制方案实施前，如果经方案分析确定所需的风险降低是不可行的，则应收集相关资料对剩余风险进行风险/受益分析；若经评审所收集的资料和文献不支持受益大于风险，则应放弃设计。反之，应确保经判定的危害处境产生的一个或多个风险得到了考虑，保证风险控制的完整性。在风险控制方案实施中或实施后，应对实施效果进行验证，以确定控制措施的适应性和有效性，对任何剩余风险都应根据风险可接受准则进行评价，对判断为不可接受的风险，还应采取进一步的风险控制措施。如果控制措施不可行，则应收集和评审相关的资料和文献对剩余风险进行风险/受益分析，若受益大于风险，则剩余风险依然是可接收到，如果风险大于受益，则为不可接受。对于判断为可接受的剩余风险，还应协调决定哪些剩余风险应予以公开，依据ISO14971:2007(等同于YY/T0316：2008)附件J 的指南公开那些剩余风险。同时对控制措施的实施是否会引起的一个或多个新的风险，或对采取措施之前评价的风险是否有影响进行分析，必要时再次进行风险分析、风险评价和风险控制，所采取活动的结果应进行记录并保存，以便于对风险管理过程进行修改、补充和更新。

3.结语

本文提出了一些针对医疗器械软件的风险控制措施，希望在推动医疗器械软件的安全性和可靠性研究等方面起到抛砖引玉的作用。同时，由于医疗器械软件故障的多样性和复杂性，往往很难确保软件百分之百的安全。针对医疗器械软件的风险，不仅要从技术方面而且要从管理方面和评审方面保证系统可靠运行。在技术方面，要在需求分析、设计实现、验证确认和后期维护等阶段采取避免失效和控制失效的措施；在管理方面，要加强质量管理、风险管理、软件生命周期过程的严格控制和相关法律法规制定；在评审方面，要进行独立的第三方审评，进一步确保软件质量。只有通过全方位的对医疗器械软件进行控制，才能尽可能地减少医疗器械软件的风险和危害。

[1] 郝素丽，王云山.软件故障导致召回的医疗器械数据分析[J].中国医疗器械信息, 2011, 17(4): 51-52.

[2] 李军,杨国忠.浅议我国医疗器械软件监管工作[J].中国医疗器械杂志,2011,35(3):210-212.

[3] 俞思聪,潘鹰,俞西萍等.国内外医疗器械软件安全性评价方法比较研究[J].中国医疗器械杂志,2010,34(5):360-364.

[4] 杜堃,何涛,马莉.医疗器械软件安全性探讨[J].中国医疗器械信息,2009,15(1):30-33.

[5] 刘斌.软件验证与确认[M].北京：国防工业出版社,2011.

[6] YY/T 0316-2008 医疗器械 风险管理对医疗器械的应用[S].

[7] IEC 62366-2007 医疗设备 可用性工程学对医疗设备的应用[S].

[8] IEC/TR 80002-1 Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software, September, 2009.

[9] YY/T 0664-2008 医疗器械软件 软件生存周期过程[S].

[10] GB/T 20438.3-2006 电气/电子/可编程电子安全相关系统的功能安全 第3 部分:软件要求[S].