How to Write a Statistical Analysis Plan (SAP)

Introduction

A Statistical Analysis Plan, or SAP, is the document that translates the statistical objectives of a clinical trial into a detailed, prespecified plan for analyzing the study data.

The protocol explains why the study is being conducted and the high-level design. The SAP explains, in operational statistical detail, how the data will be analyzed.

A good SAP should be specific enough that two independent statisticians could implement the planned analyses and arrive at essentially the same primary results. It should also be written before database lock and before the unblinded analysis of the data that could influence the choice of methods.

Key idea: An SAP is not merely a list of statistical tests. It is the prespecified bridge between the protocol's objectives, the estimand, the analysis populations, the analysis datasets, the statistical methods, and the final tables, listings, and figures.

Where the SAP Fits in the Clinical Trial

The SAP sits inside a larger chain of study planning and reporting. A useful way to visualize the relationship is:

Protocol: defines the clinical question, study design, endpoints, treatment arms, and high-level statistical objectives.

Estimand: defines the treatment effect of interest, including the population, treatment condition, variable, handling of intercurrent events, and summary measure.

SAP: specifies exactly how the estimand and protocol objectives will be estimated and tested.

Programming specifications: translate the SAP into dataset, variable, derivation, and output-level instructions.

TLFs: implement the prespecified analyses as tables, listings, and figures.

Clinical Study Report: presents and interprets the results generated from the prespecified analyses.

What Makes an SAP Different From the Protocol?

The protocol and SAP should be consistent, but they serve different purposes. The protocol generally contains the essential design and statistical principles needed to understand the trial. The SAP expands those principles into implementation-level detail.

Topic	Protocol	SAP
Primary endpoint	Defines the endpoint	Defines derivation, analysis window, handling of missing assessments, and statistical method
Analysis population	Describes intended population	Provides detailed inclusion/exclusion rules and treatment assignment conventions
Primary analysis	States high-level method	Specifies model, covariates, contrasts, estimand, confidence interval, test, and implementation details
Missing data	May provide general principles	Defines exact handling rules and sensitivity analyses
Outputs	Usually limited	Maps analyses to tables, listings, and figures

Practical rule: If an important analytical decision is left to be made after database lock, the SAP is probably not specific enough.

The Core SAP Structure

There is no single universal SAP table of contents that applies to every trial. However, most production SAPs contain the following major components.

Section	Purpose
1. Introduction	Study background, objectives, scope, and relationship to the protocol
2. Study Design	Design, treatment arms, randomization, blinding, visits, and key design features
3. Estimands	Definition of the treatment effects that the trial seeks to estimate
4. Analysis Populations	ITT/FAS, per-protocol, safety, PK, biomarker, and other populations
5. General Statistical Considerations	Significance level, confidence intervals, rounding, baseline, multiplicity, software, and conventions
6. Disposition and Demographics	Enrollment, disposition, protocol deviations, and baseline characteristics
7. Efficacy Analyses	Primary, secondary, exploratory endpoints and estimators
8. Safety Analyses	Exposure, adverse events, laboratory data, vital signs, ECGs, and other safety parameters
9. Other Analyses	PK, PD, immunogenicity, biomarkers, patient-reported outcomes, or other study-specific analyses
10. Sensitivity and Subgroup Analyses	Robustness and clinically important subgroup assessments
11. Interim Analyses	Any planned interim looks, decision rules, and information controls
12. TLF Specifications	Mapping of planned analyses to tables, listings, and figures
13. Appendices	Derivations, shells, algorithms, definitions, and additional technical details

Step 1: Start With the Protocol, Not With the Tables

One of the most common SAP-writing mistakes is to begin by copying an old SAP and replacing the study name, treatment names, and sample size.

Instead, begin by extracting the study's statistical architecture from the protocol:

Primary objective
Key secondary objectives
Primary and secondary endpoints
Analysis time points
Treatment comparisons
Randomization and stratification factors
Sample-size assumptions
Interim analyses
Multiplicity strategy
Important protocol-defined estimands or intercurrent events

Then compare the protocol with the statistical sections of the SAP as you write. The SAP may clarify details, but it should not silently create a different primary objective or change the fundamental design.

Step 2: Define the Estimand Before Choosing the Model

Modern clinical-trial analysis should begin with the treatment effect of interest, not simply with a statistical model.

An estimand can be represented conceptually as:

\text{Estimand} = (\text{Population}, \text{Treatment}, \text{Variable}, \text{Intercurrent Events}, \text{Summary Measure})

