Clinical Priority Weights In Endpoint Graphs

Clinical Priorities as Design Choices

A multiplicity graph is not only a bookkeeping device. Its initial weights and transitions determine where the family’s type I error allowance is available first, and where it can move after a rejection. Those choices should reflect the prespecified clinical objectives of the trial: for example, the relative importance of endpoints or the value of making a claim on one endpoint if another has already succeeded.

A priority weight is not an estimate of an endpoint’s treatment effect, its probability of success, or its clinical importance in every possible sense. It is a design choice about the allocation of the familywise significance level. Different defensible choices can therefore lead to different rejection opportunities, even when the data and the overall significance level are unchanged.

An initial weight of zero means that an endpoint receives no initial local level; it does not necessarily mean that the endpoint can never be tested. It may receive level through an incoming transition. Likewise, a transition weight of zero means that no level is transferred along that particular edge. If the outgoing transition weights sum to less than one, the untransferred fraction is not assigned elsewhere by default.

These graph choices operate alongside the sequential testing plan. Each endpoint’s local level is implemented by a group sequential test calibrated across its planned looks. Changing an endpoint’s local level can change the boundary it must cross; it does not change the endpoint’s test statistic or information schedule. A graph weight is therefore not itself an interim boundary.

From Clinical Rationale to Weights

The clinical team should state what priority the graph is intended to represent before examining unblinded treatment comparisons. One practical approach is to assign positive scores \(s_i\) based on a documented rationale, then normalize them to obtain initial weights:

This conversion makes the scores relative allocations, not measurements on a universal clinical scale. A score twice as large as another yields twice the initial local alpha under this rule, but does not imply twice the clinical benefit. The scores and the normalization rule should be prespecified, and the resulting allocations should be reviewed for whether they support the trial’s intended claims.

Transition weights require a separate rationale. They describe what should happen to an endpoint’s allocated level following its rejection. For instance, if success on endpoint A makes a claim on endpoint B especially valuable, the edge from A to B might carry a relatively large fraction. A transition from A to C need not match the transition from C to A: the graph can be asymmetric when the clinical consequences of the two rejection paths differ.

What a Transition Does to Rejection Opportunities

If \(H_i\) is rejected, its current local level can be redistributed according to the outgoing edge weights. Let \(\alpha_i^{\mathrm{current}}\) be its level immediately before the graph update. The update to a remaining endpoint \(j\) is

The transition uses the level attached to endpoint \(i\) at the time of the update, not automatically its initial level. If several hypotheses have already been rejected and their allocations transferred, an endpoint’s current level may exceed its initial allocation. Across interim looks, the group sequential spending and boundary-calibration rules must also be followed: an allocation is not permission to reuse alpha already spent at earlier looks.

A useful way to compare opportunities is to consider the local level an endpoint’s sequential test would need to reject under its observed statistic path, using the specified testing and spending plan. Call this requirement \(q_i\). It is not an ordinary unadjusted p-value. In a simplified calculation where the relevant level is available for the endpoint, rejection occurs when \(q_i\leq\alpha_i^{\mathrm{current}}\). In an actual group sequential implementation, the planned local-level calibration and the look at which a rejection occurs must be respected.

Why the Allocation Is Coherent

The transition constraints have a simple accounting justification. When \(H_i\) is rejected, remove its current level from the set of active endpoints. The outgoing edges distribute a total of \(\alpha_i^{\mathrm{current}}\sum_{j\ne i}g_{ij}\) among the other endpoints. The total active level after the update is therefore

The inequality follows from \(\sum_{j\ne i}g_{ij}\leq1\). Thus an update does not create additional alpha; some may be left untransferred. This accounting condition is necessary for the graph, but by itself is not a complete proof of familywise error control. That conclusion also relies on the validity of the local tests and the graph procedure’s prescribed testing and updating rules. In this course setting, each group sequential local test must control its type I error at its assigned local level over all planned looks.

Correlated endpoint statistics do not justify treating the allocations as independent probabilities of success. The graph allocates significance levels; dependence is relevant to the joint behavior of the statistics, but a valid multiplicity procedure must retain its stated error-control guarantee under its assumptions. The earlier material on correlated endpoint statistics and error control provides the relevant dependence context.

Diagnostics, Comparisons, and Limitations

Before finalizing a clinical priority graph, check both its arithmetic and its meaning. The following checks often reveal problems before the design is implemented:

• Check the initial weights. Verify that each is nonnegative and that their sum is at most 1. If the intended design allocates the entire familywise level initially, the sum should equal 1.
• Check every row of transitions. Confirm that outgoing weights are nonnegative and sum to at most 1. Record what happens to any untransferred fraction.
• Check the clinical interpretation. Ask whether the initial allocations match the claims the trial needs to support first, and whether each edge reflects a defensible consequence of rejecting its source endpoint.
• Check sequential implementation. Verify that endpoint-specific tests and boundaries are calibrated for the assigned local levels and planned looks. A correct graph cannot repair invalid local sequential tests.
• Check sensitivity. Compare plausible prespecified allocations to see whether a small change in priorities reverses important rejection opportunities. If it does, that dependence should be discussed before the design is fixed.

A fixed initial allocation without recycling is a simpler alternative: it leaves each endpoint at its starting level regardless of other rejections. A graphical procedure can offer more opportunities for later endpoint claims by reallocating level along edges after rejection. The trade-off is that the graph adds design choices that must be justified, implemented consistently, and interpreted as part of the testing strategy. Neither approach makes an endpoint more clinically meaningful, and neither guarantees rejection when the evidence is insufficient.

A common mistake is to assign a large weight to the endpoint expected to have the largest treatment effect, then describe that weight as if it were a higher probability of success. That reasoning confuses evidence allocation with a model for treatment effects. The correction is to state what the weight controls: the endpoint’s initial local significance level. If expected power or effect size is part of the design rationale, it should be assessed separately from the multiplicity allocation.

Another pitfall is to transfer all of a rejected endpoint’s original level repeatedly, even after some of that level has already been spent at earlier looks or transferred elsewhere. Use the endpoint’s current allocation and the prespecified sequential update rules. Keep a record of allocations and look-specific spending so that no alpha is counted twice.