Query Management in Clinical Data Management: A Closure-Clock Playbook for One-Round Resolution

At a glance

• A query is a closure clock, not a glossary entry. Write it so the site can answer it once, and every re-query is wasted timeline.
• Route by what the discrepancy actually is: deterministic, rule-checkable gaps belong to edit-check (system-generated) queries; judgment calls and cross-source inconsistencies belong to manual queries.
• Rising query rate and stalling open-query aging are quality signals. ICH E6(R3) frames trial-level quality tolerance limits as part of a risk-based quality system, and a spike often points at the protocol, CRF, or site training, not the site’s diligence.
• Every query action edits a record, so it must be traceable. ICH E6(R3) §4.2.4 requires corrections to be attributed, justified, and supported by source records; MHRA and FDA both require an audit trail capturing who, what, when, and why.
• “ALCOA+” (attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring, available) is the standard your query-driven edits must survive in an inspection.
• This guide gives you a discrepancy-to-query decision table, before/after query rewrites, aging buckets to track, and a copy-ready “good query” checklist.

Query management, reframed: the closure clock, not the dictionary

Most query guides hand you two definitions (manual versus system-generated) and a four-box lifecycle, then stop. That is the part of query management that does not actually cost you anything. What costs you is the re-query loop: a vague query goes to the site, the coordinator answers the wrong thing, the data manager re-opens it, and three weeks evaporate against a database-lock date.

So reframe the whole discipline around one number: how long a query stays open. Every query you raise starts a clock. The craft is writing the query so the site stops the clock in one round, and the metric that matters is how many of your queries close on the first answer. Treat query management as a closure-clock workflow and the definitions sort themselves out.

This matters beyond timelines. Under a risk-based quality system, query data is evidence. ICH E6(R3) §3.16.4 lists query resolutions among the records that document data finalisation for analysis, so your queries are part of the trial’s defensible record, not disposable email traffic.

Manual vs. system-generated queries: a decision rule, not two definitions

The useful question is not “what is a manual query versus an edit check.” It is “given THIS discrepancy, which mechanism should catch it, and who owns the answer.” Route by the nature of the discrepancy.

Discrepancy type	Query type	Owner of the answer
Missing required field; value out of protocol range; date format error; visit-window violation; arithmetic inconsistency	System-generated (edit check / programmed)	Site (CRC) corrects at entry or on auto-fire
Two fields contradict each other on the same form (e.g., “ongoing” AE with a stop date)	System-generated cross-field check where deterministic; manual where it needs judgment	CRC, escalated to data manager if ambiguous
Source-to-EDC inconsistency found during review or SDV	Manual	CRA/data manager raises; site/PI confirms against source
Clinical plausibility (lab value implausible for the participant; AE term that does not match the narrative)	Manual	Data manager or medical monitor; site/PI adjudicates
Coding or reconciliation mismatch (AE/conmed dictionary, SAE vs. safety database)	Manual	Data manager

The rule of thumb: if a computer can decide whether the data is wrong from rules alone, make it an edit check and let it fire at the point of entry; if deciding requires a human to weigh source records or clinical context, it is a manual query. Edit checks are cheap, instant, and reduce the manual backlog, but they only catch what you anticipated. Manual queries catch the judgment cases, and they are where the writing craft pays off.

One distinction worth keeping crisp: a discrepancy is a data problem you resolve with a query; a protocol deviation is a conduct problem you document and report. A query may surface a deviation, but closing the query never erases the deviation. ICH E6(R3) treats records of noncompliance, including protocol deviations, as essential records in their own right. (See the sibling topics on protocol deviations and on source data verification and risk-based monitoring for where those workflows diverge from query handling.)

How to write a query the site answers once

The single biggest lever on your closure clock is the query text. A good query is specific, self-contained, and answerable without a phone call. Here are the anti-patterns and their fixes.

Before: “Please clarify the AE.” After: “AE term ‘headache’ (Form AE, line 3) has onset date 12-MAR-2026 but the visit date is 05-MAR-2026, so onset precedes the visit. Please confirm the correct onset date against source, or correct the entry.”

Before: “Lab value looks high.” After: “ALT = 980 U/L at Visit 4 (Form LB, sample 02-FEB-2026) exceeds the reportable range and the prior value was 32 U/L. Please verify the result against the source lab report; if correct, confirm whether an AE was assessed.”

Before: “Date discrepancy, please review.” After: “Informed consent date (10-JAN-2026) is after the screening visit date (08-JAN-2026) on Form DM. Per protocol, consent must precede any study procedure. Please confirm dates against source and correct the erroneous field.”

The pattern in every fix: name the exact form and field, state the observed value and why it is being questioned, point to the source the site should check, and give a closed set of actions (“confirm” or “correct”). Anti-patterns that trigger re-queries are the open-ended “please review,” the missing field reference, asking two questions in one query, and embedding the answer you expect (which biases the site and produces a non-defensible edit).

Writing the query well is also a data-integrity act. The site’s answer and any resulting correction must stand on their own. MHRA’s guidance is explicit that a data correction or clarification procedure should provide visibility of the original record and traceability of the correction using ALCOA principles, so a query that pushes the site toward a “tidier” value rather than the true one is a defect, not a convenience.

Copy-ready “good query” checklist

• Names the exact form, field, line, and visit.
• States the observed value and the specific reason it is questioned.
• Points to the source record the site should check.
• Asks exactly one question.
• Offers a closed action: confirm, or correct to the source value.
• Does not pre-suggest the “right” answer.
• Is intelligible to someone who was not in the room when it was raised.
• Leaves a clean audit trail: attributable, time-stamped, with a reason captured on resolution.

