Why this matters
A “closed” query is not automatically a correctly closed query. If the wrong resolution type is chosen or the rationale is missing, data can move forward to analysis with silent errors. A small, well‑defined set of resolution types, plus independent post‑resolution quality control (QC), ensures that:
- data changes are justified and traceable,
- non‑resolvable issues are handled consistently (e.g., flagged for exclusion or medical review),
- speed does not overshadow accuracy.
Plain language: Pick the right label for how you closed the discrepancy, explain why, and periodically double‑check closures done by the team.
Core concepts & definitions
Key terms (expanded on first mention):
- EDC (Electronic Data Capture) — the system where case report form (CRF) data are entered and queries are managed.
- CRF (Case Report Form) — the structured set of fields collecting protocol‑specified data.
- QC (Quality Control) — independent verification of correctness and documentation quality.
- SAP (Statistical Analysis Plan) — defines how endpoints are derived and which records are included/excluded.
- SOP (Standard Operating Procedure) — local procedure that governs consistent actions (e.g., how queries are closed and reviewed).
- Audit trail — the system’s uneditable, time‑stamped record of who did what, when and why. A complete closure shows any data change (old and new value, site user, reason for change) and the query record (who closed it, when, type, rationale).
The governed resolution types
Use a concise, study‑wide catalog that is governed: defined in the data management plan (DMP), built into the EDC as a pick‑list, and changed only under change control. Below are the most common, with plain‑English guidance:
Corrected The entered value was wrong and the site has corrected it in EDC against source, with a reason for change (a vendor re‑delivers its file). Data management (DM) never makes the change. Use when: A transcription error, mis‑keyed date, or wrong unit is confirmed and corrected.
Confirmed as Entered (also “confirmed as‑is”) The entered data are accurate per source: the check fired correctly on a value that is unusual but true. Use when: Data match the source; you document the reason it looks unusual (e.g., outlier that is true).
Self‑Evident Correction (SEC) 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. Use when: The error is on the investigator‑signed SEC list (paper CRFs); in EDC, raise a query and let the site correct.
Not Able to Resolve (also “cannot be resolved”) Evidence is insufficient or conflicting after re‑query and escalation through the monitor (clinical research associate, CRA). Use when: Sources disagree or are lost and the investigator cannot establish the true value; never just to close before a data cut. Always record the next action agreed with the study team (e.g., handling per SAP; flag for medical review).
Not an Error / By Design The data or workflow is unusual but intended per protocol, edit check design, or site practice. Use when: The system raised a query for a scenario the protocol explicitly allows; no data change is needed.
Important: “Received from Site,” “Under Review,” or “Closed” are workflow states, not resolution types.
The process, step‑by‑step
Select a type from the catalog DM selects the type at closure, after reviewing the response (the CRA for source data verification (SDV) queries). Keep the catalog short, defined, and trained across all study staff and vendors.
Capture a concise rationale at closure
- What changed (or why no change)?
- What evidence supports this? (document name/date as cited by the site, or audit trail reference; never a copy with direct identifiers)
- If not resolvable: what is the next action agreed with the study team (e.g., handling per SAP, medical review)?
Record analysis impacts DM records them; biostatistics and programming set flags and derivations per the SAP.
- Was a derived variable updated?
- Was an endpoint inclusion/exclusion flag set?
- Any re‑derivations or listings to refresh?
Run post‑resolution QC regularly
- Who: someone who did not close the sampled queries (this makes it independent).
- Frequency: at least monthly; increase for new sites, new staff, surge periods, or high‑risk domains (e.g., safety, endpoints).
- Sampling approach: combine targeted (high‑risk) and random samples. Example policy: for each site/domain, review a minimum of 20 closures or 5% of closures in the month (whichever is greater; e.g., 50 of 1,000; all if fewer than 20), and 100% for newly onboarded staff in their first month.
- Checks: accuracy of type, sufficiency of rationale, evidence traceability, correct data change, correct analysis flagging, against the query, response and audit trail (source through the CRA). Defects are fixed through the query: a wrong type or thin rationale is corrected with a documented reason, and the query is reopened only when the finding shows the data issue is still unresolved; the reviewer never edits data.
Feed the learnings back
- Tweak noisy edit checks or thresholds.
- Share brief coaching notes and good rationales as examples.
- Update SOP/templates if patterns emerge.
What good looks like
- One study‑wide catalog of resolution types with examples and “when to use / not to use.”
- Every closure has a clear rationale referencing evidence (file name/date, audit record ID, or accessible link).
- Audit trail shows who changed what, when, and why; every change to site data is made by the site, with a reason for change.
- QC reports show sample size, accuracy rate (correct closures ÷ closures sampled), defect categories, and corrective actions (e.g., retraining a site, tuning a rule).
- Traceability to analysis: endpoint inclusion/exclusion flags and derivations are updated or queued.
Worked examples
Running study: Cardiovascular outcomes trial evaluating MACE (major adverse cardiovascular events). EDC modules: demographics, adverse events, endpoints. Key documents: discharge summaries, event adjudication outcomes, and the SAP.
Example 1 — Corrected
- Scenario: MACE event date entered as 2025‑03‑21 but discharge summary shows 2025‑03‑12.
- Action: The site corrects the CRF event date to 2025‑03‑12 with a reason for change; DM checks the audit trail and re‑runs the check.
- Resolution type: Corrected
- Rationale text (good example): “Event date corrected by site to 2025‑03‑12; site cites Discharge Summary, Mercy Hosp., signed 2025‑03‑14, p.2. Reason for change: transcription error.”
- Analysis impact: Endpoint windowing re‑evaluated; event remains included.
Example 2 — Confirmed as Entered
- Scenario: Serum potassium 2.9 mmol/L triggers low‑value rule. The site confirms 2.9 against its local lab report and notes the patient was symptomatic and treated in the emergency room.
- Action: No data change. Document context. The rule worked as designed; no tuning needed.
- Resolution type: Confirmed as Entered
- Rationale text: “Value confirmed by site against Local Lab Report #LL‑009827, 2025‑02‑02. Hypokalemia treated; see AE record AE‑112. True outlier; no change.”
- Analysis impact: None; the value stays in the analysis as a true result.
Example 3 — Self‑Evident Correction (SEC) vs. a query
- Scenario: Visit date recorded as 05/09/2025 (5 September in the EDC’s day/month format); the visit window and adjacent entries point to 09‑May‑2025. A colleague suggests fixing it as an SEC.
- Action: No SEC: a visit date is not self‑evident (05/09 is valid either way) and DM cannot edit site data. DM queries; the site corrects the date with a reason for change.
- Resolution type: Corrected (not Self‑Evident Correction)
- Rationale text: “Visit date corrected by site to 09‑May‑2025 (reason for change: day/month transposition; site cites clinic visit note 2025‑05‑09). Visit‑window check no longer fires.”
- Analysis impact: None beyond correct scheduling.
Example 4 — Not Able to Resolve
- Scenario: Event onset date differs: progress note says 2025‑01‑05; discharge summary says 2025‑01‑07; after a re‑query and escalation through the CRA, the investigator cannot establish which is right.
- Action: No data change; document the conflict; the study team (biostatistics, medical monitor) decides the handling under the SAP’s rule for ambiguous onset dates. DM does not decide exclusions.
- Resolution type: Not Able to Resolve
- Rationale text: “Conflicting sources (Progress Note 2025‑01‑06 vs. Discharge Summary 2025‑01‑09). Investigator unable to establish onset after re‑query and CRA escalation. Value unchanged; handled per SAP §6.3 as agreed with biostatistics and the medical monitor.”
- Analysis impact: Decided by biostatistics per the SAP (e.g., its rule for ambiguous onset dates, with a sensitivity analysis), not by DM; listed as unresolved at database lock.
Example 5 — Not an Error / By Design
- Scenario: Unscheduled visit within 24 hours of a scheduled visit triggers a duplicate‑visit rule. Protocol allows back‑to‑back assessments for symptom escalation.
- Action: No data change; document protocol allowance; propose rule refinement.
- Resolution type: Not an Error / By Design
- Rationale text: “Unscheduled visit is protocol‑allowed for escalation (Protocol §8.2). Data correct; request to refine duplicate‑visit check.”
- Analysis impact: None; both visits stay in the data.
Pitfalls & misconceptions
- “Received from Site” is not a resolution type. It is a workflow state; pick a type that explains how you closed.
- Thin rationales. “Fixed” or “As per site” is insufficient—always cite the evidence or SOP.
- Using SEC when not allowed. SECs need an error on the investigator‑agreed list; in EDC, raise a query instead.
- No next step for non‑resolvable items. “Not Able to Resolve” must include the practical consequence (e.g., endpoint exclusion, medical review).
- Measuring only speed. Cycle time without correctness leads to fast, wrong closures.
- Forgetting analysis impacts. Record the impact and hand it to biostatistics and programming, or log a task to do so.
Practice in the wild (checklist)
- Publish a Resolution Type Catalog with “use / don’t use,” examples, and analysis impacts.
- Configure EDC to require a rationale before closure (free text + evidence reference).
- State in the DMP that SECs are not used in EDC (the site corrects through a query); on paper CRFs, define SEC criteria with an investigator‑signed list.
- Run monthly post‑resolution QC by an independent reviewer with both targeted and random samples; track accuracy and documentation adequacy.
- Share a one‑page coaching sheet with good rationale examples.
- Tune noisy edit checks based on QC findings; log changes via change control.
- Ensure endpoint flags/derivations are updated or queued when closures affect analysis.
Key points to remember
Resolution type ≠ workflow state. Pick the type that explains how you closed the discrepancy; statuses like Received from Site or Closed are not resolution types.
Use a governed, study‑wide catalog. Apply the standard set consistently:
- Corrected: data changed by the site, with a reason for change, because source shows the original entry was wrong.
- Confirmed as Entered: true outlier or unusual value; no change, rationale explains why it’s correct.
- Self‑Evident Correction (SEC): unambiguous, non‑clinical error on an investigator‑agreed list; rare in EDC, where the site corrects through a query.
- Not Able to Resolve: conflicting or insufficient evidence; document the practical consequence.
- Not an Error / By Design: unusual but intended per protocol, design, or workflow—no data change.
Distinguish the “no‑change” types. Confirmed as Entered = true data; Not an Error / By Design = unusual but intended scenario.
Always justify the closure. Include a concise rationale referencing evidence (document name/date, audit trail ID, or accessible link).
Plan and record next steps for non‑resolvable items. For Not Able to Resolve, state the action agreed with the study team (e.g., handling per SAP, medical review) and why; a data cut alone is no reason to close.
Connect closures to analysis. Record the impact and make sure biostatistics and programming update the endpoint inclusion/exclusion flags, derivations and downstream listings affected by the closure.
QC the closures on a routine cadence. Have an independent reviewer (not the person who closed them) check a risk‑based and random sample with a defined minimum; verify correct type selection, adequacy of rationale, traceable evidence, correctness of any data change, and proper analysis flagging.
Prioritize accuracy, not just speed. Track accuracy and documentation quality in addition to cycle time.