Estimands: Defining the Clinical Question with ICH E9(R1)

Why the same trial data can answer different questions — and how the five estimand attributes and five intercurrent-event strategies pin down the one you mean

The bridge from a trial’s objective to the analysis. Learn what an estimand is and why ICH E9(R1) requires one: the five attributes (treatment, population, variable, intercurrent events, population-level summary), the five strategies for handling intercurrent events (treatment policy, hypothetical, composite, while-on-treatment, principal stratum), the estimand vs estimator vs estimate distinction, and how an estimand becomes the SAP and the ADaM variables you derive.

TipKey takeaways

• An estimand is a precise description of the treatment effect — what the analysis is meant to estimate — written before you choose a method or touch the data.
• It exists because the same trial data can answer different clinical questions. Without a pinned-down question, “the treatment effect” is ambiguous, and two analysts can report two honest-but-incompatible numbers.
• ICH E9(R1) defines an estimand by five attributes: treatment, population, variable (endpoint), intercurrent events, and population-level summary.
• The hard attribute is intercurrent events — things that happen after randomization (a patient stops the drug, takes rescue medication, dies) that change what an outcome means. E9(R1) gives five strategies to handle them: treatment policy, hypothetical, composite, while-on-treatment, principal stratum.
• Keep three words straight: the estimand is the question, the estimator is the method, the estimate is the number. The estimand is the bridge from the trial objective to the SAP (Statistical Analysis Plan), and from there to the ADaM (Analysis Data Model) variables and TLF shells you program.

Introduction

A patient is randomized to your drug. Eight weeks in, their symptoms flare, so the investigator adds a rescue medication. At week 24 — the trial’s endpoint — they look fine. Did the drug work?

There is no single right answer, and that is the whole point. If your question is “how does the drug perform in the real world, where people take rescue meds when they need them?”, that patient’s good week-24 score counts for the drug. If your question is “what is the effect of the drug itself, uncontaminated by rescue?”, it does not. Same patient, same data, two different treatment effects — because they answer two different questions.

An estimand is how you state, up front and unambiguously, which question you are asking. ICH E9(R1) — the International Council for Harmonisation’s 2019 addendum to the E9 guideline on statistical principles — made writing one a regulatory expectation. This lesson is that framework: why it exists, the five attributes that define an estimand, the five strategies for the attribute that trips everyone up (intercurrent events), and the estimand → estimator → estimate chain that connects a clinical question to the numbers in a submission.

The clinical-trial data flow mapped how data flows to a submission; the regulatory context explained why the regulators require CDISC (the Clinical Data Interchange Standards Consortium). This lesson is the hinge between the trial’s objective and the ADaM datasets you derive to answer it. No code to install — the one example below is base R, and if you have ever computed a group mean you have enough.

Why the framework exists

Before E9(R1), trial protocols stated an objective (“to demonstrate the efficacy of Drug X”) and jumped to a method (“a mixed model for repeated measures on the change from baseline”). What sat between them — the exact treatment effect being targeted — was left implicit, and the gaps showed up as post-randomization events nobody had agreed how to handle. One team analyzed only the patients who stayed on drug; another carried everyone’s last observation forward; a third counted dropouts as failures. All three are defensible. All three answer different questions. And the difference can be large enough to flip a conclusion.

The estimand framework closes that gap by forcing the question to be written down first, in enough detail that there is only one thing the analysis could be estimating. The discipline is deliberately ordered:

objective → estimand → estimator → estimate

State the objective, translate it into a precise estimand (the five attributes below), choose an estimator aligned to that estimand, and report the estimate. Get the order wrong — pick a method first and back into a question — and you risk an answer that is precise but to a question nobody asked.

The five estimand attributes

ICH E9(R1) says an estimand is built from exactly five attributes (Clark et al. 2022: “Defining an estimand entails specifying five attributes: treatment condition(s), population, outcome, population-level summary and postrandomisation events”). Specify all five and the clinical question is unambiguous; leave one vague and it is not.