For example, suppose a randomized trial compares Treatment A with placebo on change from baseline in systolic blood pressure at Week 12. The SAP should make clear whether the target effect is defined for all randomized patients, what happens if patients discontinue treatment, and whether the target is a treatment-policy effect, hypothetical effect, while-on-treatment effect, or another strategy.

Why this matters: Two analyses can use the same endpoint and the same regression model but answer different clinical questions if they handle intercurrent events differently.

Step 3: Define the Analysis Populations

The SAP should provide explicit, operational definitions for every analysis population used in the study.

Population	Typical Purpose
Full Analysis Set / ITT	Primary efficacy analysis according to the prespecified estimand and randomized treatment assignment
Per-Protocol Set	Supportive efficacy analysis among participants meeting predefined protocol-adherence criteria
Safety Set	Safety analyses based on participants who received study treatment according to the prespecified convention
PK Set	Participants with sufficient evaluable pharmacokinetic data for the planned PK analysis
Biomarker Set	Participants with valid samples or measurements required for the biomarker analysis

Avoid vague statements such as "patients with adequate data will be included." The SAP should define what "adequate" means.

Example: Full Analysis Set

A sufficiently detailed definition might state that the Full Analysis Set includes all randomized participants, analyzed according to randomized treatment assignment, subject to any prospectively defined exceptions.

The important point is not the specific wording. It is that the rule is deterministic and reproducible.

Step 4: Define the Analysis Variables

For each endpoint, specify exactly what variable will enter the statistical analysis.

For a continuous endpoint, this often includes baseline, post-baseline value, change from baseline, and the analysis visit.

\Delta_i = Y_{i,\text{post}} - Y_{i,\text{baseline}}

For a binary endpoint, specify the responder definition, the assessment window, and the rule for patients without an evaluable assessment.

For a time-to-event endpoint, specify the event definition, censoring rule, time origin, and analysis window.

Endpoint Type	Items the SAP Should Define
Continuous	Baseline, post-baseline value, change, visit window, transformation, units
Binary	Responder definition, denominator, assessment window, missing-response rule
Time-to-event	Event, censoring, time origin, competing events if relevant, analysis cutoff
Count	Counting window, event definition, exposure offset, distribution/model
Repeated measures	Visit structure, covariance model, baseline, fixed effects, estimand

Step 5: Define Baseline Precisely

"Baseline" sounds simple, but it can be one of the most consequential derivation rules in an SAP.

A common definition is the last nonmissing assessment obtained before the first dose of study treatment:

Y_{i,\text{baseline}} = \text{last evaluable value before first dose}

However, the actual study may require a different rule. The SAP should specify the timing window, whether unscheduled assessments are eligible, what happens when multiple measurements occur on the same date, and what happens when no qualifying baseline measurement exists.

Do not write: "Baseline will be defined according to standard conventions."

Write: the actual deterministic rule that a programmer can implement without asking the statistician what was intended.

Step 6: Define Visit Windows and Analysis Time Points

Clinical trials rarely collect every measurement at exactly the nominal visit day. The SAP therefore needs rules for assigning observations to analysis visits.

A visit-window specification should address:

Nominal target day
Lower and upper bounds of the window
Priority when multiple observations fall within a window
Handling of unscheduled assessments
Rules for observations that fall into overlapping windows
Whether the same observation can be used in more than one analysis

For example, an SAP might define a Week 12 analysis window around the target study day and specify that the observation closest to the nominal day is used when multiple qualifying assessments are available.

Step 7: Specify the Primary Analysis in Full

The primary endpoint deserves the most precise statistical specification in the SAP.

A complete primary-analysis section should normally identify:

Analysis population
Endpoint definition
Analysis time point
Estimand
Statistical model or test
Covariates
Treatment contrast
Effect measure
Confidence interval
Hypothesis test and significance level
Handling of missing data
Sensitivity analyses

Example: ANCOVA

Suppose the primary endpoint is change from baseline in a continuous outcome at Week 12. A possible primary model is:

Y_i = \beta_0 + \beta_1 T_i + \beta_2 B_i + \beta_3 S_i + \varepsilon_i

where \(Y_i\) is the Week 12 outcome or change from baseline as specified by the estimand, \(T_i\) is treatment, \(B_i\) is baseline value, and \(S_i\) represents a prespecified stratification factor or other covariate.

