Why this matters
A clear, shared query lifecycle turns disagreement into decisions. It prevents stalls and finger‑pointing, makes performance measurable (e.g., time to first response, aging—days open), and produces an audit trail that shows who did what, when, and why. When inspectors review closures, they care less about the software label and more about your consistency: one issue per query, neutral wording, correct routing, documented rationale, and auditable transitions.
Core concepts & definitions
What is a “query”? A discrepancy is any inconsistent, missing or implausible value that a check or review finds. A query (sometimes called a “data clarification”) is the documented request to explain or correct that data point. It is tied to a specific record and should focus on one issue.
Detection How we notice issues (for example, automated rules (edit checks), listings, reconciliation, or Source Data Verification, SDV). Detection does not mean the data are wrong—it means something needs clarification.
Creation Opening a query in the Electronic Data Capture (EDC) system against the correct record, written in neutral language and scoped to a single issue. Vendor and internal issues are often tracked outside the EDC, with the same lifecycle.
Assignment (Routing) Sending the query to the right owner:
- Site (investigator/study coordinator),
- Vendor (e.g., central lab or ePRO/eCOA (electronic patient‑reported and other clinical outcome assessments) provider), or
- Internal (data management (DM) or statistical programming when the action is on us, e.g., a misfiring edit check or a mapping error). The fix is made in the check or program under change control, never by editing site data; a system‑caused error in the data is fixed only by a tested, approved data‑correction script.
Response The owner corrects or explains, with evidence: the site corrects its own entry in EDC with a reason for change; a vendor re‑delivers (file name/version). Evidence is a source reference or a redacted excerpt, never a document with direct identifiers.
Review DM reviews the response/evidence and chooses a resolution type (explains how the issue was closed). For SDV queries, the monitor (clinical research associate, CRA) reviews and closes.
Closure The query moves to a final state. The audit trail captures user, timestamp, action, and reason (rationale for the closure and chosen resolution type).
Reopen Only if new information contradicts the closure (with clear rationale). Reopening should be exceptional, not routine.
States vs. Resolution types (critical distinction)
- Workflow states describe where the query is in the process (e.g., New, Sent to Site, Site Responded, DM Review, Closed).
- Resolution types describe how the discrepancy was closed (e.g., Corrected, Confirmed as Entered, Self‑Evident Correction, Not Able to Resolve).
These are not interchangeable.
Other common terms
- EDC: Electronic Data Capture system.
- SDV: Source Data Verification (checking case report form, CRF, entries against source documents).
- RACI: Responsible, Accountable, Consulted, Informed (clarifies roles).
- SLA: Service Level Agreement (expected turnaround time; for sites, the target in the data management plan, DMP).
- MACE: Major Adverse Cardiovascular Event (used in an example below).
The lifecycle, step‑by‑step
Detect
- Sources: automated rule checks, batch listings, reconciliation (e.g., lab vs CRF), or SDV.
- Tip: Record the detection source so you can analyze which controls are effective.
Open (Create a single‑issue query)
- Write neutrally: state what you see, where it is, and what is needed.
- Reference the evidence (e.g., listing ID, rule name, or, for an SDV query, the source document checked).
- Avoid “leading” language (“Please change to…”)—ask for confirmation or correction per source.
Template you can reuse
Observation: [what is inconsistent or missing]
Location: [form/visit/field, subject ID, date]
Request: Please confirm the value against source and correct as needed, or provide clarification.
Reference: [rule/listing/recon batch ID] (optional)
Assign (Route to the correct owner)
- Site vs vendor vs internal.
- Start the SLA clock once assigned. If no response arrives in time, DM escalates per the DMP, usually through the CRA; DM never answers for the site.
- If a vendor must re‑deliver, keep it vendor‑assigned until a valid file is received and verified.
Owner responds
- Correction in EDC by the site (with reason for change and a supporting comment), or
- Explanation with evidence when data are already correct (e.g., protocol exception explained and documented).
- Vendors: include the file name and delivery date/version.
DM review (decide the resolution type)
- Confirm the fix or explanation against evidence: the response, the corrected value, its audit trail, and a re‑run of the check. Comparing data with source is the CRA’s task (SDV).
- Choose one resolution type and record the rationale (short, explicit).
- If unclear, request clarification—do not guess.
Close (final state + full audit trail)
- Set to the final state (Closed); only new, conflicting evidence reopens it.
- Ensure the query record and its audit trail show: detector/source, assignee, actions taken, resolution type, rationale, and date/time.
Post‑resolution QC & learning
- Periodically have someone who did not close them review a random sample of closed queries (response, audit trail and, through the CRA, source) to confirm appropriate resolution types and rationales.
- Feed insights back into rules and templates (e.g., refine wording, adjust thresholds).
What good looks like
Example state machine
New → Sent to Site (or Sent to Vendor) → Site/Vendor Responded → DM Review → Closed
(Your EDC may use different labels, such as Open, Answered or Received from Site; publish a diagram so everyone shares the same model.)
Two loops complete it: DM Review back to the owner when the response is inadequate (re‑query), and Closed to Reopened. Who moves it: DM opens, reviews, closes and reopens (the CRA for SDV queries); the owner responds; only the site changes site‑entered data.
Resolution types (pick at closure, not earlier)
- Corrected: the owner changed the data to match source (the site in EDC, or the vendor in a re‑delivered file).
- Confirmed as Entered (also “confirmed as‑is”): data were already correct; explanation and evidence provided.
- Self‑Evident Correction: an obvious error of a kind the investigator has agreed in advance, in writing (e.g., a clear spelling slip; never a clinical value or its unit); a paper‑era practice. In EDC, DM cannot edit site data, so the site corrects through a query and the type is rarely used.
- Not Able to Resolve (also “cannot be resolved”): evidence insufficient; document attempts, impact, and the mitigation agreed with the study team (e.g., sensitivity analysis or protocol deviation record).
Transition hygiene
- One issue per query.
- Neutral, specific wording.
- Right owner first time (site vs vendor vs internal).
- Rationale captured at every key transition, especially at closure. The system time‑stamps each transition with the user (queries are closed, never deleted), and a data correction has its own audit‑trail entry: old value, new value, who, when, and reason for change.
- Reopen only with new, conflicting evidence.
Worked examples
Example 1 — Date out of sequence (cardiovascular study)
Detect: A batch rule flags that a MACE event date occurs before randomization for Subject 102‑014.
Open:
Observation: MACE event date precedes randomization.
Location: AE/Endpoint form → MACE event date (Visit: Event), Subject 102‑014.
Request: Please confirm the event date against source and correct as needed, or provide clarification.
Reference: Rule R‑END‑012.
Assign: To Site.
Response (Site): Confirms transcription error; updates date to 2025‑03‑14 with reason for change “transcription error” and cites the source note.
DM review: Checks the audit trail (old value, new value, reason) and re‑runs the rule: the date now follows randomization; discrepancy resolved.
Close: Resolution type Corrected with rationale: “MACE date corrected by site to 2025‑03‑14 per source (transcription error); rule R‑END‑012 no longer fires.”
Example 2 — Missing lab in vendor file (central lab reconciliation)
Detect: Reconciliation shows CRF has a chemistry panel at Visit 6, but the central lab transfer is missing that record for Subject 203‑009.
Open:
Observation: Chemistry panel present in CRF at Visit 6 but absent in central lab file.
Location: Lab CRF (Visit 6), Subject 203‑009.
Request: Please investigate and re‑deliver if applicable; include file name/version in response.
Reference: Recon batch RC‑LAB‑077.
Assign: To Vendor (central lab).
Response (Vendor): Identifies extraction gap; re‑delivers LAB_2025‑06‑02_v2.csv including the missing record.
DM review: Validates that the record now appears in staging and downstream curated load.
Close: Resolution type Corrected with rationale: “Record delivered in LAB_2025‑06‑02_v2.csv; presence verified in curated table.”
Note: Do not send this to the Site—the action is on the vendor. Only if the lab never received the sample does a separate query go to the site.
Example 3 — Not able to resolve (legacy source unavailable)
Detect: Screening weight appears unusually high relative to later visits for Subject 115‑002.
Open:
Observation: Screening weight is inconsistent with subsequent visit weights.
Location: Vital Signs (Screening), Subject 115‑002.
Request: Please confirm weight per source and correct as needed, or explain any protocol exception.
Reference: Listing L‑VS‑005.
Assign: To Site.
Response (Site): Clinic closed; paper source lost in flood; staff unable to verify.
DM review: No alternative evidence is available. DM escalates to the study team (clinical operations, biostatistics, medical monitor), who agree to keep the value and flag it for the sensitivity check in the statistical analysis plan (SAP).
Close: Resolution type Not Able to Resolve with rationale: “Source unavailable (site incident report attached); value retained as agreed with the study team; flagged for sensitivity check per SAP §6.2.”
Follow‑up: Clinical operations and quality assurance assess the loss of source records (it may be recorded as a deviation); the unresolved item is listed in the database‑lock documentation.
Pitfalls & misconceptions
- Multi‑issue queries. Packing several problems into one thread makes resolution and auditing harder. Open one query per issue.
- Leading language. “Please change to X” is not neutral. Ask to confirm/correct per source.
- Mixing states with resolution types. “Site Responded” is a state, not a closure reason.
- Closing without rationale. “Closed—Corrected” with no explanation is weak in audits. Add a short, specific note.
- Routing to the wrong owner. Vendor data problems should not be sent to sites.
- Over‑using reopen. Reopen only with new, conflicting evidence.
Practice in the wild (checklist)
- Publish a simple state diagram and RACI for each state/transition.
- Enforce one issue per query with neutral, specific wording.
- Route to the right owner (site vs vendor vs internal) and start the SLA clock.
- Require a resolution type and short rationale at closure.
- Attach or reference evidence (rule/listing/recon batch, file name/version, source reference or redacted excerpt).
- Sample a subset of closed queries monthly for post‑resolution QC; feed lessons back into rules/templates.
- Treat reopen as exceptional; require rationale and link to new evidence.
Key points to remember
- States vs. resolution types—don’t mix them. States show where the query is in workflow (e.g., Sent to Site, DM Review, Closed). Resolution types explain how it was closed (e.g., Corrected, Confirmed as Entered, Self‑Evident Correction, Not Able to Resolve).
- Write neutral, single‑issue queries. State what you see, where it is, and what is needed. This speeds resolution and keeps metrics meaningful.
- Route to the right owner the first time. Site for source clarifications; vendor for delivery/extraction issues; internal when the action is on data management or programming.
- Choose the resolution type at closure—after verifying evidence. Confirm the correction or explanation, then select one resolution type and record a brief, explicit rationale.
- Make closure auditable. Capture who/what/when/why and link evidence (e.g., rule/listing/reconciliation ID, vendor file name/version, or redacted source excerpt).
- Reopen only with new, conflicting evidence. Treat reopen as exceptional and document the rationale.
- Quality is more than speed. Track timeliness, but have an independent reviewer sample closed queries at random for post‑resolution QC to confirm appropriate resolution types and rationales, and feed improvements back into rules and templates.