Programmatic Review vs SDV

Why this matters

Clinical data moves quickly and affects decisions about participant safety and study outcomes. Programmatic review (code‑driven checks and listings) scales across all subjects and visits to find systemic issues—things a human is unlikely to spot by paging through forms. Source Data Verification (SDV) is a record‑by‑record comparison between the Electronic Data Capture (EDC) system and the source documents at the site; it confirms fidelity to source and is a powerful moment for site coaching.

Treating these as interchangeable creates gaps:

• Relying only on SDV misses cross‑subject patterns (e.g., the same unit error in every lab import).
• Relying only on programmatic review misses context that lives only in the source (e.g., a clinician’s note that justifies an outlier). It also cannot see a plausible transcription error: an in‑range value that differs from the source passes every check, and only a comparison with source finds it.

Used together, they raise data quality while using time wisely.

Core concepts & definitions

• Programmatic review — A repeatable, code‑based process that produces listings and flags to detect patterns, inconsistencies, and risks across the dataset (subjects, visits, domains). Examples: duplicates, impossible sequences (e.g., procedure before consent), cross‑form mismatches, out‑of‑range trends by site. It overlaps with the batch checks of the previous chapter: an automated edit check usually raises its query by rule, while a review listing is read by a data manager, who decides what to query.
• Source Data Verification (SDV) — A monitoring activity: compare EDC entries to original source (charts, lab reports, device printouts). Confirms transcription accuracy and completeness; enables on‑the‑spot coaching by the Clinical Research Associate (CRA). A mismatch becomes a query, and the site corrects its entry; the CRA never edits site data. SDV applies to data transcribed from source: directly loaded data (central lab, devices, electronic diaries) are checked by reconciliation and programmatic review instead.
• Source Data Review (SDR) — A broader qualitative review of source (not a line‑by‑line check) to assess protocol compliance and data quality at the site. (People often say “SDV” when they mean SDR—know the difference.)
• Risk‑based focus — Allocate effort where errors would most affect safety, primary/secondary endpoints, or regulatory credibility. The monitoring plan sets how much SDV/SDR is done and on which data; programmatic review findings feed centralized monitoring (ICH E6) and help target SDV/SDR.
• Query — A clear, non‑leading question to the data owner (site or vendor) requesting clarification or correction, tracked through resolution with an audit trail.

Rule of thumb: Programmatic review finds what to ask (systematically). SDV/SDR helps confirm what’s true in the source and why issues occur.

The process, step‑by‑step

1. Define review scopes Map checks to three buckets:

   • Safety‑critical (e.g., Serious Adverse Events; dose interruptions).
   • Endpoint‑critical (e.g., primary efficacy timepoints; adjudicated events).
   • Operational risk (e.g., timeliness, missingness, visit windows).

2. Build review scripts

   • Create reproducible scripts that generate listings/flags for: outliers, duplicates, date order errors, cross‑form mismatches, unit inconsistencies, and late/missing data.
   • Parameterize by site, visit, timeframe so you can slice quickly.
   • Keep scripts under version control with run logs and change notes.
   • Test each script before first use, with data that should and should not be flagged, and re‑test after every change.

3. Triage & open queries

   • Triage by impact (safety/endpoints first), then by volume (patterns).
   • Write non‑leading queries, cite the form/field/record, and state the observed inconsistency plainly.
   • Route correctly: site vs vendor vs internal fix (e.g., mapping error). The site corrects its own entries and the vendor corrects and re‑sends its data; an internal fix changes a specification, mapping or program, never site data (a system‑caused data error is corrected only by a tested, approved data‑correction script).

4. Use SDV/SDR selectively

   • Prioritize high‑risk domains and sites (e.g., sites with recurrent date issues).
   • During SDV, confirm fidelity to source; during SDR, assess process and protocol adherence.
   • Treat monitoring visits as coaching sessions—explain correct entry and documentation practices (the CRA coaches; site staff make every entry and correction).

5. Close the loop

   • Feed recurring findings into: rule updates, training refreshers, Data Management Plan (DMP) amendments, and EDC edit checks (changed under change control and re‑tested).
   • Run post‑resolution QC on a sample of closed queries to confirm each was resolved and documented correctly, and re‑run the listing to confirm the pattern has stopped.

What good looks like

• Scheduled programmatic runs (e.g., weekly; more often for safety‑critical listings) on stable scripts; outputs land in a standard folder with timestamps and run parameters documented.
• Version control (e.g., Git) for scripts and query templates; merge requests reviewed by a second clinical data manager (CDM) or data engineer.
• Risk‑aligned SDV/SDR plan, not 100% by default; coverage increases only when risk/quality signals justify it.
• Clear roles: CDM leads programmatic review; CRAs lead SDV/SDR; vendors own feed mappings; statisticians advise on endpoint sensitivity.
• Dashboards that show: open/aged queries by risk area, missing critical timepoints, site timeliness, and “found by code vs found by SDV”. They are fed from the logged findings (each tagged with rule, script version, risk, owner, found‑by and query status), not compiled by hand.
• Post‑resolution QC: independent sampling of closed queries, with acceptance criteria (e.g., ≥95% correctly resolved and documented).
• Traceability: each query links back to the specific rule/listing and script version that generated it.

Worked examples

The examples below are self‑contained. Each shows what the code checks, what to ask, what SDV/SDR covers, and how to fix the root cause.

Example 1 — Cardiovascular trial: event before randomization

Scenario

A Major Adverse Cardiovascular Event (MACE) date appears before the randomization date for four subjects at two sites.

What the code checks

• Compare EVENT_DATE from the Adverse Event/Endpoint form to RAND_DATE from the Randomization form.
• Flag if EVENT_DATE < RAND_DATE for events marked as on‑study.

