Cause-specific hazard versus cumulative incidence: know which question changed

Last updated: 7 Oct 20265 min read

tutorial

A cause-specific hazard is an instantaneous event rate among those still event-free; cumulative incidence is a probability by a stated horizon.

Read the denominator for a rate

A queue manager asks whether a process change makes resolution faster among tickets still open and not withdrawn. The cause-specific resolution hazard examines target events among tickets in that event-free risk set. Its local rate is conditioned on reaching the time without either event. It is useful for describing a transition mechanism, but a hazard ratio is not the same as a ratio of resolved-ticket probabilities. The risk-set lesson checks whether the denominator is constructed correctly.

Account for the competing path

A process could raise the resolution hazard and also sharply raise withdrawal. The final fraction resolved by day twelve depends on both paths, because withdrawals remove tickets before they can resolve. A model for only the resolution hazard cannot directly give the observed-world resolution probability without information about the competing hazard as well. The grouped code calculates one event-time transition from a supplied event-free survival value; it does not fit either hazard model or attach uncertainty.

Select a measure for the decision

If the operational promise is the share of eligible tickets resolved by a deadline despite withdrawal, report cumulative incidence at that deadline. If the question is the resolution transition among tickets currently event-free, a cause-specific rate is relevant. For causal comparisons, intervention effects on withdrawal and censoring must be considered; changing the competing event can change target incidence even without a direct effect on the target transition. The cumulative-incidence lesson provides the probability calculation.

Document timing and assumptions

Show event counts by time, the event-free risk set, the separate transition rates, and horizon-specific probabilities. Define whether reopenings begin a new episode and whether customers can withdraw after resolution. A competing-event analysis of first outcomes cannot answer how often a resolved ticket reopens. If censoring depends on unrecorded ticket difficulty, even a correctly built competing-risk curve can be biased. The project audits that distinction before a queue change is called successful.

Implementation

def event_time_transition(event_free_probability, at_risk,
                          resolved, withdrawn):
    if not 0 <= event_free_probability <= 1 or at_risk <= 0 or        min(resolved, withdrawn) < 0 or resolved + withdrawn > at_risk:
        raise ValueError("invalid transition inputs")
    resolution_increment = event_free_probability * resolved / at_risk
    withdrawal_increment = event_free_probability * withdrawn / at_risk
    next_event_free = event_free_probability - resolution_increment -                       withdrawal_increment
    return resolution_increment, withdrawal_increment, next_event_free

assert tuple(round(value, 2) for value in event_time_transition(0.8, 40, 5, 3))        == (0.1, 0.06, 0.64)

Performance and operating cost

One transition is O(1); a k-time curve is O(k) time and can stream with O(1) extra space. Estimating separate hazards with covariates is more costly and needs adequate events per type. No amount of model fitting compensates for a mislabeled withdrawal event.

Common Mistakes

Calling a cause-specific hazard ratio a risk ratio.
Reporting target-event incidence without counting competing events.
Using a first-event analysis to claim something about later reopenings.
Ignoring censoring related to unrecorded difficulty.