Matching patients with consideration of immortal time bias

[Kevin Quach]

Hi,

I am conducting a chart review with a matched cohort study design where I am trying to sample two control (received a transplant in home country) patients to an exposed (international transplant) patient. In the attached picture, d0 represents day 0 as the time of transplant, dx represents the day that the exposed patient returns to original/home country for follow-up, and dy represents the day that the patient develops an event/outcome of interest. (The dotted line in the second line represents a period of no data available to us since the patient was abroad.)

There are two caveats to this matching algorithm:
(a) the control patient can only develop an event after dx (to control for immortal time bias)
(b) there are variables called x' and y' that we want to match for between exposed and control patients.

The code I have tried thus far is as follows but I believe it does not consider my caveat (a).

stset eventdate, failure(exposed=1) id(id) origin(time dx) enter (time dx) scale(365.25)
set seed 3156163
sttocc, match(x' y') n(2) nodots

I hope you could shed some light how to appropriately do this using Stata.

Thank you very much for your time,
Kevin

[Steve Samuels]

I like to know more before attempting a detailed answer:

1. Show an extract of your data lines with the id, time variable(s), relevant time/event indicators, and matching variables for four patients: two control patients , one with and one without an outcome event, and for two transferred patients, one with and one without an event.

2. What are the variables you intend to match on? If categorical, how many categories?

3. What are the numbers of transfer patients and the numbers of potential controls?

Please use actual variable names throughout (x' and y' are not valid variable names).

I prefer not to engage with semi-anonymous posters, So before you respond, I ask that you follow the FAQ request to use first and last names (section 6 of http://www.statalist.org/forums/help). You can add your last name to your username at : http://www.statalist.org/forums/contact-us

[Kevin Quach]

Hi Steve,

Thank you for your reply. I appreciate your help and would like to let you know that I have put in a request to change my username to reflect my last name.

1. For number 1, I have attached the image that depicts an extract of my data lines with the requested variables. I have provided data on 6 hypothetical patients. Using -sttocc- command, I was able to match two controls to each exposed patient as indicated by _case and _set.

For "exposed", 1 indicates patients who left the country and 0 indicates patients who stayed in their home country.
For "event", 1 indicates presence of event and 0 indicates no event.

"d0" is the time of operation/transplant. "dx" is the time of return to home country. "dy" is the time of event. You will notice that d0=dx if exposed=0 because they would have never left the country.

2. There are two matching variables of interest (severity and age). "Severity" indicates severity of disease and is categorical with 3 categories. "Age" is also a categorical variable with 4 categories.

3. There are 44 exposed patients and over 1000 potential controls.

Best,
Kevin

[Steve Samuels]

The next time somebody asks you for a small listing of data, please just copy and paste into the text or into a code block. I thought I might need to copy something from your listing, but I couldn't do it even with heavy-duty OCR.

The correct stset statement is:

stset dy,  failure(event) origin(time d0) enter(time dx)

The key to avoiding "immortal time" bias is to recognize that the origin for the start of event risk for all patients is the date of transplant. Thus your original stset statement was incorrect on two counts: the wrong origin and, also, the presence of the id() option, which is needed only for multiple record data. Also, I see no need to change the time scale to years if all you intend to do is sttocc.

[Steve Samuels]

Correction: Adding the id()option in the stset statement was not an error, just not necessary in this case.

[Kevin Quach]

Hi Steve,

Thank you very much for your help! It makes sense!

Best,
Kevin