2. 医疗设备软件失效与危害分析

医疗设备软件的失效分析，不能只停留在“程序崩溃”这一层。与普通消费软件不同，医疗设备软件的失效往往通过测量偏差、输出错误、报警缺失、治疗参数失控等形式作用于患者，其后果可能从轻微不适一直延伸到死亡。因此，本节的核心任务是建立一条从“软件失效模式”到“失效后果”再到“危害等级”的完整推理链，并进一步理解软件与硬件、人因、使用环境之间的耦合失效，最后借助真实不良事件报告完成案例分析。

一、软件失效模式的分类

软件失效模式描述的是“软件以何种方式偏离了预期行为”。在医疗设备语境下，常见的失效模式可以归纳为几类：

• 计算与算法失效：剂量计算、滤波、趋势拟合、单位换算出现偏差。例如输液泵按 mL/h 计算流速时，若把体重单位 kg 误当作 lb，输出流速会偏大约 2.2 倍。
• 数据与状态失效：传感器数据被错误缓存、旧值未刷新、状态机卡死。典型表现是监护仪波形冻结但报警不触发。
• 时序与并发失效：任务调度超时、中断丢失、多线程竞争导致控制周期抖动。对闭环胰岛素泵而言，控制周期从 5 min 漂移到 15 min 就可能造成血糖过冲。
• 接口与通信失效：与传感器、执行器、医院信息系统之间的数据帧丢失、校验失败、协议版本不匹配。
• 报警与提示失效：报警阈值判断错误、报警被静音后未恢复、提示信息被遮挡或语言不匹配。
• 配置与数据失效：参数配置错误、默认值不合理、掉电后配置丢失或回滚到旧版本。

这些失效模式并非孤立存在。一个“数据缓存未刷新”的问题，可能同时表现为显示滞后、报警延迟和记录不完整，因此在分析时要按失效模式—触发条件—可观测现象三元组来描述，而不是只写一句“软件异常”。

二、失效后果与危害等级划分

失效后果要落到“对患者和操作者的影响”上。工程上通常先判断伤害的严重度，再结合发生概率确定危害等级。严重度可粗略分为：无伤害、轻微不适或需临时干预、可逆性伤害、不可逆伤害或危及生命。概率则可分为频繁、偶尔、罕见、极不可能等档位。

一个实用的做法是采用类似下面的危害等级矩阵（示例，具体分级应依据所适用的风险管理标准和企业程序文件确定）：

需要强调的是，危害等级不是软件缺陷等级。一个代码层面的小 bug，如果作用在关键控制路径上，也可能被评为高风险；反之，一个复杂的架构问题若只影响日志显示，危害等级可能很低。分析时必须从“患者接触点”反推，而不是从代码复杂度正推。

三、软件与硬件、人因、环境的耦合失效

真实的不良事件很少是单一原因。软件失效常常与硬件退化、人因操作和环境扰动叠加，形成耦合失效。下面这张图展示了四类因素如何汇聚到同一个患者伤害事件上。

耦合失效的典型链条是：硬件传感器漂移 → 软件未做合理性校验 → 显示数值缓慢偏移 → 操作者误信数据 → 延误处置。在这条链上，软件本可以通过“变化率检查”“多传感器交叉验证”“超限强制报警”来切断传播，但如果这些防护缺失，软件就从“安全屏障”变成了“失效放大器”。

人因耦合同样关键。例如报警被静音后，软件若没有在 2 min 内自动恢复报警，操作者又因忙碌未手动恢复，就会形成“报警静音 + 人因疏忽”的叠加失效。环境耦合则常见于电磁干扰导致通信重传、网络中断导致远程监控数据丢失。分析时应把每一类因素都写成可验证的假设，而不是笼统归因于“操作不当”。

四、基于真实不良事件报告的案例分析

下面以一个输液泵过量输注的公开不良事件场景为例（参数为教学示例，非实测数据），演示分析过程。

事件描述：某输液泵在更换输液袋后，护士输入新的流速 120 mL/h，但设备仍按上一袋的 60 mL/h 运行，约 40 min 后患者出现循环负荷过重表现。

失效模式定位：软件在“更换输液袋”状态下未强制重新确认流速，且界面显示的是新输入值，而控制模块使用的是旧值，属于数据与状态失效叠加接口失效。

耦合因素：人因方面，护士认为输入即生效；硬件方面，泵管安装后未触发流量校准；环境方面，病房同时有多台设备报警，注意力被分散。

危害等级判断：后果为可逆伤害但需紧急干预，发生概率为偶尔，按前述矩阵属于中风险，需采取软件强制确认、状态回读、流速变化率报警等控制措施。