You Can't Build a Detector for Absence

A failure mode with no signal

Here's a constraint that shows up in more systems than people expect, and healthcare has a clean example of it.

In medication reconciliation at hospital admission, peer-reviewed studies put omission — a drug the patient actually takes that's simply missing from the list — at roughly 76% of errors found. Incorrect dosage is a distant second around 16%. Between 39% and 50% of admitted patients have at least one unintended discrepancy depending on setting.

Now notice what's different about omission compared to every other error type:

Error	Detectable in the record?
Wrong dose	Yes — range check
Duplicate therapy	Yes — compare entries
Interaction	Yes — pairwise lookup
Contraindication	Yes — rule against diagnosis
Omission	No

Everything except omission is a function of data that exists. Omission is the absence of data. There's no outlier, no anomaly score, no rule that fires. You could run every validator you own against that record and it would pass, because the record is internally consistent. It's just incomplete, and incompleteness doesn't announce itself.

The general principle

You cannot detect absence by examining a single source. There is no signal in the thing that isn't there.

This sounds obvious stated plainly, but it gets violated constantly, because the instinct when you have a data quality problem is to build a validator over the data you have. That works for every error class except the one where the data is missing — which, here, is the majority class.

Detecting absence requires a second, independent source and a comparison. That's the only mechanism. Which means the architecture isn't "analyse the record," it's "reconcile across sources," and those are very different systems.

Why merge-and-dedupe is the wrong build

The tempting version: pull the hospital list, pharmacy fill history, last discharge summary, specialist notes. Merge. Dedupe. Return a clean unified list.

This fails for a reason worth internalising: merging is a resolution operation, and resolution destroys the finding.

When the pharmacy shows a statin filled 90 days ago and the hospital list omits it, a merge has to pick a winner. But "which source is right" isn't a data question here — it's an unestablished clinical fact. Did the patient stop? Did a specialist discontinue it? Did nobody ask? Different answers, different actions. The moment you auto-resolve, you've thrown away the only thing that was actually valuable: the knowledge that sources disagree.

Corollary: absence is ambiguous in a way presence isn't. A drug missing from a list can mean discontinued, never prescribed, prescribed elsewhere, or not mentioned during a rushed intake. Four meanings, one identical-looking gap. No amount of cleverness distinguishes them from the data alone.

What to build instead

Model it as a disagreement engine, not a merger:

1. Represent SOURCES_DISAGREE as a first-class state. Not an error, not something to reconcile away — an output. Your schema should be able to say "pharmacy asserts X, hospital list is silent, unresolved."
2. Retain provenance per assertion. Every fact carries which source claimed it and when. You'll need this the moment anyone asks why a discrepancy was flagged.
3. Rank by consequence, not confidence. A missing anticoagulant and a missing vitamin D are not the same finding. Reviewer attention is the scarce resource; spend it by clinical weight.
4. Route to someone who can resolve it out-of-band. Some of these are only answerable by asking the patient. Design for that as the terminal step rather than pretending the system can close the loop itself.

Same shape as the four-state evaluation I wrote about last time — UNKNOWN deserves to be a value, not a default to NO.

The honest boundary

An agent cannot confirm a medication list. Confirmation requires a clinician or pharmacist talking to the patient. Also worth stating: pharmacy fill data shows dispensing, not adherence — a filled prescription means it was collected, not that it's being taken. And I'm not claiming this reduces adverse drug events; that needs outcome evidence I don't have. The narrow claim: a discrepancy never surfaced is never investigated.

We build this pattern at IntelliBooks Studio. Happy to get into the provenance schema or the disagreement-state modelling in the comments.