Causal Bayesian version of rbmi that exploits post-ICE data

[jwb133]

I've recently started a new 3 year project that will develop Bayesian reference based methods. @wolbersm is a collaborator on the project.

In particular, we want to implement in a package the methods described in this arXiv preprint. Briefly, this involves fitting a modified model in Stan that incorporates any observed post-intercurrent event (ICE) data. The modified model is based on that proposed by White et al (2020). The model includes one or two additional parameters that dictate how mean trajectories post-ICE depend on the on-treatment model parameters (as estimated in the current standard model used by rbmi).

I am interested in exploring the potential to include this additional functionality within rbmi, rather than as a separate stand-alone package, and would be keen to find out if the rbmi maintainers/owners are interested/willing to explore this.

[wolbersm]

Hi @jwb133

Thank you for raising this. I am of course supportive to explore this potential enhancement. It would be great if rbmi supported such models! Obviously, integration into rbmi would only work if the new functionality could be integrated seamlessly without breaking any of the existing syntax or functionality. Also, the rigor of implementation would need to match the standards of rbmi.

@gowerc, @danielinteractive, @gravesti, @luwidmer: What do you think about this from a statistical engineering perspective?

It might also be sensible to have a short call with the rbmi developers (including @tobiasmuetze) at some point where you could present your plans in more detail.

[jwb133]

Thanks @wolbersm.

I completely understand your points regarding breaking existing syntax or functionality, and for rigourous testing. Perhaps a preferable route would be for us to develop a new package that imports rbmi, exploits its existing functions where possible and adds or creates modified versions of functions where necessary. Having done this, the rbmi team could then consider more concretely the viability and desirability of trying to fold the new functionality into rbmi.

In any case, we'd be pleased to discuss further at some point either here, via email or a call, as you prefer.

[gowerc]

Sorry just to say I'm still on pat-leave until 1st September so am not really able to look into this properly at the moment. I fully defer any decision making from my side to @luwidmer and support what ever he recommends :)

[danielinteractive]

Thanks @jwb133 for reaching out! I agree with @wolbersm comments.
I guess a discussion could be useful. Usually for this kind of new research also a prototype implementation in script form / documented in a Quarto doc can be a good first step before package inclusion.

[luwidmer]

Agree with @danielinteractive and @wolbersm here, I think we typically go with a design document that guides the implementation and a prototype implementation before considering adding the code to the package (and next CRAN release).
@jwb133 do I understand correctly that this would involve adding more models for the same endpoint? If yes, we may want to think about @danielinteractive's design doc where at least for one endpoint there may be more than one model as well (see issue #559)?

For the methodology review, I would defer to @tobiasmuetze and @wolbersm.

[tobiasmuetze]

I think it would be good to have the various causal models in {rbmi} eventually.

I agree with @danielinteractive and @luwidmer that a prototype implementation should be done first.