4. 验证证据工程基础
在医疗软件的需求追溯与验证活动中，“证据”不是泛指任何与开发有关的文档，而是指能够支持某一项需求已被正确实现、且风险已被充分控制的客观记录。更准确地说，验证证据是可核查、可追溯、可复现的信息载体，它把“我们声称做到了”转化为“有记录证明我们确实做到了”。如果一条需求只有设计描述而没有验证记录，那么它在监管审查中仍然属于未闭环状态。
证据的核心属性包括三点：第一，关联性，即证据必须明确指向某条需求、某个风险控制措施或某个设计输出；第二，客观性，即证据应来自实际执行过程，而不是事后补写的说明；第三，可追溯性，即从需求到证据之间应存在唯一且可反向查询的标识链路。例如，需求 REQ-ALM-014 要求“当血氧饱和度低于 90% 时，报警应在 10 秒内触发”，那么对应的测试记录必须包含该阈值、时间测量方法和实际触发时间，而不能只写“报警功能正常”。
在医疗软件生命周期中，常见的验证证据类型主要有四类：测试记录、分析报告、审查记录和演示。它们并不是互相替代的关系，而是根据需求性质、风险等级和验证目标组合使用。
- 测试记录：通过执行测试用例获得的结果记录，包括输入数据、操作步骤、预期结果、实际结果、判定结论、执行人和时间。它最适合验证功能性、边界条件、报警响应、数据精度等可观测行为。
- 分析报告：通过计算、建模、静态分析或逻辑推理形成的论证材料。例如对算法误差传播的分析、对内存占用上限的估算、对失效模式影响的分析。它适用于无法直接通过运行测试完全覆盖的属性，如安全性、可靠性、性能上限。
- 审查记录：由具备资质的人员对需求、设计、代码、风险文档进行系统性检查后形成的记录，包括审查对象、审查依据、发现问题、处理结论和关闭状态。它适合发现遗漏、不一致和可追溯性缺口。
- 演示：在受控条件下向指定人员展示软件行为并形成记录，通常用于用户界面流程、临床工作流、报警呈现方式等难以完全自动判定的场景。演示必须有脚本、有观察记录、有结论，不能只是“口头确认”。
证据强度是证据工程中非常关键但容易被忽视的概念。它描述的是某项证据对“需求已满足”这一结论的支持力度。强度不是由文档页数决定的，而是由证据与需求的匹配程度、执行过程的受控程度、结果的可重复性以及独立复核程度共同决定。一般来说，可以按以下维度判断证据强度：
| 维度 | 强证据特征 | 弱证据特征 |
|---|---|---|
| 与需求的对应关系 | 直接覆盖需求条款，逐条可追溯 | 仅间接相关，需大量推断 |
| 执行受控程度 | 按批准脚本执行，环境、版本、数据可复现 | 临时操作，环境或版本不明 |
| 结果客观性 | 有原始输出、日志、截图、测量值 | 只有结论性描述，无原始数据 |
| 独立复核 | 由非作者人员复核并签署 | 自测自签，无第二人确认 |
| 异常处理 | 偏差已记录、评估并关闭 | 异常被忽略或口头解释 |
可接受准则则是把证据强度转化为可操作的判定门槛。它回答的问题是：对于某条需求或某个风险控制措施，达到什么条件才算证据充分？可接受准则通常由风险等级驱动。高风险需求，例如与患者安全直接相关的报警、剂量计算、闭环控制，通常要求强证据组合，如“测试记录 + 独立复核 + 边界与异常场景覆盖”；中等风险需求可采用“测试记录 + 审查记录”；低风险需求可能只需“演示 + 审查记录”即可。关键在于，可接受准则必须在验证活动开始前定义，而不是在证据收集完成后倒推。
下面这张图展示了一个典型的证据判定链路：从需求出发，经过证据类型选择、强度评估，最终进入可接受准则判断，并区分“通过”“有条件通过”“不通过”三种状态。图中同时标出了证据强度不足时最常见的回流路径——补充测试、补充分析或重新审查。
在实际项目中，证据强度不足往往不是因为没有做测试，而是因为记录方式无法支撑判定。例如，测试记录只写“报警正常”，没有记录触发阈值、响应时间和测量方法，那么即使测试确实执行过，也无法证明需求中的“10 秒内触发”被满足。再如，分析报告只给出结论“算法安全”，却没有输入假设、计算过程和边界条件，那么它只能算作说明材料，不能作为强证据。
因此，建立可接受准则时，建议把每条需求或每个风险控制措施与证据要求绑定，形成可检查的判定表。下面给出一个可直接参考的示例结构，用于在验证计划中定义证据门槛：
需求编号：REQ-ALM-014
需求描述：SpO2 < 90% 时，报警应在 10 秒内触发
风险等级：高
证据类型要求：测试记录 + 独立复核
可接受准则：
1. 测试记录包含阈值 90%、采样条件、时间测量方法；
2. 至少覆盖正常边界 89%、90%、91% 三种输入；
3. 实际触发时间 ≤ 10 秒，且记录原始时间戳；
4. 由非测试执行人复核并签署；
5. 若出现超时，偏差已记录、评估并关闭。
判定结论：通过 / 有条件通过 / 不通过需要特别强调的是，证据强度与可接受准则必须在需求评审阶段就与需求同步定义。如果等到测试完成后再讨论“这些记录够不够”，往往会出现两种被动局面：一是证据已经无法补录，只能重新执行；二是为了赶进度而降低准则，导致高风险需求的实际验证强度不足。正确的做法是，在需求追溯矩阵中为每条需求标注证据类型、强度要求和可接受准则，使验证活动从一开始就围绕明确的证据目标展开。
总结来看，证据工程的核心不是“收集更多文档”，而是“让每一条需求都有匹配其风险等级的、可核查的、可追溯的客观记录”。测试记录、分析报告、审查记录和演示各有适用边界；证据强度决定结论的可信度；可接受准则则把这种可信度转化为团队和监管方都能一致执行的判定标准。三者结合，才能让需求追溯真正闭环，而不是停留在形式上的文档对应。