缺失数据无法被检测：遗漏类错误的技术盲区

一种没有任何信号的错误模式

有一个约束条件出现在比人们想象中更多的系统里，医疗领域有一个很清晰的例子。

在入院时的用药核对中，经同行评审的研究表明，遗漏——即患者实际服用的药物但 simply missing from the list——约占发现错误的 76%。剂量错误以约 16% 位居第二。根据 settings 不同，39% 至 50% 的入院患者至少有一项非故意的差异。

现在注意遗漏与其他所有错误类型的不同之处：

除遗漏之外的一切都是对存在数据的函数。遗漏是数据的 absence。没有异常值，没有异常分数，没有触发的规则。你可以用你拥有的每条验证规则去运行那条记录，它都会通过，因为记录本身是内部一致的。它只是不完整，而不完整性不会 self-announces。

通用原则

你无法通过检查单一来源来检测 absence。不存在的东西里没有信号。

这听起来显然是废话，但它不断被违反，因为当遇到数据质量问题时，本能是去对已有的数据构建一个验证器。这对除数据缺失之外的所有错误类别都有效——而在这里，恰恰是多数类别。

检测 absence 需要第二个独立来源和一次比较。这是唯一的机制。这意味着架构不是"分析记录"，而是"跨来源 reconciliation"，这是两个非常不同的系统。

为什么合并去重是错误的构建方式

诱人的版本：拉取医院用药清单、药房发药记录、上次出院小结、专科 notes。合并。去重。返回一个干净的统一列表。

这失败的原因值得内化：合并是一个 resolution 操作，而 resolution 会摧毁发现。

当药房显示一种 statin 在 90 天前被调配，而医院清单遗漏了它，合并必须选出一个胜者。但"哪个来源是对的"在这里不是一个数据问题——这是一个未确定的临床事实。患者停药了吗？专科医生停药了吗？没人问过吗？不同的答案，不同的行动。一旦你自动 resolution，你就丢弃了唯一真正有价值的东西：来源之间存在分歧这一认知。

推论：absence 在某种程度上是 ambiguous 的，而 presence 则不是。一条用药记录缺失可以意味着停药、从未开过、在别处开过、或在匆忙的入院问诊中未被提及。四个含义，同一个看起来相同的缺口。再多聪明也无法仅从数据本身区分它们。

应该构建什么

将它建模为一个分歧引擎，而不是合并器：

将 SOURCES_DISAGREE 表示为第一类状态。不是错误，不是要 reconciliation 掉的东西——而是一种输出。你的 schema 应该能够说"药房断言 X，医院清单沉默，未解决。"

保留每个断言的 provenance。每条事实都携带哪个来源在何时声称了它。当有人问为什么某条差异被标记时，你就会需要这个。

按后果排序，而不是按置信度排序。缺失抗凝药和缺失维生素 D 不是同样的发现。审查人员的注意力是稀缺资源；按临床权重来花费它。

路由给能够 out-of-band 解决它的人。其中一些只有通过询问患者才能回答。将此设计为最终步骤，而不是假装系统本身可以关闭这个循环。

与上次写的四态评估相同的形状——UNKNOWN 值得作为一个值，而不是默认为 NO。

Agent 无法确认用药清单。确认需要临床医生或药剂师与患者交谈。还需要说明：药房发药数据显示的是发药，而不是依从性——取药意味着被领取了，而不是正在服用。我也不是在说这能减少药物不良事件；那需要我没有的结果证据。狭窄的主张：从未被发现的差异永远不会被调查。

我们在 IntelliBooks Studio 构建这个模式。愿意在评论区深入讨论 provenance schema 或分歧状态建模。