2

I aim at estimating a competing risks / multistate model with frailties with the coxme R-package and the survival package. I think that this is possible to do in the surivial package with the coxph function:

# competing risks model
survival::coxph(Surv(time, type) ~ X + frailty(ID), id = ID, data = data)  
# where type is a factor consisting of target states

# multistate model
survival::coxph(Surv(StartTime, EndTime, toState) ~ X, data = data, id = ID, state = fromState) 

However, for the multistate model, it is not possible to add the frailty(ID) part of the formula. Why?

And: How would I go about to model competing risks and multistate models with the coxme package? The surivial package documentation (p. 48) suggests that the coxme package superseds the method of adding a frailty(ID) to the coxph term. Hence, it would be better to model frailties with the coxme package. But there is no documentation for the coxme package for modeling competing risks or multi-state models.

teeglaze
  • 125
  • 1
  • 2
  • 8
  • For what it's worth, I'm experiencing the same issue with `frailty(ID)`, whereas `cluster(ID)` runs just fine. (Though I am not confident that `cluster(ID)` is correct!) – carbocation Oct 09 '21 at 21:53

2 Answers2

2

I cannot give you a definitive answer, but I faced a very similar problem with a multistate model. Likewise, I could not make frailty(ID) work properly with coxph. The model took an enormous amount of time to run. It might be a technical problem, as suggested in the 2015 paper you cite: "Only for ordinary survival models frailties can be fitted using standard software" (p.690).

Also, cluster(ID) becomes redundant if there is a univocal ID per transition (models with and without it shuold return the same estimates).

Conversely, coxme runs very smoothly. I think you can simply use the coxme package on an appropriately structured dataset (as you would with coxph). I found this guided example quite informative to begin with. coxme is also used in this paper to estimate a multistate model with frailty.

Alessandro
  • 121
  • 6
  • Thanks a lot for your help. I think the guided example is technically not for a multistate model, as there is only one type of event (death). But the example paper is, and I think they also use a mix of functions from the survival and coxme pacakge. – teeglaze Aug 12 '21 at 09:45
  • Yes, the worked example is not on multistate models; it just gives a nice, practical overview on frailty models with both `coxph` and `coxme`. From my reading of the paper, the authors use both packages to run two frailty models, which are then compared. Applying the same logic used with coxph to coxme, I think you can run a command line such as: `coxme(Surv(StartTime, EndTime, toState==to) ~ X + (1 | ID), data = subset(data, fromState==from))`. – Alessandro Aug 12 '21 at 19:32
  • Ah, nice! Thanks for the formula. I did not know you could do it like that :) – teeglaze Aug 16 '21 at 08:03
1

I don't have experience with frailty models, so I can't speak to why a frailty term seems to be incompatible with a multi-state model.

If you are primarily interested in accounting for intra-individual correlations and aren't wedded to the particulars of frailty modeling, however, then you can accomplish something similar with a cluster(id) term instead. With the cluster approach, the initial analysis is done without regard to the id values, but error estimates take the within-individual correlations into account. The idea is that a frailty term is like using a mixed model, while a cluster term is like using a generalized estimating equation.

EdM
  • 57,766
  • 7
  • 66
  • 187
  • 1
    Thank you! I believe that the 'coxph' function already takes within-individual correlations into account when the argument 'id' has a value. So I guess the 'cluster(id)' term then becomes obsolete. I am still wondering why a frailty value for each id cannot be estimated (such as with 'frailty(ID)'). Is it a technical / implementation issue or a statistical one (also see [this](https://pubmed.ncbi.nlm.nih.gov/22116343/) article). – teeglaze Mar 05 '21 at 10:37