#	Attribute	The question it pins down	Example
1	Treatment	The treatment condition of interest, and the comparator it is measured against	Drug X 50 mg/day vs placebo, each on top of standard care
2	Population	The patients targeted by the scientific question (often a clinically meaningful subset, not just “everyone enrolled”)	Adults with moderate-to-severe disease
3	Variable (endpoint)	The measurement obtained for each patient to address the question	Change from baseline in symptom score at week 24
4	Intercurrent events	How to account for post-randomization events that affect the outcome’s meaning or existence	Rescue medication handled by the hypothetical strategy (see below)
5	Population-level summary	The single comparison between treatment conditions that answers the question	Difference in mean change from baseline

Read across a row and you get one clause of a sentence; read all five and you get the estimand: “In adults with moderate-to-severe disease (population), the difference (summary) in mean change from baseline symptom score at week 24 (variable) between Drug X 50 mg and placebo (treatment), had no patient taken rescue medication (intercurrent event, hypothetical strategy).” That sentence is the estimand — and notice it is pure clinical English, with no statistical method in it yet.

Four of the five attributes are usually easy to state. The fourth — intercurrent events — is where the real thinking happens, and where E9(R1) added the most.

Intercurrent events: the attribute that does the work

An intercurrent event (ICE) is an event that occurs after treatment starts and either changes the meaning of the outcome or prevents it from existing at all. The canonical examples:

• Treatment discontinuation — the patient stops the study drug early.
• Rescue or additional medication — the patient takes something else to control symptoms.
• Treatment switching — the patient crosses over to the other arm.
• Death — for a non-mortality endpoint, there is no week-24 symptom score to measure.

ICEs are not the same as missing data. A patient who discontinues but is still measured at week 24 has produced a value — the question is whether that value answers your question. A patient lost to follow-up has missing data. The two interact, but the estimand decision is about meaning, not absence: given that the ICE happened, what outcome do you even want?

E9(R1) gives five strategies (see §A.3.2 of the addendum). The first decision for every ICE in a trial is which one to apply — and different ICEs in the same trial can use different strategies.

The five strategies for handling intercurrent events

Strategy	What it does with the ICE	The question it answers	Rescue-medication example
Treatment policy	Ignores the ICE: use the outcome value regardless of whether the ICE occurred	“Effect of being assigned the treatment, real-world adherence and all” (the intention-to-treat, or ITT, spirit)	Use the week-24 score whether or not the patient took rescue
Hypothetical	Targets the outcome in a scenario where the ICE had not occurred	“Effect of the treatment itself, had no one needed rescue”	Estimate the week-24 score that would have been seen without rescue
Composite	Folds the ICE into the endpoint definition — the event is part of being a (non-)responder	“Effect on a success that requires avoiding the ICE”	A patient who takes rescue is defined a non-responder, regardless of their score
While on treatment	Uses the outcome only up to the ICE, discarding what comes after	“Effect of treatment for as long as it is taken”	Use the last symptom score recorded before rescue began
Principal stratum	Restricts to the subset of patients in whom the ICE would (or would not) occur	“Effect in the patients who would never need rescue”	Estimate the effect only within the stratum that would not take rescue under either arm

Three points keep these straight:

• Treatment policy and hypothetical are the two most common, and they sit at opposite ends. Treatment policy measures effectiveness (the drug as actually used, ICEs included); hypothetical isolates the drug’s pharmacological effect (the world without the ICE). Our opening patient counts for the drug under treatment policy and is adjusted away under hypothetical — same data, opposite handling.
• Composite and while-on-treatment change the variable itself: composite redefines what counts as a response; while-on-treatment redefines the measurement window. They need no imputation because the ICE is built into the endpoint.
• Principal stratum changes the population, and it is the subtlest. Membership is defined by how a patient would behave (a potential, partly counterfactual property) — not by what was observed — which is exactly what makes it hard to estimate and why it is used sparingly.

The same data, two estimands, two answers

The framework’s whole claim is that the estimand — not the data — decides the number. Here is that claim in a few lines of base R: one small trial, two strategies for the same ICE, two different treatment effects. No packages, made-up values for illustration.

Start with the trial: eight subjects, a responder endpoint at week 24, and a rescue flag marking the intercurrent event (the two Drug subjects who took rescue medication).

