Written for the product-minded reader building on NHS or wider healthcare data (Head of Product persona) who feels the pain of dirty data operationally but may not yet connect it to integration design specifically. UK+US market: the mechanism is universal even though the NHS texture (SNOMED, Trust-local codes) is used for concreteness. Deliberately restrained on WeHub's claims; the piece earns trust by admitting what a validation layer can't promise as much as what it can.
One field, in one system, gets populated wrong. A date entered in the wrong format. A code selected from the wrong list because the dropdown wasn't scoped correctly. A free-text entry where a coded value belonged. On its own, that's a single bad record, forgettable.
Except it rarely stays a single bad record. It flows into a feed, the feed flows into three downstream systems, each of those systems derives its own reports and dashboards from it, and eighteen months later a data quality audit finds the same error sitting in eleven places, each one now treated as an independent source of truth. That's how dirty data actually behaves in a healthcare organisation: it doesn't stay contained, it propagates.
In brief
Dirty data spreads because integration, by design, copies and reshapes data across systems; every downstream consumer of a bad record inherits the error and often adds its own transformation on top of it, compounding rather than correcting the problem. It shows up in three recognisable shapes: structural (malformed or missing fields), semantic (values that don't mean what the receiving system assumes), and referential (records that no longer agree on who or what they describe). The only place to stop it economically is at the boundary, through validation before data enters the pipeline and terminology binding for anything coded, because catching it downstream means fixing it in every system it's already reached.
The record that became ten thousand records
Here's the mechanism, stripped to its essentials. A source system emits a record with a subtly wrong field: a date in the wrong format, a code from an unscoped list, a name entered with an encoding error. That record travels through an integration feed into a downstream system, which stores it, and possibly transforms it again on the way into its own reports. A dashboard is built on top of that downstream system. A second system consumes the same original feed and makes its own, slightly different, assumption about the bad field. Now the same underlying error exists in two systems, interpreted two different ways, feeding two different reports that quietly disagree with each other.
Repeat that across a live NHS estate with dozens of feeds and years of history, and the felt experience is exactly what most digital and product teams describe: a pervasive, low-grade distrust of data that nobody can quite pin down to a single cause, because by the time it's noticed, the cause has multiplied.
Why integration is a multiplier, not a filter
The uncomfortable truth is that most integration layers are built to move data faithfully, not to judge it. A pipeline that reshapes and routes a record is, by default, agnostic to whether the record was any good in the first place; its job is fidelity, not quality control. Unless a validation step is deliberately inserted, the integration layer will carry a bad record exactly as far and as fast as it carries a good one, and typically faster, since bad records rarely trigger the kind of manual review a human might otherwise apply.
This is the honest reframe: dirty data isn't primarily a data entry problem, though poor entry is where most of it originates. It's an integration design problem, because integration is the mechanism that decides whether a single bad record stays local or becomes systemic.
The three shapes dirty data takes
Structural dirt is the most visible: a missing mandatory field, a malformed date, a value in the wrong format for its type. It's the easiest to catch, because it's checkable mechanically, and the fact that it still slips through most integrations says more about missing validation than about the difficulty of detecting it.
Semantic dirt is quieter and more dangerous: a field that's structurally perfect but means the wrong thing, because it was coded against an ungoverned list, drawn from the wrong value set, or left as free text where a governed code belonged. This is the shape that turns into a clinical safety issue rather than a reporting inconvenience, because a structurally valid but semantically wrong diagnosis code looks exactly as trustworthy as a correct one until someone checks.
Referential dirt is the subtlest: records that no longer agree about which patient, encounter or provider they describe, usually the aftermath of an imperfect merge, a duplicate registration, or an identifier that drifted between systems. It's the hardest to catch mechanically, because each individual record can look perfectly clean; the problem only appears when two records are compared and found to disagree about a shared identity.
Where it actually needs stopping
The economics are stark and worth stating plainly. Catching a bad record at the boundary, before it enters the pipeline, costs one fix. Catching it after it's reached three downstream systems costs at least three fixes, plus the harder problem of reconciling whatever each system has already derived from it, plus the trust cost of everyone who saw the wrong number before it was corrected.
That's the case for validation as a gate rather than a downstream cleanup exercise: every record checked against a schema for structural correctness, and every coded field checked against a governed value set for semantic correctness, before anything downstream ever sees it. Referential issues need a second, complementary habit: reconciliation checks that compare records across systems periodically, looking specifically for the disagreements that only surface in comparison, since no single-record validation gate will catch them.
What "clean" realistically means
It's worth being honest about what a validation and terminology layer can and can't promise. It can catch structural and semantic problems at the point of entry, reliably and mechanically, which prevents a huge share of dirty data from ever propagating. It can bind coded fields to governed terminology, which is what WeHub Term and the validation built into WeHub Studio workflows are designed to do. What it can't do is guarantee that data entered upstream, in the source system itself, was clinically correct in the first place; a validation gate confirms a value is well-formed and drawn from the right list, not that a clinician chose the right diagnosis. Clean, in this sense, means the integration layer stopped adding to the problem and started catching what it reasonably can, not that every upstream data entry decision was perfect.
The bottom line
Dirty data spreads because integration is designed to move data faithfully, and faithfully includes faithfully wrong. The fix isn't a one-off cleanup project; it's a permanent habit of validating structure and binding meaning at the boundary, before a bad record gets the chance to become ten. Pick one high-traffic feed this month and ask two questions: does anything check its structure before downstream systems see it, and does anything check its codes against a governed value set? If either answer is no, that feed is quietly multiplying its own errors right now.
