4. 软件安全分级
软件安全分级是医疗器械软件风险管理中最先落地、也最容易被做偏的一步。它的本质不是给软件“贴一个等级标签”，而是回答一个具体问题：当这段软件失效时，伤害可能以多大概率、通过什么路径发生？ IEC 62304 给出的 A、B、C 三级，正是围绕“伤害可能性”这一维度建立的判定框架，并直接决定后续开发、验证、确认活动需要做到什么深度。
一、A、B、C 三级的判定定义
IEC 62304 对软件安全级别的定义，核心在于“软件失效是否可能导致伤害”，以及“伤害是否可能在软件失效后发生”：
- A 级：软件失效不可能导致伤害，或不可能导致超出可接受水平的伤害。典型情形是软件仅用于信息展示、统计、日志记录，且没有任何路径影响患者接触或治疗输出。
- B 级：软件失效可能导致非严重伤害。伤害可能发生，但后果可逆、可恢复，通常不危及生命，例如轻微用药提醒错误、非关键参数显示偏差。
- C 级：软件失效可能导致死亡或严重伤害。伤害可能发生且后果严重，例如输液泵速率控制、放疗剂量计算、除颤能量输出、呼吸机通气参数控制。
需要特别强调：分级对象是软件项（software item），而不是整个产品。一个输液泵系统整体可能是 C 级，但其中的日志模块、界面语言切换模块可能只属于 A 级。分级必须落到可独立开发、独立验证的软件单元或软件项上，否则后续裁剪就无从谈起。
二、判定路径：从失效到伤害的因果链
判定不能凭直觉，而应沿着“软件失效 → 系统行为 → 危害 → 伤害”的因果链逐段追问。下面这张图给出了一个可操作的判定路径，把“伤害是否可能发生”和“伤害是否严重”拆成两个连续判断点。
图中两个判断点对应两个关键问题：第一，失效是否可能传导到患者；第二，传导后的伤害是否严重。只有两个问题都回答“是”，才落到 C 级。若第一问为“否”，直接 A 级；若第一问为“是”而第二问为“否”，则为 B 级。
三、分级对开发、验证、确认活动的裁剪影响
分级的意义在于“按风险配置资源”。级别越高，要求的活动越完整、越严格；级别越低，允许合理裁剪。下表给出三类活动在 A、B、C 级下的典型差异，可作为裁剪决策的参考基线。
| 活动类别 | A 级 | B 级 | C 级 |
|---|---|---|---|
| 软件开发计划 | 需要，可简化 | 需要，含详细设计 | 需要，含详细设计与追溯矩阵 |
| 软件需求分析 | 需要，可合并 | 需要，含安全需求 | 需要，含安全需求与风险控制追溯 |
| 软件架构设计 | 不强制 | 需要 | 需要，含接口与隔离设计 |
| 单元验证 | 可裁剪 | 需要 | 需要，含覆盖率与边界测试 |
| 集成与系统测试 | 需要 | 需要，含异常路径 | 需要，含故障注入与最坏情况 |
| 确认活动 | 基本功能确认 | 含临床场景确认 | 含临床场景与风险控制有效性确认 |
| 可追溯性 | 建议 | 需要 | 强制，需求—设计—测试—风险全链 |
裁剪不是“少做”，而是“把力气花在刀刃上”。A 级软件可以不做详细架构和单元验证，但集成测试和基本功能确认仍不可省；C 级软件则必须建立从风险控制措施到测试用例的双向追溯，确保每一条安全需求都有对应的验证证据。
四、实战判定练习
下面给出三个典型软件项，请先自行判定，再看解析。
练习 1：某输液泵的“电池电量显示”软件项。失效表现为电量显示偏高，护士据此延迟更换电池，但泵在低电量时会自动报警并停止输液。
解析：电量显示失效本身不直接控制输液，且低电量报警与停止输液构成独立保护。伤害路径被阻断，判定为 A 级。但需注意：若报警功能也由同一软件项实现且可能同时失效，则需重新评估。
练习 2：某监护仪的“心率趋势图绘制”软件项。失效表现为趋势图曲线错位，医生可能误读趋势，但实时心率数值显示正常且独立。
解析：趋势图错误可能误导临床判断，但实时数值独立且正确，伤害通常可逆、非严重，判定为 B 级。
练习 3：某放疗设备的“剂量计算”软件项。失效表现为计算结果偏高 10%，且该结果直接用于制定照射计划。
解析：剂量计算直接决定照射量，失效可导致过量照射，后果为严重伤害甚至死亡，判定为 C 级。该软件项必须执行完整的开发、验证、确认与追溯活动。
五、分级结果的落地要求
完成分级后，必须把结果写入软件安全分级清单，并与风险管理文件建立关联。清单至少应包含：软件项名称、唯一标识、判定结论、判定依据（失效模式与伤害路径）、对应风险控制措施、以及该级别下裁剪后的活动清单。这样，分级才不是一张静态表格，而是后续开发、验证、确认活动的实际输入。
最后提醒：分级不是一次性的。当软件架构调整、新增功能、或风险分析发现新的伤害路径时，必须重新判定受影响软件项的安全级别，并同步调整其开发与验证活动。分级错了，后面的裁剪就全错了。