Your worst data quality problem is the one that never throws an error

I work on data infrastructure for public transportation rather than healthcare, so I want to be upfront that the examples below come from transit. The failure mode doesn't, and every informatics person I've described it to has recognized it immediately.

Here it's. The data quality problems that hurt most are not the ones that break something. They are the ones that produce output which is well-formed, plausible, on time, and wrong.

The audit that reframed it for me

I spent part of this year assessing the quality of published data feeds across a large metropolitan region. Dozens of organizations, all publishing to the same standard, all with the same obligation.

The result I didn't expect: the gaps didn't correlate with resources. Several of the largest and best-funded organizations had feeds that were missing, stale, or malformed. They had budget. They had staff. They had the systems.

What they did not have was anybody whose job was to check. Publishing sat with one team. Validation sat with nobody. Every one of those feeds passed schema validation, arrived on schedule, and contained information that had stopped being true.

Why this class of failure survives

Because every mechanism your organization has for noticing problems is triggered by something breaking.

A pipeline that fails pages someone. A malformed record throws an exception. A schema violation gets rejected. All of that infrastructure exists and works.

A field that has quietly contained a stale value for eight months does none of those things. It validates. It parses. It populates the dashboard, feeds the model, and answers the query. Everything downstream behaves exactly as it would if the value were correct, which is the entire problem.

And the people positioned to notice are usually outside the organization. In my case, the riders and the app developers consuming the feed. In a clinical setting, the people downstream of a measure that has drifted. Neither group typically has a channel to report it that anyone is obligated to act on, so they route around it and the organization learns nothing.

Three checks that find what validation doesn't

None of these are novel. They're just rarely anyone's assigned job.

Freshness against expectation, not against schema. Not "does this field have a value" but "when did this value last change, and is that plausible?" A field that should vary weekly and has been constant for a quarter is the single highest-yield signal I know. It's trivial to compute, it requires no domain knowledge, and it catches upstream feeds that silently stopped updating while continuing to serve their last good value.

Distribution drift on the values themselves. Not just nulls and ranges, but the shape. If a categorical field's mix shifts sharply between periods and nothing about the world changed, something upstream changed and nobody told you. This catches vocabulary changes, integration updates, and the moment a source system quietly started defaulting a field.

Reconciliation against an independent source. The most expensive check and the only one that catches consistent, systematic error. If your only source for a fact is the system that produces it, you can't detect a bias in that system, you can only detect inconsistency. Where a second source exists, even a partial or lower-quality one, comparing them periodically is worth more than any amount of internal validation.

The organizational half, which matters more

You can implement all three and still fail, because the underlying problem isn't technical.

Somebody has to own the output rather than the system. Owning a system means keeping it running. Owning an output means being accountable for whether it is correct. Those are different responsibilities, and in most organizations the second one does not exist as a named role. If nobody's name is next to "this dataset is right," it's not, you simply haven't found out yet.

The second requirement is a channel for downstream consumers to report a problem, and an obligation to respond. In the transit case, the people who knew the feeds were broken had known for a long time. There was nowhere to say it that produced action. That isn't a data problem in any technical sense and it was the largest single cause of the gaps.

What I would do first

Take your most-used dataset. For each field, answer two questions: when did this last change, and who would notice if it were wrong?

The fields where the answer to the first is "longer ago than it should be" are your active problems. The fields where the answer to the second is "nobody" are your future ones.

That exercise takes an afternoon and in my experience it's more informative than a quarter of data quality tooling, because the tooling is measuring conformance and the exercise is measuring truth. Those diverge, and the gap between them is where the damage lives.