4. SaMD软件安全分级与生命周期裁剪

IEC 62304 把医疗器械软件的安全等级划分为 A、B、C 三级，这个等级不是对软件“质量好坏”的评价，而是对软件失效可能造成的伤害后果的度量。它直接决定了生命周期过程中哪些活动是强制的、哪些可以裁剪、哪些必须留下可追溯的证据。很多团队在项目启动时凭感觉写一个“B级”就往下走，结果在注册审评或体系审核时被迫返工，代价极高。本节把判定逻辑、裁剪规则和一次可复现的风险活动规划串起来讲清楚。

一、A/B/C 级判定的核心逻辑

判定的起点不是软件本身，而是软件所处的系统级风险控制链。IEC 62304 的定义可以归纳为三个递进问题：

• A 级：软件失效不可能导致伤害，或不可能导致不可接受的风险。注意“不可能”需要证据支撑，例如软件输出仅用于医生参考且医生有独立判断，或软件失效后系统进入安全状态。
• B 级：软件失效可能导致非严重伤害（non-serious injury）。非严重伤害通常指可逆的、无需住院或长期治疗的伤害。
• C 级：软件失效可能导致死亡或严重伤害（serious injury）。严重伤害包括不可逆损伤、需要医疗干预、危及生命等。

关键点在于：外部风险控制措施可以降低软件等级。如果系统层面已经用硬件限位、独立报警、双重通道等手段把软件失效的后果控制住，那么软件本身可能从 C 降到 B 甚至 A。但这条路径必须写清楚“外部措施是什么、它如何独立于软件、失效时如何被验证”，否则审评不认。反之，如果软件是唯一的风险控制手段，等级只会往高走。

二、生命周期过程的裁剪策略

IEC 62304 把生命周期过程分为开发、维护、风险管理、配置管理、问题解决等几大类。A/B/C 的差异主要体现在开发过程的强制程度上，可以用下面这张图快速对照：

从图中可以看出，A 级最宽松，但“宽松”不等于“什么都不做”。A 级仍然必须做需求分析、系统测试、发布和配置管理，只是不强制架构设计、详细设计和单元验证。B 级增加了架构设计和集成测试，C 级则把详细设计和单元验证也纳入强制范围。裁剪的边界必须写在软件开发生命周期计划（SDP）里，并说明裁剪理由。

三、基于风险的活动规划实战

下面用一个教学示例走一遍完整流程。假设我们开发一款“胰岛素泵控制软件”，软件根据连续血糖监测（CGM）数据计算并下发基础率。这是一个典型的 SaMD 场景。

第一步：系统级风险分析。 识别出危害“胰岛素过量输注导致低血糖”。软件失效模式包括：基础率计算错误、CGM 数据解析错误、通信中断后未报警。若软件失效直接导致过量输注，且无独立硬件限位，则软件安全等级为 C 级。

第二步：评估外部风险控制措施。 假设系统设计了一个独立于主控软件的硬件限流器，最大输注速率被物理限制在安全阈值内。此时软件失效的后果从“严重伤害”降为“非严重伤害”，软件等级可降为 B 级。但必须提供硬件限流器的独立验证证据，并在风险文件中记录该降级依据。

第三步：按等级规划活动。 若最终定为 B 级，则必须执行：软件需求分析、架构设计、集成测试、系统测试、发布与配置管理。详细设计和单元验证可以裁剪，但建议对“基础率计算”这一高风险模块保留单元测试，因为它是风险控制的关键路径。

第四步：把风险控制映射到测试用例。 例如针对“CGM 数据解析错误”，设计测试用例：输入一段包含异常跳变的 CGM 数据（如 5 分钟内从 6.0 mmol/L 跳到 22.0 mmol/L），预期软件应拒绝该数据并触发“传感器异常”报警，而不是直接按错误值计算基础率。测试通过标准是报警在 2 秒内触发，且基础率保持不变。

四、可交付成果：安全分级与裁剪决策表

下面这张表可以直接作为项目启动时的填写模板。每一行对应一个软件项或模块，填写后由风险负责人和法规负责人共同签字确认。

填写时注意：同一款软件的不同模块可以有不同的安全等级，但最终软件整体的等级取最高值。上表中 CGM 数据解析模块为 C 级，因此整个软件的开发过程必须按 C 级执行，不能因为其他模块是 A 或 B 就整体降级。这一点在 IEC 62304 中表述为“软件系统应被赋予其软件项中最高的安全等级”。

最后强调一个实操细节：安全等级判定和裁剪决策必须在开发早期完成并纳入风险管理文件，而不是等到测试阶段再补。每次需求变更或风险控制措施调整后，都要重新评估等级是否变化。如果硬件限流器被移除，B 级必须立即回到 C 级，相应的详细设计和单元验证活动也要补回来。这个动态维护的过程，才是 IEC 62304 生命周期裁剪真正落地的地方。