2. 医疗软件法规与标准框架

医疗软件的验证与确认（V&V）不是孤立的技术活动，它必须落在具体法规与标准所定义的“合规坐标系”中。同一个测试用例，在 IEC 62304 语境下回答的是“软件是否按架构与需求正确实现”，在 ISO 14971 语境下回答的是“剩余风险是否可接受”，在 FDA 21 CFR Part 820 语境下回答的是“设计输出是否满足设计输入、是否可追溯到设计历史记录”。理解这些框架各自管什么、彼此如何映射，是制定 V&V 策略的前提。

一、五个框架的分工：谁管质量体系，谁管软件过程，谁管风险

可以把它们分成三层来看。第一层是质量体系层：ISO 13485 规定医疗器械组织的质量管理体系要求，是“组织级”的；FDA 21 CFR Part 820（Quality System Regulation，QSR）是美国市场的质量体系法规，其设计控制条款（820.30）直接规定了设计验证、设计确认、设计评审与设计历史文档（DHF）的要求。第二层是软件过程层：IEC 62304 规定医疗器械软件生命周期过程，把软件按 A、B、C 三个安全等级分级，并规定各级别必须执行的活动与文档。第三层是风险管理层：ISO 14971 规定风险管理过程，输出风险可接受性准则、风险控制措施与剩余风险评价，是 V&V 的“判据来源”。欧盟 MDR（EU 2017/745）则是法规层，它不另立一套软件过程，而是通过通用安全与性能要求（GSPR）附录 I 以及引用协调标准，把上述标准“法规化”。

关键认识是：ISO 14971 定义“什么算可接受”，IEC 62304 定义“软件怎么做”，ISO 13485 与 Part 820 定义“组织如何证明做对了”，MDR 定义“进入欧盟市场必须满足哪些法定要求”。V&V 活动同时被这四者约束，因此必须建立映射，而不是各写一套文档。

二、IEC 62304 的软件安全分级如何决定 V&V 强度

IEC 62304 的分级依据是“软件失效是否可能导致伤害”：A 级为不可能导致伤害或不健康；B 级为可能导致非严重伤害；C 级为可能导致死亡或严重伤害。分级直接决定验证活动的深度。例如，C 级软件必须进行单元验证（unit verification），且要求对每个软件单元建立详细设计；B 级可只做集成与系统级验证；A 级通常不需要单元级验证。此外，C 级要求软件架构设计、详细设计、单元验证记录，并强调对 SOUP（不明来源软件，即现成软件）的评估与风险控制。

一个常见的实操判断是：若某软件项被定为 C 级，则其单元测试覆盖率、代码审查、静态分析都必须有记录，且这些记录要能追溯到软件需求与风险控制措施。若定为 B 级，则重点放在集成测试与系统测试，单元级可依赖代码评审而非逐单元测试。分级不是“越严越好”，而是“与风险相称”，过度分级会浪费资源，分级不足则构成合规缺陷。

三、ISO 14971 如何为 V&V 提供判据与追溯链

ISO 14971 的核心逻辑是：识别危害 → 估计风险 → 评价风险 → 控制风险 → 评价剩余风险 → 整体受益-风险判断。对 V&V 而言，最重要的输出是风险控制措施。当风险控制措施落在软件上时，该措施就转化为一条软件需求，进而转化为一条验证活动。例如，某输液泵软件识别到“流速设置超出安全上限”这一危害，风险控制措施为“软件在流速超过 500 mL/h 时拒绝执行并报警”。这条措施成为软件需求，验证时必须构造边界用例：499、500、501 mL/h，确认 501 被拒绝且报警触发。这就是“风险—需求—验证”的追溯链。

需要强调的是，ISO 14971 要求验证的是风险控制措施的有效性，而不仅是软件功能是否正确。因此 V&V 记录中应明确写出“本测试对应风险控制措施 RC-03，验证其有效性”。

四、FDA 21 CFR Part 820 与 MDR 的 V&V 要求差异

Part 820.30 把设计验证定义为“确认设计输出满足设计输入”，把设计确认定义为“确认器械满足用户需求与预期用途”。两者在 FDA 语境下是分开的：设计验证偏“做对产品”，设计确认偏“做对的产品”。对软件而言，设计验证通常对应需求测试、单元/集成测试；设计确认通常对应临床评价、可用性测试、真实使用场景测试。Part 820 还要求设计历史文档（DHF）包含所有验证与确认记录，并保持可追溯。

MDR 的 GSPR 附录 I 第 17 条专门针对电子可编程系统，要求软件按最新技术水平开发、考虑生命周期过程、风险管理与信息安全。MDR 不直接规定测试方法，而是要求制造商证明符合协调标准（如 IEC 62304、ISO 14971、IEC 82304-1）。因此，面向欧盟的 V&V 策略通常是“以 IEC 62304 为过程骨架，以 ISO 14971 为风险判据，以 GSPR 为合规检查表”。

五、映射关系：一张图看清五者如何共同约束 V&V

下面这张图把五个框架放在同一张“约束—输出”关系图中：左侧是各框架，中间是它们对 V&V 的直接要求，右侧是 V&V 必须产出的证据。图中同时标出追溯方向，便于理解为什么一份测试记录要同时满足多个框架。

六、实操：如何建立一份可用的 V&V 映射表

实际工作中，建议以“需求—风险—测试—标准条款”四列建立映射表。下面给出一个可填写的示例结构，字段直接对应上述框架，便于在项目里落地。

填写时注意两点。第一，“对应标准条款”不是越多越好，只填真正约束该测试的条款，否则追溯矩阵会膨胀到无法维护。第二，风险控制措施 ID 必须与 ISO 14971 风险管理文件中的编号一致，这样在审核时才能从测试记录直接跳回风险分析，形成闭环。

总结来看，V&V 的合规性不取决于做了多少测试，而取决于测试是否对准了正确的判据、是否覆盖了风险控制措施、是否留下了可追溯的证据。ISO 13485 与 Part 820 管“证据是否受控可查”，IEC 62304 管“测试深度是否与软件等级相称”，ISO 14971 管“测试是否验证了风险控制有效性”，MDR 管“是否满足欧盟法定要求”。把这四者映射到同一张追溯矩阵上，V&V 才真正具备可审核、可辩护的工程意义。