医疗器械软件生命周期过程(IEC 62304)

IEC 62304《医疗器械软件 软件生存周期过程》是国际通行的医疗器械软件生存周期标准，也是我国监管与技术审评认可的重要参考依据。该标准不规定具体技术实现，而是要求企业建立与其软件安全级别相称的过程与活动。本文梳理标准的结构、分级逻辑与企业落地要点。

软件安全分级：A级、B级与C级

IEC 62304的核心思路是按风险分级施加要求。企业需首先根据软件可能导致伤害的严重程度进行分级：A级为不可能导致伤害，B级为可能导致非严重伤害，C级为可能导致死亡或严重伤害。分级应基于风险分析，并在风险管理文档中说明理由。分级决定了后续活动的深度，例如C级软件需要更完整的架构设计、更严格的单元测试与集成测试覆盖、更细致的可追溯性。值得注意的是，一个软件系统可由多个软件项组成，不同软件项可以有不同的安全级别，这一点在复杂系统中尤为关键，也是分级工作最容易简化的地方。

标准的过程结构

标准包含若干过程组：软件开发过程（需求分析、架构与设计、实现、集成与测试、系统测试、发布）、软件维护过程（问题分析与修改、修改实施与验证）、软件风险管理过程、软件配置管理过程与软件问题解决过程。企业常忽视后三项，但它们恰恰是体系持续受控的保障：风险管理贯穿始终，配置管理保证版本可追溯，问题解决过程保证缺陷从发现到关闭有完整记录。标准并不要求所有活动都必须产生独立文档，允许合并与裁剪，但裁剪理由必须记录在案并经过评审，不能以减少工作量为目的随意删减。

与ISO 13485和ISO 14971的衔接

IEC 62304与ISO 13485的设计开发条款高度对应：软件需求对应设计输入，架构与详细设计对应设计输出，集成与系统测试对应设计验证，临床评价或用户确认对应设计确认，变更控制对应设计更改。与ISO 14971的衔接体现在：软件风险分析是产品风险分析的组成部分，风险控制措施应在需求与设计层面落实，剩余风险需经过评价与批准。三者协同时，建议建立统一的可追溯矩阵，把用户需求、软件需求、风险控制措施、设计实现与测试用例串成一条链，使审核与审评都能快速定位证据。

生存周期文档与记录要求

标准要求的输出通常包括：软件开发计划、需求规格、体系结构设计、详细设计（按等级裁剪）、单元测试与集成测试记录、系统测试记录、发布记录、配置管理记录、问题记录与风险管理记录。这些文档构成软件设计历史文档（DHF）的主体。实践中常见的问题是文档与代码脱节：设计文档长期不更新，或测试用例未覆盖需求变更。解决之道是把文档生成与更新纳入开发流程与质量门禁，例如规定需求变更必须同步更新追溯矩阵与测试计划，否则不予评审通过，以此保证文档始终反映产品真实状态。

遗留软件与SOUP的处理

对于缺乏完整生存周期记录的遗留软件，标准允许通过风险评估与补充活动使其满足要求，例如补做架构梳理、静态分析、回归测试与文档回溯，并对证据缺口进行风险评价与批准。对于现成软件（SOUP，包括开源组件与第三方库），企业应建立清单，明确版本、用途、许可与安全级别，评估其失效对产品的影响，并对引入的配置与接口进行验证。忽视SOUP管理是当前软件与人工智能器械的常见缺陷，也是网络安全管理的重要薄弱环节，应当纳入采购与供应商控制程序统一管理。

IEC 62304的价值在于提供一套与风险相称的软件工程纪律。企业若能将其过程要求真正嵌入研发流程，并与ISO 13485、ISO 14971形成统一证据链，就能在合规与研发效率之间取得更好的平衡。