📚 课程目录第2章医疗软件法规与标准基线

2. 医疗软件法规与标准基线

医疗软件测试不是“把功能点测完”就结束，它必须回答一个更严格的问题：你凭什么证明这款软件安全、有效、合规？ 这个“凭什么”就是法规与标准基线。不同市场的监管框架各有侧重，但最终都会收敛到同一条主线——风险驱动的全生命周期控制，以及可追溯的测试证据链。理解这条主线，才能把测试活动从“技术行为”升级为“合规证据生产”。

一、五套基线的定位与分工

先厘清每套文件“管什么”，避免混用。

FDA 21 CFR Part 820（QSR，现逐步过渡到 QMSR）：美国质量体系法规，规定设计控制、采购控制、生产与服务控制、纠正预防措施（CAPA）、投诉与记录等。对软件而言，设计控制中的设计验证与设计确认是测试证据的直接来源。
IEC 62304：医疗器械软件生命周期过程标准，核心是软件安全分级（A/B/C）、开发过程、维护过程、风险管理过程、配置管理与问题解决。它决定“测试要做到什么深度”。
ISO 13485：医疗器械质量管理体系要求，强调文件化、过程方法、可追溯性与持续改进，是组织级“证据管理制度”。
ISO 14971：风险管理标准，要求识别危害、估计风险、评价风险、控制风险并验证控制措施有效性。它是测试用例优先级的源头。
NMPA 注册要求：中国医疗器械注册与备案管理，含产品技术要求、软件研究资料、网络安全描述、临床评价等，测试证据需满足其申报格式与内容要求。

五者关系可以概括为：ISO 13485 管“体系怎么运转”，FDA 820 管“美国市场怎么合规”，IEC 62304 管“软件怎么开发”，ISO 14971 管“风险怎么控”，NMPA 管“中国怎么申报”。测试证据链必须同时满足这五套要求，而不是各写一套。

二、软件安全分级决定测试强度

IEC 62304 按软件失效可能导致的伤害程度分为 A、B、C 三级：A 级无伤害可能，B 级可能非严重伤害，C 级可能死亡或严重伤害。分级不是标签，而是直接决定测试策略：

等级	典型场景	测试强度要求
A	仅用于统计、非诊断辅助	基本功能验证，单元测试可简化
B	参数计算、报警提示	单元+集成+系统测试，需覆盖异常路径
C	给药剂量、放疗计划、生命支持	全路径覆盖、边界与故障注入、独立验证

例如某输液泵软件被定为 C 级，则“剂量计算模块”的测试不能只验证正常输入，还必须覆盖：输入超范围、单位混用、传感器漂移、通信中断、看门狗复位等场景，并保留每条用例与风险控制措施的对应关系。

三、从风险到测试用例的映射

ISO 14971 要求对每个危害给出风险控制措施，而控制措施是否有效，必须通过测试验证。因此测试用例不是凭空设计的，而是从“危害—控制措施—验证方法”推导出来的。典型映射逻辑如下：

危害 H-01：剂量计算错误导致过量输注
  → 风险控制 RC-01：剂量上限硬限制 + 二次确认
    → 验证方法 V-01：输入超上限值，系统拒绝并告警
      → 测试用例 TC-101：输入 9999 ml/h，期望拒绝且记录日志
      → 证据：测试记录 + 日志截图 + 需求追溯矩阵行

这条链就是测试证据链的最小单元：危害可追、控制可查、用例可执行、结果可复现、记录可审计。任何一个环节断裂，注册审评时都可能被质疑。

四、证据链的完整结构

把上述关系放大到项目级，证据链应形成“需求—风险—设计—测试—结果”的闭环。下图展示五套基线如何汇聚到同一条证据链上：

五、NMPA 注册对测试证据的具体要求

NMPA 注册申报中，软件相关测试证据通常体现在三处：产品技术要求（含软件功能、性能、接口指标）、软件研究资料（含软件描述、风险管理、生存周期、网络安全、验证与确认）、检验报告（由具备资质的检验机构出具）。测试证据链需要与这三处一一对应。

以“软件研究资料”为例，审评关注的是：软件安全级别判定依据是否充分、需求是否可追溯、测试是否覆盖全部需求与风险控制措施、缺陷是否闭环。若某条需求没有对应用例，或某条用例没有执行记录，都会形成证据缺口。

实操建议：建立一张“需求—风险—用例—结果”四列追溯矩阵，每列都带唯一编号。注册前逐行检查，任何一行出现空值即为缺口，必须补齐或说明理由。

六、常见证据链断裂与修复

实际项目中最常见的断裂有四类：

风险控制措施未验证：风险分析写了“增加二次确认”，但测试用例只测了正常流程。修复：为每条控制措施补一条“反例”用例。
需求与用例编号不对应：需求改了版本，用例没同步。修复：把追溯矩阵纳入配置管理，需求变更时强制触发用例评审。
测试记录缺少环境与版本信息：无法复现。修复：记录软件版本、硬件配置、测试数据、执行人与时间。
缺陷未闭环：发现问题后未记录处理结论。修复：每个缺陷必须有“修复—回归—关闭”三段记录。

注意：IEC 62304 的 C 级软件要求对“软件单元”进行验证，且当无法实现完整单元测试时需说明理由并采取替代措施。这不是可选项，而是审评重点核查项。

七、把基线落到测试计划里

最后给出一个可执行的落地方式：在测试计划中设置“合规映射”章节，逐条列出本节涉及的法规条款、对应测试活动、证据形式与责任人。例如：

条款：IEC 62304 5.5.2 软件单元验证
测试活动：对剂量计算模块执行单元测试
证据形式：单元测试报告 + 覆盖率报告 + 评审记录
责任人：测试工程师 / 独立评审人
判定：语句覆盖率≥90%，分支覆盖率≥80%，异常路径全覆盖

当每一行都能填满，测试证据链就真正建立起来了。法规与标准不是测试的负担，而是测试设计的输入——它们告诉你“哪些必须测、测到什么程度、留下什么证据”。把这条基线吃透，后续的测试体系设计、用例编写与注册申报才有稳固的根基。