The short version
- The purpose of a dry run is to find the problems that lock would otherwise find, while there is time to fix them.
- "All programs ran without errors" is the least informative result a dry run can produce.
- Define in advance what the run must prove, and triage every finding into one of four classes with an owner and a date.
What the dry run is for
ICH E9 describes a blind review: checking and assessing the data between the end of the trial and the breaking of the blind, so that decisions about the analysis, such as which subjects belong in which population and how to handle missing values, are finalized before anyone sees results by treatment [1]. A dry run is the operational vehicle for that review. It runs the planned outputs on current, blinded or dummy-randomized data so that statisticians, data managers and programmers can see what the final run will look like.
If the dry run only checks that the code executes, it tests the part of the work that is easiest to fix later. The expensive surprises at lock are data issues, open decisions and unrealistic timing, and a dry run can find all three.
What a dry run should prove
Agree these five statements with the study statistician before the run, and judge the run against them afterwards.
- The data cut is realistic. It includes every source the final run will use, including external vendor data, and is as close as possible to final completeness.
- Every population and derivation rule is decided. Each population flag can be produced from a written rule. Rules that need a judgment are listed with an owner.
- The high-risk outputs were reviewed by a person. Primary and key secondary efficacy, disposition and the main safety tables were read for sense, not only checked for errors.
- Data issues went back to source. Findings that are data problems became queries, not code workarounds.
- The timeline was rehearsed. The team measured how long the end-to-end run, QC and review took, and that figure is used to set the final run's dates.
Traceability helps with the second and fourth points. When analysis datasets record which source records and variables each derived value came from, a reviewer can follow a strange value back to its origin quickly [2].
Triage the findings
Every finding goes into one class, with an owner and a latest acceptable date.
| Class | Example | Owner | Must close by |
|---|---|---|---|
| Data issue | Missing adverse event start dates | Data management | Before the last data query cycle |
| Decision needed | Whether a protocol deviation excludes a subject from per-protocol | Statistician and clinical lead | Before the population sign-off |
| Programming defect | A wrong visit window in a lab table | Programming | Before final QC |
| Presentation | Footnote wording, decimal places | Programming with statistics | Before the final run |
The data issues and decisions are the important ones, because they are the ones a late fix cannot absorb. A risk-proportionate approach to quality, which ICH E6(R3) expects, means spending review effort where an error would change a conclusion [3].
A synthetic example
The fictional ZEPHYR-101 dry run produces 61 findings. Forty are presentation issues, nine are programming defects, eight are data issues and four are decisions. Sorting them by class changes the conversation: instead of "61 findings, we are behind", the study lead hears "four decisions need owners this week, and eight queries must go out in the next cycle". The presentation issues are batched for the final run.
Do this today
- Write down the five statements your next dry run must prove and share them with your statistician before the run.
- Add a class, an owner and a latest acceptable date to every open dry-run finding.
- Record how long the last end-to-end run, QC and review took, and use that figure in the lock plan.
Check yourself
One question
Show the answer
Answer 2. The dry run's job is to surface data issues and open decisions while they can still be fixed at source or decided on paper. Changing code to make outputs run hides the question; excluding records hides the data.
Apply it
Turn it into a plan
The brief says what to check. The Navigator and the Handbook turn it into dated, owned actions for your milestone, in your browser, with no study data.
Sources
References
- ICH. E9 Statistical Principles for Clinical Trials. Step 4, 1998. www.ich.org ↗
- CDISC. Analysis Data Model Implementation Guide (ADaMIG) version 1.3. www.cdisc.org ↗
- ICH. E6(R3) Guideline for Good Clinical Practice. International Council for Harmonisation; 2025. www.ich.org ↗
Standards and guidance change. Confirm the version in force for your study, sponsor and region before relying on any reference. Examples are synthetic and illustrative. This brief is generalized professional guidance, not regulatory advice.
Next brief · Wednesday 10:00 ET · Reviewer's Eye