1. 医疗软件交付的特殊性
医疗软件与普通消费级或企业级软件最大的区别，不在于技术栈，而在于它直接或间接作用于人的生命健康。一段在电商系统里只造成页面报错的缺陷，放到输液泵、放射治疗计划系统或体外诊断设备中，可能演变为剂量错误、误诊或治疗中断。因此，理解医疗软件交付，必须先从"它是什么、被谁管、失效会怎样"三个问题入手，再谈持续集成与持续交付（CI/CD）在其中的价值与边界。
一、医疗软件的定义与分类
医疗软件通常指用于疾病诊断、治疗、监护、康复、预防，或用于医疗设备控制、医学数据处理与医疗决策支持的软件。按监管与风险视角，业界普遍将其分为几类：
- 独立医疗软件（SaMD，Software as a Medical Device）：本身即为医疗器械，不依附于硬件，如AI辅助诊断软件、心电图自动分析软件。
- 嵌入式/固件软件：运行在医疗硬件内部，控制设备行为，如输液泵控制固件、CT机重建算法。
- 医疗器械软件附件（SiMD/Accessory）：驱动或配合硬件工作，如设备上位机软件。
- 医疗IT与健康管理软件：医院信息系统（HIS）、电子病历（EMR）、实验室信息系统（LIS）等，部分受监管，部分按数据安全与隐私法规管理。
分类的意义在于：软件类别直接决定其风险等级，而风险等级决定交付流程的严格程度。同样是"改一行代码"，在健康管理App里可能当天上线，在II类或III类SaMD中则可能需要重新评估、回归测试甚至提交变更申请。
二、三大监管体系的核心要求
医疗软件进入不同市场，需满足对应监管机构的要求。下表对比了三大主流体系对软件交付影响最直接的部分：
| 监管体系 | 适用市场 | 对软件交付的关键要求 |
|---|---|---|
| FDA（美国） | 美国 | 按风险分Class I/II/III；软件需符合IEC 62304软件生命周期过程；上市前提交510(k)/PMA；变更需评估是否触发新提交 |
| NMPA（中国） | 中国 | 医疗器械软件注册审查指导原则；要求软件研究资料、版本命名规则、网络安全描述；重大变更需重新注册 |
| MDR（欧盟） | 欧盟 | 按MDR 2017/745分类；需符合IEC 62304、IEC 82304；需公告机构审核；上市后监督（PMS）与警戒系统严格 |
三者共同的技术基石是IEC 62304《医疗器械软件生命周期过程》。它把软件安全等级分为A、B、C三级：A级指不可能造成伤害，B级指可能造成非严重伤害，C级指可能造成死亡或严重伤害。等级越高，对需求追溯、架构设计、单元验证、集成测试、发布评审的强制要求越严。CI/CD流水线的设计，本质上就是把这些强制要求"自动化地嵌入"到每次构建与发布中。
三、患者安全与软件失效风险
医疗软件失效的后果具有不可逆性。常见的失效模式包括：
- 计算错误：如放疗剂量计算偏差、药物剂量推荐错误。
- 数据错配：患者A的检验结果关联到患者B。
- 时序/控制失效：输液泵流速控制异常、报警延迟。
- 可用性缺陷：界面误导导致医护人员误操作。
- 网络安全失效：被篡改数据或勒索导致设备停摆。
这些风险意味着：医疗软件的"交付"不是"把功能做出来"，而是"在可证明的安全边界内，把经过验证的版本放到正确的环境中"。任何绕过验证的快速上线，都可能把技术债务转化为临床风险。
四、CI/CD在医疗领域的价值与挑战
把CI/CD引入医疗软件，价值是明确的：自动化回归测试让每次变更都能快速验证是否破坏既有安全行为；可追溯的构建产物让"这个版本到底由哪些代码、哪些依赖构成"有据可查；受控发布与回滚让问题版本能在临床影响扩大前被撤回；审计日志让监管检查时能还原每一次变更的决策链。
但挑战同样突出。第一，验证成本高：医疗软件的测试用例往往与临床场景强绑定，自动化覆盖率提升缓慢，很多验证仍需人工确认。第二，变更边界模糊：一次看似普通的依赖升级，可能被监管判定为"重大变更"，需要重新提交。第三，环境差异大：医院网络隔离、设备型号多样、操作系统版本老旧，导致"在我这里能跑"不等于"在临床能跑"。第四，合规证据链：CI/CD流水线本身也要被验证，流水线的变更同样需要受控。