Using model terms in pred_input_info() + extension to competing risks

[edbonneville]

Dear {predRupdate} team,

Thank you for developing this (much needed) package!

Not an issue but more of a suggestion (sorry if this is the wrong place..): as part of a paper on validating competing risks prediction models, we also thought about this question of validating an existing model/how one would go about sharing an existing model (without sharing the data the model was developed on).. so we made a short script showing how this could be done.

The idea is pretty much the same as the one in this package, with our model_info list analogous to a pred_input_info object, and predictRisk_shared_CSC() is basically what you would need inside pred_predict() if you were to extend to models based on cause-specific proportional hazards. We also thought that sharing the terms attribute of a model was better than sharing the formula, since the former is much more useful when splines are used in the model (it has the knots locations, and is easy to use with model.matrix on new data).

I guess it is a bit early in the development on the package, but hopefully some of this is useful if you are eventually considering extending to accommodate competing risks.

Thanks!

[GlenMartin31]

Dear Edouard, many thanks for your feedback and suggestions - they are very much appreciated and I certainly agree with them. Extending into other model types, including competing risks, is certainly on the 'to-do' list for this package, so your paper and suggestions will be incredibly useful towards this. Would be great to collaborate on doing this when the time comes, if of interest.

Thanks again
Glen

[danielegiardiello]

Dear all,

@GlenMartin31 very nice, needed and useful work! Congrats.

It would be very nice if we could collaborate on the competing risks extension.
Other potential collaborations:

• Might it be of interest to further extend the repository with decision curve analysis?
  A good basis may be the following repositories with the corresponding code for logistic, survival and competing risks using this script (Vickers et al., 2006-2008).

• Maybe it is not the primary goal of this repo/package. If you would also like to include internal (optimism-corrected bootstrap) validation as a potential additional function, these functions proposed in this script (for logistic) and in this script (for survival) can estimate the internal validation performance assessment for discrimination and calibration.

• Available to develop the same idea to Python and create a library. We started to program it in this script for logistic, and in this script for survival. Some extra efforts needed for competing risks in Python.

Feel free to contact me if you are (both) interested.

Best,
Daniele

[GlenMartin31]

Dear both, we would be very interested in collaborating to incorporate competing risk methodology within the package. We think this would benefit the functionality greatly.

It seems like you have developed a lot of this code already, so we wondered if the best way forward would be for you to make an initial pass at integrating this into the package (making necessary changes to your existing code as needed) and submit a pull request for us all to review. We would obviously add you both as authors onto the package to acknowledge this, if you agree with this way forward.

At the same time, there are three additional things that we are working on for the package that I think would complement the competing risk angle: (i) allow one to pass model objects directly into the functions (which I think is how your code works, so would sync well here), (ii) add linear and multinomial model functionality, and (iii) adding decision curve functions (I agree this is needed). Us doing this in parallel is another benefit to the above suggested way forward.

Let us know what you think.

Best wishes
Glen, on behalf of the predRupdate team.

[edbonneville]

Dear both,

(Sorry for late answer..) Sounds fun! I would be happy to take an initial crack at a pred_input_info() + pred_predict() for competing risks. I think passing model objects is a nice idea, though often these need x = TRUE or model = TRUE to be useful (after which you effectively share development data).

Re. the decision curves: worth considering that the {dcurves} package already accommodates survival and competing risks outcomes, and is on CRAN. It is possible to develop local functions to make decision curves (@danielegiardiello would be more experienced than me for making these), though it would save time / future maintenance by putting {dcurves} in the suggests part of the description file, and make a short vignette on how to use it from {predRupdate}-based objects.

[danielegiardiello]

Dear all,

great! Sorry for my late reply.

I would be happy to understand how to include decision curves to the available functions in this package, as Ed suggested.
Please stay in touch.

Best,
Daniele