2. 软件安全分级

在医疗器械软件生命周期工程中,安全分级是几乎所有后续活动的“总开关”。IEC 62304 把医疗器械软件划分为 A、B、C 三个安全级别,级别一旦确定,开发计划、需求分析、架构设计、详细设计、单元验证、集成与系统测试、配置管理、问题解决等过程的强制程度都会随之变化。因此,分级不是一次形式化的填表,而是一次基于“伤害可能性”的风险推理。

一、判定准则:从“软件失效后果”出发

IEC 62304 的分级逻辑并不看软件规模、代码行数或开发难度,而是看软件失效或软件缺陷可能导致的伤害后果。标准给出的判定路径可以概括为三个问题:

  • A 级:软件不可能造成伤害,或软件失效不会导致任何伤害。此时软件对风险控制没有贡献,或即使失效,伤害也仅可能由硬件、操作者等其他因素引起。
  • B 级:软件可能造成非严重伤害。即软件失效可能导致伤害,但该伤害不会导致死亡或严重伤害(如轻微擦伤、短暂不适、可自行恢复的错误)。
  • C 级:软件可能造成死亡或严重伤害。即软件失效可能导致患者、操作者或环境中的人员死亡或严重伤害。

这里的关键词是“可能”和“严重伤害”。判定时不能只看软件本身的功能,而要看软件失效后,伤害是否可能发生、伤害的严重程度如何。如果软件失效后,硬件保护、机械限位、操作者确认等外部风险控制措施仍然有效,且这些措施独立于软件,那么软件级别可以降低;反之,如果软件本身就是唯一的风险控制手段,级别通常会被推高到 C 级。

判定要点:先识别软件失效模式,再判断该失效是否可能直接或间接导致伤害,最后判断伤害的严重程度。不要用“软件功能重要”代替“软件失效后果严重”。

二、判定流程:从风险分析到级别结论

实际项目中,安全分级通常嵌入风险管理过程,而不是孤立进行。一个可操作的判定流程如下:

  1. 识别软件项及其功能,明确软件在医疗器械预期用途中的角色。
  2. 对每个软件功能进行失效分析,列出可能的失效模式(如输出错误、延迟、丢失、卡死、计算偏差等)。
  3. 分析每种失效模式可能导致的危害,并评估伤害的严重程度。
  4. 检查是否存在独立于软件的外部风险控制措施;若存在,评估其独立性和有效性。
  5. 根据最严重的可能伤害,确定该软件项的安全级别。
  6. 若一个软件系统包含多个软件项,应分别定级,并取最高级别作为系统级约束,或按架构隔离后分别管理。

需要特别注意的是,安全级别是针对“软件项”而不是整个产品。一个输液泵可能整体被归为 C 级,但其内部负责日志记录的软件项可能只需 A 级;如果架构上能把高安全级别软件与低安全级别软件充分隔离,就可以避免“一刀切”带来的过度开发负担。

IEC 62304 软件安全分级判定关系 软件项 / 软件功能 识别预期用途与角色 失效模式分析 输出错误 / 延迟 / 丢失 / 卡死 伤害可能性与严重程度 是否可能造成伤害?伤害多严重? 外部风险控制措施 硬件限位 / 机械保护 / 操作者确认 是否存在独立于软件的保护? A 级 不可能造成伤害 软件失效不导致伤害 或伤害由其他因素引起 示例:日志记录、非临床数据存储 B 级 可能造成非严重伤害 伤害可恢复、不危及生命 无死亡或严重伤害风险 示例:参数显示偏差、提示延迟 C 级 可能造成死亡或严重伤害 软件是唯一或关键风险控制 失效直接危及生命 示例:输液速率控制、放疗剂量计算 无伤害可能 非严重伤害 死亡或严重伤害

三、实例分析:三个典型场景

场景一:电子体温计的显示软件。该软件读取温度传感器数据并显示体温。若软件失效导致显示错误温度,操作者可能误判病情,但体温计本身不执行治疗,且操作者通常会结合症状判断。伤害可能是延误就医,但不会直接造成死亡或严重伤害。因此,该软件项通常定为 B 级。如果该体温计仅用于健康人群的日常监测,且错误显示不会导致任何医疗决策,则可能定为 A 级。

场景二:输液泵的流速控制软件。该软件根据处方计算并控制输液流速。若软件计算错误或控制失效,可能导致药物过量或不足,直接危及生命。此时软件是风险控制的关键环节,且没有独立于软件的机械限速装置能完全覆盖所有失效模式。因此,该软件项应定为 C 级。

场景三:CT 图像存储与传输软件。该软件负责将重建后的图像存储到数据库并传输到工作站。若软件失效导致图像丢失或错配,可能影响诊断,但医生通常可以重新扫描或通过其他方式确认。伤害可能是延误诊断,但不会立即造成死亡或严重伤害。因此,该软件项通常定为 B 级。如果该软件仅用于图像归档、不参与诊断决策,且丢失图像可由原始数据重新生成,则可能定为 A 级。

四、分级后的工程影响

安全级别确定后,IEC 62304 对每个级别提出了不同的过程要求。A 级软件只需关注开发计划、需求分析、架构设计、发布和问题解决等基本活动;B 级在此基础上增加了详细设计、单元验证和集成测试;C 级则进一步要求更严格的详细设计、单元验证、集成测试、系统测试和风险控制验证。级别越高,需要保留的记录、追溯关系和验证证据越多。

过程活动 A 级 B 级 C 级
开发计划 要求 要求 要求
需求分析 要求 要求 要求
架构设计 要求 要求 要求
详细设计 不要求 要求 要求
单元验证 不要求 要求 要求
集成测试 不要求 要求 要求
系统测试 不要求 不要求 要求
常见误区:把“软件功能重要”等同于“安全级别高”。例如,医院信息系统中的计费软件很重要,但计费错误不会造成患者伤害,因此不应定为 C 级。安全分级只回答一个问题:软件失效是否可能导致死亡或严重伤害。

五、可复用的分级判定记录示例

为了让分级结论可追溯、可审查,建议为每个软件项保留一份判定记录。以下是一个可直接参考的字段结构:

软件项名称:输液泵流速控制模块
软件项标识:SW-INF-001
预期用途:根据处方计算并控制输液流速
失效模式:流速计算错误、控制输出偏差、通信中断
可能危害:药物过量或不足,导致患者死亡或严重伤害
外部风险控制:无独立于软件的机械限速装置
伤害严重程度:死亡或严重伤害
安全级别结论:C 级
判定依据:软件失效可能直接导致死亡或严重伤害,且软件是唯一风险控制手段
判定人 / 日期:张三 / 2025-06-01
复核人 / 日期:李四 / 2025-06-02

这份记录的价值在于:它把“为什么定 C 级”讲清楚了。当后续开发需要裁剪活动、调整验证深度或进行变更影响分析时,这份记录就是最直接的依据。安全分级不是一次性的标签,而是贯穿需求、设计、测试和变更控制的风险主线。