3. 设计审查的法规与标准依据

医疗器械软件设计审查最容易出现的偏差，是把“标准符合性”当成一句结论，而不是一组可核查的证据。IEC 62304、ISO 13485、ISO 14971、IEC 82304 以及 FDA、NMPA 的监管要求，各自关注的层面并不相同：有的管软件生命周期过程，有的管质量管理体系，有的管风险，有的管独立软件产品，有的管上市前提交与审评。设计审查要做的，是把这些条款翻译成具体、可验证、可留痕的审查项，并明确每条审查项对应哪份证据、由谁提供、在哪个阶段关闭。

一、五类依据的分工与交叉

IEC 62304 是软件生命周期过程标准，核心是把软件开发划分为开发策划、需求分析、架构设计、详细设计、单元实现与集成、系统测试、发布等过程，并按软件安全分级（A、B、C）决定过程的严格程度。它回答的是“软件怎么被开发出来、过程是否受控”。ISO 13485 是质量管理体系标准，关注设计控制、文件控制、采购、生产与服务、纠正预防措施等，回答的是“组织是否有能力持续稳定地做出合规产品”。ISO 14971 是风险管理标准，要求贯穿全生命周期的风险分析、评价、控制与剩余风险判断，回答的是“危害是否被识别并降到可接受水平”。IEC 82304 针对健康软件产品，尤其是独立软件，补充了产品级要求，如预期用途、系统要求、可用性、信息安全、数据完整性、随附文档等。FDA 与 NMPA 则从监管角度提出上市前要求：FDA 关注软件文档、软件级别、网络安全、互操作性及 510(k)/De Novo/PMA 路径下的软件证据；NMPA 关注软件描述文档、网络安全描述文档、软件研究资料、临床评价及注册审查指导原则。

这五类依据不是并列关系，而是“过程—体系—风险—产品—监管”的层次关系。设计审查时，不能只查 IEC 62304 的条款清单，也不能只查注册资料是否齐全，而应建立交叉映射：一条监管要求往往需要多个标准条款共同支撑，一条标准条款也可能同时服务于多个监管审查点。

二、从条款到审查项的翻译方法

把条款翻译成审查项，建议采用“四要素法”：查什么、看哪份证据、判定准则是什么、谁签字关闭。以 IEC 62304 的软件安全分级为例，条款要求根据软件可能导致的危害严重程度确定 A、B、C 级。对应的审查项不是“是否做了分级”，而是“分级是否基于 ISO 14971 的危害分析结果、是否覆盖所有软件项、分级结论是否有评审记录、分级变化是否触发过程调整”。证据包包括：软件安全分级报告、危害分析输入清单、分级评审记录、分级变更记录。判定准则可以写成：每个软件项均有明确级别；级别判定可追溯到具体危害；C 级软件项已执行 62304 中对应的全部过程要求。

再以 ISO 13485 的设计控制为例，条款要求对设计输入、设计输出、设计评审、设计验证、设计确认、设计转换和设计变更进行控制。对应审查项应落到具体记录：设计输入是否包含功能、性能、安全、法规、可用性、网络安全等要求；设计输出是否可追溯到设计输入；设计评审是否在关键节点进行且参与者具备相应职能；设计验证是否覆盖全部设计输入；设计确认是否在模拟使用条件下完成。证据包包括设计历史文档（DHF）中的输入清单、输出清单、追溯矩阵、评审记录、验证报告、确认报告和变更记录。

三、建立映射表的实操示例

实际审查中，建议维护一张“条款—审查项—证据—责任人—状态”映射表。下面给出一个可参考的示例片段，字段可根据项目裁剪，但“条款来源”和“判定准则”不建议省略。

四、审查时的常见断点

映射表建立后，审查的重点是找“断点”。常见断点有四类：第一，条款有、审查项无，说明标准要求没有被翻译成可核查动作；第二，审查项有、证据无，说明执行记录缺失；第三，证据有、判定准则无，说明审查结论依赖个人经验，不可复现；第四，证据与条款版本不一致，例如仍引用旧版 IEC 62304 或旧版注册指导原则。审查时可以用“反向追溯”快速定位：从一份证据出发，问它支撑哪条审查项、该审查项来自哪条法规或标准、当前版本是否有效。若链条中任一环断裂，就应开出审查发现项，并要求补充证据或修订映射表。

需要强调的是，IEC 62304、ISO 13485、ISO 14971、IEC 82304 与 FDA、NMPA 要求之间不是简单的一对一关系。同一条审查项可能同时支撑多个条款，例如“软件需求可追溯”既服务于 62304 的需求管理，也服务于 13485 的设计控制，还服务于 14971 的风险控制验证。因此映射表应允许“多对多”，但每条审查项必须至少有一个明确的条款来源，每条条款也必须至少有一条审查项承接，避免出现监管要求悬空或审查项无依据的情况。