Writing a Query a Site Can Actually Answer

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

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

Why this matters

The single largest determinant of whether a query gets a useful answer is how it is written, and most queries are written by a system from a template that was drafted without anyone imagining the person who would read it.

A coordinator opening their query list sees dozens of items. The ones phrased as answerable questions get answered. The ones phrased as complaints get a value change or a shrug.

What a good query contains

The specific value in question, quoted, with enough identification that the coordinator can find it without searching. The visit, the form, the field, the value as recorded.

Why it is being asked. Not the rule that fired, which is internal, but the substantive concern. "Systolic 190 is outside the expected range for this population" tells the coordinator what to look for. "Edit check DM0147 failed" does not.

What would resolve it, stated as options rather than as an instruction. "Please confirm the value against source, or correct it if a transcription error, or confirm it is correct as recorded."

What it is for, where the field matters. A coordinator who knows a value feeds the primary endpoint will treat it differently, and rightly.

What a bad query contains

A rule identifier as the explanation. Meaningless outside the system that generated it.

An implied answer. "Please correct the systolic blood pressure" has told the coordinator what the answer should be, and some will supply it. The neutral form asks them to verify.

A demand for information the site does not have. A query asking a site to explain a discrepancy with a central laboratory result the site has never seen cannot be answered by the site, and it should have gone to the laboratory.

Several questions in one. A query raising four issues gets one answer addressing the easiest.

No context at all. "Please clarify" is the least useful string in data management.

Tone, and why it is a data quality matter

Queries are read as communication from the sponsor, and a study raises thousands of them over its life. The cumulative tone shapes how the site regards the sponsor's requests, including the ones that matter urgently.

A query implying the site has made an error, when the value may well be correct, spends goodwill every time it is wrong. A query written neutrally as a question spends none and gets a better answer.

This is not a matter of politeness for its own sake. The site's willingness to look something up carefully, at the twentieth query of the afternoon, is a real resource and it is depletable.

Re-queries

When a query is answered and the answer does not resolve the question, the re-query must say what was insufficient about the previous answer.

Re-sending the same text is the most common failure and it is read, correctly, as the sponsor not having read the answer. A re-query should acknowledge the answer given and state precisely what is still open.

In practice

A data manager reviews the ten most frequently generated query texts, which together account for most of the study's query volume.

One reads: "Value out of range. Please verify or correct."

She rewrites it: "Recorded systolic blood pressure is [value] mmHg at [visit]. This is outside the range expected for this study population. Please check against the source record and either confirm the value is correct as recorded, or correct it if it differs from source. If correct, a brief note on the clinical context is helpful. This measurement contributes to the safety analysis."

Longer, and it names the value, the visit, the concern, both acceptable outcomes, and why it matters.

Across the study, the proportion of these queries answered with an explanation rather than a value change rises substantially, which is the right direction: the value usually was correct, and the earlier phrasing was producing changes to correct values.

What this looks like when it goes wrong

A query reads "Please clarify the adverse event onset date."

The coordinator does not know what is unclear. The date is present, plausible, and formatted correctly. She assumes the issue is that it precedes the visit date, and changes it to the visit date.

The original date was correct. The actual concern was that the onset preceded the reported start of the medication suspected of causing it, which is a real and interesting question the query never asked.

The change destroyed the information the question existed to explore. The audit trail shows a change with the reason "per query," and the reviewer who eventually asks about that event finds a date that agrees with everything and tells them nothing.

One vague query, one reasonable inference, one unrecoverable fact.

Key takeaways