Common Event-Coding Errors in Fine-Gray Software

Why Event Coding Deserves an Audit

Fine-Gray regression models the subdistribution hazard for a particular event cause. Software cannot infer which event you intend to study: it uses the status values and options supplied to it. If a competing event is coded as censoring, or the selected failure code names the wrong event, the fitted model can target a different quantity from the one in the analysis plan. The output may still look numerically plausible.

A reliable audit starts with the raw event records, not the regression table. For each person, verify the observed follow-up time, whether an event was observed, and—if so—which mutually exclusive event occurred first. Then verify that those facts are represented correctly in the software’s inputs and options. This tutorial focuses on these data and software checks; it does not replace the earlier material on Fine-Gray regression or censoring assumptions.

Definition: Let \(T\) be the time to the first event, \(C\) the censoring time, \(X=\min(T,C)\) the observed follow-up time, and \(J\) the event cause when an event is observed. For a chosen cause \(k\), a convenient software-independent status variable \(G\) is \(G=0\) for right-censoring and \(G=j\) when cause \(j\) occurs at \(X=T\). Thus \(G=k\) identifies the event of interest, \(G\ne k\) and \(G>0\) identifies a competing event, and \(G=0\) identifies censoring. Numeric codes are conventions, not universal meanings: the code and the software option that selects cause \(k\) must agree.

This setup assumes that the recorded event is the first event in the competing-risk process, that event types are mutually exclusive as recorded, and that the time and event-status fields refer to the same follow-up history. Censoring means that event status becomes unknown after the recorded time; it does not mean that a different event occurred. The validity of model-based inference also requires an appropriate censoring assumption, possibly conditional on covariates or handled using weights, as established in the earlier material.

What the Software Must Represent

For cause \(k\), the cumulative incidence function is \(F_k(t)=P(T\le t,J=k)\). Fine-Gray regression represents its evolution using the subdistribution hazard. In a proportional subdistribution-hazards model, the covariate effect is commonly written \(\exp(\beta^\mathsf{T}Z)\). The input status code determines which observed events contribute as failures for this model.

\widetilde{\lambda}_k(t\mid Z) = \widetilde{\lambda}_{k0}(t)\exp(\beta^\mathsf{T}Z)

A key distinction is that Fine-Gray regression does not simply treat every competing event as ordinary censoring. Conceptually, a person who has already experienced a competing event remains represented in the subdistribution risk set for cause \(k\), with the method’s prescribed risk-set construction and censoring adjustments. A right-censored person, by contrast, is no longer observed after censoring. Coding both records as status zero removes the distinction the model needs.

Software interfaces differ. Some accept a numeric status vector plus a specified failure code and censor code; others use a factor or a multi-state survival object and a named event type. Do not assume that “1” always means the event of interest, or that a package’s default failure code matches your data. Before fitting, write down the mapping between the data values and the software arguments. For example, a function with arguments such as failcode and cencode requires the selected cause and censor code to be set consistently with the actual status values.

Worked Example: Selecting the Intended Failure Code

Suppose a hypothetical dataset follows 120 patients for a first event. The data dictionary defines status 0 as censored, 1 as disease recurrence, and 2 as death before recurrence. The analysis target is recurrence. A frequency check gives 24 records with status 1, 18 with status 2, and 78 with status 0.

The intended target count is 24, the competing-event count is 18, and the censored count is 78. Therefore the model input must identify status 1 as the failure code and status 0 as the censor code. Status 2 must remain a non-target event, not be recoded to zero.

If the software is mistakenly told that status 2 is the failure code, its target count will be 18, not 24: it is modeling death before recurrence as the event of interest. The arithmetic check is immediate: \(24+18+78=120\), and the selected-cause event count must match the count for the intended cause. A regression table that reports 18 target failures is a warning to check the selected cause, even if estimation completed without an error.

A Derivation: Why These Codes Change the Target

The status coding is not merely a label attached to an otherwise unchanged fit. It determines which cause-specific cumulative incidence the model represents. To see the distinction, consider the empirical event records before fitting a regression. For each observed event time, records with \(G=k\) identify increments in the cumulative incidence for cause \(k\); records with \(G=j\ne k\) identify increments in a different cause’s incidence. Censored records identify neither type of event at their censoring time.

If cause \(j\) is recoded as the target, then the indicator used to identify target failures changes from \(I(G=k)\) to \(I(G=j)\). Unless these indicators are identical for every record—which they are not when both causes occur—the event increments being modeled differ. If cause \(j\) is instead recoded as censoring, its event records are removed from the competing-event category. That also changes the data representation used to construct the target’s subdistribution risk sets and cumulative incidence.

I(G=k)\ne I(G=j) \quad\text{for records with }G=k\text{ or }G=j, \qquad k\ne j

This establishes why a successful optimizer cannot validate the cause coding: it can converge correctly for the model implied by the supplied data, even when that model is not the one intended. Independent checks of the event mapping and target-event count are necessary.

Worked Example: Competing Events Mistaken for Censoring

Consider 10 hypothetical patients followed through day 10. The event records are: 2 recurrence events on day 4, 1 death-before-recurrence event on day 6, 2 recurrence events on day 8, 1 censoring at day 5, and 4 patients event-free and observed through day 10. For recurrence, the intended status counts are 4 target events, 1 competing event, and 5 right-censored observations.

Suppose the data preparation step sets status to 1 for recurrence and to 0 for both death and actual censoring. The software now sees 4 failures and 6 censored observations. The failure count still equals 4, so checking only the target count will not catch the error. But the competing-event count has fallen from 1 to 0, while the censor count has risen from 5 to 6.

