Writing Effective Queries

Why this matters

Queries are the main way data management (DM) asks sites to clarify, correct, or justify data in the Electronic Data Capture (EDC) system. If a query is ambiguous, leading, or bundles multiple issues, it slows closure, creates back‑and‑forth, and increases audit risk. Clear, neutral, single‑issue queries close faster, protect blinding, and leave an audit trail that any reviewer can understand.

Core concepts & definitions

Plain‑language glossary (minimize abbreviations):

• EDC (Electronic Data Capture) — The system where study data are entered and managed.
• CRF (Case Report Form) — The forms/pages in the EDC used to capture subject data.
• Source data — Original records at the site (e.g., medical charts, device readouts).
• Discrepancy — A missing value, or a mismatch between entered data and protocol, ranges, logic, or source—a flag to clarify, not proof of an error.
• Query — A formal question sent in the EDC to resolve a specific discrepancy.
• Single‑issue query — Addresses exactly one problem so the resolution is unambiguous.
• Neutral language — Describes what you observe without suggesting the “correct” value (suggesting one is called a leading query, or coaching).
• Reproducibility — Another reviewer can locate the same record and re‑create the discrepancy using your description alone.
• Rule/listing — Automated edit checks (“rules”) or data listings used to detect issues.
• Escalation — A controlled, documented route, set in the data management plan (DMP), to bring in the monitor (clinical research associate, CRA), the site’s principal investigator (PI) or the medical monitor when normal queries do not resolve the issue or when safety/blinding is at risk.

Three quick tests before you send:

1. Single‑issue test: Does this query ask about exactly one issue (one discrepancy, even when it involves two fields)?
2. Neutrality test: Would a neutral reader say I’m not coaching toward a specific value?
3. Reproducibility test: Could someone else find the same record and see the same issue?

The process, step‑by‑step

A. Before you draft

1. Confirm the locator — Subject ID, visit, CRF page/field, and timestamp if relevant.
2. Check for duplicates — Is there an open query on this exact issue already?
3. Consider blinding — Avoid revealing treatment assignment or patterns that could unblind.
4. Validate the trigger — Rule name/ID, listing name, or protocol reference you used.
5. Assess materiality — Safety‑critical, primary endpoint, or trend? This affects urgency and routing.

B. Draft with a standard structure (“what/where/why/ask”)

• What & where: The exact record location (subject/visit/CRF/field).
• Why it’s a discrepancy: Observed vs expected; cite rule/listing or protocol section when applicable.
• Ask (action or evidence): Ask the site to check source and either correct the entry or confirm it as entered—without assuming which applies. Source evidence means a reference (document name/date) in the query response, never a copy with direct identifiers.
• Next step: State the expectation or escalation path if unresolved within the SLA (service level agreement: the response‑time target in the DMP).

Reusable template

Subject <ID>, <Visit/Date>, <CRF.Field>:
Observed <value/condition> differs from expected (<brief reason>, e.g., rule <RULE_ID> / protocol <section>).
Please check against source and correct in the EDC, or confirm as entered and cite the source document (name/date) in your response.
If unresolved by <SLA>, we will escalate per study governance.

C. Tone and clarity

• Prefer plain language: “entered value exceeds physiologic range” over “value is invalid.”
• Avoid coaching: never propose the exact “correct” value or unit.
• Keep it concise; avoid bundling multiple findings.

D. When to escalate (stop re‑querying)

A re‑query is a follow‑up on the same query when the response does not resolve it; say what is still unclear rather than repeat the question. Trigger escalation if any of the following apply:

• Two clear re‑queries with contradictory or non‑responsive answers.
• Aging threshold in the DMP exceeded (e.g., >30 days open without progress).
• Safety‑critical or primary endpoint impact that cannot wait for the normal query cycle.
• Blinding risk if further detail is pursued via query.
• Systemic issue (recurring pattern across many subjects/sites).

How to escalate: Follow the DMP. Usually DM sends the CRA a short summary with examples; the CRA takes it to the PI, and clinical operations handles site‑level problems (retraining, corrective action). The query stays open, with the escalation noted on it; DM never answers for the site or changes the data. A safety concern goes to the medical monitor at once, and the site still reports any serious adverse event (SAE) to pharmacovigilance (PV) directly.

What good looks like

Subject 1023, Week 12, VS.SYSBP: Entered value 320 mmHg exceeds physiologic range (rule VS_RNG_01). Please check against source and correct in the EDC or confirm as entered.

Why this works:

• Single issue (one field).
• Precise locator (subject, visit, form.field).
• Neutral (states observation; does not suggest a value).
• Reproducible (rule ID provided).

Phrase bank (useful snippets)

• “Please check against source and correct, or confirm as entered.”
• “Observed value is outside expected range per rule <RULE_ID>.”
• “For audit clarity, please indicate the source document name/date.”
• “If unresolved by <date>, we will escalate per governance.”

Worked examples

All examples are self‑contained. Each includes context, a poor (“Bad”) query, and an improved (“Good”) query.

1) Physiologic range (Vital Signs)

Context: Cardiovascular (CV) trial; Systolic BP appears implausible.

Bad: “This BP is wrong—please fix to 120.”

Why it’s bad: Coaching; no locator; non‑neutral.

Good: “Subject 2014, Baseline, VS.SYSBP recorded as 38 mmHg, below physiologic range (rule VS_RNG_01). Please correct in the EDC or confirm with source.”

2) Internal consistency (Systolic vs Diastolic)

Context: Systolic < Diastolic on same assessment.

Bad: “Numbers are flipped—change SYS to 120.”