The SAP should identify the treatment contrast of interest rather than merely saying "ANCOVA will be used."

Weak SAP: "An ANCOVA will be performed adjusting for baseline."

Strong SAP: specifies the dependent variable, treatment factor, baseline covariate, additional prespecified covariates, estimand, contrast, confidence interval, and inference rule.

Step 8: Specify Binary Endpoint Analyses

For a binary primary endpoint, the SAP should define both the response variable and the statistical comparison.

If \(R_i=1\) denotes response and \(R_i=0\) denotes nonresponse, the response rate can be written as:

\hat p = \frac{\sum_i R_i}{N}

Possible treatment comparisons include a risk difference, risk ratio, odds ratio, or model-based adjusted treatment effect.

Effect Measure	Interpretation
Risk difference	\(p_A-p_C\)
Risk ratio	\(p_A/p_C\)
Odds ratio	\(\{p_A/(1-p_A)\}/\{p_C/(1-p_C)\}\)

The SAP should also state how confidence intervals are constructed and how patients without an evaluable endpoint are handled.

Step 9: Specify Time-to-Event Analyses

For time-to-event endpoints, "Kaplan-Meier analysis" is not a sufficient SAP specification by itself.

The SAP should define:

Time origin
Event definition
Censoring rules
Analysis cutoff
Primary estimator or model
Stratification factors, if applicable
Effect measure
Confidence interval
Handling of competing events when relevant

For example, a Cox model may be expressed as:

h_i(t) = h_0(t)\exp\left(\beta T_i+\gamma^\top Z_i\right)

The treatment effect is commonly summarized using the hazard ratio:

HR=e^\beta

But the SAP should not automatically assume proportional hazards merely because a Cox model is familiar. The model assumptions and appropriate sensitivity analyses should be considered when relevant.

Step 10: Handle Repeated Measures and Longitudinal Data

For repeated measurements, specify the model structure rather than simply saying "MMRM will be used."

A typical repeated-measures model may include treatment, visit, treatment-by-visit interaction, baseline value, and prespecified stratification factors:

Y_{ij} = \beta_0 + \beta_1 T_i + \beta_2 V_j + \beta_3(T_iV_j) + \beta_4 B_i + \varepsilon_{ij}

The SAP should identify the covariance structure, estimation method, degrees-of- freedom approach when applicable, treatment contrast, and the visit at which the primary inference is made.

Important: The model is only one part of the analysis. The estimand determines what the model is intended to estimate, especially when treatment discontinuation, rescue medication, death, or other intercurrent events occur.

Step 11: Prespecify Missing-Data Handling

Missing data should not be treated as an afterthought.

For each important endpoint, the SAP should answer:

What constitutes a missing observation?
Which observations are considered evaluable?
Is the primary analysis based on a model that accommodates incomplete data?
Are values imputed?
If imputation is used, what model generates the imputations?
Are auxiliary variables used?
What sensitivity analyses assess departures from assumptions?

For multiple imputation, the basic structure can be represented as:

\text{Observed Data} \rightarrow \text{Imputation Model} \rightarrow m\text{ Completed Datasets} \rightarrow \text{Analysis} \rightarrow \text{Pooling}

The SAP should specify the number of imputations, variables included in the imputation model, treatment of monotone and intermittent missingness when relevant, and the pooling procedure.

Step 12: Address Intercurrent Events Explicitly

Intercurrent events occur after treatment initiation and affect whether or how the endpoint is observed or interpreted.

Examples include:

Permanent treatment discontinuation
Rescue medication
Switching or initiation of prohibited therapy
Death before the planned assessment
Major protocol violations

The SAP should describe the strategy used for each important intercurrent event. Common conceptual strategies include treatment policy, hypothetical, composite, while-on-treatment, and principal-stratum approaches.

Strategy	Concept
Treatment policy	Effect of assignment regardless of the intercurrent event
Hypothetical	Effect under a specified hypothetical scenario in which the event did not occur
Composite	The intercurrent event becomes part of the endpoint definition
While on treatment	Effect up to the point associated with the intercurrent event
Principal stratum	Effect within a population characterized by potential occurrence or nonoccurrence of the event

Step 13: Prespecify Multiplicity

If the trial has multiple confirmatory hypotheses, the SAP should explain how the familywise type I error is controlled, if such control is required.

Potential strategies include:

Hierarchical or sequential testing
Bonferroni or weighted Bonferroni procedures
Holm procedures
Gatekeeping strategies
Graphical approaches
Other prespecified multiplicity procedures

