What Data Management Actually Owns

Part of Clinical Data Management and Integrity: What Data Management Owns.

About 5 minutes. Free, in your language, no account needed.

Why this matters

A clinical trial exists to answer a question, and the answer is computed from data. Everything else in the trial is machinery for producing that data honestly.

Data management is the function that owns whether the data can carry that weight. Not whether it exists, and not whether it is tidy. Whether a regulator, a statistician and a reader of the published result can rely on it.

The role is frequently described as cleaning data, which understates it in a way that matters. A clean database can be wrong. A database with a thousand open queries can be entirely trustworthy. Cleanliness is a property of the file; reliability is a property of the relationship between the file and what actually happened to participants.

The three things you own

One: that the data reflects what happened. Every value in the database traces to something that occurred to a real participant and is evidenced somewhere. This is the whole of it, and everything below serves it.

Two: that the instrument collects what the question needs. The case report form is an instrument, and a badly designed one produces data that is complete, consistent and useless. Most of the damage here is done before the first participant is enrolled, which is why data management belongs in protocol design rather than after it.

Three: that the record of change is intact. Who changed what, when, and why. A database with no audit trail cannot be relied upon regardless of how correct its current values are, because nothing distinguishes a correction from an alteration.

What you do not own

You do not decide clinical facts. If a laboratory value and a clinician's note disagree, data management surfaces the disagreement. It does not resolve it by choosing. Resolving a discrepancy by picking a value is the characteristic data integrity failure, and it is usually done with good intentions by someone trying to be helpful.

You do not own the statistical analysis. The statistician defines what the analysis requires. Data management makes sure the data supports it and says clearly when it does not.

You do not own the source. The site does. Data management can ask what the source says; it can never tell the site what the source should say.

Where the function sits

Data management is unusual in a trial because it touches everybody and directs nobody.

It depends on the site to enter and correct data. It depends on vendors for laboratory, imaging and electronic outcome data. It depends on monitoring to verify against source. It depends on safety for adverse event data. It depends on statistics to define the requirement. And it has authority over none of them.

That shape means the function's effectiveness rests almost entirely on the clarity of what it asks for. A query a site cannot answer does not get answered. A specification a vendor cannot implement does not get implemented. Precision is not a stylistic preference here; it is the only lever the role actually has.

In practice

A study is three months from database lock with 1,400 open queries, and the team is anxious.

The data manager sorts them rather than counting them. Eleven concern the primary endpoint. Sixty concern safety data. Around 900 concern date formats and administrative fields that no analysis reads. The remainder concern secondary endpoints of varying importance.

She reports three numbers instead of one: eleven queries that could change the study's answer, sixty that could change its safety conclusions, and roughly 1,300 that could not change anything.

The study team was preparing to put four people on query resolution for eight weeks. The real work is eleven queries requiring careful clinical follow-up, sixty requiring safety review, and a decision about whether the remaining 1,300 justify the site burden of chasing them at all.

Note what made the difference: not effort, but knowing which data the answer depends on. That is the judgment the role exists to supply.

What this looks like when it goes wrong

A database locks with no open queries. Every field is populated, every edit check passes, and the data is clean by every measure the system reports.

The primary endpoint is assessed at week twelve. The case report form collected the assessment date but not the time, and the protocol requires the assessment within a window measured in hours for a subset of participants.

The data is clean. It is also incapable of answering whether those assessments were in window, because the field that would have shown it was never collected. No query could have found this, because a query finds a value that is wrong, and this is a value that does not exist.

The failure happened during instrument design, eighteen months before lock, and everything after it was diligent work on the wrong problem.

Key takeaways