Why this matters
Not everything should be an edit check. Human judgment detects clinical implausibility, subtle patterns, and context that would make automated rules too noisy or brittle. Visual review is how a Clinical Data Manager and clinical team connect dots across domains (for example: vital signs, medications, adverse events (AEs), lab results, electrocardiograms (ECGs)) to decide whether the overall clinical story makes sense.
Bottom line: Use people for pattern recognition, timelines, and grey‑area judgments. Use machines for precise, repetitive rules.
Core concepts & definitions
Visual review A guided inspection of curated listings and graphs to assess plausibility and consistency across multiple data domains. The goal is to learn whether the subject’s clinical story holds together. It is also called manual review. Its listings and plots are produced by programs, as in the programmatic review of the previous chapter; what visual review adds is the clinical team’s judgment of whether the data make sense together.
Cross‑domain plausibility Checking whether events in one domain are compatible with data in others (for example, a hospitalization shortly after a severe lab abnormality, or a medication that explains a change in blood pressure). Part of this is a rule: an adverse event marked as treated, with no medication recorded for it, is caught by a batch edit check. Whether the recorded medication fits the event (its reason for use, its dates) is a judgement, and belongs in visual review.
Automation threshold A practical rule: if encoding the logic requires heavy context, would trigger many false positives, or needs nuanced medical judgment, keep it manual (or prototype manually before automating).
Documentation Clear capture of what you reviewed, what you decided, and why—including any queries raised and any candidate ideas to convert into future automated checks. This creates audit‑ready traceability. The topics, listings, reviewers and review frequency are set in advance, in the Data Management Plan or a data review plan it references (the name varies by sponsor).
Roles
- Clinical Data Manager (CDM): Facilitates, prepares listings/plots, logs decisions.
- Medical Reviewer (MR): Provides clinical judgment (usually the sponsor’s medical monitor).
- Clinical Research Associate (CRA): Connects findings to site conduct and source.
- Statistician or Data Scientist (optional): Helps with outlier detection and trends.
The process, step‑by‑step
Choose high‑value topics Start where automation is weak and judgment matters. Check the edit check specification first: a rule already covered by a programmed check stays out of the session. Typical topics:
- Cross‑domain stories (labs ↔ medications ↔ adverse events ↔ vital signs).
- Temporal narratives (admissions, procedures, rescues, dose changes).
- Site‑level drift (sudden changes in ranges or variability).
- Free‑text narratives that influence interpretation: no programmed check can judge whether a comment is clear, complete and plausible.
Prepare materials Provide context‑rich views, not raw dumps (test the listings and plots before first use, like any review program):
- Subject timeline: dates for dosing, visits, hospitalizations, key labs, AEs.
- Curated listings: latest values + recent changes; flags for large deltas.
- Simple plots: run charts for labs/vitals; site‑level boxplots; time‑aligned overlays by visit or study day.
- Annotations: highlight outliers, protocol windows, medication starts/stops.
Run the session (decisions, not presentations)
- Attendees: CDM (facilitator), MR (decision maker), CRA (site liaison).
- Structure: short agenda with specific questions (e.g., “Do ECG findings align with the new antiarrhythmic medication?”).
- Decisions in real time: log query text, responsible owner, and due date. Before raising a query, check that no open query from an edit check or the CRA already covers the point.
- Safety first: escalate potential safety issues to the safety/pharmacovigilance team immediately; do not wait for the meeting to end. This internal escalation never replaces safety reporting: the site reports each serious adverse event (SAE) to pharmacovigilance directly.
Record outcomes
- Visual Review Log: date/time, dataset version, who attended, what was viewed, decisions, query IDs, rationale.
- Candidate Rule Register: repeated, low‑noise patterns that might be promoted to automated checks later.
Promote or park
- Promote to rule if: (a) repeats across subjects/sites, (b) low context needed, with clear thresholds and time windows, (c) low false‑positive risk. A promoted rule is specified, tested and released under change control, like any other edit check.
- Keep manual if: (a) requires clinical nuance, (b) rare edge case, (c) would be noisy if automated.
What good looks like
Focused agenda At most five to seven concrete questions, not a tour of every listing. Example: “Subjects with >10 mmHg drop in diastolic blood pressure after starting medication X: are AEs recorded and clinically consistent?”
Traceable outcomes Every decision has a path to action: query ID, change request (to a check, listing or specification, not a direct edit of data), or no action with rationale. The site corrects its own data in answer to a query. Link back to subject IDs and listing versions.
Candidate rule pipeline Repeated manual findings are captured with proposed logic, estimated impact, and a decision date for automation.
Definition of Done (per session)
- All agenda items addressed.
- Log updated and filed.
- Owners assigned and deadlines set.
- Safety concerns escalated immediately, not after the session.
Copy‑paste templates
Agenda (example)
Objective: Assess plausibility of BP changes after starting Medication X.
Scope: Subjects who initiated X in the last 30 days.
Materials: Timeline listing v1.9; Lab/Vitals run charts v2.1.
Questions: (1) Are AEs aligned? (2) Any admissions within 7 days? (3) ECG changes?
Visual Review Log (minimal fields)
Date | Dataset/Listing version | Attendees | Subjects/Sites | Findings | Decision | Rationale | Owner | Due | Evidence/Links | Query IDs
Candidate Rule Register (minimal fields)
Pattern | Proposed Logic | Expected Benefit | False-Positive Risk | Decision | Target Release
Worked examples
Each example is self‑contained, with a brief scenario, what to look for, the decision made, and how to document it. No prior modules are required.
1) Intravenous saline contamination suspected (laboratory results)
Scenario
A subject receives an infusion at Visit 8. The same day, the laboratory results show:
- Sodium and chloride both spike upward compared with prior visits.
- Bicarbonate and potassium appear lower.
- Hemoglobin and hematocrit are slightly reduced compared with the preceding visit.
- No corresponding adverse event is recorded.
What to look for
Review the timeline: infusion time, blood draw time, and lab receipt time. Check whether the pattern appears across multiple analytes, not just one. Compare with previous and next visits.
Decision
The combined pattern suggests dilution/contamination from saline near the time of draw rather than a true clinical deterioration.
Actions & documentation
- Raise a single targeted query to the site: “The Visit 8 laboratory results differ markedly from this subject’s earlier visits. Please check the sample collection time and the infusion start and stop times against source and confirm or correct them.” The query names no cause and asks for no repeat sample: a re‑draw is the investigator’s decision.
- Log rationale in the Visual Review Log; attach the plotted values and specific time stamps.
- Add to the Candidate Rule Register as a potential future pattern‑detection check (multiple analytes moving together within a short interval after infusion).
2) Rescue medication near an efficacy assessment
Scenario
On Day 28, a subject shows an unusually strong improvement on the primary efficacy scale. Concomitant medication records show rescue medication given the evening before the assessment.
What to look for
- Confirm exact timing of the rescue medication relative to the assessment window.
- Check protocol language: should the assessment have been postponed, or does the protocol define it as not evaluable, if rescue medication was used recently?
Decision
The assessment may be confounded by the rescue medication. The value stays in the database as collected: the review team neither excludes nor changes it. The protocol and the statistical analysis plan (SAP) set in advance how it is used in analysis; rescue use that breaks a protocol restriction is recorded as a protocol deviation.
Actions & documentation
- Query the site to check the date and time of the rescue medication and of the assessment against source and confirm or correct them.
- Record the decision in the log and flag the case to the statistician: the SAP, not the review session, decides how the value is used.
- Consider a future automated check (time‑based cross‑check between rescue meds and efficacy windows) if false positives are expected to be low.
3) Blood pressure drop after starting antihypertensive medication
Scenario
A subject starts an antihypertensive medication on Day 15. By Day 22, systolic and diastolic blood pressure drop substantially. No adverse event is recorded, and dizziness is mentioned in a free‑text comment.
What to look for
- Time‑align medication start/stop with vitals.
- Look for orthostatic symptoms (e.g., dizziness) in free text or AE listings.
- Review whether dose adjustments occurred.
Decision
The change is clinically plausible given the medication. However, the symptom mention suggests an AE might be missing or under‑documented.
Actions & documentation
- Raise a query that quotes the comment and asks the site to record an AE if one occurred, or confirm that none did, and to check that any dose change is recorded; it names no diagnosis.
- Log the reasoning and attach the vitals chart.
- Do not automate this pattern yet; it depends on nuanced clinical interpretation and free‑text signals.
4) Prolonged QT on ECG with a known QT‑prolonging drug
Scenario
ECG on Day 21 shows a prolonged corrected QT interval (QTc) above the protocol threshold. Concomitant medications include a drug known to prolong QT started on Day 18. No AE or dose change is recorded.
What to look for
- Confirm ECG reading, medication timing, and protocol thresholds.
- Check whether any follow‑up ECG was done.
Decision
The medical reviewer judges the combination potentially clinically significant; it needs immediate safety escalation.
Actions & documentation
- Escalate to the safety team immediately, per study procedure.
- Raise a site query to confirm actions taken (repeat ECG, dose change).
- Document escalation and links to evidence in the Visual Review Log.
- Consider a future automated check only if thresholds and time windows are stable and low‑noise.
Pitfalls & misconceptions
Re‑checking machine‑friendly rules manually Required fields, simple reference ranges, and visit windows belong to automated checks. Manual time is too precious.
Assuming all cross‑domain logic can be automated Many relationships require clinical nuance and context that change from subject to subject.
No documentation of decisions Undocumented judgments create audit risk and confuse downstream teams.
Scope creep Trying to review “everything” in one session dilutes attention. Keep agendas focused.
Unblinding risk Ensure listings and plots used for review respect blinding rules; if the review is blinded, show neither treatment assignments nor data that could reveal them (for example, drug concentration results).
Unit and timing traps Misreads due to unit conversions, time zones, or collection vs receipt times can lead to incorrect conclusions. Always check metadata.
Practice in the wild (checklist)
- Define a standing agenda (top 5–7 questions) per review session.
- Prepare context‑rich timelines and listings (with deltas, flags, time stamps).
- Verify blinding is preserved and safety escalation routes are ready.
- Run the session with clear roles (CDM facilitator; MR decision maker; CRA site liaison).
- Log decisions, rationales, and query IDs in a Visual Review Log.
- Maintain a Candidate Rule Register to capture repeatable patterns.
- Promote patterns to automation only when low‑noise and generalizable.
- After the session, assign owners and due dates; follow up to closure.
- Before database lock, confirm all visual‑review actions are resolved.
Key points to remember
- Purpose & scope: Reserve manual/visual review for clinical plausibility and cross‑domain context—multi‑domain stories, temporal narratives, free‑text nuance, site‑level drift, and potential safety signals where automation would be noisy or brittle.
- Don’t duplicate automation: Routine machine‑friendly logic belongs in edit checks—required fields, formats/ranges, protocol windows, and straightforward cross‑field rules with low false‑positive risk.
- Run focused sessions: Use a short, question‑driven agenda; bring context‑rich timelines, curated listings with deltas/flags, and simple plots; keep roles clear (CDM facilitator, MR decision maker, CRA site liaison); escalate safety immediately.
- Document for traceability: Maintain a Visual Review Log capturing date/time, dataset or listing version, attendees, subjects/sites, findings, decisions and rationale, owners, due dates, evidence/links, and query IDs.
- Promote only when ready: Move patterns to automated rules only if they repeat, require minimal context, have clear thresholds/windows, and show low false positives; otherwise keep them manual.
- Preserve blinding: Ensure all materials and discussions respect blinding rules; in blinded reviews, expose neither treatment assignments nor data that could reveal them.
- Close the loop: Every conclusion maps to an action—a query, a change request, or no action with rationale—with owners and deadlines assigned and tracked to closure.