trial <- data.frame(
  USUBJID   = sprintf("01-%03d", 1:8),
  ARM       = c("Drug", "Drug", "Drug", "Drug",
                "Placebo", "Placebo", "Placebo", "Placebo"),
  rescue    = c("Y", "Y", "N", "N", "N", "N", "N", "N"),   # the intercurrent event
  responded = c("Y", "N", "Y", "Y", "N", "Y", "N", "N")    # observed at week 24
)
trial

  USUBJID     ARM rescue responded
1  01-001    Drug      Y         Y
2  01-002    Drug      Y         N
3  01-003    Drug      N         Y
4  01-004    Drug      N         Y
5  01-005 Placebo      N         N
6  01-006 Placebo      N         Y
7  01-007 Placebo      N         N
8  01-008 Placebo      N         N

Treatment-policy estimand. The ICE is irrelevant: take each patient’s observed week-24 response as it stands, then compute the response rate per arm.

# Treatment policy: use the observed response regardless of rescue
tp <- tapply(trial$responded == "Y", trial$ARM, mean)
round(tp, 2)

   Drug Placebo 
   0.75    0.25 

Composite estimand. Same data, one change: taking rescue medication is treatment failure, so a rescued patient is recoded a non-responder before the rates are computed.

# Composite: taking rescue medication counts as a non-responder
resp_composite <- ifelse(trial$rescue == "Y", "N", trial$responded)
cs <- tapply(resp_composite == "Y", trial$ARM, mean)
round(cs, 2)

   Drug Placebo 
   0.50    0.25 

The placebo arm is unchanged, but the Drug response rate drops from 0.75 under treatment policy to 0.5 under composite — so the estimated treatment effect (Drug minus Placebo) falls from 0.5 to 0.25. Nothing about the data changed. The only thing that moved was the question — how to treat the intercurrent event — and the answer moved with it. That is why the estimand is written before the analysis, not after.

Estimand vs estimator vs estimate

Three words that sound alike and mean very different things. Keeping them apart is most of understanding the framework — the addendum is explicit that the estimand is distinct from the estimator and the estimate, and that the analysis method must be chosen to match the estimand:

• Estimand — what you want to estimate. The clinical question, made precise by the five attributes. It contains no statistics — it is a sentence about treatments and patients.
• Estimator — how you estimate it. The method of analysis (a mixed model, a Cox model, a rate difference) aligned to the estimand. A treatment-policy estimand and a hypothetical estimand for the same endpoint need different estimators.
• Estimate — the number the estimator produces from the trial data, with its confidence interval and p-value.

The order is one-directional and it matters: estimand → estimator → estimate. You define the question, choose a method that targets it, and report the result. Picking a familiar method first and treating whatever it returns as “the” effect is exactly the mistake the framework was written to stop.

E9(R1) pairs this with sensitivity analysis: analyses that target the same estimand but relax the assumptions the main estimator relied on (for example, the missing-data assumptions behind a hypothetical strategy). If the conclusion holds when those assumptions are stressed, it is robust. Sensitivity analysis is not a different question — that would be a supplementary analysis (a different estimand entirely). Same estimand, stressed assumptions: sensitivity.

Why a programmer should care: the bridge to the SAP and ADaM

This is a biostatistics framework, but it lands squarely in the programming. The estimand is the top of a chain that runs straight into the datasets you build:

estimand → Statistical Analysis Plan (SAP) → ADaM variables & TLF shells → estimate

The biostatistician writes the estimand and the SAP; the ADaM datasets are where its attributes become columns. The intercurrent-event strategy in particular is programmed — it decides which records and which derived flags an analysis dataset must carry:

• A treatment-policy estimand keeps every post-ICE measurement, so the BDS (Basic Data Structure) analysis dataset retains those rows and the analysis flag (ANL01FL) includes them.
• A while-on-treatment estimand needs a derived cut-off — the analysis must stop at the ICE, so records after it are flagged out.
• A composite estimand needs a derived responder/failure variable that already encodes the ICE.
• A hypothetical estimand drives the missing-data / imputation handling the estimator assumes.

In a time-to-event endpoint (ADTTE), the same logic decides the censoring rules — when a patient who discontinues or switches is censored versus counted as an event is precisely an intercurrent-event decision. Get the estimand right and the ADaM derivations have a clear, defensible specification; get it vague and the programming inherits the ambiguity. The CDISC standards (next in this series) and the admiral ADaM lessons later in the pillar are, in large part, the machinery that turns these five attributes into traceable analysis variables.

