Why Event-Type Coding Matters
An absolute-risk prediction for a particular cause depends on knowing which first event occurred, not merely whether some event occurred. If a person is followed until a target event, a different failure, or the end of observation, those outcomes have different meanings. In particular, a competing event is an observed failure that prevents the target first event from occurring later as the first event; censoring means that observation ended without an observed failure by that time.
Coding is therefore part of defining the prediction target. A record that marks a competing event as censoring, or marks early loss to follow-up as a competing event, does not simply contain a formatting error: it describes a different observed outcome. The coding scheme below is for a standard first-event competing-risks target with a fixed set of causes.
This definition assumes one record per person for the specified first-event outcome; a clear time origin and event definition; and a cause list that is stated in advance, exhaustive for the failures being classified, and mutually exclusive. “Exhaustive” means every qualifying first failure can be assigned a listed cause. “Mutually exclusive” means a single first failure receives exactly one cause code. If the scientific question is about recurrent events, multiple simultaneous outcomes, or transitions among several states, this simple first-event coding is not sufficient without a different data structure and target definition.
A censoring code does not assert that no event will ever occur. It says only that no qualifying event was observed before the person’s observation ended. The coding also does not say that censoring is statistically independent of future event risk. That is a separate assumption relevant to estimation and prediction procedures; correct coding cannot make an unsupported censoring assumption true.
Constructing the Observed Outcome
The practical task is to translate each person’s history into a single observed time, an event indicator, and, if an event was observed, exactly one event-type code. The event time must refer to the first qualifying failure under the stated target. Follow-up ending while the person is still event-free contributes a censoring time, not a failure cause. A different observed failure before the target cause is a competing event, not censoring.
State the time origin, what counts as the first event, and the mutually exclusive cause categories. Make clear whether an event outside the target definition is ignored, treated as a competing event, or changes the target.
Record the event time if a qualifying first event was observed before follow-up ended. Otherwise record the last time the person was known to be event-free as the observed censoring time.
Use a distinct code from 1 through \(K\) for the adjudicated cause of an observed event. Use 0 only when the record is right-censored without an observed qualifying event.
Check that event indicators and codes agree, event times are valid, no person has two first-event causes, and any tied or uncertain records follow the prespecified protocol.
Worked Example: Coding First Events and Censoring
Suppose a hypothetical study follows people from enrollment and records the first of two failures: cause A or cause B. Follow-up ends at the stated last event-free time if neither failure has occurred. For illustration, code A as 1, B as 2, and censoring as 0. The table gives the recorded histories.
| Person | Recorded history | \(\tilde T\) (days) | \(\Delta\) | \(\tilde J\) |
|---|---|---|---|---|
| P1 | Cause A at day 12 | 12 | 1 | 1 |
| P2 | Cause B at day 9 | 9 | 1 | 2 |
| P3 | Event-free through day 15; follow-up ends | 15 | 0 | 0 |
| P4 | Cause B at day 6, before any cause A | 6 | 1 | 2 |
| P5 | Cause A at day 18 | 18 | 1 | 1 |
P1 and P5 receive code 1 because their first observed failures are cause A. P2 and P4 receive code 2 because their first observed failures are cause B. P3 receives code 0: the person was known to be event-free through day 15, but no failure was observed. The event indicator and code must agree: \(\Delta=1\) for codes 1 and 2, and \(\Delta=0\) for code 0. In this hypothetical data, the event-type counts are 2 for cause A, 2 for cause B, and 1 censored; those counts sum to the 5 people recorded.
The one-code rule can be expressed with indicator variables. For each cause \(k\), let \(I(\tilde J=k)\) indicate that cause \(k\) was observed, and let \(I(\tilde J=0)\) indicate censoring. Because every record is either censored or has exactly one assigned cause, exactly one of these indicators equals 1:
This identity is a simple but useful audit. If its left side is 0, a record has no valid status. If it exceeds 1, the record has conflicting statuses or multiple cause codes. It is not a probability calculation; it checks that each person occupies one and only one observed-outcome category.
Aligning Codes With a Prediction Horizon
Event-type coding and a horizon-specific prediction label are related but not identical. The event-type record describes what was observed and when. For a prediction target such as cause \(k\) by time \(\tau\), a person with an observed cause-\(k\) event by \(\tau\) has that outcome. A person with a different cause by \(\tau\) has a competing first event. A person known to be event-free through \(\tau\) has no event by the horizon. But a person censored before \(\tau\), with no prior event, has an unknown horizon outcome—not a known no-event outcome.
For an observed event after \(\tau\), the person is known to have had no first event by \(\tau\). For censoring after \(\tau\), the person was also observed event-free through \(\tau\). In contrast, censoring before \(\tau\) does not establish the person’s status at \(\tau\). Keeping the full event-time and event-type record preserves this distinction; replacing every record with a simple yes/no label can erase it.
Worked Example: Labeling Status at a Fixed Horizon
Use the five hypothetical records above and set \(\tau=10\) days. The target is cause A by day 10. P1 has cause A at day 12, so P1 is known not to have had cause A by day 10. P2 has cause B at day 9, so a competing first event occurred by the horizon. P3 is censored at day 15, after being observed event-free through day 10, so P3 is known to have had no first event by the horizon. P4 has cause B at day 6, also a competing event by the horizon. P5 has cause A at day 18 and is known not to have had cause A by day 10.
For this horizon, there are 0 observed cause-A events by day 10, 2 competing first events by day 10, 3 people known to be event-free through day 10 or to have their first event later, and 0 people censored before day 10. These are labels derived from the histories, not an estimate of population risk. If P3 had instead been censored at day 7 without a prior event, P3’s status at day 10 would be unknown and should not be recoded as “no event by day 10.”
Before using the coding for prediction, confirm the following conditions in the data and documentation:
- The time origin, time units, qualifying event definitions, and prediction horizon are consistent across records.
- Each observed first failure has one adjudicated cause from the cause list; no unclassified failure is silently converted to censoring.
- Code 0 is reserved for censoring, rather than used for a competing cause, an event-free state at a fixed date, or missing cause information.
- The event indicator agrees with the event-type code, and an event time does not occur after the recorded end of observation.
- Same-time events, uncertain dates, and records with conflicting cause documentation are handled under a stated, reproducible rule.
Ambiguity, Alternatives, and Failure Modes
Some records cannot be coded correctly by applying a mechanical rule to a spreadsheet. If two causes are recorded at the same time, the analyst must determine whether the record reflects a genuine simultaneous event, rounded dates, or a data-entry conflict. Under a first-event competing-risks target, the causes must ultimately be made mutually exclusive. A defensible solution may require reviewing source records or applying a clinically justified adjudication rule; choosing a cause arbitrarily merely to satisfy software is not a valid resolution. If the scientific question treats simultaneous events as a distinct outcome, that category must be specified explicitly and the target redefined accordingly.
A composite endpoint is a different legitimate choice when the goal is to predict the occurrence of any of several failures. It combines selected causes into one outcome and no longer answers a cause-specific risk question. Similarly, recording separate yes/no variables for each cause can allow one person to be counted as having multiple first-event outcomes, violating the single first-event coding structure. Those choices may suit other questions, but they should not be substituted without changing the stated prediction target.
A common mistake is to code a competing failure as censoring because the person can no longer experience the target cause as a first event. The reasoning confuses “cannot later be the target first event” with “was not observed to fail.” The correction is to assign the competing cause its own event code. Another common mistake is to assign code 0 to every person without the target event by \(\tau\). That incorrectly treats known competing events and people censored before \(\tau\) alike as observed non-events. Keep the cause and time information, and distinguish competing failures from censoring before constructing any horizon-specific labels.
Coding is necessary for prediction but does not by itself determine an estimator, validate the model, or establish the assumptions required to estimate absolute risk. Earlier material on probability coherence and bounds addresses checks on predicted quantities; this coding step instead checks whether the observed outcome supplied to a prediction procedure matches the intended cause-specific target. A perfectly consistent code can still accompany incomplete follow-up, misclassified causes, or a censoring mechanism that requires further assessment.
Worked Example: Resolving a Cause-Code Conflict
In a hypothetical database, cause A is recorded at day 20, but the follow-up form says that a first cause-B event occurred at day 14. The database currently contains \(\tilde T=14\), \(\Delta=1\), and \(\tilde J=1\), using code 1 for A and code 2 for B.
The record is internally inconsistent: the recorded time points to the day-14 first event, while the cause code points to the day-20 event. Under the stated first-event target, the day-20 event cannot be coded as the first event if the cause-B event at day 14 is confirmed. If source review confirms cause B at day 14 as the first failure, the corrected record is \(\tilde T=14\), \(\Delta=1\), \(\tilde J=2\); the later cause-A event does not replace the first-event code. If review instead shows that the day-14 entry is erroneous and cause A at day 20 is the first confirmed failure, the record is \(\tilde T=20\), \(\Delta=1\), \(\tilde J=1\). If the conflict cannot be resolved, it should be flagged and handled under a documented data-quality plan, not silently assigned to whichever code makes the table consistent.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A person has cause B at day 7, and the target is cause A as the first event. What are \(\tilde T\), \(\Delta\), and \(\tilde J\) if B is coded 2?
- With horizon \(\tau=12\), a person is event-free when last observed at day 9. Is the person known to have no event by day 12?
- A dataset assigns both cause 1 and cause 2 to one person’s first event. What coding requirement has failed, and what should be done?
- Why is a person censored at day 16 with no prior failure known to be event-free at day 12, while a person censored at day 8 is not?
Solutions. (1) The observed first failure is cause B at day 7, so \(\tilde T=7\), \(\Delta=1\), and \(\tilde J=2\). It is a competing event for the cause-A target, not censoring. (2) No. Follow-up ended before day 12, so the person’s outcome between days 9 and 12 is unobserved; horizon status is unknown. (3) Mutual exclusivity has failed: one first event must receive exactly one cause code. Review and adjudicate the source information using the prespecified rule, or flag the unresolved record rather than assigning a cause arbitrarily. (4) Censoring at day 16 means the person was observed through day 12 without an event, so no first event by day 12 is known. Censoring at day 8 leaves days 8 through 12 unobserved, so an event by day 12 cannot be ruled out.