With the estimand framework, we gained a very useful toolbox to fine-tune how we answer the question of interest. In practice, however, the hard part is not only choosing an estimand strategy; it’s making sure the clinical question, participant journey, data collection, and analysis still describe the same thing.

Here, I reflect on five familiar situations that can create confusion, extra work, or difficult interpretation in real studies, and provide the practical dos and don’ts for addressing them.

The lost event: When the analysis set and the estimand work against each other

This is not a rare issue: the legacy approach of using a strict analysis set to target the question of interest, now paired with intercurrent events and their strategies. Picture a strict analysis set: three doses, no prohibited medications, a post-dose assessment, and possible exclusion for important protocol deviations at the study team’s discretion. This is what we used to do.

At the same time, several intercurrent events had been defined for this trial, such as permanent treatment discontinuation due to an adverse event, lack of efficacy, or use of rescue medication. Each event had a planned strategy. On paper, this may look thorough. However, the problem arose when we asked the basic question: during which period could these events actually be observed for participants who remained in the analysis set, if the analysis-set definition could exclude participants with these events in the first place?

A participant who stopped treatment early because of an adverse event might never have received the second dose or completed the required post-dose assessment. The participant is then excluded by the analysis-set definition before the estimand strategy can do any useful work. The intercurrent event has not vanished from the study, but it has effectively vanished from the analysis.

This can create a strange result that is tricky to follow and even more difficult to present.

Do:

Confirm that the events can actually occur and be handled within the population used for the analysis.

Don’t:

Define an intercurrent-event strategy for participants who have already been excluded from the analysis.

Responder or non-responder? When a more conservative model also creates a less understandable result

Consider a binary endpoint assessed at a fixed time point. A participant permanently discontinues treatment before that assessment, so the outcome is missing. Under one imputation approach (hypothetical), the participant is classified as a responder.

The protocol, however, added another, more conservative assumption. In theory, after discontinuation, the participant might have experienced additional events, such as rescue medication or another clinically relevant change. A second step was therefore introduced to reflect this possibility. Under that approach, the same participant was classified as a non-responder.

There is a reasonable argument for this. It may reduce the risk of an overly optimistic result. But the cost is complexity. The participant’s contribution now depends on several linked assumptions, and the result becomes difficult to explain.

The approach may be statistically defensible and still not very useful. If only a few participants are affected, the extra machinery may require substantial programming, validation, and documentation, while adding little to the interpretation of the trial.

Do:

Before adding another conservative layer, ask what decision it could realistically change.

Don’t:

Assume that greater complexity automatically means greater robustness.

Define the event before you need it: Generic discontinuation forms are not an estimand strategy

It is possible to rely on case report form (CRF) data or other sources to identify intercurrent events. But this only works if the right information is collected clearly and consistently. Problems arise when we try to reconstruct the event later from generic end-of-treatment or end-of-study forms, or from data sources not originally designed for this purpose.

In this example, the form included reasons such as adverse events, lack of efficacy, protocol deviation, investigator decision, sponsor decision, withdrawal by the participant, or loss to follow-up. However, the protocol defined only adverse events and lack of efficacy as intercurrent events. Later, an SAP amendment added the use of a certain medication as an intercurrent event. Other reasons remained outside the formal estimand definition.

This created two problems. First, the same underlying clinical story may be recorded in different ways. A participant may withdraw because of an adverse event or become lost to follow-up after experiencing lack of efficacy. The final form may show only “withdrawal” or “lost to follow-up,” while the event that matters for the estimand is hidden in another part of the database.

Second, a late change can lead to inconsistent data capture. If medication use becomes an intercurrent event after study conduct started, earlier participants may not have been assessed in the same way as later participants. The analysis then depends on data that were not collected with the estimand question in mind.

Do:

Define the event, timing, data source, and classification rule before the study starts.

Don’t:

Assume that labels such as “withdrawal” or “lost to follow-up” explain the underlying clinical cause.

One strategy does not always fit all: Simple is good, but only when it still answers the right question

A misconception is that one endpoint should be analyzed with one estimand strategy for all intercurrent events. For example, all relevant intercurrent events may be handled using a composite strategy, a hypothetical strategy or a treatment-policy strategy. This may sometimes be the right choice. But if it is applied mechanically, it misses part of the point of the estimand framework.

Sometimes that simplicity is exactly what the study needs. But different events can have very different meanings. Rescue medication, treatment discontinuation due to an adverse event and temporary interruption for an unrelated reason may not belong under the same strategy.

The estimand framework allows the strategy to match the specific intercurrent event. A treatment-policy strategy may make sense for one event, while a hypothetical or composite strategy may be more appropriate for another. The best choice depends on the clinical question, not on which strategy is easiest to repeat across the SAP.

Do:

Start with what the event means clinically.

Don’t:

Force every event into one strategy just to keep the SAP short.

Estimands everywhere? Use the framework where it adds value, not as decoration

Every study has a question it is trying to answer. But not every question requires an elaborate estimand implementation.

An early-phase study with a small number of participants, short follow-up, and a highly controlled setting may have few intercurrent events and limited missing data. A detailed framework covering every exploratory endpoint can require substantial protocol, data-management, programming, and review effort without materially improving the decision.

The same question applies within later-phase trials. Primary and key secondary endpoints normally deserve careful estimand definition because they drive the main clinical conclusions. Some exploratory biomarkers or supportive endpoints may not benefit from equally extensive handling of intercurrent events, particularly when they are not intended to support a formal claim.

Do:

Use a fit-for-purpose level of detail based on the endpoint, study phase, expected events, and importance of the question.

Don’t:

Treat estimand language as a box-checking exercise.

Final takeaways

These examples all point to the same practical lesson: design backwards from the clinical question.

The estimand framework is most valuable when it connects the clinical objective, participant journey, data collection, and statistical analysis. The main risks appear when those pieces are developed separately: the analysis set removes the participants who experience the event, the database does not capture the reason needed for classification, or the statistical solution becomes too complicated to interpret.

Some clinical questions are genuinely complicated, and some intercurrent events require different strategies. But every layer of complexity should earn its place. It should answer a clearer question, reduce an important bias, or improve a decision.

Lastly, bring clinicians, statisticians, programmers, data managers, and operational colleagues into the discussion early. Walk through realistic participant examples. Test whether the planned event can be identified in the data. Explain the strategy without formulas. If the team cannot describe what happens to one participant in one clear paragraph, the implementation may need another look.

Share Via