Illustrative listing

What to ask (query text template)

“Please confirm the event start date for MACE on [form/visit]. The current date (2024‑06‑10) precedes randomization (2024‑06‑12). Please check the date against source and correct or confirm it; if the event occurred before randomization, record it as the protocol directs.”

What SDV/SDR covers

CRA reviews source notes (hospital report, admission/discharge summary). Confirms whether the event was pre‑screening, pre‑randomization, or mis‑entered.

Root‑cause & fix

• Root cause: site confusion about “on‑study” vs “medical history.”
• Fix: update help text on the endpoint form; add an edit check to prompt when EVENT_DATE < RAND_DATE; include a site refresher during the next monitoring call.

Example 2 — Lab units inconsistent after vendor feed

Scenario

Potassium values from one site’s local laboratory, loaded through a vendor interface, come out about four times lower than typical once converted to the standard unit.

What the code checks

• Join lab results to the unit dictionary; verify expected unit for analyte.
• Convert to a standard unit; flag implausible converted results (e.g., K+ = 1.1 mmol/L).
• Group by site to highlight clustering.

Illustrative listing

What to ask

For the vendor: “Confirm mapping for Potassium at site 1012 (mg/dL observed). Expected mmol/L per spec. If the mapping is wrong, please correct it and re‑send the affected records.”

For the site (if site‑entered labs): “Confirm reported unit on lab printouts; update unit where necessary.”

What SDV/SDR covers

Loaded results are not routinely source‑verified, but here the CRA makes a targeted check of the local lab’s reports in the site’s source and verifies the unit shown (mmol/L). Documents whether transcription or vendor mapping caused the issue.

Root‑cause & fix

• Root cause: unit mapping error in the lab interface configuration: results reported in mmol/L were labelled mg/dL, so the conversion divided them by about 3.9.
• Fix: vendor corrects mapping and resends a delta load; CDM re‑runs conformance checks; add a pre‑ingestion unit sanity check to the pipeline.

Example 3 — Visit window & duplicate assessments

Scenario

Two ECGs exist for the same visit and timestamp; one has missing heart rate.

What the code checks

• Identify duplicate keys (Subject + Visit + Datetime + Procedure).
• Flag duplicates and nulls on critical fields.
• Verify the visit is within the protocol window for that timepoint.

Illustrative listing

What to ask

“Two ECG records share the same visit and time. Please confirm which record is correct and mark the other in error (it stays in the audit trail). If two ECGs were intended, please differentiate by time or ‘repeat’ indicator and complete heart rate.”

What SDV/SDR covers

CRA checks printouts to see whether one reading failed quality control or was a repeat due to a poor trace; confirms which record is valid.

Root‑cause & fix

• Root cause: staff saved two drafts and later completed one.
• Fix: enable on‑form duplicate detection; add site tip: “Use Repeat # field for valid repeats.”

Pitfalls & misconceptions

• “SDV replaces programmatic review.” It doesn’t. SDV checks fidelity of individual records; it rarely finds cross‑subject or cross‑form patterns.
• “Programmatic review is just listings.” Not if done right. Findings must translate into actionable queries, routing, and follow‑ups.
• “More SDV is always better.” Unfocused 100% SDV burns time and misses systemic issues; use risk‑based coverage.
• “Edit checks make programmatic review unnecessary.” Edit checks, at entry or in batch, test fixed rules within one subject’s data; programmatic review also finds patterns across subjects and sites and over time (trends, clusters, the same error repeated).
• “Data management always reviews before monitors.” The reason CDM often leads is that code surfaces systematic discrepancies early; order should follow the risk signal, not rigid hierarchy.
• Neglecting closure quality. Fast closure without verification leads to ping‑pong queries and rework; always run post‑resolution QC on a sample of closed queries.

Practice in the wild (checklist)

• Keep review scripts in version control with change notes and run logs.
• Tag each finding with risk (safety / endpoint / operational) and owner (site, vendor, internal).
• Use standard query templates with neutral language and precise context.
• Route vendor issues (mappings, loads) outside site workload; don’t “site‑query” what a pipeline should fix.
• Track found‑by (programmatic vs SDV/SDR) to learn where to invest effort.
• Maintain a data issue register for recurring patterns and their fixes.
• Sample closed queries monthly for correctness and documentation quality.
• Refresh training when the same pattern appears in ≥2 sites or ≥3 subjects.
• Add or tune edit checks only after testing the rule on existing data to see how many false positives it would raise.
• Re‑run key listings before lock and document “all clear” snapshots.

Key points to remember

• Distinct roles, complementary tools. Programmatic review is code‑driven, cross‑record pattern detection at scale; SDV/SDR verifies alignment to source and captures context via site coaching. Use them together.
• Risk first. Prioritize safety‑ and endpoint‑critical checks; expand to operational quality next.
• Use each where it fits best. Programmatic review for patterns (e.g., unit mapping, temporal/date logic, cross‑form mismatches); SDV/SDR when truth or context resides only in source or when a site needs training.
• Turn findings into routed action. Convert listings into clear, non‑leading queries and route to the correct owner (site vs vendor/internal). Don’t “site‑query” issues that stem from specifications, mappings, or loads.
• Measure closure quality, not just speed. Track both timeliness and correctness of resolutions; perform independent post‑resolution QC on a sample to verify fixes and documentation.
• Roles & collaboration. CDM leads programmatic review to surface systemic issues early; CRAs lead SDV/SDR at sites. Neither replaces the other.
• Close the loop. Feed recurring patterns into updated rules, training refreshers, the monitoring plan and DMP, and edit checks; re‑run key listings before lock and document the “all‑clear.”