标准概述
IEC 62304的全称是"Medical device software — Software life cycle processes"，由IEC发布，当前有效版本为IEC 62304:2006/Amd 1:2015。这份标准规定了医疗器械软件在策划、需求分析、架构设计、详细设计、实现、集成测试、系统测试、发布和维护各阶段应遵循的过程要求。
它适用于两种场景：软件本身就是医疗器械（即SaMD，Software as a Medical Device），以及软件作为医疗器械的嵌入组件。无论哪种情况，只要软件用于医疗目的，IEC 62304就是监管机构审查的基准标准。
FDA将IEC 62304列为认可的共识标准（Recognized Consensus Standard），在510(k)和PMA审评中广泛引用。欧盟MDR也将其作为协调标准（Harmonised Standard），公告机构审核软件类器械时以此为技术依据。
软件安全分类（Class A/B/C）
IEC 62304的核心机制是按风险程度对软件进行安全分类，以此决定开发过程中需要执行哪些活动。三个等级的定义如下：
Class A — 软件系统不会导致危害情形，或即便导致危害情形，在考虑软件系统外部的风险控制措施后，残余风险仍可接受。这一等级的开发要求相对较轻，但2015年修正案（Amendment 1）增加了系统测试的强制要求，不再允许完全跳过测试环节。
Class B — 软件系统可能导致危害情形，外部风险控制措施不足以将风险降至可接受水平，且可能造成的伤害为非严重伤害。此等级要求完整的需求文档、架构设计文档和集成测试。
Class C — 可能导致的伤害为死亡或严重伤害。这是最严格的等级，要求详细设计文档、单元测试、集成测试、完整的可追溯性矩阵，以及所有过程活动的全面文档记录。
2015年修正案的一个重要变化是明确了分类依据：制造商应基于"最坏情形"（worst-case scenario）来评估软件可能导致的伤害，从而确定安全等级。分类过程应当与ISO 14971风险管理活动紧密结合。
软件开发生命周期过程
IEC 62304定义了以下核心过程：
软件开发策划 — 制定软件开发计划，明确开发模型（瀑布、迭代、敏捷等均可接受）、开发工具、配置管理方案、以及各安全等级对应的具体活动。标准本身不限定开发模型，在我们看来，这给了团队相当大的灵活度。
软件需求分析 — 建立软件需求规格，包括功能需求、性能需求、接口需求和安全需求。需求应与系统级别的风险分析保持可追溯性。
软件架构设计 — 将软件分解为软件项（Software Items），定义各项之间的接口和数据流。对Class B和Class C软件，架构文档是强制性的。
软件详细设计与单元实现 — 仅Class C强制要求。需要在编码前完成详细设计，并对每个单元进行验证。
软件集成与测试 — Class B和Class C均需进行集成测试，验证软件项的正确交互。Class A在2015修正案后也需要进行系统级测试。
软件发布 — 确认所有计划活动已完成，已知异常已评估，发布版本的文档齐全。
SOUP管理
SOUP（Software of Unknown Provenance）是IEC 62304中一个特别值得关注的概念，指来源不明的软件——包括开源库、第三方组件、商业现成软件（COTS）等。在实际开发中，几乎没有产品不使用SOUP。
标准要求制造商对每一个SOUP组件进行识别和管理：记录其名称、版本号、制造商/来源；评估其已知缺陷（anomalies）是否会引入不可接受的风险；对Class B和Class C软件，还需要定义SOUP的功能和性能要求，并验证SOUP是否满足这些要求。
2015年修正案在第5.5.4节强化了SOUP管理要求，明确制造商须对第三方库的已知缺陷进行系统化评估，并给出风险可接受性的论证依据。
从实操角度看，SOUP管理在近几年变得更加重要。FDA在2025年6月发布的最终版网络安全指南中，要求所有"网络设备"（cyber device）在上市前提交软件物料清单（SBOM），其中就包含了对SOUP/第三方组件的全面披露要求。
与IEC 82304-1的关系
IEC 82304-1:2016是一项产品标准，全称"Health software — General requirements for product safety"，适用于独立运行的健康软件产品（不依赖专用硬件）。两者的关系可以这样理解：IEC 82304-1定义了产品"应该做到什么"，IEC 62304定义了开发过程"应该怎么做"。
IEC 82304-1在其第5章中多处引用IEC 62304的具体条款，要求开发过程遵循IEC 62304。对于SaMD产品，如果同时适用两项标准，通常的做法是以IEC 62304为开发过程框架，以IEC 82304-1补充产品级别的安全要求，如上市后监测和问题处理。
FDA对软件类器械的监管要求
FDA对医疗器械软件的监管持续收紧。目前需要关注的几项重要指南包括：
"Cybersecurity in Medical Devices"最终版指南（2025年6月） — 这份指南实施了FD&C法案第524B条的要求，适用于所有含软件的器械。制造商须在上市前提交SBOM、威胁模型、漏洞管理计划等网络安全文档。指南明确了"网络设备"的定义：只要器械包含软件或器械本身就是软件，就属于网络设备的范围。
"Content of Premarket Submissions for Device Software Functions"指南 — 要求在510(k)和PMA申报中提交软件描述文件（Software Description）、危害分析、软件架构图、测试验证报告等。软件安全等级越高，要求的文档越详细。
实操建议：在产品开发早期就按IEC 62304的要求建立软件开发过程，将风险管理融入每个阶段，可以避免后期返工。
EU MDR下的软件合规
MDR将软件纳入了医疗器械的定义范围，且附录VIII的分类规则11（Rule 11）专门针对软件进行分类——旨在提供诊断或治疗建议的软件最低为IIa类，涉及治疗决策的可为III类。
欧盟委员会发布的MDCG 2019-11号指南为SaMD的分类提供了详细说明。公告机构在审核软件类器械时，会重点核查IEC 62304的执行情况，包括安全分类的合理性、开发过程文档的完整性、以及SOUP管理的规范性。
ISO 13485质量体系中的设计控制流程，与IEC 62304的软件开发生命周期过程存在对应关系。建立体系时将两者整合，能有效减少文档冗余。
参考资源
- IEC 62304:2006+AMD1:2015 — IEC官方标准页面
- IEC 82304-1:2016 — 健康软件产品安全标准
- FDA认可共识标准：IEC 62304 — FDA标准认可数据库
- FDA网络安全指南（2025年6月最终版） — 网络设备上市前提交要求
- MDCG 2019-11 SaMD分类指南 — 欧盟SaMD分类指导文件
最后更新：
