Good Queries vs Weak Queries: A Practical Guide for Clinical Data Managers

Introduction

Query writing is not just communication. It is a data quality control.

In clinical data management, a query is the primary tool for resolving data issues at the source. The quality of the query - how clearly it identifies the issue, provides context, and requests action - directly determines how quickly and accurately the site responds, how many back-and-forth cycles are needed, and how clean the final data will be at database lock.

A weak query wastes time for sites, CDMs, and monitors. A strong query resolves the issue the first time.

Why Query Quality Matters

Poor query wording slows data cleaning and increases rework. Six reasons query quality is a CDM priority:

1. Site Burden - Unclear queries confuse sites and lead to more back-and-forth, eroding site relationships and slowing overall study progress.
2. Query Turnaround Time - Vague queries require clarification before the site can respond, doubling the query cycle time.
3. Data Cleaning Efficiency - Good queries reduce rework and re-query rates, improving cleaning productivity approaching lock.
4. Data Review Clarity - Well-written queries with the relevant field, value, and expected record create clean audit trails that CDMs, monitors, and data reviewers can follow.
5. Audit Trail Quality - Under ICH GCP E6(R2) Section 5.5, all data changes in an EDC must be traceable - including queries and resolutions. A query that does not clearly identify the issue creates an audit trail gap that regulatory inspectors will find.
6. Database Lock Readiness - Accurate, resolved data from well-managed queries accelerates review and helps achieve lock with confidence.

A strong query reduces confusion, shortens turnaround time, and improves data quality.

Weak vs Strong Query Principles

A good query helps the site review the issue and take the correct action.

Weak Query	Strong Query
Vague	Specific - names the exact field, value, and issue
Subjective	Objective - based on data and review rules
Incomplete context	Actionable - states clearly what the site should do
Creates guesswork	Non-leading - does not suggest the answer
No clear action	Protocol-aligned - references the rule or expected value

Strong queries are easier to understand, easier to answer, and easier to audit.

Three Practical Examples

Example 1: Date Inconsistency

Scenario: Visit 3 date (05-JUN-2024) is earlier than Visit 2 date (10-JUN-2024) - a chronological impossibility.

Weak query: "Please check the date." - The site does not know which date, which visit, or what is wrong.

Strong query: "The Visit 3 date (05-JUN-2024) is earlier than the Visit 2 date (10-JUN-2024). Please review and confirm if the value is correct, or provide clarification." - Specific, objective, actionable.

Example 2: Out-of-Range Value

Scenario: Systolic blood pressure recorded as 220 mmHg, outside the programmed review range (>180).

Weak query: "Value looks high." - Subjective and unclear; the site does not know which field, what the range is, or what action is needed.

Strong query: "The reported systolic blood pressure is 220 mmHg, which is outside the programmed review range (Systolic >180 mmHg). Please confirm if the value is correct or update as applicable." - Objective, rule-based, non-leading.

A leading query that implies the expected answer is a data integrity risk. If the site changes a correct value because the query implied it was wrong, the audit trail now reflects an incorrect correction. Non-leading query wording is a data integrity protection, not a style preference.

Example 3: Missing Assessment

Scenario: Day 15 ECG assessment is missing from the EDC.

Weak query: "Missing data." - No context, no field name, no visit, no clear action.

Strong query: "The required Day 15 ECG assessment is missing. Please enter the assessment or document the reason it was not performed." - Specific visit and assessment named; two clear response options given.

What Makes a Good Query? Eight Characteristics

A good query identifies the issue, provides context, and requests a clear action.

1. Specific - Names the exact field, visit, and value
2. Objective - Based on data and review rules, not personal interpretation
3. Actionable - States clearly what the site should do in response
4. Non-leading - Does not suggest or imply the expected answer
5. Protocol-aligned - References the protocol visit window, schedule, or requirement
6. Based on review rules - Grounded in edit check logic or the Data Validation Plan
7. Easy to respond to - Site can answer without needing clarification
8. Audit-trail friendly - Query and response together form a complete, traceable record

Common Query Writing Mistakes

1. Too vague - "Please clarify." The site does not know what to review or what is wrong.
2. Too leading - Suggests the answer; a data integrity risk if the site corrects a value that was actually correct.
3. Too little context - Missing the visit, field name, value, or expected record. The site cannot respond accurately.
4. Too much wording - Multi-sentence queries with multiple issues buried in the text are harder to read and respond to. One query per issue.
5. No clear action - "Please review." Review and do what? Confirm? Correct? Document a reason? Response expectations must be explicit.

Poor queries create rework. Strong queries create clarity.

A Five-Step Query Writing Framework

A repeatable structure for writing stronger queries - consistently and efficiently:

1. Identify the Issue - What is inconsistent, out of range, missing, or unclear? Be specific about the field and data point.
2. Give Context - Include the visit, field, value, and expected record or reference. What should the data show?
3. Request Action - Ask to review, correct, or clarify. Be explicit about what you need the site to do.
4. Stay Non-leading - Do not suggest the answer. The site is the source of truth for the clinical record.
5. Support the Audit Trail - Make the issue and expected resolution clear so the query-response pair forms a complete, defensible record.

Full strong query example: "The AE Onset Date (05-MAY-2024) is after the Visit Date (03-MAY-2024). Please confirm the correct date."

A simple framework improves consistency across the study team.

CDM Standards for Query Quality

1. Consistent application of the framework - Every CDM team member should use the same structure. Inconsistent query quality creates inconsistent site responses and inconsistent audit trail documentation.
2. Query review before issuing - For complex or sensitive queries (eligibility, safety, consent), review the wording before sending. A poorly worded query about a serious adverse event is both a data quality risk and a site relationship risk.
3. Re-query rate as a quality metric - Re-query rate is one of the most actionable CDM metrics for assessing query quality. A high re-query rate on a specific form, site, or CDM signals that query wording, site training, or eCRF design needs attention. When re-querying, always include the original context and the additional clarification - not just re-issue the same query.

Final Takeaway

1. Less confusion - Clear queries reduce ambiguity and misinterpretation at the site
2. Less rework - Accurate, specific queries minimise re-queries and corrections
3. Faster resolution - Complete and clear queries get resolved quicker
4. Better database lock readiness - High-quality data from well-managed queries accelerates review and lock

Query writing is not just communication. It is a data quality control.

This content is AI-assisted and expert-reviewed. All query writing principles are aligned with ICH GCP E6(R2), CDISC data standards, and clinical data management best practices. Content is intended for clinical research professionals for educational and professional development purposes.