Minutes epinowcast meeting: 2022-09-23
Note: some people that were interested in joining this rather spontaneous meeting could not participate because of a different time zone. In the future, we will try to arrange meeting times that are as compatible with everyones sleeping patterns as possible 
Decision making in meetings vs. the forum
We follow a general rule: During meetings, no final decisions regarding the development of epinowcast or the community are made. Actual decisions/consensus should always be established in text form on the discourse forum. Of course this will not always be 100% enforced, e.g. regarding very small implementation decisions for a single feature when everyone involved was on the call. But especially if decisions have implication for epinowcast as a whole or could be of interest the the wider community, we try to stick to this rule.
Of course we will make plans during a meeting and get a consensus of the people on the call. But we should at least always describe the plans on the minutes from the meeting and give other people the chance to comment/veto before carrying them out.
Forecasting
The forecasting post this was based on can be seen here: Forecasting in epinowcast - #4 by Gunnar
@Gunnar has implemented a neat approach to extend the current expectation model to forecasting (by projecting it beyond the present for a certain forecasting horizon, using the generated quantities).
There are several levels of extension of this approach which could make sense to have
- Do not only forecast expected observations, but also the realized ones by using a count data distribution (like the Poisson or Negative Binomial we currently have). This would be quite straightforward for the Poisson, and a bit more tricky/approximate using the Negative Binomial
- Forecast the full reporting triangle/matrix, i.e. cases by reference date and delay/reporting date, and potentially distinguish between cases with known and unknown reference date. This requires projecting all sub-modules into the future, but would allow evaluating forecasts in “real-time”. It is still a bit unclear how we can get a sustainable implementations scheme for that, in the sense that adding new modules does not always lead to a lot of additional work
Expectation model
The PR this discussion was based on can be seen here: Flexible expectation model by seabbs · Pull Request #152 · epinowcast/epinowcast · GitHub
There was a discussion about the use of modifiers to the expected observations in the expectation model. The general idea is to allow for seasonality/differences etc. in the observations by reference date, e.g. when people are more/less likely to get tested on a certain day of the week.
The current state in the expectation model PR is to apply a modifier to the expected observations after they have been computed from the latent cases using the latent delay distribution. Part of this was to enforce that the modifier model has an intercept of zero. In the meeting, we came to the conclusion that it is conceptually more appealing to apply the modifier rather to the latent delay distribution and then compute the expected observations afterwards.
This doesn’t make a difference to the model really, but makes the modifier more similar to the reporting day effects in the reporting delay model, which makes sense conceptually. In fact, the long-term goal would be to express the latent delay distribution (and also the generation time distribution) also via a discrete-time survival model. The modifier would then be on the hazard scale.
A different aspect is an overall scaling of latent cases to observations, e.g. scaling from infections to observed deaths using an infection-fatality-rate (IFR). This is something that will probably only be possible using a very strong prior and/or several data streams (e.g. cases and deaths). Currently, it is implicitly supported by the possibility to supply an improper (i.e. scaled) latent delay distribution (see test script Germany_latent_renewal.R on that branch). We said the we want to leave this for now as is and add a scaling component/submodule at a later stage maybe.
Finally, there was a short discussion regarding the log scale modeling of the renewal process and potential tradeoffs with modeling a stochastic renewal equation (implementing a sampling of infections on the log scale may prove difficult). Before going more into this, we however have to figure out whether log scale modeling actually works efficiently for the renewal process. Some people (me) still have doubts about it 
Outsourcing of functionality / adding new packages
We are thinking of adding additional packages, e.g. for a baseline nowcasting model (Include a simple reference model - #6 by samabbott) that does not require stan to run, or for loading nowcasting datasets (Create a collection of benchmark data sets - #4 by samabbott, both nice ideas by @johannes ) to the epinowcast github organization - instead of adding these things to the main epinowcast package itself.
In the long run, we might also separate the pre- and postprocessing functionality from the nowcasting model, allowing more modularity. The separated packages will of course depend on each other to a certain extent.
Please let us know if you have thoughts on this.