做有源医疗器械注册的同行，最近想必都在关注一件事。
2025年，医疗器械软件相关的政策文件密集出台。国家药监局在5月发布了《移动医疗器械注册审查指导原则（2025年修订版）》，11月北京市药监局又印发了《第二类医疗器械独立软件技术审评规范》。加上即将于2026年更新的IEC 62304国际标准，软件验证这一块的审查尺度正在持续收紧。
不少企业在技术审评中收到发补意见，问题都指向同一个文档——软件验证报告。
一、软件验证报告到底是什么？为什么越来越重要？
说白了，软件验证报告就是你向审评机构证明"这段软件是可靠的"的系统性证据集合。
根据EN 62304:2006/AC:2008《医疗器械软件 软件生命周期过程》（国内对应GB/T 34986），凡是含有软件组件的有源医疗器械，都需要在注册申报时提交完整的软件验证资料。这份报告的核心目的，是通过结构化的文档和测试记录，证明软件在整个生命周期内都经过了有效控制。
2025年发布的《医疗器械生产质量管理规范》修订版，进一步强调了软件全生命周期的质量管控要求。从需求分析、风险管理到测试确认，每一个环节都需要形成可追溯的文件记录。
这里需要区分一个常见概念。独立软件（如PACS系统、移动医疗App）和软件组件（如嵌入在激光设备中的控制软件），虽然技术形态不同，但生命周期质控的原则是一致的。区别在于独立软件需要单独注册，而软件组件随产品整体申报。不少企业第一次做有源产品注册时，容易把这两者混为一谈，导致申报资料准备的方向出现偏差。
一个值得关注的趋势是，IEC 62304的2026版已经进入最终审批阶段，预计2026年8月正式发布。新版本用"软件过程严格度等级"替代了原有的A/B/C安全分类体系，并首次增加了对AI/ML软件的专门指导。这意味着，现有的验证报告框架需要同步升级。
图：EN 62304是医疗器械软件验证的国际基准标准
二、核心要点一：软件安全分类决定验证深度
EN 62304将医疗器械软件按风险程度分为三类。A类指软件失效不会导致任何健康伤害；B类指可能引起非严重伤害；C类则指可能导致严重伤害或死亡。
分类不同，所需的文档深度和验证活动也有明显差异。
在实际操作中，很多团队对分类的判定过于乐观。以激光类治疗设备为例，虽然软件本身不直接接触人体，但一旦参数控制出错导致激光功率异常，就可能对患者造成伤害。这类软件应当归为B类，需要完整的风险分析、详细设计文档、单元测试和集成测试记录。如果按A类来准备，资料深度往往达不到审评要求。
分类判定的依据，应当结合产品的预期用途、使用场景和软件失效后的最坏情况来综合分析。建议在项目早期就组织研发、质量和临床人员共同评审，形成书面的分类 rationale。
图：不同安全等级的软件对应不同的文档和验证要求
三、核心要点二：风险管理要贯穿软件全生命周期
风险管理不是一次性的活动，而是需要贯穿软件从立项到退市的全过程。
根据GB/T 42062（ISO 14971）的要求，软件风险分析需要覆盖三个层面：首先是开发过程中的技术风险，比如需求不完整、代码逻辑错误；其次是使用过程中的操作风险，比如用户误操作、信息显示不充分；还有验证过程的计划风险，比如测试覆盖不足、验证方法不合理。
在实际审评中，常见的问题包括：风险识别不全面、控制措施缺乏针对性、剩余风险评估不充分。很多报告只列了寥寥几条风险，控制措施写得笼统，一看就是"为了有而有"，缺乏真实的工程思考。
一份合格的风险分析表，至少应当包含以下要素：危害描述、可能导致的损害、危害发生的原因、风险控制措施、控制措施的验证方法，以及控制后的残余风险结论。每一项都需要有据可查，能够追溯到具体的设计文档或测试记录。
图：GB/T 42062规定的医疗器械风险管理活动流程
四、核心要点三：追溯分析是报告的灵魂
追溯分析（Traceability Analysis）是很多企业最头疼的部分，也是审评老师看得最细的部分。
它的核心逻辑是：每一个软件需求，都要能找到对应的设计规格、实现代码和测试用例。反过来，每一项测试活动，也要能回溯到最初的需求来源。这种双向追溯形成了一个完整的证据链，让审评人员能够确认"你说了要做的，确实都做了，而且都做了验证"。
在实际操作中，比较常见的困难有两个。一是前期需求规格写得过于笼统，导致后续无法建立精确的对应关系。二是开发过程中需求发生了变更，但追溯矩阵没有及时同步更新，造成前后不一致。
建议在项目启动阶段就搭建好追溯矩阵的框架，随着开发推进逐步填充内容。需求变更时，同步更新设计文档、代码注释和测试计划，确保矩阵始终反映最新的项目状态。这份矩阵最终会成为软件验证报告中最核心的交付物之一。
五、核心要点四：测试矩阵需要覆盖全部功能路径
软件测试部分通常包括单元测试、集成测试和系统测试三个层级。
单元测试针对每个功能模块单独验证，比如按键扫描是否正确响应、LCD显示是否刷新正常。集成测试关注模块之间的交互，比如用户按下按键后，系统是否正确调用对应的输出控制函数。系统测试则从用户视角出发，验证完整的操作流程是否符合预期。
审评中常见的测试类问题包括：测试用例数量不足、边界条件覆盖不全、实际测试结果缺少原始记录。一份合格的测试报告，每个测试用例都需要有明确的测试方法、预期结果、实际结果和结论。如果某个测试项未通过，还需要说明原因分析、后续处理措施以及复测结果。
图：软件开发与测试验证的V模型对应关系
软件验证报告的准备是一项系统工程。从分类判定、风险分析到追溯矩阵和测试记录，每一个环节都需要研发、质量和法规团队的紧密配合。
2025年以来，独立软件和有源器械中的软件组件的审评要求都在持续细化。加上IEC 62304 2026版即将生效，软件验证的合规门槛只会越来越高。提前建立起规范化的验证流程和文档体系，不仅是应对当前注册申报的需要，更是为后续产品迭代和变更注册打下基础。
为了方便大家高效准备软件验证相关资料，我们整理了一份覆盖EN 62304全生命周期的软件验证报告模板。这份模板按照标准要求的12个核心章节编排，包含了需求规格、风险管理、追溯矩阵、测试用例等关键表格的范例格式，适用于B类有源医疗器械的软件验证工作。
在公众号后台回复【验证模板】，即可自动获取完整版PDF文件。
关注医械加油站，带你深耕医械合规，拆解国内外注册实战干货！