For a simple Bonferroni allocation across \(K\) hypotheses:

\alpha_k=\frac{\alpha}{K}

The exact procedure should be determined by the study design and regulatory strategy rather than selected after examining the results.

Step 14: Define Subgroup Analyses

Subgroup analyses should be clinically justified and prespecified whenever they are intended to support important conclusions.

Examples include:

Age category
Sex
Geographic region
Disease severity
Baseline biomarker status
Prior treatment history
Randomization strata

The SAP should distinguish between descriptive subgroup summaries and formal tests of treatment-by-subgroup interaction.

Y = \beta_0 + \beta_1T + \beta_2S + \beta_3(T\times S) + \varepsilon

A statistically significant interaction is not automatically evidence of a clinically meaningful subgroup effect. Interpretation should consider the prespecified hypothesis, multiplicity, sample size, consistency, and biological plausibility.

Step 15: Specify Safety Analyses

Safety sections often contain a large number of outputs, so consistency is especially important.

The SAP should define conventions for:

Treatment-emergent adverse events
Serious adverse events
Severity grading
Relationship to study treatment
Preferred terms and system organ classes
Multiple occurrences within a participant
Exposure-adjusted incidence when appropriate
Laboratory abnormalities and shift analyses
Vital signs and ECG parameters

For example, if a participant experiences the same adverse event multiple times, the SAP should specify whether the participant is counted once in incidence tables or whether event counts are also summarized.

Step 16: Describe Protocol Deviations and Their Statistical Role

Protocol deviations should be classified according to prespecified criteria and should not be used opportunistically to improve or weaken treatment results.

The SAP should distinguish:

Deviations important to study conduct
Major or critical deviations affecting the primary analysis
Participants excluded from a per-protocol analysis
Deviations summarized descriptively but retained in the primary analysis

Key principle: The criteria for excluding a participant from a per-protocol analysis should be defined before reviewing treatment-group outcomes that could be affected by the classification.

Step 17: Define Interim Analyses and Data Access

If an interim analysis is planned, the SAP should specify its purpose, timing, information fraction or triggering event, statistical procedure, stopping boundaries when applicable, and who has access to unblinded results.

For a group-sequential design, the cumulative type I error must be controlled across the planned looks rather than treating each interim test as an independent 5% test.

The SAP should also describe operational controls around:

Database snapshots or data cuts
Blinding
Unblinded statistical teams
Independent data monitoring committees when applicable
Decision-making based on interim results

Step 18: Build the Statistical Analysis Around the TLFs

A strong SAP is closely connected to the planned tables, listings, and figures. Each important analysis should map to an output.

Analysis	Example Output
Disposition	Table of screened, randomized, treated, completed, and discontinued participants
Baseline characteristics	Demographics and baseline disease characteristics by treatment
Primary endpoint	Primary efficacy table with treatment effect and confidence interval
Longitudinal endpoint	Summary table and mean-profile figure
Time-to-event endpoint	Kaplan-Meier figure and summary table
Safety	TEAE summary, SOC/PT table, laboratory shift table
Protocol deviations	Participant-level listing and summary table

A useful quality-control exercise is to ask: Can every important SAP analysis be traced to one or more planned outputs, and can every important output be traced back to a SAP section?

Step 19: Write the Statistical Methods Precisely

Avoid phrases that sound statistical but do not specify an analysis.

Avoid	Prefer
"Appropriate descriptive statistics will be presented."	Define which summaries are used for continuous and categorical variables.
"An appropriate model will be fitted."	Name the model, response, fixed effects, covariance structure, and contrast.
"Missing data will be handled appropriately."	Define the primary missing-data approach and planned sensitivity analyses.
"Subgroup analyses will be performed."	List subgroups, populations, endpoints, and whether interactions are tested.
"Confidence intervals will be provided where appropriate."	State the confidence level and which treatment effects receive intervals.

Step 20: Include General Statistical Conventions

The general-statistical-considerations section should centralize conventions that apply across the analysis.

Common topics include:

One-sided versus two-sided tests
Nominal significance level
Confidence interval level
Decimal places and rounding
Units
Rules for zero counts and percentages
Handling of ties
Statistical software and version
Random-number seeds when simulation or imputation requires them
Analysis data cut and cutoff date
Rules for derived dates and elapsed time

For example, if a two-sided 95% confidence interval is used, the corresponding nominal significance level is:

\alpha=0.05

