2. 医疗设备软件生命周期与更新需求

医疗设备软件的安全更新，不能脱离它所依附的器械整体来谈。一台输液泵的固件、一台CT机的重建算法、一套监护中央站的数据库组件，它们的更新节奏、风险边界和验证深度完全不同。要判断“什么时候必须更新、更新到什么程度、由谁批准”，首先必须回答三个前置问题：这段软件属于哪一类、它处在生命周期的哪个阶段、它受到哪些临床环境约束。本节围绕这四个问题展开，并给出可落地的分类与触发判断方法。

一、医疗设备软件的分类：先分清“谁是器械”

监管与工程实践中，医疗设备软件通常按“软件本身是否构成医疗器械”以及“其失效对患者的危害程度”两个维度分类。第一维度区分三类：

• 独立软件（SiMD 之外的 SaMD）：软件本身即为医疗器械，如AI辅助诊断软件、放疗计划系统。它没有硬件载体，更新即产品变更。
• 嵌入式软件（固件）：运行在设备主控或专用板卡上，直接控制能量输出、运动、剂量、报警等，如输液泵电机控制固件、除颤器放电时序固件。
• 配套/非器械软件：如设备配置工具、维修诊断软件、数据导出工具，通常不直接作用于患者，但可能间接影响设备状态。

第二维度按危害程度分级，工程上常对应 IEC 62304 的软件安全分级 A/B/C：A 级为不可能造成伤害，B 级为非严重伤害，C 级为可能造成死亡或严重伤害。分级直接决定验证深度——C 级软件的任一补丁都必须做回归测试与风险再评估，而 A 级工具类软件可采用简化流程。分类不是学术标签，它决定了后续所有更新活动的“重量级”。

二、生命周期模型：更新发生在哪一段

医疗设备软件生命周期通常采用“概念—需求—设计—实现—验证—上市—维护—退役”的 V 模型或迭代模型。安全更新的主战场在上市后维护阶段，但触发源可能来自任何阶段：需求阶段遗漏的网络安全要求、设计阶段未考虑的协议漏洞、实现阶段引入的第三方库缺陷、验证阶段未覆盖的边界条件，都可能在上市后以漏洞或故障形式暴露。

关键认识是：更新不是生命周期的“补丁”，而是维护阶段的一个受控子过程。它必须回接需求与风险文档，形成闭环。例如某监护仪发现网络协议栈存在缓冲区溢出，修复动作不只是替换库文件，还要更新威胁模型、补充渗透测试用例、修订网络安全需求条目，并评估是否影响已注册的适应症与性能指标。

三、更新触发条件：四类信号与判断阈值

更新不能凭感觉发起。工程上可归纳为四类触发源，每类都有可操作的判断依据：

① 安全漏洞披露。当厂商收到 CVE 通告、监管机构安全预警，或通过 SBOM（软件物料清单）比对发现所用第三方库存在已知漏洞时触发。判断阈值不是“有漏洞就更新”，而是结合 CVSS 评分、漏洞可利用性、设备是否联网、是否可远程触达综合判定。例如某输液泵使用 OpenSSL 1.0.2，若该泵仅通过隔离串口通信、无网络接口，则远程利用风险极低，可纳入下次计划更新；若该泵带 Wi-Fi 且暴露于院内网，则应按紧急更新处理。

② 现场故障与不良事件。当同一软件版本在多个现场出现可复现的死机、误报警、数据丢失或治疗中断时触发。此时需先区分是软件缺陷还是硬件/使用问题，常用方法是比对故障日志中的软件版本号与调用栈。

③ 法规与标准变更。如某地区强制要求医疗器械具备网络安全更新机制、要求提供 SBOM，或标准版本升级（如 IEC 62304 修订），触发合规性更新。

④ 功能增强与兼容性。医院信息系统升级、新耗材启用、通信协议变更，导致设备软件需适配。这类触发虽非安全驱动，但同样要走变更控制。

四、临床环境约束：更新为什么不能像手机一样推送

临床环境对更新施加了硬约束，这些约束直接改变更新方案的设计：

• 可用性优先：ICU、手术室、急诊设备不允许随意停机。更新窗口通常安排在设备空闲期或备用机替换后，不能“重启即更新”。
• 验证状态锁定：设备当前软件版本是经过验证的“基线”，任何变更都可能使原有验证结论失效，必须重新评估。
• 网络隔离：许多医疗设备位于独立 VLAN 或物理隔离网段，无法直接联网下载，需通过离线介质或受控升级服务器分发。
• 可追溯与可回退：每次更新必须记录版本、时间、操作人、校验值，并保留回退到上一版本的能力，以防更新引入新问题。
• 多厂商共存：同一科室可能有多品牌设备，更新策略需分别遵循各厂商的升级规程，不能统一“一刀切”。

五、利益相关者分析：谁决定、谁执行、谁承担后果

医疗设备更新是多方协作过程，各方关注点不同，必须在更新方案中明确职责：

综上，医疗设备软件更新的起点不是补丁本身，而是分类、生命周期定位、触发判断与约束识别。只有先把这四件事说清楚，后续的补丁验证、部署与回退才有稳固的依据。