# Community Seminar 2024-08-07 - Kaitlyn Johnson - Wastewater modeling to forecast hospital admissions in the US: Challenges and opportunities

**URL:** <https://community.epinowcast.org/t/community-seminar-2024-08-07-kaitlyn-johnson-wastewater-modeling-to-forecast-hospital-admissions-in-the-us-challenges-and-opportunities/237>\
**Category:** Meetings\
**Created:** [6 August 2024 14:38 UTC](https://community.epinowcast.org/t/community-seminar-2024-08-07-kaitlyn-johnson-wastewater-modeling-to-forecast-hospital-admissions-in-the-us-challenges-and-opportunities/237 "2024-08-06T14:38:33Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![adrianlison](https://dub1.discourse-cdn.com/flex005/user_avatar/community.epinowcast.org/adrianlison/32/27_2.png) [@adrianlison](https://community.epinowcast.org/u/adrianlison)\
**Post date:** [12 August 2024 09:03 UTC](https://community.epinowcast.org/t/community-seminar-2024-08-07-kaitlyn-johnson-wastewater-modeling-to-forecast-hospital-admissions-in-the-us-challenges-and-opportunities/237/17 "2024-08-12T09:03:51Z")

</div>

What would be a real game changer for me is to have a domain (but not inference tool)-specific language for the kinds of semi-mechanistic generative epi models we use + a package to represent this in a convenient data structure **in `R`.** This is because I expect `R` to remain popular in epi research and public health for quite some time, while probabilistic programming is evolving fast and I don’t know how long people will still like `stan`.

If there was a ppl-agnostic structure to represent the different models in `epinowcast`, `EpiNow2`, `EpiSewer`, `epidist`, etc. (and I think that @samabbott and @sambrand have already laid the conceptual groundwork for this in `EpiAware`, although in `Julia` and maybe still a bit tightly coupled with `Turing`), and a package with helper functions to produce corresponding `stanargs` (including inits and priors, as mentioned above) that follow some clear convention, then we would as a first step “only” have to

- adjust our `stan` models to receive arguments for the “data” block from this representation
- adjust the interface functions of our `R` packages to define the inputs for `stan` via this ppl-agnostic representation (instead of directly specifying stan arguments as we now do most of the time)

This would not necessarily require a shared stan library as it leaves the ppl implementation of the models completely open (it remains the responsibility of the developer to implement the model correctly and to reject representations that your stan model cannot implement).

The immediate advantage of this would be cleaner interface functions in `R` with a lower entry barrier for new contributors - right now, I can at least say for `epinowcast` and `EpiSewer` that IMO you need quite an in-depth understanding of the respective stan model (including variable names!) to work on the interface functions… which is really bad.

The more long-term advantage of this would be that this could pave the way for transitioning to other ppls (or offering several backends) _while still offering our tools in R_. I guess that in `Julia` you could ideally take such a representation and directly construct the respective EpiAware model during runtime. And if someone wants to try build that with `stan`/`brms`, we won’t stop them 😃

---

_[View the full topic](https://community.epinowcast.org/t/community-seminar-2024-08-07-kaitlyn-johnson-wastewater-modeling-to-forecast-hospital-admissions-in-the-us-challenges-and-opportunities/237)._