🟢 With an AI agent

Ask Prova “what’s the difference between the treatment-policy and hypothetical strategies for an intercurrent event?” — it answers grounded in this pillar’s lessons, with runnable R you can try on example trial data. The runtime is the judge. Ask Prova →

Common issues

These are the conceptual slips that derail people new to the estimand framework.

Confusing an intercurrent event with missing data. An ICE is about an outcome’s meaning, not its absence. A patient who stops the drug but is still measured at week 24 has a value — the ICE question is whether that value answers your estimand, and which strategy applies. Missing data is a separate problem (no value at all), handled by the estimator’s assumptions. Decide the ICE strategy first; the missing-data method follows from it.

Treating “intention-to-treat” as the whole answer. ITT names a population principle (analyze patients as randomized). It does not, by itself, say how to handle a patient who switched treatment or took rescue. The treatment-policy strategy is the estimand-framework expression of the ITT spirit for intercurrent events — but the framework asks you to choose a strategy explicitly, ICE by ICE, rather than wave at “ITT” and leave it implicit.

Picking the estimator before the estimand. Reaching for a familiar model (MMRM, Cox) and then asking “what effect does this give?” inverts the framework. The method must be chosen to target a pre-specified estimand. Two trials running the identical model can be estimating different things if their estimands differ — and only the estimand tells you what the number means.

Frequently asked questions

NoteWhat is an estimand in a clinical trial?

An estimand is a precise description of the treatment effect a trial is meant to estimate — the clinical question, written before the analysis. ICH E9(R1) defines it through five attributes: treatment, population, variable (endpoint), intercurrent events, and the population-level summary. Specifying all five removes the ambiguity in a phrase like “the treatment effect.”

NoteWhat are the five estimand attributes in ICH E9(R1)?

Treatment (the conditions being compared), population (the patients targeted), variable (the endpoint measured on each patient), intercurrent events (how post-randomization events that change the outcome’s meaning are handled), and the population-level summary (the single comparison — e.g. a mean difference or hazard ratio — that answers the question).

NoteWhat is an intercurrent event, and how is it different from missing data?

An intercurrent event occurs after treatment starts and either changes the meaning of the outcome or stops it existing — treatment discontinuation, rescue medication, treatment switching, or death. It is about meaning: a measured value may still exist but no longer answer your question. Missing data is the separate problem of no value at all. You choose an intercurrent-event strategy first; the missing-data handling follows.

NoteWhat are the five strategies for handling intercurrent events?

ICH E9(R1) defines five: treatment policy (use the outcome regardless of the event), hypothetical (the outcome had the event not occurred), composite (the event becomes part of the endpoint definition), while on treatment (use the outcome only up to the event), and principal stratum (restrict to the subset of patients in whom the event would, or would not, occur).

NoteWhat is the difference between an estimand, an estimator, and an estimate?

The estimand is what you want to estimate (the clinical question, no statistics in it). The estimator is how you estimate it (the analysis method, aligned to the estimand). The estimate is the resulting number with its confidence interval. The framework’s discipline is the order: estimand first, then a matching estimator, then the estimate.

NoteHow does an estimand connect to ADaM programming?

The estimand sits at the top of the chain estimand → SAP → ADaM variables and TLF shells → estimate. Its intercurrent-event strategy is programmed into the analysis datasets: which records are kept, which derived flags (analysis flags, responder variables) are built, and — for a time-to-event endpoint (ADTTE) — the censoring rules. A clear estimand gives the ADaM derivations a defensible specification.

Test your understanding

ImportantYour turn: choose the intercurrent-event strategy

A trial measures change from baseline in a depression score at week 12. Some patients start a new antidepressant (the intercurrent event) before week 12. For each clinical question below, name the E9(R1) strategy that matches it:

1. “We want the drug’s effect as it would be used in practice, where some patients add other medication.”
2. “We want the effect of our drug alone, as if no one had added another antidepressant.”
3. “Adding a new antidepressant is itself a treatment failure — count those patients as non-responders.”
4. “We only care about the score while the patient is still on our drug, before they add anything.”

