Why Event-Type Coding Matters
A competing-risks data set records more than whether an event occurred. It records which event occurred first, or whether follow-up ended without an observed event. A cause-specific Cox analysis must preserve that distinction in the source data and then identify which recorded event counts as the event of interest for the particular model being fitted. A mistaken status code can turn a competing event into the target event, or treat the target event as censoring, changing the analysis rather than merely changing its presentation.
The basic coding task has two parts: store one observed follow-up time and one event-type code for each subject, then create a target-specific event indicator. The original event-type code should be retained. It allows the target indicator to be checked and makes it possible to build a correctly coded analysis for another cause without reconstructing information that has been discarded.
The time and status have different roles. \(T_i\) answers when did observed follow-up end? \(J_i\) answers why did it end? A status value is not a duration, and an event-type code is not a numerical ranking of severity. The code labels are arbitrary so long as they are defined consistently and interpreted correctly.
The Source Record and the Cause-Specific Analysis Record
In the source record, keep one row per subject for the first-event analysis, with the observed time, the original event type, and relevant covariates. For example, if the event codes are 0 for censoring, 1 for relapse, and 2 for death before relapse, the source status should retain 0, 1, and 2 as distinct values. The labels should be documented alongside the data, rather than inferred from memory or from the order of values in a software output.
For a Cox model focused on relapse, use \(\delta_{i1}=I(J_i=1)\) as the event indicator. A relapse is coded 1; censoring and a competing death are both coded 0 for this particular cause-specific event indicator. Their original values remain different in \(J_i\). If instead the model concerns cause 2, construct \(\delta_{i2}=I(J_i=2)\). Thus, the binary status is specific to the cause being modelled: it is not a replacement for the multi-category source status.
For a conventional cause-specific Cox fit, the time supplied is the recorded \(T_i\), and the binary event indicator supplied for cause \(k\) is \(\delta_{ik}\). This coding identifies target-cause events; it does not label a competing event as though it were the target. The cause-specific hazard is the instantaneous rate of cause \(k\) among subjects who have not yet experienced any event, conditional on the covariates in the model. The coding does not require assuming that hypothetical times to different causes are independent.
Assumptions and Scope of the Coding
The interpretation above applies when the analysis concerns the first event among a set of well-defined, mutually exclusive causes. Each subject has one time origin, a recorded follow-up endpoint, and at most one observed first-event cause. Event codes should refer to the event that actually ended event-free follow-up, not to every condition a subject may have experienced during the study. If the scientific question concerns recurrent events, transitions after an initial event, or multiple simultaneous outcomes, a one-row first-event record may not represent the process being studied.
Censoring is distinct from a competing event in the source data. Censoring means the target event and other events were not observed before follow-up ended; a competing event means another specified event occurred and ended the first-event follow-up. For valid Cox inference, the censoring mechanism must be noninformative for the relevant event-time analysis conditional on the covariates and design information used. Correct event coding cannot repair informative loss to follow-up, inaccurate times, or a misclassified cause.
Keep entry time, if subjects enter observation after the time origin, in a separate entry-time field; do not encode delayed entry as an event type or change the event code to compensate for it. Likewise, time units must be consistent across records, and the time origin must be defined. A record with time measured in days should not be combined uncritically with one measured in months. Tied event times are a modelling and software-handling issue; they are not a reason to alter the event-type codes.
Worked Example: Creating the Indicator for Relapse
Suppose a hypothetical study follows six subjects from randomization. The agreed source codes are 0 = censored, 1 = relapse, and 2 = death before relapse. For a cause-specific Cox analysis of relapse, calculate \(\delta_{i1}=I(J_i=1)\) for every subject.
| Subject | \(T_i\) (months) | \(J_i\) | Recorded outcome | \(\delta_{i1}\) |
|---|---|---|---|---|
| A | 4 | 1 | Relapse | 1 |
| B | 7 | 0 | Censored | 0 |
| C | 3 | 2 | Death before relapse | 0 |
| D | 9 | 1 | Relapse | 1 |
| E | 6 | 0 | Censored | 0 |
| F | 8 | 2 | Death before relapse | 0 |
For subject A, \(J_A=1\), so \(\delta_{A1}=I(1=1)=1\). For subject B, \(J_B=0\), so \(\delta_{B1}=I(0=1)=0\). Subject C has \(J_C=2\), and \(I(2=1)=0\); the same calculation gives 0 for F. Subject D has \(I(1=1)=1\), and E has \(I(0=1)=0\). The resulting target-specific status vector, in row order, is \((1,0,0,1,0,0)\).
The input times remain \((4,7,3,9,6,8)\) months. In particular, the 3 months for subject C is not replaced by a missing time or by a later time: it is the observed time of the competing event. The original code \(J_C=2\) should also remain available in the source data, even though the relapse-specific indicator for C is 0.
A Reproducible Coding Workflow
A disciplined workflow makes the mapping explicit before fitting a model. It also separates errors in the raw event history from errors in constructing the status variable for a particular cause.
Write down the time origin, the event-free follow-up endpoint, the causes that count as first events, and the meaning of censoring.
Assign one distinct code to each cause and a separate code to censoring. Check that every permitted value has a written definition.
Confirm that time is observed and valid, and that the event code agrees with the documented follow-up outcome.
For the chosen cause \(k\), set \(\delta_{ik}=1\) exactly when \(J_i=k\), and set it to 0 otherwise.
Compare the count of target events with the number of rows for which \(J_i=k\), and check the time and event fields passed to the model.
This workflow follows directly from the definition of the indicator. Among all records with a valid source status, the number of target events must satisfy
If these counts differ, the target indicator was not generated from the stated codebook or the records changed between coding and fitting. This check is simple, but it detects common failures such as using the wrong target code or converting a status field inconsistently.
Worked Example: Auditing Codes Before Fitting
Consider a hypothetical extract with five records. The codebook says 0 = censored, 1 = relapse, and 2 = death before relapse. The extract is shown below.
| Subject | Time (months) | Status in extract | Documented outcome |
|---|---|---|---|
| G | 5 | 1 | Relapse |
| H | 4 | 0 | Death before relapse |
| I | 6 | 2 | Death before relapse |
| J | 0 | 0 | Censored at study start |
| K | 7 | 1 | Relapse |
For the relapse model, the indicator generated mechanically from the extract is \((1,0,0,0,1)\), because only status 1 maps to \(\delta_{i1}=1\). The event count is therefore \(1+0+0+0+1=2\), matching the two records with status 1. That arithmetic check alone does not establish that the extract is correct: subject H is documented as having a competing death, but status 0 means censoring. The source record and codebook disagree, so H must be investigated and corrected from the underlying record before analysis. Do not simply change the relapse-specific indicator; the source event type itself is wrong.
Subject J requires a separate review. A follow-up time of 0 may be possible under a particular time convention, but it can also signal a date-subtraction or time-origin error. The correct action depends on the study design and source dates. It is not valid to change the time just to make the model run. After resolving the two issues, regenerate the indicator and repeat the audit.
Deriving Indicators for More Than One Cause
The original cause code can be used to construct a separate binary indicator for every cause. For \(K\) mutually exclusive causes, each record has one source value \(J_i\), and the cause-specific indicators are \(\delta_{i1},\ldots,\delta_{iK}\). If subject \(i\) has an observed cause \(j\), then \(\delta_{ij}=1\), while the indicators for all other causes are 0. If subject \(i\) is censored, all cause-specific indicators are 0.
This identity is a useful validation check for mutually exclusive first events. A row with two cause indicators equal to 1 contradicts the one-first-event coding scheme. A row with all indicators equal to 0 is expected for censoring, but not for a record whose source status identifies an observed event.
Worked Example: Three Causes and Two Target Models
A hypothetical registry uses the codes 0 = censored, 1 = disease recurrence, 2 = treatment toxicity, and 3 = death from another cause before either event. For a subject with \(T_i=11\) weeks and \(J_i=2\), calculate the three indicators and identify the event status for recurrence and toxicity analyses.
For recurrence, \(\delta_{i1}=I(2=1)=0\). For toxicity, \(\delta_{i2}=I(2=2)=1\). For death from another cause, \(\delta_{i3}=I(2=3)=0\). Their sum is \(0+1+0=1\), as expected for one observed first event. The source time remains 11 weeks and the source cause remains code 2.
If the same subject is included in a recurrence-specific Cox analysis, the supplied event indicator is 0, not 1. If included in a toxicity-specific analysis, the supplied event indicator is 1. The record is not reclassified in the source data when the target model changes; only the derived indicator changes. The event-time unit remains weeks in both analyses.
Common Mistakes, Diagnostics, and Limits
Several coding errors are easy to miss because the model may still produce output. The checks below should be done against the study definitions and source records, not just against the fitted model’s event count.
- Using one generic nonzero code for every event. This loses the cause distinction. Keep each cause identifiable in the source status, then create the binary indicator for the chosen target cause.
- Coding every observed event as the target event. A competing cause is not a target-cause event. For cause \(k\), check that \(\delta_{ik}=1\) only if \(J_i=k\).
- Calling competing events censored in the source data. They may have indicator 0 in a particular target-cause model, but their source cause code must remain distinct from ordinary censoring.
- Reversing the software’s event convention. Some interfaces use 1 for an event and 0 for censoring, while others allow different conventions or factor labels. Confirm the model interface’s interpretation rather than assuming it.
- Dropping or altering event times for competing events. Preserve the observed first-event time. Check that time and status refer to the same subject and the same follow-up endpoint.
- Assuming the indicator count proves all coding is correct. A wrong source status can still produce a self-consistent indicator. Compare status codes with independently documented outcomes.
A cause-specific Cox analysis is not itself an absolute-risk calculation. The cause-specific hazard describes the rate of a particular event among those still event-free at a given time; it does not by itself give the probability of experiencing that cause by a future horizon in the presence of competing events. Absolute-risk prediction requires combining information about the relevant causes, as covered in the earlier material on competing-risk prediction. Fine-Gray regression uses a different modelling setup and should not be given the cause-specific binary input merely because the same original cause codes are available.
The coding also cannot compensate for an unclear event definition, inconsistent adjudication, informative censoring, or an analysis population that does not match the intended first-event question. If event types overlap by definition or events can occur repeatedly, clarify the outcome structure before applying this one-first-event representation.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A source codebook defines 0 = censored, 1 = stroke, and 2 = myocardial infarction. For a myocardial-infarction-specific Cox analysis, what is the event indicator for a subject with \(T_i=15\) days and \(J_i=1\)? What should remain in the source record?
- For a three-cause first-event analysis, a subject is observed to have cause 3. What are \(\delta_{i1},\delta_{i2},\delta_{i3}\), and what is their sum?
- An extract has four rows with status codes \(1,0,2,1\), under a codebook with 0 = censoring, 1 = relapse, and 2 = competing death. Calculate the number of relapse events and say what mismatch check should be made.
- Explain why a competing event can have a target-specific indicator of 0 without being coded as ordinary censoring in the source data.
Solutions. (1) The indicator is \(\delta_{i2}=I(1=2)=0\). Retain \(T_i=15\) days and the original \(J_i=1\), identifying stroke. (2) The indicators are \((0,0,1)\), with sum 1 because one first event was observed. (3) The relapse indicator vector is \((1,0,0,1)\), so there are 2 relapse events. Compare this count with the number of source rows whose status is 1, and also verify each source code against its documented outcome. (4) The binary indicator answers whether the event was the chosen target cause; it does not redefine the observed outcome. The original source code preserves the distinction between a competing event and follow-up ending without an observed event.