Chapter 15 / Managing the Clinical Trial Lifecycle / Paid beta preview

Chapter 15: Data Cleaning, Database Lock, Analysis, and CSR

How data cleaning, database lock, analysis, and CSR convert conduct into evidence. ## Participant Visits Are Over, But The Trial Is Not DIAB-220 reached last patient last visit, or LPLV, on a Thursday afternoon. The final participant completed the final protocol-required visit, the study team sent polite congratulations, and Lauren Brooks let herself believe, briefly, that the hard part had ended. LPLV ends planned participant visits. It does not finish the trial's operational, analytical, reporting, records, or decision story. On Friday morning, Priya Raman's data-cleaning dashboard arrived. There were 180 open electronic data capture (EDC) queries, 35 older than 30 days, several involving Week 12 HbA1c values and adverse-event stop dates. The electronic clinical outcome assessment (eCOA) vendor still showed missing diary files after Month 2 for several participants. The central lab had two transfer exceptions. The interactive response technology system (IRT) did not agree with the final drug return record for one site. The safety database had an unresolved serious adverse event reconciliation item. Monitoring reports still listed two unresolved findings tied to source documentation. The clinical research organization (CRO) summary said, "Most data are entered." Victor Stein, Senior Director of Data Management and Clinical Systems, looked at Lauren and said, "Entered is not the same as clean." Data cleaning means identifying, querying, reconciling, correcting, documenting, and closing data issues according to the data management plan, edit checks, review listings, reconciliation rules, and accountable review processes. It is not a clerical sweep after the trial. It is the controlled conversion of trial conduct into analyzable, traceable evidence. Chapter 14 showed that conduct problems do not stay politely inside conduct. Missed visit windows, late adverse event entries, eCOA gaps, IRT mismatches, monitoring findings, participant-status ambiguity, and drug accountability questions all become data, lock, analysis, and clinical study report problems. Lauren's first question was, "When will Data Management lock the database?" Maggie Chen corrected it: "What evidence proves the database is lock-ready?" ## The LOCKED Frame Maggie gave Lauren a new frame: | Letter | Meaning | PM Question | |---|---|---| | L | Listings And Line Checks | What issues are visible in listings, dashboards, and review outputs? | | O | Open Queries And Ownership | Which queries remain open, who owns them, and which affect CTQs? | | C | Cross-System Reconciliation | Do EDC, safety, lab, eCOA, IRT, monitoring, and TMF records agree? | | K | Key Data Readiness | Are primary endpoint, safety, eligibility, exposure, and disposition data ready? | | E | Evidence Handoff To Analysis | Has Biostatistics received analysis-ready data with assumptions documented? | | D | Document The Story In The CSR | Does the CSR explain conduct, data, deviations, analysis, and results clearly? | Critical-to-quality [ICH E8(R1)] factors, or CTQs, are the trial features most important to participant protection and reliable results. In the lock period, CTQs show up as questions: are primary endpoint values complete, are safety events reconciled, are participant statuses precise, are treatment exposure records consistent, and are protocol deviations classified before analysis? Database lock is not a ceremony that makes data true. It is a controlled milestone showing that data are sufficiently cleaned, reconciled, reviewed, and approved under defined procedures for planned analysis. Clean does not mean perfect. Clean means reviewable, traceable, decision-ready, and honestly documented. ## The Data Flow Priya showed Lauren why EDC was not "the database" in the full practical sense. | Stream | Plain Meaning | Why It Matters Before Lock | |---|---|---| | Source records | Original records or first-captured information at the site | Support the trial data and monitoring review | | EDC | Electronic data capture system for case report form data | Holds much collected clinical data, but not every external stream | | eCOA | Electronic tool for participant-, clinician-, or observer-reported outcomes | Missing entries may affect endpoint quality or participant-burden interpretation | | Central lab data | Lab results transferred from a central vendor | Must match participants, visits, dates, units, and expected transfers | | IRT | Randomization and supply system | Supports treatment assignment, dispensing, exposure, and drug accountability | | Safety database | Safety system for adverse events and serious adverse events | Must reconcile with EDC and source safety information | | Medical coding | Standardized coding of events, history, and medications | Enables consistent safety and medication summaries | | Analysis datasets | Structured datasets prepared for planned analyses | Not raw EDC exports; they reflect standards, derivations, and SAP rules | | TLFs | Tables, listings, and figures from analysis datasets | Become core outputs for review, interpretation, and reporting | | CSR | Clinical study report | Integrated account of design, conduct, participants, safety, efficacy, data, and interpretation | An edit check is a programmed or configured rule that flags missing, inconsistent, or impossible data. A manual query is a question raised by Data Management or another reviewer when data need clarification. Query aging is the length of time a query remains open. Old queries can signal site overload, unclear source records, weak CRO follow-up, or a

...