中华人民共和国医药行业标准
YY/T 1406—2026代替 YY/T 1406. 1—2016
医疗器械软件 GB/T 42062 应用于
医疗器械软件的指南
Medical device software—Guidance on the application of GB/T 42062 to
medical device software
2026‑03‑09 发布 2027‑03‑01 实施
国家药品监督管理局 发 布
前 言
本文件按照 GB/T 1. 1—2020《标准化工作导则 第 1 部分：标准化文件的结构和起草规则》的规定 。
本文件代替 YY/T 1406. 1—2016《医疗器械软件 第 1 部分：YY/T 0316 应用于医疗器械软件的指 , 与 YY/T 1406. 1—2016 相比，除结构调整和编辑性改动外，主要技术变化如下：
——用 YY/T 0664—2020 及内容代替 YY/T 0664—2008 及内容;
——用 GB/T 42062—2022 及内容代替 YY/T 0316—2016 及内容;
——将“总则 ”更改为“范围 ”和“规范性引用文件 ”(见第 1 章和第 2 章，2016 年版的第 1 章);
——更改了适用范围(见第 1 章，2016 年版的 1. 1);
——将术语“安全相关软件 ”更改为“安全有关软件 ”(见3. 3，2016 年版的2. 3);
——将“风险管理通用要求 ”更改为“风险管理系统通用要求 ”(见第 4 章，2016 年版的第 3 章);
——将“包含软件的安全的系统的特征 ”更改为“包含软件的安全的系统的特性 ”(见4. 1. 4，2016 年
版的 3. 1. 4);
——将“人员资格 ”更改为“人员能力 ”(见 4 . 3，2016 年版的3. 3);
——将“编程经验和意向 ”更改为“编程经验和意识 ”(见 4 . 3. 3，2016 年版的3. 3. 3);
——将“软件开发计划(根据 YY/T 0664—2008)的风险相关主题 ”更改为“软件开发计划(根据 YY/ T 0664)风险相关的特定主题 ”(见 4 . 4. 3，2016 年版的 3. 4. 3);
——将“ 医疗器械预期用途和与安全有关特征的识别 ”更改为“预期用途和可合理预见的误使用 ”(见5. 2，2016 年版的 4. 2)，将“总则 ”更改为“预期用途 ”(见 5. 2. 1，2016 年版的 4. 2. 1)，增加了条标
题“可合理预见的误使用 ”(见5. 2. 2);
——增加了“与安全有关的特性的识别 ”(见5. 3);
——将条标题“危险(源)识别 ”更改为“危险和危险情况的识别 ”(见 5 . 4，2016 年版的4. 3);
——将“估计每个危险情况的风险 ”更改为“风险估计 ”(见 5 . 4，2016 年版的4. 3);
——增加了按伤害的概率和严重度进行风险估计的内容(见5. 5. 3);
——删除了“降低风险 ”条款(见 2016 年版的6. 1);
——将“用设计方法取得固有安全 ”更改为“通过设计和制造获得固有安全 ”，并增加相关内容(见7. 1. 1. 2，2016 年版的 6. 2. 1. 2);
——将“ 安 全 信 息 ”更 改 为“ 安 全 信 息 和 用 户 培 训 ”，并 增 加 相 关 内 容(见 7. 1. 1. 4，2016 年 版 的6 . 2 . 1 . 4);
——将“ 风 险 控 制 措 施 和 软 件 结 构 性 设 计 ”更 改 为“ 风 险 控 制 措 施 和 软 件 体 系 结 构 设 计 ”(见
7. 1. 2. 2，2016 年版的 6. 2. 2. 2);
——将“ 防护性措施细节 ”更改为“ 防护措施细节 ”(见7. 1. 2. 3，2016 年版的 6. 2. 2. 3);
——将“ 软 件 异 常 的 风 险 控 制 措 施 ”更 改 为“ 软 件 反 常 的 风 险 控 制 措 施 ”(见 7. 1. 2. 5，2016 年 版 的
6 . 2 . 2 . 5);
——将“风险/受益分析 ”更改为“受益-风险分析”(见 7 . 4，2016 年版的6. 5);
——将“ 综 合 剩 余 风 险 的 可 接 受 性 评 价 ”更 改 为“ 综 合 剩 余 风 险 评 价 ”(见 第 8 章 ，2016 年 版 的
第 7 章);
——将“风险管理报告 ”更改为“风险管理评审 ”(见第 9 章，2016 年版的第 8 章);
——更改了“生产和生产后信息 ”(见第 10 章 ，2016 年版第 9 章)，将其拆分为“总则 ”(见10. 1)、“信息
收集”(见 10. 2)、“信息评审”(见 10. 3)和“措施”(见 10 . 4)四部分 。
请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别专利的责任 。
本文件由国家药品监督管理局提出 。
本文件由全国医疗器械质量管理和通用要求标准化技术委员会(SAC/TC 221)归口 。
本文件起草单位：北京国医械华光认证有限公司 、中国食品药品检定研究院 、东软医疗系统股份有限公司 、上海市医疗器械检验研究院 、清华大学 、山东省医疗器械和药品包装检验研究院 、深圳迈瑞生物医疗电子股份有限公司 、上海联影医疗科技股份有限公司 、深圳华大智造科技股份有限公司 、上海西门子医疗器械有限公司 、航卫通用电气医疗系统有限公司 、北京透彻未来科技有限公司 。
本文件主要起草人：刘荣敏 、孙业 、郑佳 、邵玉波 、李冲 、马锐兵 、刘重生 、岳小伟 、张克 、何燕德 、李容 、颜妙丽 、卢智 、韩强 、王美英 、常佳 、王婷婷 、戎澄 。
本文件及其所代替文件的历次版本发布情况为：
——2016 年首次发布为YY/T 1406. 1—2016;
——本次为第一次修订 。
引 言
软件通常是医疗器械不可或缺的组成部分 。建立包含软件的医疗器械的安全和有效性，需要知晓软件的预期用途，同时要证明软件的实现满足这些预期用途且不引起任何不可接受的风险 。
软件本身不是危险，但软件可促成危险情况，理解这一点很重要 。宜以系统的视角考虑软件，软件的风险管理不能脱离系统孤立地进行 。
复杂的软件设计可能涉及复杂的事件序列，这些序列可能促成危险情况 。软件风险管理的任务主要包含识别那些能导致危险情况的事件序列 ，以及在这些事件序列中能在哪些位置中断序列 ，以防止伤害的发生或降低其发生的概率 。
注 1： 附录 A 提供了软件相关危险 、危险情况等定义的讨论及事件序列分析的示例 。
促成危险情况的软件事件序列可分为两类：
a) 事件序列表现为软件对输入的不可预见的响应(软件规范中的错误);
b) 事件序列是由编码错误引起的(软件实现中的错误)。
由于正确地规范和实现复杂系统的难度以及完整验证复杂系统的难度，所以这些分类对软件来说是特有的 。
注 2： 附录 B 提供了导致危险的软件原因的示例 。
因为很难估计会促成危险情况的软件反常的概率 ，并且因为软件在使用中不会因为损耗而随机失效，所以软件方面的风险分析宜关注可能导致危险情况的潜在软件功能和软件反常的识别——而不是估计概率 。软件反常引发的风险大多数情况下仅需要评价伤害的严重度 。
风险管理通常是有挑战性的，当涉及软件时更是如此 。本文件条款包含了关于软件特性的额外的细节 ，这为从软件的视角理解 GB/T 42062—2022 提供了指南 。GB/T 42062—2022 和YY/T 0664—2020的内容为本文件提供了基础 。
注 3： 附 录 C 提 供 了 需 要 在 风 险 管 理 活 动(针 对 GB/T 42062—2022 的 条 款)和 软 件 生 存 周 期(针 对 YY/T 0664— 2020 的条款)中避免的与软件有关的潜在隐患 。
注 4： 附录 D 提供了软件生存周期过程与风险管理过程之间的关系的信息 。
本文件方框中的文本内容直接引用自 GB/T 42062—2022 标准 ，在文本的前面写明“GB/T 42062— 2022 原文”。此外，部分章条的标题直接使用 GB/T 42062—2022 相应条款的标题，条款的内容不构成要求，即使标题名称含有要求二字 。
本 文 件 借 鉴 IEC/TR 80002⁃1：2009[7]的 结 构 和 内 容 ，并 根 据 GB/T 42062—2022 和 YY/T 0664— 2020 的要求进行调整 。此外还添加了与最新风险控制技术及风险管理实践有关的示例，以及其他内容 。
本文件在医疗器械/系统中包含软件时供需要实施风险管理的风险管理从业者和需要理解如何满足GB/T 42062 中阐述的风险管理要求的软件工程师使用 。
本文件不涉及已由现有标准或规划中的标准所覆盖的领域，如报警 、可用性工程 、网络 。
不预期将本文件作为法规检查或认证评定活动的依据 。
本文件中“宜 ”用来表示在满足要求的若干可能中推荐特别适合的一种，并未提及或排斥其他的可能性，或者用来表示某种做法更好但不是必需的要求。“宜 ”不应理解为要求 。
本文件的结构：
a) 本文件遵循了 GB/T 42062—2022 的结构，并为与软件有关的风险管理活动提供了指南;
b) 由于软件生存周期中风险管理活动的迭代特性，在提供的信息中存在一些有意的冗余 。
医疗器械软件 GB/T 42062 应用于
医疗器械软件的指南
1 范围
本文件提供了将 GB/T 42062—2022 中包含的要求应用于 YY/T 0664—2020 中所指的医疗器械软件(独 立 软 件 和 软 件 组 件)的 指 南 ，本 文 件 不 增 加 或 改 变 GB/T 42062—2022 或 YY/T 0664—2020 的要求 。
本文件适用于 YY/T 0664—2020 中所指的医疗器械软件 。本文件还适用于需要实施安全风险管理过程的医疗保健环境中的所有软件，而无论其是否被归类为医疗器械 。
本文件不适用于：
——生产或质量管理体系软件;
——软件开发工具 。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款 。其中 ，注日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件 。
GB/T 42062—2022 医疗器械 风险管理对医疗器械的应用
YY/T 0664—2020 医疗器械软件 软件生存周期过程
3 术语和定义
GB/T 42062—2022 和YY/T 0664—2020 界定的以及下列术语和定义适用于本文件 。
3. 1
多样性 diversity
一种冗余的形式 ，其中冗余要素使用不同的(多样的)组件 、技术或方法以降低共同原因导致所有要素同时失效的概率 。
3. 2
冗余 redundancy
提供多个组件或机制来完成同样的功能，使得一个或多个组件或机制的失效不会妨碍功能的执行 。
3. 3
安全有关软件 safety‑related software
能够促成危险情况的软件，或用于实施风险控制措施的软件 。
4 风险管理系统通用要求
4. 1 风险管理过程
4. 1. 1 总则
安全是系统(这里指整个医疗器械)的一个属性，该系统可能包括软件 。风险管理宜在包括软件及其全部硬件环境的系统上进行 。软件风险管理活动不宜脱离系统进行 。
虽然软件方面的风险管理脱离整体医疗器械的风险管理不能有效地进行，但作为软件生存周期的不可或缺的组成部分，有些活动由软件工程师完成可能是最好的 。与用于整体医疗器械风险管理(GB/T42062— 2022)的要素相比，软件中的有些要素需要更多关注并有不同的解释 。为了做到有效，需要强调的是软件方面的风险管理也需要关注医疗器械的风险 。
注 1 ：脱离整体医疗器械的风险管理 ，软件方面的风险管理无法有效地进行 ，因为硬件失效 、软件失效以及硬件和软件的风险控制措施互相依赖 。
注 2： 例如 ，所有的软件失效都是系统性的而非随机的(许多硬件失效/故障是随机的)，且其失效的概率无法精确估计 。 因此，风险的概率要素应用于软件的方式是非常不同的，见 5. 5. 3。
在医疗器械设计的早期阶段，软件工程师有很多机会致力于医疗器械的总体安全 。宜在系统设计确定之前考虑软件在医疗器械安全方面的作用 。
通过参与到医疗器械设计过程 ，随着设计进展 ，软件工程师有助于就软件有关风险做出与安全有关的决定 。这些决定宜包括但不限于：
——提供足够的硬件资源以支持软件;
——硬件和软件间功能的划分;
——整体医疗器械的预期用途和软件用户界面的预期用途;
——避免非必要的复杂软件 。
4. 1. 2 迭代
典型的软件开发生存周期经常使用迭代 。迭代的使用允许：
——研究不同软件设计的可行性;
——在不同时期开发不同的软件项;
——软件不同版本的阶段性交付;
——纠正软件开发过程中产生的错误 。
YY/T 0664—2020 要 求 风 险 管 理 活 动 在 整 个 软 件 生 存 周 期 中 迭 代 并 与 系 统 设 计 活 动 相 协 调 。例如 ，在软件开发期间 ，YY/T 0664—2020 的5. 2. 4 要求在软件需求确定后对医疗器械风险评估进行重新评价 。这种重新评价可能导致系统需求规范和医疗器械风险评估的更新 。风险评价宜在需求 、体系结构设计和详细设计直至软件实现的所有阶段重复进行 。
GB/T 42062 没有规定设计和开发过程 ，其通常只要求在设计(包括风险控制措施)实现之前和之后(而不是设计期间)完成风险管理步骤 。例如 ，当一个风险控制措施已被实施 ，GB/T 42062 要求对其进行评审以确保其没有引起任何进一步的危险和危险情况 。这不宜理解为仅在实施完成之后才要求进行这种评审——比较有利的做法是：一旦进一步的危险显现出来就需要进行处置 。这意味着在风险控制措施实施过程中进行迭代 。
所有的交付物始终保持一致是很重要的 。迭代对交付物的一致性是一种威胁 。 因此，应用严格的配置管理很重要 ，以保证变更的所有影响都被识别 ，且所有相关的交付物在变更后得到更新 。 当涉及软件时，这一点尤其重要，因为软件可能很快变更，一个看上去小的变更可能产生非预期的负面影响 。与软件有关的所有信息都需要是最新的 ，以避免工程师间的错误交流 。宜检查软件变更提案的负面影响 ，特别是影响安全的负面影响 。这可能导致风险管理过程的某些部分重复进行 。
4. 1. 3 主动的或被动的安全设计方法
风险管理宜随着医疗器械规范的实质性输入尽早开始，在设计早期阶段考虑安全，也就是说，主动的设计方法比被动的设计方法更好 。在主动方法中 ，安全与其他客户需求一起被考虑 ，并转化为早期的安全需求 。尽管被动方法有时不可避免(例如在更新遗留产品时)，但主动方法通常是获得安全的医疗器械最有效 、最快捷和最经济的方法 。
主动的安全设计的优点如下：
——从一开始系统规范不仅包含医疗器械要做什么，也识别宜避免的系统行为以降低风险;
——从一开始就能策划系统的体系结构，并能证明其在避免或防止不安全状态的同时提供想要的功
能特性;
——因为体系结构已被精心细致地融入全部的设计中，能在避免返工的同时开发风险控制措施;
——能在早期作出安全方法和风险控制措施的选择(例如，可使通过设计的固有安全最大化，并使安全信息最小化)。
4. 1. 4 包含软件的安全的系统的特性
安全的系统高度期望的特性包括：
——使用简单的硬件安全机制以避免对安全有关软件项的过度需求;
——仅使用非常简单的安全有关软件项;
——安全有关软件项分布在若干独立的处理器中;
——足够的硬件资源，以在需要时运行所有安全有关软件，避免资源争夺;
——使用确定性软件时序设计;
——失效情况下的适当处理，例如：
• 警告用户存在失效并留出知情干预的机会;
• 在失效的情况下提供简化功能;
• 在失效的情况下，可能时，安全地关断;
• 从失效中快速恢复;
——防止软件代码在其运行环境中被修改的方法，包括软件自行修改或由数据输入造成的修改;
——检出和/或防止与安全有关的数据损坏的方法 。
4. 2 管理职责
GB/T 42062—2022 和YY/T 0664—2020 都设定已建立质量管理体系 。GB/T 42062—2022 的4. 2列出了风险管理对最高管理者的要求 。
注： GB/T 42062—2022 的4. 1 规定风险管理能作为质量管理体系的一个不可或缺的组成部分 ，并且 YY/T 0664— 2020 的4. 1 规定能通过使用符合 GB/T 42061[2]的质量管理体系或国家法规要求的质量管理体系来证明制造商具备始终如一地满足客户要求和适用的法规要求的能力 。YY/T 0664—2020 的附录 B 中的 B . 4 也提供了关于其 4 . 1 条款的指南 ，说明有必要作为质量管理体系的一个不可或缺的组成部分建立风险管理过程 ，作为应用适当的软件工程方法和技术的整体框架 。
为实现有效的风险管理过程以及对医疗器械软件的安全设计和维护，最高管理者负责将必要的组织结构 、充分的资源 、职责和培训(见 4 . 3)落实到位 。
制造商可考虑将软件开发或维护过程活动外包(如设计 、实现 、测试或维护)。 在这些情况下，最高管理者仍然对确保外包的软件开发或维护过程活动进行适当的风险管理活动，以及对确保风险控制措施的适当实施负全部责任 。
当软件开发外包时 ，制造商宜通过适当的合同来确保对软件及其设计有充分的控制 ，以确保 GB/T 42062 中 要 求 的 全 部 风 险 管 理 在 医 疗 器 械 整 个 生 存 周 期 中 均 得 到 执 行 ，包 括 软 件 发 布 后 软 件 反 常 的纠正 。
制造商宜考虑对供方设定绩效要求(见针对供方控制的GB/T 42061 的 7 . 4)，例如要求供方证实： ——符合 GB/T 42062 的有效的风险管理;
——符合 YY/T 0664 的有效的软件工程实践;
——提供持续满足顾客要求和适用的法规要求的医疗器械软件的能力 。
如果有应用于外包过程或产品的风险控制措施，那么风险控制措施及其重要性宜形成文件并在合同中向供方明确传达 。
4. 3 人员能力
4. 3. 1 总则
参与软件系统开发和维护的小组成员宜具有与其承担的任务相适应的知识和经验 。对承担风险管理相关任务人员的基本要求是具有风险管理所需的知识 。包括临床专家(如临床支持和技术服务专家以及其他相关学科的专家)、软件工程师 、系统设计师 、可用性/人因工程专家和相关领域专家的多学科团队的参与，以及他们与软件工程人员和测试人员互动的程度和类型也宜从风险管理角度加以考虑 。
这可能要求为每一个人制订培训计划以确保对所要求活动的完全理解 。
同样，也宜考虑风险管理小组成员在软件方面的资格而且可能需要专门的培训 。
以下几条提供了宜考虑的所需知识领域的概述 。
4. 3. 2 预期用途/相关领域的知识
在医疗器械设计的所有阶段，有效应用预期用途的知识很重要 。这对于软件设计者和软件风险管理人员尤其重要 。软件的复杂行为很容易促成用户误用或混淆，导致以前未预见的危险和危险情况 。对临床实践彻底的领会能使风险管理者识别危险和危险情况 ，使软件工程师避免危险和危险情况 ，或设计出风险控制措施 。
制造商宜确保临床专家(如临床支持和技术服务专家及其他相关学科的专家)能参与设计活动和风险管理活动，或至少对这些活动提供建议 。
另外，制造商宜考虑对软件工程师和风险管理者提供医疗器械临床应用方面的培训 。
4. 3. 3 编程经验和意识
有经验的软件开发人员和测试人员能逐渐认识到在测试中发现所有软件缺陷的难度，因此也能认识到测试后还存在一定比例的软件缺陷 。在软件开发团队中包含有经验的人员并且给予其适当的权限来指导 、监督和质疑经验少的人员是很重要的 。
为以下软件任务分配有经验的人员尤其重要：
——软件可能的失效方式的识别;
——与软件失效相关的风险分析;
——风险控制措施的识别;
——发布后的问题报告分析;
——变更的设计和实现，特别是软件发布以后 。
在所有这些任务中 ，通过经验会意识到软件及软件开发过程哪里会出错 ，并且意识到进行变更的同时保持软件设计的完整性的难点 。
4. 4 风险管理计划
4. 4. 1 总则
风险管理计划宜通过下列各项阐述软件是医疗器械一部分的事实：
——医疗器械描述，包括医疗器械的何种功能将由软件实现;
——软件将依据 YY/T 0664 开发的声明;
——对软件风险管理特有的软件开发内容的引用;
注： 对软件开发计划的引用也许是表明包含软件风险管理特有的软件开发内容的最简单方式 ，见 4. 4. 2 和4. 4. 3。
其讨论了风险管理计划和软件开发计划的关系及依据 YY/T 0664 的软件开发计划中与风险相关的特定主题 。
——软件导致或软件控制的风险的可接受性准则(如果与医疗器械其他组件的可接受性准则不同)。
软件导致或软件控制的风险的可接受性准则可能与其他组件的风险可接受性准则不同，一个原因是其伤害的概率不能估计 。在这种情况下 ，风险可接受准则宜基于伤害的严重度(见5. 5. 3 关于软件导致伤害的概率的讨论)。 如果能断定危险的实际后果很小 ，风险就能判定为可接受 ，也不必有风险控制措施 。然而，对于重大危险，即能造成高严重度伤害的危险，任何级别的暴露水平都不能被认为其相应的风险低到可接受 。在这种情况下，需要实施风险控制措施 。
当概率无法估计时，剩余风险的可接受性准则宜考虑已实施的风险控制措施及其在降低伤害发生概率方面的有效性 。风险控制措施宜是所有合理可行措施的组合 ，满足适用的标准和法规 ，并符合最新技术水平(见 YY/T 1437—2023[3])。
当策划与生产和生产后信息的收集和评审有关的活动时，对于软件宜考虑以下特定要求 。
——如果使用未知来源软件(SOUP)，宜积极监视和评价可公开获得的反常清单及关于 SOUP 实际
性能的信息 ，并对此做出安排 。如可能 ，在获得 SOUP 的同时 ，宜与 SOUP 供应商达成协议以支持以上活动 。如果医疗器械的使用者可自行(有意地或无意地)修改医疗器械的 SOUP(例如，SOUP 补丁或升级包)，那么宜特别关注和监视市场上提供的 SOUP 新版本 。关于 SOUP 及生产后监视见第 10 章 。
——制造商宜使投诉发起人有可能识别和报告软件的版本 。
4. 4. 2 风险管理计划与软件开发计划的关系
GB/T 42062 对风险管理计划和YY/T 0664 对软件开发计划的要求不宜被视为要求具有特定标题的特定文档 。计划的要素可包含在任何文档中以适应制造商的质量管理体系，只要：
——计划的多文档结合满足上述两个标准要求并可验证;
——所有计划彼此一致;
——所有计划能及时提供使用;
——保持对所有计划的更新以反映不断变化的环境 。
4. 4. 3 软件开发计划(根据 YY/T 0664)风险相关的特定主题
软件开发计划宜确保软件开发过程与软件开发相关的标准 、方法和工具(依据 YY/T 0664—2020 的第 5 章在软件开发计划中的描述)都是有效的风险控制措施(见7. 1. 2. 6 关于过程作为风险控制措施的讨论)。 这可通过由其他组织 、供方和组织内的其他项目提供证据来实现 。否则，就在本项目内策划并验证其有效性 。
当建立医疗器械风险管理过程时 ，宜考虑软件风险管理特有的方面 ，如安全编码标准 、验证方法(如形式化证明 、同行评审 、走查 、仿真等)、语法和逻辑检查器的使用 。如果考虑将这些方面作为风险控制措施，也宜对其进行验证(见表 B . 2 中验证风险控制措施的示例)。
适当时，宜在计划 、程序或培训中对医疗器械开发每个阶段的软件风险管理活动进行说明 。
4. 5 风险管理文档
软件过程宜建立体系以使以下可追溯性成为可能 ，即从软件有关的危险和软件风险控制措施开始 ，并追踪其实施，直至相应的安全有关软件的需求以及满足那些需求的软件项 。
上述所有活动都宜能够追溯至其验证(见 YY/T 0664—2020 的7. 3. 2)。
因为软件在开发期间可频繁变更 ，并因为其可以不同的版本发布 ，与软件有关的那部分风险管理文
档也可能变更并有多个版本 。
表 1 列出了除GB/T 42062—2022 的要求外 ，宜包括在风险管理文档中的 YY/T 0664—2020 对文档的要求 。
表 1 除 GB/T 42062—2022 的要求外宜包括在风险管理文档中的文件要求
5 风险分析
5. 1 风险分析过程
如 GB/T 42062—2022 所述，术语风险分析包含三项不同的活动：
——预期用途的识别;
——已知或可预见的危险(及其原因)的识别;
——估计每个危险和危险情况的风险 。
必须认识到风险分析是整个软件开发过程不可或缺的组成部分 ，而不是一个或两个独立的事件 ，这对于其有效性是非常重要的，因为危险和失效模式信息在软件开发生存周期过程中不断累积并需要在设计的每个阶段加以考虑 。
因为很难估计能促成危险情况的软件反常的概率，软件方面风险分析的关注点主要是对可能导致危险情况的潜在的软件功能和反常的识别——而不是估计概率 。关于估计概率的更多详细描述见 5. 5. 3。
软 件 作 为 促 成 因 素 的 最 坏 情 况 下 伤 害 的 严 重 度 是 确 定 软 件 开 发 过 程 严 格 程 度 的 主 要 输 入(见
YY/T 0664—2020 的4. 3)。 5. 2、5. 3 和 5 . 4 中提供的信息旨在帮助识别有效的风险管理过程中软件特有的方面 。另外 ，软件方面的风险分析在形成的文档中宜是可识别的 ，且宜包括用来对硬件失效实施风险控制措施的软件，以及导致危险的软件原因和相关的风险控制措施 。
5. 2 预期用途和可合理预见的误使用
5. 2. 1 预期用途
每个医疗器械都有其预期用途，同时还宜考虑到对这些用途存在有意或无意的误用的可能 。尽管这不是软件特有的问题，但软件的使用可导致误用风险的增加，因为：
——医疗器械的行为更加复杂，因此更加难以掌握或理解;
——使用者可能对软件过分依赖，而不理解其局限性;
——医疗器械可能是可配置的，而使用者可能没有注意到当前配置;
——医疗器械可能与其他医疗器械或非医疗器械以其制造商无法详细预期的方式进行通信 。
负责生成系统需求的人员和软件工程师有一个共同的责任——将包括软件在内的系统的预期用途以及所有与安全和安全使用有关的系统和软件需求一起记录在风险管理文档中 。软件工程师具体负责识别在系统水平上过于细微而不明显的预期用途部分 。
5. 2. 2 可合理预见的误使用
5. 2. 2. 1 用户界面
软件使设计更加灵活的用户界面成为可能 ，而这可影响用户的行为 ，导致可合理预见的误使用的新形式 。通常的误用源于对过于复杂的用户界面的误解和为避免错误和不安全状态而过分依赖软件 。重要的是预见这些误使用和改变设计以尽可能地避免这些误使用 。
这包括多语言标记的实现，特别是当这种标记是风险控制措施时 。 以下几点宜特别注意：
a) 不同语言对存储空间的不同需求;
b) 不同字符集的使用;
c) 使用字符代替符号;
d) 使用不同的单位可能需要对数据结果进行额外的换算;
e) 日期格式和数字标点;
f) 不同语言和/或字符集不同的布局要求;
g) 对确认的支持 。
作为对 GB/T 42062 的补充，可用性过程的内容见 IEC 62366_1。
5. 2. 2. 2 医疗器械的相互连接
医疗器械软件的使用使医疗器械和非医疗器械之间各种相互连接和相互通信成为可能 。这些连接和通信很可能产生由医疗器械和所连接器械组成的系统的新应用(和误用)。 虽然容易预见到可发生这种新的应用和误用，但如果这些连接和通信不受限制，医疗器械制造商就不易识别所有这种应用和误用 。
因此 ，制造商对医疗器械的通信接口规定了有限的预期用途 ，并在设计接口时尽可能将连接和通信限制在安全的范围，这是很重要的 。
例如，软件利用医疗器械内置接口，基于对用户 、患者的识别以及数据产生的前后关系，检查输入的治疗数据的一致性和合理性 。如果数据由外部产生并通过网络连接输入到医疗器械中，则可能无法进行同样的检查 。在这种情况下，制造商可考虑将这种软件检查作为一种网络应用，使之对网络用户可用，和/或将输入的数据限制在可信任的数据源，并为在临床环境中负责网络连接的人员编写一份全面的手册 。
IEC 80001_1[6]包含了临床环境下医疗器械与 IT 网络的集成 ，其具体描述了制造商和将医疗器械接入 IT 网络的人员的责任 。
5. 3 与安全有关的特性的识别
没有用于软件的补充指南 。
5. 4 危险和危险情况的识别
危险识别的目的是分析所有可预见的危险，并设计和实施有效的风险控制措施 。
与热能 、电能或者悬挂物不同，软件本身不是危险(可能导致伤害的潜在根源);与软件接触不会造成损伤 。然而，软件可能导致人体暴露在危险下，换句话说，它可能促成危险情况 。软件失效(任何形式)常常促使危险转化为危险情况 。
因此虽然软件很少引入新的危险，但其经常改变危险情况 。更重要的是，对制造商而言，它可将避免危险情况的责任由用户转移到制造商 。
例如 ，手术刀存在显而易见的切伤危险 。然而 ，对这种危险制造商按惯例不承担人体工程学设计以外的责任，因为这种危险被假定完全在外科医生的控制范围内 。如果手术刀是远程外科手术系统的一部分，同样的危险仍然存在，但现在避免切伤危险的责任要由提供手术刀控制软件的制造商分担 。
这意味着一些在没有软件时仅依靠器械的专业使用进行风险控制的危险，现在转为由制造商通过软件风险管理来控制 。
一个重要的案例是由数据误处理带来的误诊的危险 。这的确是一种危险，但当这些数据由临床医生处理时 ，制造商就没有责任 。现在许多医疗器械利用软件来生成 、存储 、处理或使用数据 ，这使得该危险部分成为制造商的责任 。
软件促成危险情况可有多种方式，包括以下几种情况(见附录 B)：
——软件可能正确地实现了某个不安全的系统需求，导致具有危险性质的行为直到实际伤害发生才被察觉;
——软件规范可能错误地实现了系统需求，导致非预期的行为，虽然这种行为符合软件规范;
——软件的设计和实现可能出错，导致软件的行为与规范相违背 。 明显的错误可能源于对软件规范的误解，以及将规范转换为代码时的差错 。而较不明显的错误可能源于软件项间和软件与其基础设施(包括硬件和操作系统)间的非预期交互 。
对包含软件的医疗器械，进行仔细和全面的危险识别可(在风险管理过程的后期)带来以下重要成果： ——防止软件导致伤害的硬件风险控制措施;
——将潜在有害的软件功能从设计规范中删除;
——使用软件来防止伤害的风险控制措施(见 YY/T 0664—2020 的5. 2. 3);
——识别软件中需要以低错误率实现的部分和软件规范中需要进行特殊测试的部分(见 YY/T0664— 2020 的 4 . 3);
——识别较高安全级别的软件项，其需要与其他软件项(较低的软件安全级别)隔离以防止非预期负面影响产生的伤害(见 YY/T 0664—2020 的4. 3 和 5. 3. 5)。 对此进一步的讨论见 7. 1. 2. 2. 4。
为充分识别危险，医疗器械的临床使用需要得到充分理解 。另外，软件的复杂性带来了特别的挑战，包括可能的复杂用户界面 。 因此 ，软件危险的识别不能孤立地进行 ，其宜由多学科的团队在系统层面开展 ，团队中包括临床专家(如临床支持和技术服务专家)、软件工程师 、系统设计师以及可用性/人因工程专家(见 4 . 3)。
危险识别宜考虑由医疗器械的性质导致的伤害(如切伤 、辐射或电死患者)及与软件使用有关的额外的危险 。后者可能包括：
——向临床医生或患者提供错误信息;
——对患者的错误识别(在医疗器械存储患者详情和处方的情况下);
——由软件反常引起的治疗延误或治疗无法进行 。
注： 对许多医疗器械来说，治疗延误或治疗无法进行不被认为是对患者的伤害 。
识别的危险宜包括按其规范操作时与软件有关的危险，和与软件反常有关的危险(见7. 1)。
通常软件使得医疗器械的用户界面更加复杂 。特别是包括软件的医疗器械经常处理信息，在根据患者的受益判别合理性的同时，还宜考虑与错误信息或错误使用信息有关的额外的危险，例如：
——错误的数据输入;
——引起用户误读的显示;
——用户对报警的误解和忽视;
——由于数据或报警过多使用户应接不暇(见 IEC 62366_1[5])。
5. 5 风险估计
5. 5. 1 总则
要估计与软件有关的风险，首先需要识别包括软件在内的危险情况 。软件既可能是导致危险情况的事件序列的初始原因 ，也可能位于事件序列的其他位置 ，就像预期检出硬件故障的软件的情况 。软件可能包含未知来源软件(SOUP)组件或重用的先前开发的组件 。
风险估计基于每个已识别的危险情况所导致的伤害的概率和严重度 。 因为很难估计软件反常引发伤害的概率(见5. 5. 3)，所以在估计导致伤害的事件序列中包含软件反常的危险情况的风险时 ，需要谨慎使用软件反常发生的概率 。
5. 5. 2 识别的方法
有多种方法可用来识别软件在危险情况中的潜在作用 。这些技术采用不同的途径，在软件开发的不同阶段发挥作用 。其中的任何一种都不是唯一恰当的方法 。关于风险分析的一些可获得的技术信息见YY/T 1437—2023 的附录 B 。
故障树分析(FTA)是一种传统的自上而下的方法(见 IEC 61025[4])，其通常从医疗器械整体开始分析 。FTA 主要用于分析伤害的起因 。其假定伤害发生 ，利用布尔逻辑来识别伤害发生必需的事件或条件 。 以逐步细化的方式分析事件或条件 ，直到能防止伤害的一个或多个风险控制措施得到识别 。FTA能用来识别导致危险情况的事件序列中包含的软件项 。
失效模式和效应分析(FMEA)是一种自下至上的方法(见 GB/T 7826[1])，其从组件或子系统(对软件来说就是 YY/T 0664 中的软件项)开始，并提出问题：如果该要素失效，那后果是什么?
考虑到预见每个软件项中存在哪些软件缺陷的难度 ，FMEA 的起始点会是列出每个软件项的安全有关需求，并考虑这个问题：如果该需求无法满足，那后果是什么?
这使得失效会引起伤害的软件项，以及需要防止的失效类型得到识别 。
当识别能导致危险情况的事件序列或事件组合时 ，关注直接与医疗器械基本性能有关的软件(如计算血液葡萄糖水平的算法)以及危险有关的具体原因是最容易的 。考虑能导致不明显的失效模式并因此导致一个或多个医疗器械危险的软件原因也很重要 。软件原因的示例见附录 B 。
注： 具体原因是软件中的缺陷，而软件的功能明显与器械临床功能有关，并导致器械的危险 。例如，计算试验结果的算法缺陷 。
精确地预见在软件项中发生什么失效是困难的 ，但识别缺陷的类别是可能的 ，每一类都有众所周知的风险控制措施 。例如，数据崩溃类故障能通过求和校验程序来检出和防止 。软件原因示例及建议的处理方式见附录 B 。制造商宜保持自己的与其产品相关的软件缺陷类别清单 。
5. 5. 3 概率
特定版本软件中的反常在该软件的所有拷贝中都会出现 。然而因为软件的每个单独拷贝输入的随机性，软件反常导致软件失效的概率很难估计 。
关于估计软件失效发生概率的方法不存在共识 。如果软件出现在导致危险情况的事件序列中，在估计危险情况的风险时不宜考虑软件失效发生的概率 。此时考虑最不利情况下的概率是适当的，并宜将软件失效发生的概率设为 1 。 当可能做到估计序列中其余事件(如果其不是软件)的概率时 ，该概率可用作危险情况发生的概率(图 1 中的 P1)。 如果无法做到，危险情况发生的概率宜设为 1。
估计危险情况导致伤害的概率(图 1 中的 P2)通常需要临床知识 ，以区分临床实践有可能防止伤害发生的危险情况和更可能导致伤害的危险情况 。
注 1：基于医疗器械的复杂程度，一个危险可能导致多个危险情况，并且每个危险情况可能导致多种伤害 。
注 2：伤害发生概率(P)由独立的 P1 和 P2 组成 。
注 3：细箭头代表风险分析的要素，粗箭头描绘了危险如何导致伤害 。
图 1 危险、事件序列、危险情况和伤害之间的关系图示示例(取自 GB/T 42062—2022 的附录 C)
在许多情况下 ，可能无法估计伤害发生的概率 ，宜仅依据伤害的严重度估计风险 。在这些情况下的风险估计宜关注危险情况引发的伤害的严重度 。
虽然可能无法估计软件失效发生的概率，但很明显许多风险控制措施降低了这种失效导致危险情况的概率 。例如，软件反常导致的内存崩溃 。 内存求和校验会检出失效并降低危险情况的概率 。该求和校验不能保证所有可能的崩溃都被检出 ，然而 ，这种手段将检出绝大部分此类崩溃并因此把风险降低至可接受水平 。虽然在实施求和校验之前或之后都无法估计危险情况发生的概率，但能断定求和校验执行后危险情况发生的概率比实施求和校验之前要低 。制造商有责任证实风险控制措施对于剩余风险满足风险管理计划规定的可接受性准则是有效的 。
总之 ，软件的风险估计宜主要关注失效发生时伤害的严重度和相对概率 ，而不是试图估计每个可能的软件失效的概率 。
注： 这有助于对相同严重度的危险进行甄别，以便更加关注那些具有更高实际伤害概率的危险 。
尽管如此，如果有以往类似软件的设计开发经验 、历史数据或上市前软件测试数据，亦或类似软件上市后的反馈信息，也可用来估计当前软件可能发生的伤害的概率，并和伤害的严重度一起考虑 。
5. 5. 4 严重度
对软件导致的风险的严重度的估计对所采用的软件开发过程有影响 。根据 YY/T 0664，过程的严格程度取决于软件可能导致的伤害的严重度 。
为了按照 GB/T 42062 进行风险评价 ，如何定义严重度等级取决于制造商 ，但与 YY/T 0664 中软件安全分级相联系对定义严重度等级是有帮助的 。否则可能需要两次定义严重度，一次为了整个风险管理过程所需的风险评价，另一次为依据 YY/T 0664 确定软件安全级别 。
6 风险评价
如 5. 5. 3 所述 ，很难估计软件失效的概率 。 当这导致伤害的概率不能估计时 ，宜仅基于伤害的严重度评价风险 。
7 风险控制
7. 1 风险控制方案分析
7. 1. 1 复杂系统风险控制方案的选择
7. 1. 1. 1 总则
在复杂系统中，可能有许多能导致危险情况的事件序列 。不可能或没有必要对这种序列中的每个事件都应用风险控制措施 。对所选事件应用风险控制措施就足以把伤害的总概率降至可接受水平 。
7. 1. 1. 2~7 . 1. 1. 4 给出了如何在软件中实施三种风险控制措施的概述 。另外还讨论了到底哪些事件需要风险控制措施(见7. 1. 1. 5)。
7. 1. 1. 2 通过设计和制造获得固有安全
通过设计获得固有安全常通过消除医疗器械不安全的功能特性来实现，或者通过改变设计用更安全的方法(即以避免或最小化危险情况的方法)来实现功能特性 。这通常有简化设计的效果，使设计更易实现 、用户更易操作 。
对于在软件中实现的功能特性更是如此 。不加辨别地在软件系统中包含所有可能的客户期望是 一种误区 。这可能导致软件组件间能交互的方式大量增加，引入意想不到的危险情况 。通过在医疗器械及其软件的开发过程的早期实施风险管理，能够避免这些问题同时仍然使大部分客户满意 。
在大多数情况下，对于软件通过设计的方法取得固有安全涉及：
——除去不必要的功能特性;
——改变软件体系结构以避免导致危险情况的事件序列;
——简化用户界面以降低使用时人为错误的概率;
——规定软件设计规则以避免软件反常 。
规定软件设计规则以避免软件反常的示例包括：
——仅使用静态内存分配以避免与动态内存分配有关的软件反常;
——使用限定的编程语言版本以避免可能导致编程错误的结构 。
关于通过制造获得固有安全，宜特别关注软件拷贝过程所用软件 、工具及设备的确认和维护，确保所拷贝的医疗器械软件的完整性，并防止对软件安全产生不良影响 。
7. 1. 1. 3 防护措施
使用软件的医疗器械的防护措施能通过硬件或软件实施 。 防护措施的设计宜证明其独立于所应用部分的功能 。如果在硬件上应用软件防护措施，相对容易实施，反之亦然 。
在选择以软件方式实施防护措施并应用于软件时 ，避免同一个原因导致多重失效的可能性是重要的 。如果一个防护措施检出和/或防止一个危险情况 ，制造商宜证明该防护措施和提供基本性能的软件功能特性具有充分的隔离 。
例如 ，为患者提供治疗的软件可在一个处理器上运行 ，而实施软件防护措施的软件在另一个独立的处理器上运行 。
7. 1. 1. 4 安全信息和用户培训
医疗器械中软件的使用很可能导致比用户所看到的更加复杂的情况 。这很可能导致对安全信息的更多依赖，从简单的屏幕警告到复杂的用户手册和明确定义的培训课程 。通过注重良好的用户界面设计能降低这些书面材料的量和复杂程度 。
医疗器械软件的使用经常涉及培训，如果将用户培训作为风险控制手段，则培训资料属于安全信息;此外，制造商还宜确保在软件预期使用寿命内具备相应的培训能力，见 IEC 62366⁃1[5]。
7. 1. 1. 5 哪些事件需要风险控制措施
许多事件序列都可能导致危险情况 。不可能或不必要对这些序列中的每个事件应用风险控制措施 。有选择地对一些事件应用风险控制措施，就足以把总的伤害概率降至可接受水平 。
在决定哪些事件宜被检出 、阻止或使其发生的可能性降低时 ，绘制出能导致危险情况的事件序列显然是有帮助的 。虽然故障树分析(见5. 5. 2)不显示事件序列 ，但能通过它来识别这些序列 。风险控制措施的正确运行将作为“与门 ”的一个“非 ”输入 ，不管“与门 ”其他的输入是什么 ，伤害都会被阻止 。 图 2 表示 FTA 图的一部分 ，图中一个不正确的软件输出(其本身是一个事件序列的输出)由旨在检测不安全情况的风险控制措施所阻止 ，防止其对患者造成伤害 ，并防止输出有害影响(如通过终止一个动作)。 只有当风险控制措施失效时 ，不正确的软件输出才能导致对患者的伤害 。需要注意的是 ，导致不正确软件输出的事件序列并不需要被详细探究以确保其不能导致对患者的伤害 。
对患者的伤害
图 2 风险控制措施阻止不正确软件输出引发伤害的 FTA 图示
明显可应用风险控制措施的点包括：
——软件系统作为一个整体的输入;
——软件系统作为一个整体的输出;
——软件模块之间的内部接口 。
限制软件输入范围的风险控制措施能防止不安全的输出 。它也能降低输入导致伤害(由于软件反常)的可能性 ，因为其降低了软件以可能未经测试的非预期方式运行的概率(见5. 5. 3)，但这种降低不是太明显 。
限制软件输入范围能通过软件或硬件风险控制措施来实现，例如：
——能检查输入并且拒绝不安全或不一致值的软件风险控制措施;
——硬件风险控制措施可能包括一个上锁的房间以防止未经授权的人输入数据 。
设置于医疗器械或其软件输出的风险控制措施能检查软件输出值是否在安全范围内和是否具有内部一致性以防止伤害发生，这能通过以下方法实现，例如：
——能检查输出值并防止其偏离安全范围的软件风险控制措施;
——限制施加给患者的能量的硬件风险控制措施;
——由警告标签和硬线连接的“停止 ”开关组成的风险控制措施 。这种风险控制措施假定有能力的操作者能够发现危险情况 。
除了应用于医疗器械或其软件的输入和输出的风险控制措施外，也可对软件组件的输入和输出应用风险控制措施 。这使得检查软件更小组件的输入和输出并防止伤害成为可能 。
可能无法规定医疗器械安全运行的单一参数范围 ，但可规定一个“安全操作范围”，换句话说是一个参数组合 ，其组成医疗器械安全运行的边界 。能用软件来评估医疗器械的操作是否在安全操作范围内 。例如，软件能通过对应用部分测得的温度和暴露时间的组合来检测灼伤患者的可能性 。
在有些案例中 ，临床医生知道软件输入和输出的安全范围 ，但在医疗器械的设计中却无法预期 。在这些案例中，能通过风险控制措施确保医疗器械严格按照临床医生规定来运行 。能用硬件或软件的风险控制措施来检出软件输出与输入间的不一致 。
例如 ，临床医生可开出使用医疗器械治疗的处方 ，其对不同的患者有很大不同 。仅通过分析输入值和输出值不能检出危险情况 。尽管如此 ，仍可应用软件风险控制措施确保医疗器械输出与输入(预期的处方)的准确匹配 。
7. 1. 2 风险控制方法
7. 1. 2. 1 概述
为了对软件有效地实施适当的风险控制措施，宜对产品开发和软件生存周期有深入的理解 。有些风险控制措施在设计早期很容易实施，但在开发过程后期无法实施或实施成本太高 。如果没有在产品开发过程的早期从风险管理角度仔细考虑软件 ，可能会做出硬件方面的决定 ，无意中过度依赖正确的软件操作来保证医疗器械的安全 。
隔离软件项并为软件项赋予软件安全级别可能是有用的，这样能将高度关键的软件项(例如，那些有缺陷会导致死亡的软件项)与不会影响安全的软件项区分开来 。见 YY/T 0664—2020 的4. 3 软件安全分级相关内容 。
赋予软件安全级别 ，能作为对更关键的软件项进行更严格控制 、重点验证和配置管理活动的基础 。如果这样做 ，宜仔细考虑其副作用 ;对关键性较低的软件项 ，如其对任何更关键的软件项有影响 ，则其宜与受其影响的软件项有相同的分级 。宜注意 YY/T 0664 允许在同一个活动或任务中使用不同的方法(见YY/T 0664—2020 的5. 1. 4 关于规定方法的要求)。 制造商可制定方案来区分软件安全分级为 C 的软 件 项 。例 如 ，制 造 商 可 对 复 杂 程 度 高 的 软 件 项 使 用 更 正 式 的 验 证 方 法(例 如 ，代 码 检 查 相 对 于 代 码
评审)。
需要注意的是，软件项可能在初期被分类为与安全有关，然后通过某些风险控制措施或设计选择，将其视为关键性较低的软件项 。合理地执行风险管理能通过隔离和固有安全设计，使安全有关软件的子集尽可能减少到最小 。
确保软件安全需要在整个产品开发生存周期开展各种活动 。可靠性技术(如正式的故障分析方法)并不能构成完整的风险管理方法 。可靠性和安全，尽管非常相关，但它们并非同一个属性，认识到这一点也很重要 。关注可靠性的软件生存周期过程并不一定能达到足够的安全 。
7. 1. 2. 2、7. 1. 2. 3、7. 1. 2. 4、7. 1. 2. 5 和 7. 1. 2. 6 中更详细地描述了一些特定的风险控制措施 ，并就如何处置风险的特定原因给出了指南 。
7. 1. 2. 2 风险控制措施和软件体系结构设计
7. 1. 2. 2. 1 概述
软件体系结构宜描述通过固有安全设计来控制风险的软件功能特性，以及通过防护措施来降低风险的软件机制 。
7. 1. 2. 2. 2 通过体系结构特性提供的固有安全设计
与软件控制功能相关的危险是可避免的 ，例如 ，通过硬件实现该功能 ，正如与硬件功能相关的危险(磨损 、疲劳)可通过使用软件来避免一样 。
有时某个危险可通过高层级的设计决定完全避免 。例如 ，从硬件角度来看 ，使用电池代替交流电源能完全排除触电死亡的风险 。 同样的 ，导致危险的整个编程错误能通过高层级的设计决定来消除 。例如，内存泄漏能通过仅使用静态数据结构来避免 。
在使用软件的系统中有个特殊的问题 ，认为软件能不受限制地共享硬件基础设施 。这种观念是错误的 。
系统设计中有一个通用规则 ，系统宜包括足够的资源 ，以在需要时执行所有必要的任务 。这个规则对软件和硬件都适用 。如果一个软件项在安全方面发挥作用，风险评估宜阐述以下问题 。
——安全有关软件项在需要时能否访问它的处理器?
——在不安全状况发展成事故前，安全有关软件项能否确保足够的处理器占用时间以完成其任务?
——能否证明没有其他软件项能破坏或干扰安全有关软件项?
如果安全有关软件不得不与非安全有关的软件共享处理器 ，那么以上的问题尤为重要 ，因为安全功能会和非安全功能竞争资源(关于隔离见7. 1. 2. 2. 4)。
开发方法的选择宜确保所有上述问题对设计者可见 。例如 ，将安全有关软件项设计为一个进程 ，并在操作系统有空闲时才运行 ，这样的设计是不够的 。开发方法宜支持计划安排 、优先级和时序的审慎设计 。
7. 1. 2. 2. 3 容错体系结构
医疗器械需要有许多功能以确保患者或用户的安全 。这些功能可包括不能被中断或延迟的临床功能，以及实施防护性风险控制措施的功能 。
容错设计是一种非常通用的方法 ，用以提高医疗器械可靠性(参考软件工程实践者 ，包括 Pullum[8]和 Banatre[9])。 容 错 设 计 的 目 的 是 确 保 安 全 有 关 的 功 能 在 组 件 故 障(包 括 软 件 反 常)发 生 时 仍 会 继 续运行 。
容错设计常常利用冗余 。这是一个至关重要组件的简单复制，以便在一个组件失效时系统能继续运行，或者由额外组件组成，以便检出失效并将运行切换到替代模式，此时功能可能受限 。
使用容错设计能在软件失效时使至关重要的功能继续运行 。在这种情况下，使用同一软件多重拷贝的简单冗余可能是不充分的，因为同样的缺陷在软件的每个拷贝中都存在 。
在这种情况下 ，需要使用多样性 。例如 ，使用额外的软件检出软件错误并执行恢复程序 。额外的软件宜避免与被监控的软件共享任何特性，以排除一个软件缺陷导致两个软件都失效的可能性 。
在更关键的情况下，可由两个或更多软件项完成同样的功能，但它们从一个通用的规范开始，被独立设计和实现 。这就是“多样性编程”。然而需要注意 ，不同开发工程师有犯同样错误的趋势 ，这会使多样性失效 。还要注意通用规范可能包含不正确的需求 。最终，需要使用一些方法(如表决)来确保故障软件不会产生任何影响 。至少需要三个不同的软件项来实现表决机制 。
当使用冗余来实现容错设计时，不管是否使用多样性，告知用户发生了失效很重要 。否则，具有容错设计的医疗器械可能看起来运行正常，但实际上是在降低安全性的情况下运行 。
7. 1. 2. 2. 4 通过隔离降低软件原因带来的风险
软件缺陷可能使在相同硬件上运行的不相关的软件发生错误 。制造商宜选择隔离安全有关软件项和非安全有关软件项的方法 ，使非安全有关软件项不能干扰安全有关软件项的运行(见 YY/T 0664— 2020 的5. 3. 5)，并宜证明隔离是有效的 。这包括证明软件项使用适当的资源(物理资源或时间)以避免软件项间非预期的争夺 。
软件项间的有效隔离需要处理以下几种软件项发生非预期交互的可能方式 。
——当软件争夺共享硬件(如处理器 、存储设备和其他输入/输出设备)的占有时间时，软件项可能以非预期的方式交互 。这能妨碍软件项在预期的时间运行 。提供充分的硬件资源是一种体系结构特性(见7. 1. 2. 2. 2)，宜有足够的规范和策划来确保在需要时有充分的时间来运行所有的软件项 。
——多个软件项可能共同存在于同一个内存中;这会导致一个软件项非预期地改变属于另一个软件项的数据 。在极端情况下，一个软件项可能偶然地改变了另一个软件项的编码 。许多处理器和操作系统提供硬件辅助隔离内存使用的方法 。 当有这些方法时，就宜使用 。许多这样的方法会防止非预期的交互，即使其中一个软件项存在缺陷 。
——当软件项共享变量(包括全局变量 、环境变量和操作系统参数)时，也可能存在非预期的交互;这会在其中的一个软件项存在缺陷时，导致软件项间非预期的通信 。软件项间变量共享宜做到最小化 。必要的话，向所有工程师发布规则，以确保只有少数规定的软件项才能改变共享变量，而所有其他的软件项仅能读取共享变量，而不能修改它们 。
最强的隔离方式是在不同的处理器上运行不宜交互的软件项 。然而，上述推荐的谨慎的体系结构设计可在单一处理器上提供适当程度的隔离 。
在实验室环境中测试系统，对于给定的测试用例，可能表明物理和时间资源都是充分的，然而现场的应用负荷或执行环境(其他过程在同一地点运行)使软件以某种方式失效从而导致伤害 。
另一方面 ，如果实验室中的测试用例确实表现出低性能并采用无效措施草率地提升软件速度 ，这些措施可能破坏设计并通过不可预见的副作用增加其他风险 。
有效的隔离宜证明在正常操作下：
a) 能防止数据流崩溃：非安全有关软件项不能修改安全有关数据;
b) 能防止控制流崩溃：
• 安全有关功能总能在正确的时间执行，不受非安全有关软件项的行为影响;
• 非安全有关软件项不能修改安全有关软件项;
c) 能防止执行环境崩溃：安全有关软件项和非安全有关软件项(如处理器寄存器 、设备寄存器 、内存访问特权)使用的软件系统部分不会发生崩溃 。
导致违背上述原则的事件(如硬件失效)宜能被检出并且使系统采取必要的行动来确保持续安全 。
7. 1. 2. 3 防护措施细节
在很多情况下，通过固有安全设计来避免所有危险或者对所有潜在失效执行容错是不切实际的 。在这些情况下 ，防护措施是次优的管理潜在危险的方法 。这些措施通常通过以下方式实施 ，首先检出潜在的危险情况，之后或者自动干预以减轻后果，或者产生报警使用户可干预 。
例如 ，X 射线治疗系统可有一个使用软件逻辑或硬件的互锁系统 ，当通往设施的任何门打开时关闭X 射线发生器 。互锁功能对治疗没有作用 。使用它的唯一目的就是减轻非预期的射线暴露的伤害 。
在某些情况下(即医疗器械功能丧失不会产生危险)，安全可能以未完成任务为代价获得 。例如 ，实验室血液分析仪未能提供结果 ，在某些情况下这可能并不危险 ，但提供错误结果可能是危险的 。在这个示例里，当保护性检验程序显示非预期的故障时关闭分析仪，与继续工作相比降低了风险 。在失效-安全(fail_safe)体系结构中 ，系统或组件故障 ，或其他危险
评论