How should I set up my data collection form in preparation for Cox analysis?

Question

I am planning on doing a Cox model analysis to study risk factors for a disease, retrospectively via medical record review. Will the model allow for mixing of binary , continuous, and/or ordinal variables in one equation? I am using Redcap, which allows you to create a data-form with a graphical user interface with multiple choice questions, text fields where you can input an integer, calendar drop-downs for dates, etc etc...and in the end you can export an Excel sheet of the raw data with which to perform the analysis. My question is simply what is the best way to encode these questions on the data form to make the raw data more amenable to cox modeling? For example, if one of our covariates is number of previous cancers, would it be best to set this up as a textbox where you type in the integer or as a multiple choice question that has "1" through "10+" as options? (We decided that we don't want to bother counting after 10 so we will encode everyone with more than 10 prior cancers as simply "10+")

Another issue is the variable of treatment modality. Currently we have this set up as multiple choice "check-boxes", i.e. the ones that allow you to select more than one option. This way we could select all the adjuvants that people had on a case by case basis. However, I am starting to worry that this will present an issue for the cox analysis...Would it have been better to think of all the different possible combinations of therapies and make each of them one of the multiple choice options? i.e. instead of having it as : surgery [X], chemo [X], radiation [X] ....we could have it as surgery, chemo, and radiation [X]....The automatically generated excel sheet that I mentioned will convert everything into a binary variable (unless of course you manually input integers for continuous variables).

Thank you!

Answer 1

Ok, I will try to answer all questions in sequence:

1. Handling of multiple data types: Yes. Cox PH is very good in handling all variable types. You can easily use time varying covariates, and deal with time dependent coefficients as well.

2. Data format: I hope I understand your question properly here. Think bottom-top - think of how the end result should look like, and work your way up from there. There are several options for the data structure for easy Cox model fit (note that while this is probably true-ish with all software packages, I use R):

At a bare minimum, you need a time-to-event, and an event variables. In the simplest form, where every subject has a single row of data with a single time variable - total time to event. This arrangement works when all data is static - meaning that it is not time dependent, and true for each subject at time 0.

   time event gender blood_count
1    20     0      m          12
2    30     1      m          12
3    15     0      f          15
4    27     1      m          13
5    35     1      f          12
6    71     1      f          19

If variables are time varying, than each subject needs as many rows as periods - note that not all subjects need the same cutoffs, but cutoffs need be made whenever a variable changes. Note that some variables can stay constant throughout periods, and that subjects need an identifying id:

     id t_start t_end event gender blood_count
1     1       0    15     0      m          12
2     1      15    17     0      m          13
3     1      17    22     1      m           9
4     2       0    10     0      f          10
5     2      10    25     1      f           5
6     3       0    18     1      f          11

3. Coding: I don't think this matters much. Integers are good, strings for categorical variables are good too. If you code a count variable but one 'category' is a range, it is no longer a count variable really, because the interval stops being constant. Perhaps use a dummy for over 10? Creating mutually inclusive dummies is a possibility. Grouping them together is a consideration that needs to be made according to theory / data, and can be easily changed post-data gathering, so I suggest giving multiple checkboxes, and decide later. The model cares not.