The important point is consistency. The same conventions should not be described differently in different sections of the SAP.

A Complete Worked SAP Example

Consider a hypothetical randomized Phase III trial comparing an experimental treatment with placebo in adults with a chronic disease.

Design Element	Planning Value
Design	Randomized, double-blind, placebo-controlled, parallel-group
Treatment allocation	1:1
Primary endpoint	Change from baseline in disease score at Week 12
Primary population	Full Analysis Set
Primary model	ANCOVA
Covariates	Treatment, baseline disease score, prespecified randomization stratum
Effect measure	Adjusted treatment difference
Inference	Two-sided 95% confidence interval and corresponding hypothesis test
Secondary endpoint	Proportion achieving predefined clinical response at Week 12
Safety population	All participants receiving at least one dose

Worked Primary Analysis

Let \(Y_i\) be the Week 12 change-from-baseline disease score, \(T_i\) indicate treatment, \(B_i\) be baseline score, and \(S_i\) be the randomization stratum. The model is:

Y_i = \beta_0 + \beta_1T_i + \beta_2B_i + \beta_3S_i + \varepsilon_i

The primary treatment effect is:

\Delta = E(Y\mid T=1)-E(Y\mid T=0)

The SAP should explicitly state which direction is clinically favorable. For example, if lower disease scores represent improvement, a negative adjusted treatment difference may favor the experimental treatment.

Worked Secondary Binary Endpoint

Suppose clinical response is defined as a prespecified improvement threshold. The SAP may summarize response rates as:

\hat p_T = \frac{R_T}{N_T}, \qquad \hat p_C = \frac{R_C}{N_C}

and estimate the treatment effect using:

RD = \hat p_T-\hat p_C

The SAP should specify the confidence interval method and how participants with missing Week 12 response status are handled.

Example SAP Language for a Primary Endpoint

Example specification:

The primary efficacy analysis will be performed using the Full Analysis Set, with participants analyzed according to randomized treatment assignment. The primary endpoint will be change from baseline in the disease score at Week 12, where baseline is defined as the last nonmissing assessment obtained before the first administration of study treatment. The primary comparison will be the adjusted difference between treatment groups from an ANCOVA model including treatment, baseline disease score, and prespecified randomization stratum as fixed effects. The treatment contrast, corresponding two-sided 95% confidence interval, and two-sided hypothesis test at the prespecified significance level will be reported. Additional sensitivity analyses will evaluate the robustness of the primary conclusion to prespecified assumptions regarding intercurrent events and missing data.

Notice that the example identifies the population, endpoint, baseline, model, covariates, contrast, confidence interval, hypothesis test, and sensitivity strategy. It does not leave the important analytical decisions to the results.

Sensitivity Analyses

Sensitivity analyses should answer a specific question about the robustness of the primary conclusion.

Useful categories include:

Alternative handling of missing data
Alternative assumptions about intercurrent events
Alternative model specifications
Alternative covariance structures
Per-protocol analysis
Alternative endpoint definitions when clinically justified
Influence or outlier assessments when appropriate

A sensitivity analysis should not be a fishing expedition. The SAP should explain what uncertainty it is intended to investigate and how it relates to the primary estimand.

Common SAP Mistakes

Mistake	Why It Matters
Copying the previous study's SAP	Can import incorrect populations, endpoints, visits, and analysis rules
Writing "appropriate" without defining appropriate	Leaves material decisions to implementation time
Changing methods after seeing results	Can undermine prespecification and introduce bias
Not defining baseline	Can change the derived endpoint and primary result
Ignoring intercurrent events	The statistical analysis may not correspond to the clinical question
Using "ITT" without defining it	Different teams may apply different inclusion rules
Listing TLFs without statistical specifications	Outputs may not be reproducible from the SAP
Adding post hoc analyses to the primary SAP section	Can blur the distinction between confirmatory and exploratory analyses

How to Quality-Control an SAP

A useful SAP QC process works from several directions rather than simply proofreading the document.

Protocol-to-SAP QC: every protocol objective and endpoint is represented consistently in the SAP.

Estimand-to-method QC: the statistical method actually targets the stated estimand.

SAP-to-program QC: every derivation and analysis required by the SAP can be implemented without interpretation.

SAP-to-TLF QC: every important analysis maps to an output and every output has a prespecified analysis source.

Internal-consistency QC: treatment names, populations, visits, endpoint names, sample sizes, and statistical conventions agree throughout the document.

SAP-to-Programming Traceability

