Last reviewed: October 31, 2025

In Part 1, we set the foundations. In Part 2, we cover Topics 6–10 of your itinerary—what most teams rely on to keep trials safe, analysis‑ready, and inspection‑proof:
- 6 — Reconciliation & Traceability
- 7 — Standards & Coding
- 8 — Database Lock & Inspections
- 9 — Safety & Endpoint Management
- 10 — Study Communications & Dashboards
Below you’ll find concise overviews, “how it works” checklists, and links to our five chapters per topic (each with a 2–3 line description) plus a podcast placeholder you can fill later. We removed inline footnote markers as requested and consolidated sources at the end.
Topic 6 — Reconciliation & Traceability
Why it matters. Multiple systems (EDC, labs, ECG, IVRS/IWRS, PV) must line up. Reconciliation ensures records exist where they should (presence), refer to the same thing (identity), are aligned in time (timing), and agree in value (after normalization). Traceability lets you prove where each value came from and what changed on the way in.
Must‑knows (exam & job).
- Define the grain (unit of comparison) and keys up front; mismatched grains create phantom discrepancies.
- Normalize units, time zones, date/time formats, and codes before comparing.
- Use a full‑outer‑join comparison to classify issues into presence / identity / timing / value.
- Route each discrepancy to a clear owner with SLAs (site vs. vendor vs. DM).
- Preserve immutability (as‑received files), compute checksums, and carry lineage fields (e.g.,
source_file_name,load_id,algorithm_version) into curated tables and outputs.
Process at a glance.
- Declare grain & keys → 2) Structural conformance (fail‑closed) →
- Normalize → 4) Compare (full outer) → 5) Classify & route →
- Resolve & log → 7) Trend & prevent.
What “good” looks like.
- One‑page Recon Spec (grain, keys, SoT, tolerance windows, routing).
- Automated comparisons with counts by bucket; a rolling recon log.
- Immutable archive of vendor deliveries + supersession (never overwrite).
- Lineage fields available in listings/exports so analysts can backtrace.
📘 Chapters & podcast
- Ch. 1 — Central lab vs. CRF How to pick source‑of‑truth by field, reconcile lab feeds with site‑entered data, and route issues quickly. Read chapter · Listen
- Ch. 2 — As‑received & immutability Build the “landing zone”: checksums, retention/permissions, fail‑closed conformance logs. Read chapter · Listen
- Ch. 3 — Reconciliation patterns Presence/identity/timing/value patterns with decision tables and examples (outer‑join mindset). Read chapter · Listen
- Ch. 4 — CRF↔DB audits What to sample, how to read EDC audit trails, and when to escalate to QA. Read chapter · Listen
- Ch. 5 — Recon gates to lock The last‑mile checklist and dashboards for “100% presence, value mismatches resolved/explained.” Read chapter · Listen
Topic 7 — Standards & Coding
Why it matters. Standard structure (CDASH/CDISC), codelists, and dictionaries (MedDRA, WHO‑Drug) make data combinable, comparable, and analyzable. Coding translates verbatims into stable concepts; version control keeps counts from drifting.
Must‑knows (exam & job).
- MedDRA hierarchy: LLT → PT → HLT → HLGT → SOC; use Primary SOC for standard tables; understand multi‑axiality.
- Coding practice: capture clear verbatims; query if ambiguous; code to the best‑fit LLT; store dictionary name + version on each record.
- Controlled terminology: standardize units, visit names, picklists at entry, not in late ETL.
- Versioning & change control: freeze dictionary version for milestones; assess impact before upgrades.
What “good” looks like.
- 100% coded AEs/meds, versioned dictionaries, coder conventions + QC evidence.
- Sponsor codelists (units/visits/test codes) applied at EDC and vendor ingestion.
- Pooled analyses planned against a single target dictionary version.
📘 Chapters & podcast
- Ch. 1 — MedDRA hierarchy essentials Practical LLT/PT/SOC use, multi‑axiality, and Primary SOC rules for tables. Read chapter · Listen
- Ch. 2 — Coding workflows, QC & change Coder conventions, dual‑coding/QC, impact logs, and controlled upgrades. Read chapter · Listen
- Ch. 3 — Auto‑coding & phrasing Improve auto‑match with clean verbatims; when to expand abbreviations vs. query. Read chapter · Listen
- Ch. 4 — Codelists & controlled terminology CDASH‑aligned picklists, unit standards, and vendor code mapping. Read chapter · Listen
- Ch. 5 — Global studies & language coding Cross‑language consistency, spelling variants, and translations. Read chapter · Listen
Topic 8 — Database Lock & Inspections
Why it matters. Lock is a process, not a button. Clear gates (expectedness, queries, recon, coding, adjudication, derivations) deliver an analysis‑ready cut and a package you can defend months or years later.
Lock readiness gates (typical).
- Expectedness (critical forms present ≈ 98–100% with rationale for any misses).
- Query backlog/aging (zero critical; stale tails addressed).
- External recon (100% presence; mismatches cleared/explained).
- Coding complete (final dictionary version frozen).
- Endpoint adjudications (complete).
- Derived variables (algorithms frozen & validated).
Execution.
- Start dry runs 6–12 weeks pre‑LPLV; weekly burndown + owner list; formal escalation ladder.
- Lock ceremony: freeze, sign‑offs, final extracts with checksums, audit‑trail snapshot, archive index.
- Post‑lock governance: decision tree for late discoveries (unlock vs. annotate), all changes documented.
📘 Chapters & podcast
- Ch. 1 — Lock‑readiness dashboard RAG definitions for expectedness, queries, recon, coding, adjudication, derivations. Read chapter · Listen
- Ch. 2 — Lock rehearsal & ceremony Mock cuts, timing checks, sign‑off sequence, and sealing the package. Read chapter · Listen
- Ch. 3 — Inspection‑readiness packets What inspectors ask for; building a curated, findable evidence pack. Read chapter · Listen
- Ch. 4 — Post‑lock discoveries Impact assessment → approve → change → re‑lock, with auditability. Read chapter · Listen
- Ch. 5 — Timelines & surge management Backlog math, forecasting time‑to‑green, and sizing the end‑game. Read chapter · Listen
Topic 9 — Safety & Endpoint Management
Why it matters. Endpoints drive what you collect and how you clean; safety workflows protect patients and compliance. Confusing seriousness (regulatory outcome) with severity (intensity) is a classic trap—design your CRFs and checks to keep them distinct and to notify PV fast.
Endpoint‑first build.
- Extract endpoint definitions → map minimal variables & conditions (e.g., posture/rest for BP) → convert SoA to an expectedness matrix with windows and unscheduled mapping rules → design CRFs, route adjudication, add focused checks (presence, timing, cross‑form).
Safety flow.
- AE CRF captures serious? + criteria → immediate PV notification (systemic or procedural).
- SAE reconciliation (EDC ↔ PV) on cadence; clean dates quickly for expedited timelines.
- Protect blinding: unblinded safety roles only where necessary; log treatment access.
📘 Chapters & podcast
- Ch. 1 — Serious vs. severe (SAE basics) Train sites on the distinction; configure forms and alerts accordingly. Read chapter · Listen
- Ch. 2 — Endpoint‑first CRF design From protocol text → concrete fields, windows, and checks that serve analysis. Read chapter · Listen
- Ch. 3 — Adjudication & blinding governance Roles, listings, and auditability for committee decisions (without leaks). Read chapter · Listen
- Ch. 4 — SAE reconciliation with PV Compare lists, resolve discordance, and show proof by lock. Read chapter · Listen
- Ch. 5 — Safety tables, narratives & labeling Coding choices that influence roll‑ups and narrative consistency. Read chapter · Listen
Topic 10 — Study Communications & Dashboards
Why it matters. Clear, routine communication turns metrics into action. Dashboards surface expectedness, entry lag, query rate & aging, backlog burndown, attrition, and site performance—with owners, due dates, and escalation triggers.
From monitoring to action.
- Weekly rhythm: fixed refresh → 15‑minute huddle on reds/ambers → 48–72 h root‑cause → intervention plan (target date to green) → follow‑up and governance‑aligned escalation.
- Tailor views to the audience: executive, ClinOps/CRAs, and sites (e.g., “report cards” with actionable lists).
Common pitfalls. Information overload, stale data, orphaned metrics (no owner), and blame‑centric cultures. Keep it small, current, and solution‑oriented.
📘 Chapters & podcast (Topic 14 in the library)
- Ch. 1 — DM status cadence & operating rhythm The weekly operating loop: refresh, huddle, assign, follow‑up. Read chapter · Listen
- Ch. 2 — KPI definitions (lock & interim) What to track, thresholds, and how to compute them consistently. Read chapter · Listen
- Ch. 3 — Stakeholder views (exec/ClinOps/site) Same data, different slices—keep each audience focused and productive. Read chapter · Listen
- Ch. 4 — Query aging & backlog playbook Root‑cause categories (People/Process/Tech/Protocol) and interventions. Read chapter · Listen
- Ch. 5 — Insights, storytelling & change notes Turn plots into plans; track “time‑to‑green” and note changes. Read chapter · Listen
What’s next (Part 3 preview)
We’ll close the loop with archiving & retention, audit/inspection playbooks, and validation & release governance—so you can reproduce any result years later and pass inspections with confidence.
Consolidated sources (selected)
Standards & guidance
- Good Clinical Data Management Practices (GCDMP) — Full compendium. Database closure/lock, metrics, external data, SAE reconciliation, and inspection readiness chapters. Society for Clinical Data Management (scdm.org).
- Medical Coding Dictionary Management & Maintenance (SCDM, 2024). Governance for MedDRA/WHO‑Drug use, versioning, and upgrades in studies and pooled analyses.
- Safety Data Management & Reporting (SCDM, 2024). Site capture, seriousness vs severity, PV timelines, reconciliation, and submission‑readiness.