# How to treat patients without events in time-to-event analysis?

I'm working with longitudinal data for a series of patients. Duration of followup on a patient-level is non-uniform.

Patients can either experience a discrete event (e.g., a heart attack) or never experience the event. This feature is of course binary. Additionally, patients that have experienced an event (e.g., the first heart attack) can also continue to experience more events (e.g., subsequent heart attacks). Each event is anchored to an event date which will be compared to when the patient was diagnosed with their primary, chronic condition (e.g., multiple myeloma).

I'd like to append to my dataset a derived column - TimeSinceLastEvent. Derivation of this value for first events would be calculated by (FirstEventDate - DiagnosisDate)/365 and subsequent events would be calculated by (SecondEventDate - FirstEventDate)/365, (ThirdEventDate - SecondEventDate)/365, etc.

How should I code this derived column for patients that never experience the event? I can't insert NA/NaN for these patients because downstream analyses require non-NA and finite data; so they would be imputed incorrectly anyway. One thought I had was setting these values to something drastically different, but standardized, such as -1 or 9999. Is this a valid and reasonable approach? If not, what have you used?

• How exactly you proceed will depend on the particular problem, but data of this form falls under survival-analysis. (See also censoring.) You will probably get better answers if you expand your question to describe your modeling goals. Feb 17 at 4:55
• This problem isn't exactly a survival analysis, because the event being studied can occur 0, 1, or more times. Due to that condition I don't see how censoring could be applied. In terms of modeling goals: a series of supervised machine learning models will be applied to this dataset for classification purposes. Feb 17 at 15:25

Generally, I would pick a value that is vastly outside the range of values that are non-imputed in this column since that'd probably cause more extreme (noticeable) errors in case they get included. So rather 9999 than -1. However, as you probably already attempted, the "most correct" solution would be to set it to NaN since the column is just not defined in these cases. If at any step during your analysis, some computation is done on the TimeSinceLastEvent column, anything but NaN would technically lead to incorrect results.