One of the most valuable properties of a well-written SAP is traceability. A programmer should be able to move from a planned result to the SAP section, then to the analysis dataset and derived variables, and finally to the output.

\text{Protocol} \rightarrow \text{Estimand} \rightarrow \text{SAP} \rightarrow \text{ADaM} \rightarrow \text{Program} \rightarrow \text{TLF}

For example, a primary efficacy table might trace through:

Protocol primary objective
Primary estimand
SAP primary-analysis section
ADaM analysis dataset
Derived baseline and change variables
Statistical model
Program specification
Final table shell

Best practice: If a statistician cannot explain exactly where a key number in the CSR came from, the analysis chain needs better traceability.

R Example: A Simple SAP Analysis

Suppose the primary endpoint is Week 12 change from baseline and the planned analysis uses a linear model adjusted for treatment and baseline.

fit <- lm(
  change_wk12 ~ treatment + baseline,
  data = analysis_set
)

summary(fit)

# Estimated treatment effect
coef(fit)["treatmentActive"]

# 95% confidence interval
confint(fit, "treatmentActive", level = 0.95)

The SAP should still contain the statistical specification independently of the programming language. The R program implements the SAP; it does not replace it.

R Example: Binary Endpoint

response_rate <- with(
  analysis_set,
  tapply(response, treatment, mean, na.rm = TRUE)
)

response_rate

In production work, the programming specification would additionally implement the exact responder derivation, analysis population, visit window, missing-data rule, treatment coding, and confidence-interval method defined in the SAP.

What Should Be Finalized Before Database Lock?

The SAP should be finalized sufficiently before database lock to allow prespecified analytical decisions to be made without knowledge of the final unblinded results.

A practical pre-lock checklist includes:

Protocol and amendment history reconciled
Primary and secondary endpoints confirmed
Estimands documented
Analysis populations finalized
Endpoint derivations finalized
Baseline and visit-window rules finalized
Missing-data strategies finalized
Intercurrent-event strategies finalized
Multiplicity strategy finalized
Subgroup and sensitivity analyses finalized
Interim-analysis procedures finalized, if applicable
TLF shells aligned with SAP analyses
Statistical software/version conventions documented
Review and approval completed according to the study's procedures

The SAP as a Reproducibility Document

The best SAPs are written with reproducibility in mind. They do not merely document what a statistician intends to do; they provide enough information for another qualified analyst to reproduce the planned analysis.

A useful test is:

The independent-programmer test: Give the SAP to a qualified programmer who was not involved in writing it. If the programmer repeatedly has to ask what the statistician meant, the SAP needs more operational detail.

Final SAP Checklist

Question	Check
Is every primary objective represented?	☐
Is the primary estimand explicitly defined?	☐
Are all analysis populations operationally defined?	☐
Are baseline and visit-window rules deterministic?	☐
Is every primary endpoint precisely derived?	☐
Is the primary statistical model fully specified?	☐
Are treatment contrasts and confidence intervals defined?	☐
Are missing-data and intercurrent-event strategies prespecified?	☐
Is multiplicity handled consistently with the protocol?	☐
Are subgroup and sensitivity analyses justified?	☐
Are interim analyses and information controls documented?	☐
Are safety analysis conventions complete?	☐
Can every important TLF be traced to the SAP?	☐
Can every important SAP analysis be traced to a TLF?	☐
Could an independent programmer implement the analysis without guessing?	☐

Key Takeaways

Writing an SAP is fundamentally an exercise in converting a clinical question into a reproducible statistical decision process.

Start with the clinical objective. Understand what the trial is intended to establish.

Define the estimand. Make the treatment effect and intercurrent-event strategy explicit.

Define the data. Specify populations, endpoints, baseline, visits, and derivations.

Define the statistics. Specify models, contrasts, confidence intervals, testing, multiplicity, and sensitivity analyses.

Define the outputs. Make the TLF package a direct implementation of the SAP.

QC the entire chain. Protocol → estimand → SAP → ADaM → program → TLF should be internally consistent.

References

ICH E9 (1998). Statistical Principles for Clinical Trials.
ICH E9(R1) (2019). Addendum on Estimands and Sensitivity Analysis in Clinical Trials.
ICH E3. Structure and Content of Clinical Study Reports.
U.S. Food and Drug Administration. Guidance for Industry: Statistical Principles for Clinical Trials.
U.S. Food and Drug Administration. Multiple Endpoints in Clinical Trials.