What a Query Is For

Part of Clinical Data Management and Integrity: Queries and Discrepancy Management.

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

Why this matters

A query is a question about a record. That sentence sounds obvious and almost every query problem comes from forgetting it.

A query is not an instruction to change a value. It is not a task for the site to clear. It is not a metric to drive toward zero. It is a question, and a question can legitimately be answered "the value is correct and here is why."

Where queries are managed as a backlog, sites learn that the fastest way to close one is to change the value. That behavior is created by the process, not by the site, and it converts a quality mechanism into a mechanism for making data agree with expectations.

What a query legitimately asks

Is this value correct? Raised where the value is implausible, inconsistent with another record, or outside an expected range.

Is this record complete? Raised where a required element is absent.

Which of these is right? Raised where two records of the same fact disagree.

What does this mean? Raised where an entry is ambiguous.

Each is a genuine question with more than one acceptable answer, and at least one acceptable answer involves no change to the data.

The three answers

The value was wrong, and here is the correct one. The data changes and the audit trail records the change with its reason.

The value is correct, and here is why. Nothing changes. The explanation is recorded and the record is now stronger than before, because an unusual value is documented as verified rather than merely present.

We cannot determine which is correct. The least comfortable and sometimes the honest one. The discrepancy is documented and escalated, and it is not resolved by choosing.

A process that accepts only the first answer is not asking questions.

The metric problem

Open query count is the most commonly tracked data management metric and one of the most damaging when managed as a target.

It measures the number of questions outstanding, which is influenced by the number of questions asked as much as by data quality. A study with poor data and few checks has a low query count. A study with excellent data and thorough checks may have a high one.

Driving the number down incentivizes three behaviors, all bad: asking fewer questions, accepting weaker answers, and pressing sites to change values rather than explain them.

Better measures: the proportion of queries producing a data change, which tells you whether the checks are finding anything. The age of queries on data that matters, which tells you whether the important questions are being answered. The number of unresolved discrepancies at lock, which is the thing that actually affects the analysis.

Which queries matter

Not all data affects the study's conclusions, and treating all queries as equal misallocates the scarcest resource in the study, which is site attention.

A workable ranking: data feeding the primary endpoint; safety data; data feeding secondary endpoints named in the analysis plan; eligibility and exposure data; everything else.

Being explicit about this is uncomfortable because it means saying some data does not matter much. The alternative is an implicit ranking by whichever queries are easiest, which is what happens by default.

In practice

A data manager finds 2,300 open queries eight weeks before lock.

Rather than escalating the total, she classifies. 40 touch the primary endpoint. 130 touch safety data. 310 touch named secondary endpoints. 1,820 touch fields no analysis reads.

She proposes closing the 1,820 administratively, documented as a decision with its rationale, and concentrating entirely on the 480 that matter.

The study team is uneasy, because closing queries without resolving them feels like lowering a standard. The data manager's argument is specific: chasing 1,820 queries will consume roughly six weeks of site time across 40 sites, during which the 480 that matter will compete for the same attention and some will be answered carelessly.

The decision is documented, with the criteria and the fields affected, which is what makes it a defensible judgment rather than an abandonment.

What this looks like when it goes wrong

A sponsor sets a target of fewer than 50 open queries per site before each monitoring visit.

Sites are measured against it. Coordinators are measured against it.

The target is met at nearly every site. The mechanism is that when a query is unclear or the answer requires looking something up, the fastest resolution is to change the value to whatever the query implies it should be.

The audit trail records hundreds of changes with the reason "per query." The values now agree with expectations, which is what the query process was measuring, and some of them no longer agree with the source.

Nothing was falsified in intent. A metric was set, people met it, and the only available way to meet it reliably was to make the data say what the system wanted.

Key takeaways