Good: “Subject 2014, Baseline, VS.SYSBP (68 mmHg) is 18 mmHg lower than VS.DIASBP (86 mmHg) on the same date (rule VS_INTERNAL_02). Please correct or confirm with source.”

3) Date logic (Visit before Consent)

Context: Visit date recorded before informed consent date.

Bad: “Visit date is wrong; enter after consent.”

Good: “Subject 0507, Screening Visit Date = 2025‑03‑10; Informed Consent Date = 2025‑03‑15. Visits should occur on/after consent. Please check both dates against source and correct as needed, or confirm both as entered (protocol Section 6.1).”

Note: If the site confirms both dates, study procedures may have been done before consent—a possible GCP issue, not a data error: DM escalates to the CRA at once; a query cannot fix that.

4) Missing data with allowable NA reason

Context: Lab value missing; protocol allows “Not Done” with a reason.

Bad: “Please enter the lab.”

Good: “Subject 0899, Day 14, LAB.ALT is blank. Protocol allows ‘Not Done’ with a reason when testing is missed. Please enter the result or select ‘Not Done’ and provide the reason per CRF instructions.”

5) Unit mismatch (Conversion without coaching)

Context: Sodium entered as 138 mg/dL instead of mmol/L.

Bad: “Change units to mmol/L and enter 138.”

Good: “Subject 0321, Day 7, LAB.SODIUM recorded as 138 mg/dL. CRF expects mmol/L for electrolytes. Please check the value and unit against source and correct as needed, or confirm as entered.”

6) Cross‑form inconsistency (AE vs Hospitalization)

Context: Adverse event (AE) marked ‘Severe’ with “Hospitalization = No,” while concomitant medications (ConMeds) indicate inpatient IV antibiotics for 5 days.

Bad: “You said not hospitalized—should be Yes.”

Good: “Subject 2203, AE#04: AE.HOSPITALIZATION is No; ConMeds show inpatient IV antibiotics for 5 days (2025‑04‑02 to 2025‑04‑06). Please confirm whether the AE required hospitalization and update AE.HOSPITALIZATION accordingly or note the source rationale.”

Note: Severity is not seriousness. Hospitalization is a seriousness criterion: if the answer is Yes, the event is an SAE, which the site reports to PV directly—the query never replaces that report.

7) Blinding‑sensitive outcome (Heart rate)

Context: Site‑entered heart rate at Week 8 is below the expected range; do not imply treatment effect.

Bad: “Low result likely due to treatment; please recheck.”

Good: “Subject 1102, Week 8, VS.HR recorded as 44 bpm, below the expected range (rule VS_RNG_04). Please check against source and correct or confirm as entered.”

Why it works: Only the value and the rule are stated—nothing about treatment, study arm or other subjects.

8) Repeated non‑responsive answers (Trigger escalation)

Context: The query and two re‑queries received contradictory responses.

Bad: “We already asked this; please answer properly.”

Good (stop and escalate; note added to the open query): “Subject 1455, Visit 2, ECG.QTcF = 612 ms (rule ECG_RNG_03). The three responses give different values for the same source ECG. Escalated to the CRA on 2025‑10‑15 per the DMP.” DM sends the CRA a short summary with the three responses; the CRA checks source with the PI. No third re‑query. Because a QTcF this high is a safety concern, DM had already flagged it to the medical monitor when it was first detected.

Pitfalls & misconceptions

• Bundling issues: Several unrelated findings in one query create partial answers and delays. One cross‑field check (e.g., systolic vs diastolic) is still one issue.
• Coaching: Suggesting a value, unit, or interpretation biases the record.
• Vague locators: “This page has errors” is not reproducible.
• Arguing in the EDC: Keep tone factual; avoid debate or speculation.
• Endless re‑queries: After clear attempts, escalate—don’t loop.
• Blinding leaks: Don’t discuss treatment patterns or speculate on causality.
• Identifier exposure: Never ask for names or other direct identifiers (protected health information, PHI); the subject ID is enough.

Practice in the wild (checklist)

• Use the standard query template (what/where/why/ask/next step).
• Pin the record: Subject → Visit/Date → CRF.Page.Field.
• Cite the trigger: rule/listing/protocol/CRF instruction.
• Keep it single‑issue and neutral (no suggested value/unit).
• Request correction or source evidence (one clear ask).
• Include SLA and note the escalation path if needed.
• Check for duplicates and blinding risks before sending.
• If ≥2 re‑queries or >30 days aging without progress → escalate.

Key points to remember

• Keep every query single‑issue, neutral, and reproducible—write so any reviewer can re‑create the discrepancy from your text.
• Pin the record precisely: Subject → Visit/Date → CRF.Page.Field (add timestamp if relevant).
• State observed vs expected and cite the trigger (rule/listing/protocol/CRF instruction).
• Ask for one clear action: correct in EDC or provide source evidence—do not coach a value or unit.
• Maintain a factual, concise tone; avoid arguments, speculation, and any language that could risk blinding or expose PHI.
• Include a next step/SLA when appropriate and note the escalation path if unresolved.
• Stop looping and escalate per governance after two clear re‑queries, prolonged aging (e.g., >30 days), safety/primary‑endpoint impact that cannot wait, blinding risk, or a systemic pattern.
• DM does not change site data—the site corrects through the query; a system‑caused error is fixed only by a tested, approved data‑correction script.
• Use the simple structure W‑W‑W‑A‑N: What & Where; Why; Ask; Next step.
• Remember RNS: Reproducible – Neutral – Single‑issue.