1. 医疗器械软件生命周期工程导论

1.1 为什么医疗器械软件需要“生命周期工程”

医疗器械软件（Medical Device Software, MDS）与普通商业软件最大的区别在于：它的失效可能直接导致患者伤害甚至死亡。因此，监管机构并不只关心软件“能不能用”，而是要求制造商能够证明软件在整个生命周期内都是安全、有效且可追溯的。生命周期工程（Life Cycle Engineering）正是把这种“证明责任”落到可执行活动上的方法论。

所谓生命周期，通常指从概念与需求开始，经过设计、实现、验证、确认、发布、维护，直到退役的全过程。IEC 62304 把这一过程划分为若干软件安全类别相关的活动集合，并要求每个活动都有明确的输入、输出、评审与记录。换句话说，生命周期工程不是“写代码的流程”，而是“用证据链管理风险的过程”。

1.2 定义与范围：什么算医疗器械软件

根据 IMDRF 与各国监管定义，医疗器械软件可分为三类：

• 独立软件（SaMD）：本身即为医疗器械，不依附于硬件，例如 AI 辅助诊断软件、剂量计算软件。
• 软件作为医疗器械的附件：控制或驱动硬件器械，例如输液泵控制固件、CT 重建软件。
• 嵌入式软件：运行在器械内部，与硬件共同构成医疗器械，例如起搏器固件。

范围界定的关键在于：软件是否用于诊断、治疗、监护、缓解或预防疾病。若仅用于行政、计费、教学演示，通常不属于医疗器械软件。但一旦其输出被临床决策直接采用，就必须纳入监管范围。

1.3 监管背景：从法规到标准

全球主要监管体系包括美国 FDA 的 510(k)/PMA、欧盟 MDR 2017/745、中国 NMPA 的《医疗器械软件注册审查指导原则》。这些法规的共同要求是：制造商必须建立质量管理体系（QMS），并在其中嵌入软件生命周期过程。

IEC 62304《医疗器械软件 软件生命周期过程》是这一领域最核心的协调标准。它规定了软件开发、维护、风险管理、配置管理、问题解决等过程要求，并按软件安全类别（A、B、C）规定不同的严格程度：

需要强调的是，IEC 62304 并不规定具体开发模型（瀑布、V 模型、敏捷均可），而是规定必须完成哪些活动、产生哪些证据。这为不同组织留下了灵活空间，但也要求对每个活动进行裁剪论证。

1.4 生命周期工程的核心结构

下图展示了医疗器械软件生命周期工程的核心结构：以风险管理为主线，贯穿需求、设计、实现、验证、确认与维护，并由配置管理与问题解决提供支撑。

1.5 从标准到实践：一个最小可用的落地思路

对于刚接触 IEC 62304 的团队，建议从以下三个动作开始：

1. 确定安全类别：通过风险分析判断软件失效可能造成的伤害等级，直接决定后续活动的裁剪范围。
2. 建立需求追溯矩阵：每条软件需求都应能追溯到风险控制措施、设计项和测试用例，这是审核中最常被检查的证据。
3. 把配置管理做“轻”但做“实”：至少对需求、设计、代码、测试记录进行版本标识和变更记录，确保任何时刻都能重建一个已发布版本。

1.6 常见误区与判断依据

实践中，团队最容易在以下三点上出错：

• 把“测试通过”等同于“安全有效”：测试只是验证手段之一，还需结合风险分析、临床评价与上市后监督。
• 忽略维护阶段：软件发布后的问题修复、补丁、环境变更同样属于生命周期活动，必须重新评估风险并更新文档。
• 追溯链断裂：需求变更后未同步更新设计与测试，导致审核时无法证明“变更已被验证”。

判断一个生命周期过程是否合格，最直接的标准是：能否在合理时间内，从任意一条风险控制措施出发，找到对应的需求、设计、代码、测试记录和发布版本。如果这条链路完整且可读，说明生命周期工程已经真正落地。

1.7 本章小结

医疗器械软件生命周期工程的核心，不是追求某种“完美流程”，而是建立一条可追溯、可验证、可维护的证据链。IEC 62304 提供了活动框架，ISO 14971 提供了风险主线，而配置管理与问题解决则保证这条链在变更中不断裂。理解这一点，是后续所有章节——从需求工程到上市后监督——的共同基础。