The correction is to preserve three categories: recurrence \(=1\), death before recurrence \(=2\), and right-censoring \(=0\), then select cause 1 as the target. This gives \(4+1+5=10\) records. Coding the death as censoring incorrectly tells the analysis that the patient’s event status became unknown on day 6, rather than recording a known competing event. The input no longer describes the observed competing-risk process required for the intended Fine-Gray analysis.

Audit Follow-Up Times as Carefully as Statuses

A correct status vector paired with incorrect times is still incorrect input. Common problems include mixing days and months, using a date of last contact for event cases instead of the event date, using a time origin inconsistent with the study definition, and recording a competing-event time differently from the target-event time. In the basic setup, \(X\) is the time to the first event or censoring, whichever occurs first. An event status and its recorded time must refer to that same endpoint.

A uniform conversion, such as converting every time from days to months by dividing by 30.44, preserves event ordering and ordinarily changes the unit of the time axis rather than which cause is targeted. However, mixing units across records can reorder events and change follow-up comparisons. It also makes predictions at stated time horizons easy to misreport. Check units and the time origin before fitting, not only when preparing figures.

Worked Example: Detecting a Mixed Time Scale

In a hypothetical data file, patient A has recurrence at 90 days, patient B has a competing event at 4 months, and patient C is censored at 180 days. The software requires one time unit. If the values are entered as 90, 4, and 180 without conversion, patient B’s competing event is treated as occurring at time 4 in the same unit as the other values—effectively day 4 if the chosen unit is days.

Convert all records to days: A has \(90\) days, B has \(4\times30.44=121.76\) days, and C has \(180\) days. Their time order is therefore A, B, C. In the mixed file, the apparent order is B, A, C. The competing event has been moved from after the target event to before it, which can alter the risk-set construction and the estimated cumulative incidence.

A time audit should check plausible ranges, units, event-date minus origin-date calculations, and whether event and censor times are positive and correctly ordered. If the software accepts a record with an impossible time, that is not evidence that the time is valid.

A Practical Verification Workflow

Use a reproducible audit before interpreting a fitted model. The following steps make the mapping explicit and provide checks that are independent of the regression coefficients.

Specify the analysis target.
Name the exact first event cause of interest and the time origin. Do not rely on an undocumented numeric code.

Reconcile raw records with the data dictionary.
Tabulate each status value and inspect examples from every category. Confirm that known competing events are not grouped with right-censoring.

Match software options to the mapping.
Check the failure-code, censor-code, event-type, and factor-level settings. Confirm the selected cause in the function call or model object.

Validate follow-up time.
Check units, time origin, date calculations, missing values, nonpositive values where disallowed, and consistency between an event’s status and event time.

Compare independent summaries.
Compare the software’s target-event count and cause-specific cumulative-incidence output with summaries computed directly from the intended status mapping.

For an additional check, compute a nonparametric cumulative incidence estimate using the same cause labels and time definition. The regression model need not reproduce the nonparametric curve exactly, particularly when covariates are included, but a target-event count mismatch or a curve corresponding to another cause indicates a coding or selection problem. A cause-specific Cox analysis is a different model and does not make Fine-Gray coding errors harmless; it can be a useful separate analysis only when its estimand and event handling are appropriate.

Common Failure Modes and Limitations

Assuming the software’s default code is universal. Defaults vary. Verify them in the function call and documentation, and compare the selected failure count with a direct tabulation.
Using a binary event indicator for a multi-cause outcome. If all non-target outcomes are set to zero, competing events become indistinguishable from censoring. Preserve cause labels in the analysis input.
Selecting the wrong cause while retaining valid codes. A model can run normally but estimate the subdistribution hazard for the wrong cause. Check the selected cause name or code and its event count.
Using incompatible time fields. A status field based on first event combined with a time field based on last contact creates contradictory records. Derive both from the same event-history definition.
Assuming a coding check validates the model assumptions. Correct event coding does not establish independent censoring, proportional subdistribution hazards, or correct covariate specification. Those require their own assessment.

The audit also has limits. A frequency table cannot establish that event dates were recorded correctly, and matching event counts cannot establish that cause labels were assigned correctly person by person. Review source records when labels are ambiguous, document recoding decisions, and preserve the original fields so the analysis can be reproduced. When events are not mutually exclusive or the endpoint is not a first-event outcome, the simple status scheme may not represent the intended process; resolve the endpoint definition before applying it.

Key takeaway: A Fine-Gray fit is only as well targeted as its event mapping. State the cause of interest, keep competing events distinct from censoring, align the software’s cause and censor settings with the data dictionary, and verify both the event counts and the time construction before interpreting output.

Check Your Understanding

Answer each question, then compare with the solutions below.

Status 0 means censored, status 1 means relapse, and status 2 means death before relapse. The target is relapse. Which status is the failure code, and which status is the censor code?
A dataset contains 12 target events, 7 competing events, and 31 censored records. After recoding, the software reports 12 failures and 38 censored records. What likely went wrong?
Why does a successful model fit not prove that the intended cause was selected?
All observed follow-up times were recorded in days except one competing-event time recorded in months. Why can this affect a Fine-Gray analysis?
Name two checks beyond the target-event count that help audit the input.

Solutions. (1) Use status 1 as the failure code and status 0 as the censor code; preserve status 2 as a competing event. (2) The 7 competing events were likely recoded as censoring, since the censored count increased from 31 to 38 while the target count stayed at 12. (3) The software can converge for the cause specified by the supplied codes even if that cause is not the analyst’s intended endpoint. (4) The mixed unit can place the competing event at the wrong time, changing event ordering and the risk-set information. (5) Examples include checking the competing-event and censor counts separately, verifying the cause-selection option, checking event and censor times against source dates, and comparing a nonparametric cumulative incidence estimate using the same cause labels.