3. 医疗软件风险分析基础
医疗软件的风险分析不是“写一份风险文档”，而是把危害、危害处境、损害、风险之间的因果链显式化，再用可验证的证据证明风险已被控制到可接受水平。ISO 14971 给出的正是这样一条从“识别”到“评价”再到“控制与验证”的闭环路径。对软件而言，这条路径的特殊之处在于：软件本身不会直接造成伤害，它通过控制或影响物理设备、输出错误信息、延迟或丢失关键数据等方式，改变危害发生的概率或后果严重度。
一、ISO 14971 风险管理流程的主干
ISO 14971 的流程可以概括为五个相互衔接的活动：风险管理计划、风险分析、风险评价、风险控制、剩余风险评价与风险管理报告。它们不是一次性串行，而是随设计变更、需求变更、缺陷修复而迭代。
- 风险管理计划：明确范围（哪些软件项、哪些临床场景）、职责、风险可接受准则、验证活动与评审要求。计划中必须写清“可接受”的判定方法，例如采用 ALARP（合理可行最低）原则或定量阈值。
- 风险分析：包括预期用途与安全相关特征的识别、危害识别、危害处境的估计、风险估计。软件常用的分析工具有 FMEA、FTA、HAZOP、软件危害分析（SWHA）以及基于场景的用例分析。
- 风险评价：对每个风险估计结果与可接受准则比较，判断是否需要控制。
- 风险控制：按优先级选择控制措施——设计固有安全、防护措施、安全信息。软件中常见的是增加校验、限值、互锁、确认步骤、告警与降级策略。
- 剩余风险评价与报告：确认控制措施有效后，评价剩余风险是否可接受，并形成可追溯的风险管理文档。
二、软件风险与危害的关系：从“失效”到“损害”的链条
理解软件风险，关键是区分几个层次：软件失效/缺陷（如数组越界、单位换算错误、状态机死锁）→ 危害（如胰岛素泵过量输注、放疗剂量计算偏差）→ 危害处境（患者处于该危害可能造成伤害的条件）→ 损害（低血糖、组织损伤）。软件风险分析要做的，是把这条链条中的每一环都写清楚，并标注可观察、可测试的中间量。
例如，某输液泵软件在“流速设置”模块中，若把 mL/h 误当作滴/min 处理，则可能输出错误流速。这里的软件缺陷是单位换算错误；危害是输注速率过高；危害处境是护士按错误显示值确认并启动；损害是药物过量。风险估计时，需要同时考虑发生概率（该缺陷在正常使用中触发的频率）和后果严重度（过量输注对患者的伤害程度）。
三、风险控制措施与 V&V 的关联：每条控制都要有验证出口
风险控制措施不能停留在“已增加校验”这样的描述上，必须转化为可验证的软件需求，并对应到具体的 V&V 活动。以输液泵单位换算错误为例，控制措施与验证的对应关系可以这样建立：
| 风险控制措施 | 转化为软件需求 | V&V 活动 | 通过准则（示例） |
|---|---|---|---|
| 单位强制选择与二次确认 | 流速设置界面必须显式选择单位，确认前不得下发 | 系统测试 + 可用性测试 | 未选择单位时无法启动；确认步骤可被记录 |
| 流速上限硬限值 | 软件限值 999 mL/h，超限拒绝并告警 | 单元测试 + 集成测试 | 输入 1000 mL/h 时拒绝，告警码正确 |
| 显示值与设定值一致性校验 | 每 100 ms 比对显示值与内部设定值，偏差 > 1% 触发告警 | 集成测试 + 故障注入 | 注入偏差后 200 ms 内告警并暂停 |
| 异常时声光告警并暂停输注 | 告警触发后 500 ms 内停止电机 | 系统测试 + 安全测试 | 电机停止时间 ≤ 500 ms，告警可听可见 |
这张表体现了 V&V 与风险管理的核心连接：风险控制措施 → 软件需求 → 测试用例 → 通过准则 → 剩余风险评价。如果某条控制措施找不到对应的测试用例，或者测试用例没有明确的通过准则，那么这条控制措施在风险管理文件中就是不可信的。
四、实际执行中的关键判断
在真实项目中，风险分析最容易出问题的地方有三个。第一，危害识别不充分：只分析软件自身失效，忽略软件与硬件、用户、环境的交互。例如，软件正确输出了流速，但护士因界面信息过载而误读，这仍然是软件相关的危害处境。第二，风险估计缺少依据：概率和严重度不能凭感觉填写，应参考临床数据、历史缺陷、同类产品召回信息或专家判断，并记录判断理由。第三，控制措施与验证脱节：控制措施写了“增加确认步骤”，但测试用例只验证了“界面存在确认按钮”，没有验证“未确认时不能启动”，这就没有覆盖风险控制的实际意图。
软件风险分析不是一次性文档工作，而是贯穿需求、设计、编码、测试、上市后监测的持续活动。ISO 14971 提供的是框架和逻辑，真正决定风险控制效果的，是团队是否把每一条危害都追到可验证的软件行为，是否把每一次设计变更都重新纳入风险评价，以及是否用 V&V 证据证明“风险已被控制到可接受水平”这一结论。