TipHint

Map each question to what it does with the event: ignore it, imagine it away, fold it into the endpoint, or stop measuring at it. Those are four of the five strategies.

TipSolution

1. Treatment policy — use the week-12 score regardless of the added medication (the real-world, effectiveness question; the ITT spirit).
2. Hypothetical — target the score in the scenario where the new antidepressant was not started.
3. Composite — the intercurrent event is built into the endpoint; starting another drug defines the patient as a non-responder.
4. While on treatment — use only the scores recorded up to the point the new medication began. (The fifth strategy, principal stratum, would instead restrict the population to patients who would never add another antidepressant.)

NoteQuick check: which statement describes an estimand?

A. A mixed model for repeated measures on the change-from-baseline score. B. “The difference in mean change from baseline at week 24 between drug and placebo, in adults with moderate disease, had no patient taken rescue medication.” C. “The estimated treatment difference was -2.4 points (95% CI -3.8 to -1.0).”

TipShow answer

B. An estimand is the question — the five attributes (treatment, population, variable, intercurrent-event handling, summary) in plain clinical language, with no statistical method. A is an estimator (the method). C is an estimate (the number the estimator produced). Estimand → estimator → estimate.

References

The estimand framework on this page — the five attributes, the five intercurrent-event strategies, the estimand → estimator → estimate distinction, and sensitivity analysis — follows the primary regulatory guideline; the peer-reviewed reference is a clear, freely available explainer.

• ICH E9(R1) (2019). Addendum on Estimands and Sensitivity Analysis in Clinical Trials, to the Guideline on Statistical Principles for Clinical Trials (Step 4 final guideline). International Council for Harmonisation. — the primary source for every framework claim here. database.ich.org PDF · ICH E9(R1) training material · EMA-hosted copy (EMA/CHMP/ICH/436221/2017).
• Clark TP, Kahan BC, Phillips A, White I, Carpenter JR (2022). “Estimands: bringing clarity and focus to research questions in clinical trials.” BMJ Open / PubMed Central. pmc.ncbi.nlm.nih.gov/articles/PMC8724703 — a peer-reviewed walkthrough of the five attributes and the estimand-vs-method distinction.

Conclusion

An estimand is the sentence that says exactly which treatment effect a trial is asking about, written before any method is chosen — because the same data can honestly answer different questions. ICH E9(R1) builds it from five attributes (treatment, population, variable, intercurrent events, population-level summary), and the one that carries the weight is intercurrent events, handled by one of five strategies: treatment policy, hypothetical, composite, while-on-treatment, and principal stratum. Keep the chain straight — the estimand is the question, the estimator is the method, the estimate is the number — and the rest of the pillar falls into place: the estimand becomes the SAP, the SAP becomes the ADaM variables and censoring rules you program, and the analysis you ship traces all the way back to a question someone wrote down on purpose.

Related lessons

• Clinical trial data flow: CRF to SDTM, ADaM, TLF, and submission — the pipeline this estimand feeds into; the ADaM stage is where its attributes become variables. · Regulatory context: FDA, ICH, eCTD — where ICH E9(R1) sits among the guidelines a data person works with. · CDISC ADTTE for regulatory submission — a time-to-event endpoint where the intercurrent-event strategy is the censoring rule.
• Where this fits: drug development & data flow → regulatory context → estimands (ICH E9(R1), you are here) → the CDISC standards → the SAS-to-R shift — the concepts first, then the hands-on SDTM, ADaM, and TLF workflows that program them.

Was this page helpful?

Prove you can do it. Master the whole Clinical Programming in R (pharmaverse) series — track your path, build projects, and earn a certificate.

Start free →

Go Pro — unlimited Prova on your own data and a verifiable certificate that proves the skill.

from $15/mo billed yearly

Go Pro →

✓ You're Pro — keep going. The runtime is the judge.

Get new R & Python lessons by email

Practical, reproducible, no spam. Unsubscribe anytime.

Double opt-in. We never share your email.

Share this pageXLinkedInRedditHN

Note

This lesson is reproducible: every result on this page was produced by the code shown — copy any block and run it to reproduce them. The runtime is the judge.