Database Lock to DSMB Meeting Pushing a button well takes 2-4 weeks Kevin A. Buhr Director, University of Wisconsin Statistical Data Analysis Center

Our Group University of Wisconsin Statistical Data Analysis Center (SDAC) Independent statistical support for DMC-monitored industry trials (mostly Phase 3) Variety of large (programs w/ 5-15 trials; large CV trials with ~10000 subjects) and small projects (n=30, 2-week intervention in orphan disease)

DMC Requirements The DMC wants a report that is: Current Correct Complete Comprehensible Customizable to evolving requirements No single requirement dominates all the others; they all are important.

Importance of Data Currency Recent, typical project: Two Phase 3 trials, 4-5 years, n=11000 DMC teleconference 2-3 times per year DMC report distributed one week in advance Delay from data transfer to DMC TC Range 2.5-7.5 weeks, median 3.5 weeks Report delivered one week before TC

Importance of Data Currency Typical evolution of a potential safety signal (or, in this case, “non-signal”), as actually reported: Note: results simulated based on actual distribution.

Importance of Data Currency Theoretical “perfect” reporting: All events captured on date of occurrence Snapshot/report generated day of DMC meeting DMC happy to review in an hour or two So, “unattainable”

Data Currency in Perspective Comparison of actual and “perfect” data:

Data Currency in Perspective Early in trial Signal is sensitive to additional data Signal is also sensitive to sampling error and random noise Degree of uncertainty is very high Later in trial Signal has stabilized Even in context of ongoing rapid enrollment, 3-5 weeks worth of additional data will rarely materially change results This doesn’t mean data currency is unimportant, but that it can and should be balanced against other requirements.

EDC Effect on SDAC Workflow Currency of data has little effect on SDAC workflow Before and after EDC, we received SAS snapshots Improved data quality doesn’t materially increase our efficiency Defensive programming Validation Isn’t particularly easier w/ 5 errors versus 500 errors

CDISC for Interim Reporting Problems solved by SDTM were never serious bottlenecks in our workflow: Standardizing names and formats for variables Specification of trial metadata (epochs, etc.) Adapting existing analysis code to new project These are “fixed cost” (and generally low cost) items for interim reporting

What Does Speed the Process? In our experience, we’ve had good luck with: Regular, frequently, as-is data transfers (e.g., monthly) A strong build system (e.g., draft reports for multi-protocol projects built within hours of new data transfer) An agile, continuous integration workflow Statistician-programmers with soup-to-nuts responsibility for blocks of content Nonetheless, we consider a reasonable snapshot-to-distribution timeline to be measured in weeks, not days.

Backup

EDC Effect on Overall Process Compared to days of paper CRFs: Data are far more current/up-to-date EDC eliminates many classes of errors, though introduces some new ones EDC streamlines query resolution process Facilitates frequent, as-is snapshots Large net positive effect on data currency and quality

CDISC for Interim Reporting CDISC SDTM is mixture of: Extreme inflexibility (no extra variables allowed) Extreme flexibility (FA domain, SUPP* domains, RELREC mechanisms) Compared to a direct mapping of eCRF to a “raw” dataset, SDTM: Obscures traceability (particularly if mapping contains some errors or relies on perfectly clean data) Obscures investigator “intention” where data are inconsistent We may waste time “unmapping” SDTM to original form Often, SDTMs often not ready early enough May need to start with raw and switch to SDTM

SDAC Workflow Receipt of new data Data checking / dataset exploration Data preprocessing Analysis dataset creation Graphical and tabular presentation Report compilation Quality assurance

Programming Ahead vs. Behind In our experience, report programming is an ongoing process: