The quiet work of data cleaning in decentralised trials

Data cleaning does not make headlines. It does not show up on dashboards. But it is where the quality of a trial is often defined.

In decentralised studies with inputs from apps, wearables, remote visits, and cloud-based forms, the job of reviewing, validating, and reconciling data becomes more complex. And more important. There's a reason a meaningful part of the methodological literature on trial data quality is now devoted to building statistical tools that can flag problems automatically, rather than relying purely on manual review: the volume and variety of inputs in a modern decentralised study has outgrown what a small team can eyeball line by line.

Where the mess comes from

Even well-designed study platforms generate noise. Common issues include:

• Participants skipping entries or back-filling them days later
• Sites duplicating visit dates across systems
• Timestamp mismatches caused by time zone differences
• Contradictory data between self-report and device capture for the same metric

This is not error in the traditional sense. It is signal mixed with context. Cleaning is how you separate the two and make the dataset usable.

What data managers actually do

Modern data managers are not just chasing blanks and missing values. The work involves:

• Reviewing outliers for plausibility in context, not just against a range check
• Flagging protocol deviations that were missed during real-time monitoring
• Clarifying free-text fields where responses are ambiguous or inconsistent
• Mapping interim database versions to ensure consistency across time points

Their decisions shape the final dataset. They affect both statistical validity and what regulators will accept. Some of this work has been formalised into repeatable statistical checks. Research applying central statistical monitoring methods to real trial data built programs that could check for digit preference, values suspiciously close to the group mean, unusual correlation structures between variables, and adverse event reporting rates that looked too low for a given site. Applied to a trial with deliberately fabricated data added for testing, the programs caught it. Applied to genuine trials, they found the number of real data errors to be reassuringly low, which is itself a useful signal that the underlying collection process was sound.

What good cleaning looks like

1. Pre-defined logic. Cleaning should start with rules established before data collection begins. What counts as an outlier? When should a value be re-coded? Which fields require manual review? Deciding this after the fact introduces bias.
2. Layered review. Not all data gets equal attention. Critical endpoints receive full review. Supporting fields may be checked through automated scripts or sampled review. The key is knowing which is which.
3. Documented decisions. Every correction or clarification should be tracked with a reason. Not just what changed, but why. This is what regulators and auditors will scrutinise.
4. Cross-functional input. A CRA may spot a pattern before the data team does. A principal investigator's note may resolve an apparent discrepancy. Collaboration between roles often catches what any single review misses.

Automation helps, but does not replace judgement

Automated query systems, range checks, and statistical monitoring programs are valuable, and increasingly sophisticated. But the researchers behind the central statistical monitoring methods above were candid about where the approach still falls short:

Detecting data errors is relatively straightforward; however, there are several limitations in the detection of fraud: some programs cannot be applied to small trials or to centres with few patients, and data falsified in a manner which does not fit the program's assumptions may not be detected. Kirkwood, Cox & Hackshaw, central statistical monitoring methods paper

That's the honest boundary of what statistical tooling can do on its own. It's very good at surfacing patterns that fit a known shape of problem. It's much weaker against anything that doesn't fit the assumptions baked into the check, or against a site too small to generate a meaningful statistical signal in the first place. Beyond that, there are things automation was never going to catch regardless of sophistication:

• Events that are plausible individually but implausible in sequence
• Coded values applied inconsistently across sites
• Data that passes all validation rules but does not tell a coherent story

A human still has to look at the whole picture, and every flagged output from an automated system still needs, in the words of that same research, a visual and human assessment before anyone acts on it. Tools support that judgement. They do not replace it.

The goal is not a perfect dataset. It is a reliable one: data that reflects what actually happened, cleaned in a way that is documented, defensible, and honest about its limitations. That care usually happens quietly. But it is the backbone of every strong study, and the growing sophistication of the statistical tools available to support it doesn't change who is ultimately accountable for the call.