The short version
- Independent double programming means a second programmer writes their own code from the specifications and the results are compared. It is the strongest routine check, and the most expensive.
- Applying it to every output roughly doubles programming effort and stretches the timeline without making the important outputs any safer.
- Classify outputs by the consequence of an error, then match the QC method to the class.
Why not double program everything
ICH E8(R1) asks studies to identify the factors critical to quality, those whose failure would affect participant safety or the reliability of results, and ICH E6(R3) asks for quality management proportionate to the risks to them [1, 2]. Applying the same heavy check to a listing and to the primary analysis is the opposite of proportionate. It also has a capacity cost that shows up as delay: a team loaded close to full has long queues, and QC is usually where the queue forms [3].
The arithmetic
Take a synthetic deliverable of 120 outputs. Suppose a production program takes 6 hours on average, independent programming of the same output 5 hours plus 1 hour to compare and resolve, and a structured peer review 1.5 hours.
| QC approach | Production | QC | Total hours |
|---|---|---|---|
| Double program all 120 | 720 | 720 | 1,440 |
| Risk-based: 25 high, 45 medium, 50 low | 720 | 25 × 6 + 45 × 1.5 + 50 × 0.5 = 242.5 | about 963 |
The risk-based plan saves roughly 475 hours, about twelve weeks of one programmer, and spends its full independent effort on the 25 outputs where an error would change a conclusion. The figures are illustrative; your own hours come from your own completed work.
A simple classification
| Class | Typical outputs | QC method |
|---|---|---|
| High | Primary and key secondary efficacy, analysis datasets behind them, key safety summaries, anything in a label or a regulatory response | Independent double programming of the dataset and the output, with documented comparison |
| Medium | Other efficacy and safety tables, derived parameters | Independent programming of the key numbers, or structured peer review of code and output |
| Low | Listings, displays of collected data, outputs reconciled elsewhere | Review of the specifications and a sample check of the output |
Two refinements make it work. First, classify the analysis datasets, not only the tables: an error in an analysis dataset propagates to every output that uses it. Second, promote an output to a higher class when it is new, unusually complex, changed late or produced by someone new to the study.
What double programming does not catch
Two programmers reading the same unclear specification can make the same mistake. Independent programming checks the implementation, not the specification. That is why the high class also needs a statistician to read the output for sense, and why ambiguous specification text should be resolved in writing before either programmer starts.
A synthetic example
The fictional ZEPHYR-101 team classifies its 120 outputs at the start of programming. During the dry run, a late change to the visit windows promotes four medium outputs to high. The plan absorbs it because the classification and its rules were written down, and the extra 18 hours are visible in the capacity estimate rather than discovered in the last week.
Do this today
- Classify your next deliverable's analysis datasets and outputs into high, medium and low, with a one-line reason for each high.
- Write the promotion rules: new, complex, changed late or new programmer.
- Put the QC hours for each class into your capacity estimate and compare with the hours you actually have.
Check yourself
One question
Show the answer
Answer 2. An error in the primary efficacy analysis could change the main conclusion of the study, so it earns the most independent checking. A listing is a direct display of data, and a count that is reconciled elsewhere already has an independent check.
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. E8(R1) General Considerations for Clinical Studies. Step 4, 2021. www.ich.org ↗
- ICH. E6(R3) Guideline for Good Clinical Practice. International Council for Harmonisation; 2025. www.ich.org ↗
- Reinertsen DG. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing; 2009.
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 · Friday 10:00 ET · Failure Friday