Why Time Encoding Matters
A joint model can only use the event history that its input data represent. If a recorded event time is measured from enrollment but longitudinal measurements are timed from diagnosis, the two parts of the analysis no longer refer to the same timeline. Likewise, treating a subject who joined a study late as observed from time zero incorrectly places that subject in earlier risk sets. These are data-encoding errors, not model-fitting details.
The key task is to describe, for each subject, a common time origin, when observation of the event process begins, when it ends, and whether the end was an event or censoring. The rules below apply whether software expects one event row per subject or a start-stop representation. Exact input names and event-code conventions vary, so the software documentation must be checked before mapping these quantities to columns.
When everyone enters at the origin, \(A_i=0\). With delayed entry, \(A_i>0\): the subject is known to be event-free and under observation at entry, but contributes no observed person-time before entry. The interval notation \((A_i,Y_i]\) means the subject is at risk at event time \(t\) when \(A_i<t\le Y_i\). This convention includes the endpoint \(Y_i\) and excludes the entry instant. If the study records an event at exactly the recorded entry time, the data definition and software’s tie convention must be resolved; the usual positive-length follow-up representation does not silently determine how such a record should be handled.
From Dates to a Consistent Time Scale
Choose an origin that matches the scientific question and the intended analysis. Examples include randomization, diagnosis, birth, or a defined calendar date. Then express entry, event, censoring, and any longitudinal measurement times on the same scale and in the same units. If the origin is enrollment, a visit 90 days after enrollment and an event 180 days after enrollment are represented as 90 and 180 days. A calendar date is not itself an elapsed time unless the input format explicitly expects calendar dates.
The origin is part of the data definition, not a harmless display choice. Subtracting a constant from every time can preserve their ordering, but it does not fix a mismatch in which some columns use age and others use time since enrollment. For a subject entering an age-based analysis at age 52, for example, entry is 52 years—not zero—if the chosen origin is birth. Resetting that subject’s time to zero at entry changes the time scale and erases the fact that the subject entered at age 52.
Worked Example: Converting Follow-Up Dates to Elapsed Time
Suppose a hypothetical study defines day 0 as enrollment. Three subjects have these histories: subject A has an event on day 180; subject B has no event and last contact on day 150; subject C joins the event follow-up on day 60 and has an event on day 210. All dates are already expressed as days since enrollment.
For A, entry is \(A_A=0\), the observed exit is the event time \(Y_A=180\), and \(\delta_A=1\). Its record is entry 0, exit 180, event indicator 1. For B, \(A_B=0\), \(Y_B=C_B=150\), and \(\delta_B=0\). Its record is entry 0, exit 150, event indicator 0. For C, \(A_C=60\), \(Y_C=T_C=210\), and \(\delta_C=1\). Its record is entry 60, exit 210, event indicator 1.
The observed interval for C is \((60,210]\), a length of \(210-60=150\) days. It is not \((0,210]\): the subject was not under observed event follow-up during the first 60 days. In a software interface that uses separate entry, exit, and status columns, the conceptual rows are \((0,180,1)\), \((0,150,0)\), and \((60,210,1)\). The column names and required status coding must be confirmed for the selected software.
Right Censoring and the Event Indicator
Right censoring means that an event has not been observed by the end of a subject’s follow-up. The observed information is that the event time exceeds the censoring time, not that the event occurred at the censoring time. Accordingly, the exit-time column contains the last time at which the subject’s event status is known, while the event indicator distinguishes an event endpoint from a censoring endpoint. A follow-up end date must not be assigned an event indicator of 1 merely because it is the last recorded date.
The encoding assumes that event status is correctly ascertained through each recorded exit time and that the censoring mechanism is appropriate for the intended analysis. In a standard survival analysis, independent censoring is usually required, at least conditional on modeled covariates: after conditioning, the event process for subjects who remain observed should not be selectively censored in a way that carries unaccounted information about their event time. Correct columns do not make an informative censoring mechanism ignorable.
The meaning of 0 and 1 is not universal across software. Some interfaces use 1 for an event and 0 for censoring; others allow a different event value or require a factor with a specified reference level. Define the meaning in the analysis plan, then recode explicitly to match the software rather than assuming the convention from a variable name. A competing event is also not automatically ordinary right censoring: whether it is handled as a competing risk or in another way is a separate modeling decision.
Worked Example: Checking Risk-Set Membership With Delayed Entry
Consider four hypothetical subjects, all measured in months from the same origin. Their records are: P, entry 0, exit 8, event; Q, entry 3, exit 8, censored; R, entry 5, exit 10, event; S, entry 8, exit 12, event. For this example, assume the records are valid, all subjects are event-free at entry, and the interval convention is \((A_i,Y_i]\).
At time \(t=8\), a subject is at risk if \(A_i<8\le Y_i\). P satisfies \(0<8\le8\), Q satisfies \(3<8\le8\), and R satisfies \(5<8\le10\). S does not satisfy the condition because \(A_S=8\), so \(8<8\) is false. Thus the risk set just before the event endpoint at month 8 is P, Q, and R. P has the event at 8; Q is censored at 8; R remains under observation beyond 8.
At time \(t=10\), R satisfies \(5<10\le10\), and S satisfies \(8<10\le12\). P and Q have already exited. The risk set is therefore R and S, with R experiencing the event at 10. This check catches a common delayed-entry error: if S were incorrectly coded as entering at zero, it would appear in the risk set at times before month 8, although it was not yet observed.
A Short Derivation of the Risk-Interval Check
The risk-set rule follows directly from the observed interval. Subject \(i\) is under observation after entry, so a candidate event time must satisfy \(t>A_i\). The subject has not yet exited at times beyond \(Y_i\), so it must also satisfy \(t\le Y_i\). Combining the two conditions gives the at-risk indicator
An observed event at time \(t\) additionally requires that the subject’s exit is an event endpoint. Its event indicator at that time is therefore represented by
This distinction matters when subjects share an exit time. At month 8 in the example, both P and Q are in the risk set immediately before the endpoint, but only P has an event; Q is censored. A software representation should retain both facts rather than infer the event indicator from the exit time alone.
Putting the Fields Into a Software Input
In a simple subject-level event table, the essential conceptual fields are an identifier, entry time, exit time, and event indicator. Each row should describe one subject’s event-follow-up interval unless the software explicitly requires a different structure. If there is no delayed entry, entry is zero for all subjects on the chosen scale. The longitudinal table may have multiple rows per subject, but its measurement times still need to be interpretable relative to the same origin used for event follow-up.
Before fitting anything, perform mechanical checks on the encoded values. For every subject, verify that the entry and exit times are finite, use the intended unit, and satisfy \(A_i<Y_i\) under the standard positive-length interval convention. Check that the event indicator has only the allowed values and that its coding agrees with the source records. Review a small number of records against their dates by hand, including at least one event, one censoring time, and one delayed entry if present. If a subject’s event or censoring time precedes entry, the row is inconsistent as a valid observed follow-up interval and needs investigation rather than automatic correction.
Write down the origin and unit, such as days since randomization or age in years, before deriving any time column.
Convert dates to that clock. Set entry to the actual beginning of event observation and exit to the observed event or last event-free follow-up time.
Code whether the exit is an observed event or censoring, then check the coding against the software’s documented convention.
Check \(A_i<Y_i\), inspect event-time risk sets using \(A_i<t\le Y_i\), and reconcile any ties or zero-length records with the data definitions and software rules.
Worked Example: Auditing an Age-Time Input
A hypothetical analysis uses age in years as its time scale, with birth as the origin. Subject M first enters event follow-up at age 52.0, has an observed event at age 53.5, and has no earlier censoring. Subject N enters at age 51.0 and is last known event-free at age 54.0. Assume N has no observed event by that date.
For M, \(A_M=52.0\), \(Y_M=53.5\), and \(\delta_M=1\). The observed interval is \((52.0,53.5]\), with length \(53.5-52.0=1.5\) years. For N, \(A_N=51.0\), \(Y_N=54.0\), and \(\delta_N=0\). N contributes \((51.0,54.0]\), a length of \(54.0-51.0=3.0\) years. At age 52.5, both satisfy the risk-set rule: \(52.0<52.5\le53.5\) for M and \(51.0<52.5\le54.0\) for N.
If M’s input instead reset entry to 0 and exit to 1.5, it would encode time since entry, not age. That might be a valid alternative analysis if intended, but it is not the stated age-time analysis: at age 52.5, the software could no longer place M correctly on the age scale. The correction is to retain entry age 52.0 and exit age 53.5. This example assumes the age origin and dates are accurately defined and that the observed entry is valid; it does not establish that delayed entry is statistically independent of event time.
Diagnostics, Alternatives, and Limitations
Several discrepancies often reveal an encoding problem before any model is fit:
- An event time is earlier than entry, or an exit precedes entry. Check date conversions, units, and whether the purported event occurred before the subject entered the eligible cohort.
- Subjects with delayed entry appear in risk sets before entry. Check whether the input uses a true entry-time field or has silently reset each subject’s clock to zero.
- The number or timing of coded events does not match source records. Check whether the event indicator was reversed or whether censoring dates were mislabeled as events.
- Longitudinal measurement times appear after event exit or use a different zero point. Reconcile the measurement and event clocks and investigate whether a measurement was collected after event follow-up ended.
- Many zero-length intervals or events exactly at entry appear. Confirm time precision, event-date conventions, and the software’s treatment of entry-event ties; do not add an arbitrary small increment just to make the data run.
There are several legitimate time-scale choices, but they answer different questions. Time since enrollment places every participant’s origin at enrollment; age as the time scale places subjects on an age axis and requires their age at entry. Calendar time can be relevant when event rates change over calendar periods. The choice should be justified by the analysis question, and all relevant event-process times must follow it. Similarly, setting entry to zero is appropriate when observation genuinely starts at the chosen origin, while a start-stop representation with nonzero entry is needed when observation begins later on that scale.
Correct encoding is necessary but not sufficient for a valid joint analysis. The software must support the intended data structure, and the assumptions about censoring and delayed entry must be plausible for the scientific setting. A correctly entered risk interval does not remove selection caused by who survives or remains eligible until entry. Nor does an event table by itself verify that the longitudinal measurements are correctly linked to subjects or timed to the same origin. Those issues require substantive design knowledge and model checks beyond this data-encoding task.
Check Your Understanding
For each question, write the entry time, exit time, and event indicator where requested. Solutions follow the questions.
- Time is measured in months since enrollment. A subject enters event follow-up at month 4, has an event at month 11, and has no earlier censoring. Give the encoded interval and status.
- At time 7, which of the following subjects are at risk under the interval convention \((A_i,Y_i]\): U has entry 0 and exit 7 with an event; V has entry 2 and exit 7 with censoring; W has entry 7 and exit 10 with an event?
- A subject has no event and is last known event-free at day 240 after enrollment. What are the exit time and event indicator? Does the exit time mean the event occurred on day 240?
- In an age-time analysis, a subject enters at age 60 and is censored at age 62.5. Give the entry and exit values. Explain why coding entry as zero would not represent age as the time scale.
Solutions. (1) The interval is \((4,11]\); entry is 4 months, exit is 11 months, and \(\delta=1\). Its observed length is \(11-4=7\) months. (2) U is at risk because \(0<7\le7\); V is at risk because \(2<7\le7\); W is not at risk at 7 because \(7<7\) is false. Thus the risk set is U and V, but only U has an event at 7. (3) The exit is day 240 and \(\delta=0\). No: day 240 is the censoring time, the last time event-free status is known, not an observed event time. (4) Entry is age 60, exit is age 62.5, and \(\delta=0\). Setting entry to zero would shift the subject onto time since entry rather than preserve the age scale.