The query life cycle and where it stalls

The lifecycle is open → answered → verified → closed (with re-query as the failure branch).

• Open: query is raised against a data point, clock starts.
• Answered: site responds, either correcting the data or explaining it.
• Verified: data manager or CRA confirms the answer resolves the discrepancy.
• Closed: no further action; the resolution is recorded.

Stalls cluster at two joints. The first is open-to-answered, where the query sat too long at the site, usually because it was unclear or low-priority. The second is answered-to-verified, the re-query branch, where the site answered but did not actually resolve the discrepancy, so it bounces. A high re-query rate is almost always a query-writing problem on your side, not a slow-site problem on theirs.

Track aging in buckets so the joint that is stalling is visible: 0–7 days, 8–14, 15–30, and 30+ days open. The 30+ bucket is your inspection-risk and lock-risk population and deserves named ownership and escalation, not a status-meeting mention.

Query rate and aging as an RBQM signal

Here is the reframe that the ranking pages miss: query rate and aging are not just operational housekeeping, they are quality signals you are expected to act on.

ICH E6(R3) builds quality into the trial by design and asks sponsors to identify the factors critical to quality and to set quality tolerance limits at the trial level to support the control of risks to those factors. The guideline frames quality control as a risk-based activity applied to each stage of data handling to ensure data are reliable and processed correctly. Query metrics are one of your most direct readouts of whether that data handling is under control.

So read the metrics as signals, not scores:

• Query rate per CRF page or per participant, trended over time and compared across sites.
• First-pass resolution rate (share closing on the first answer): your query-writing quality.
• Open-query aging distribution across the buckets above.
• Time-to-resolution, segmented by manual versus system-generated.

When a query rate spikes, resist blaming the site first. A cluster of identical queries across many sites is rarely a discipline problem; it is usually an upstream defect: an ambiguous CRF field, an over-tight or wrong edit check, a confusing protocol instruction, or a training gap. A spike concentrated at one site points the other way. Either way, ICH E6(R3) expects monitoring to be a planned, risk-based activity whose extent and nature are adjusted based on experience during the trial, so a query-rate signal should feed back into where and how you monitor, not just into more queries.

Audit trail, ALCOA+, and the defensible edit

Every query that results in a data change is an edit to a regulated record, and the edit has to be defensible long after everyone has forgotten the trial. This is where the data-integrity regulations bind tightly.

ICH E6(R3) §4.2.4 requires that corrections to data be attributed to the person or computerised system making the correction, justified, supported by source records around the time of original entry, and performed in a timely manner. That is the full specification of a defensible query resolution: who, why, against what source, and when. The same guideline (§2.12.2) requires that changes to source records be traceable, not obscure the original entry, and be explained via an audit trail.

MHRA’s GxP data-integrity guidance defines the audit trail as metadata that secures the life-cycle details of a record (creation, additions, deletions, alterations) without obscuring the original, and that reconstructs the “who, what, when and why” of each action. It also sets the bar your query edits are judged against: the ALCOA principles, attributable, legible, contemporaneous, original, and accurate, plus complete, consistent, enduring, and available.

FDA’s 2024 electronic-systems guidance is aligned and, for US-regulated work, more operationally specific: audit trails must capture all changes to the electronic record, the individuals making the changes, and the date and time, and should include the reason for the change. FDA also warns that audit trails should be protected from modification and from being disabled, and that all audit-trail documentation on creation, modification, and deletion must be available for inspection.

There is no conflict among the three here; they reinforce each other. ICH E6(R3) states the correction obligation, MHRA names the ALCOA+ quality attributes, and FDA specifies the mandatory audit-trail components and their inspection availability. The practical takeaway is one habit: never resolve a query by silently overwriting a value. Capture the reason, preserve the original, and let the site’s correction trace back to its source.

Tooling: what EDC query features to use, and their compliance boundary

Your EDC earns its keep on the mechanical parts: programmed edit checks that fire at entry, query queues with owner assignment and aging timers, status workflow that enforces the open-answered-verified-closed states, and a computer-generated, time-stamped audit trail on every field. Use all of it. ICH E6(R3) expects computerised systems used in trials to address audit trails, user management, and validation, and FDA expects entities to produce audit-trail and validation documentation on inspection.

But be precise about the compliance boundary. The software enables compliance; it does not deliver it, and it does not transfer responsibility. No EDC feature makes a trial compliant on its own. The sponsor remains responsible for setting the right edit checks, for the quality of manual queries, for reviewing the audit trail on a risk basis, and for the integrity of the resulting data. A configured query module is a tool for meeting the requirements above, not a certificate that you have met them.

Where teams get it wrong

• Treating query count as the goal. Zero queries can mean a clean database or a broken edit-check suite. First-pass resolution rate tells you more than raw volume.
• Over-programming edit checks until sites are buried in noise and stop reading queries carefully, which raises the re-query rate.
• Writing queries that pre-suggest the answer, producing edits that look tidy and fail an audit because the original observation was nudged, not corrected.
• Letting the 30+ day aging bucket grow quietly until database lock, then triaging under pressure, which is exactly when defensible-edit discipline slips.
• Confusing a discrepancy with a deviation, and assuming that closing the query also closes the conduct issue.
• Treating the EDC’s audit trail as automatic insurance rather than something the sponsor must actually review on a risk basis.

Sources

• ICH E6(R3) Good Clinical Practice, version r3, ICH — https://www.ich.org/page/efficacy-guidelines
• FDA Guidance: Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations Questions and Answers, version 2024, FDA
• MHRA GxP Data Integrity Guidance and Definitions, version 2018 (Revision 1), MHRA