Incorporating time-varying transmission dependent on climate (or other) data

[adamkucharski]

One of the things that came up in the discussions with HARMONIZE was incorporation of climate data into transmission dynamic models – the process of implementing this could also help identify best ways to integrate other sources of time varying data that would influence transmission.

A potential motivating question here could be: for a given climatology, introduction time, and assumptions about transmission (perhaps linking with #20 ) and immunity (e.g. from serology), what could a future vector-borne epidemic look like?

Examples of such applications include analysis of Zika in Brazil (see Fig 4) and Fiji (see Fig 4). There was also a real-time analysis in Martinique, where climate effects were assumed to be negligible (which, of course, requires knowledge of climate to motivate this).

HARMONIZE data outputs will likely come in a range of spatial and temporal resolutions (e.g. using their data cube format), with functionality to specify. There are also a number of other public products available (see discussion page) But thinking more about integration, an ODE model with seasonally varying tranmission will require a function seasonal_function(time) where time is continuous, which means the main data processing step will be convert discrete data at some time scale (e.g. days/weeks) into a continuous function. Here is an example with the process equations in a simple SIR model:

    beta <- beta_0 * seasonal_function(time)

    dS <- -beta * S * I / N
    dI <- beta * S * I / N - gamma * I
    dR <- gamma * I

This could be expanded relatively easily to include a vector population and time-varying parameters influencing biological parameters like incubation, biting rate, vector lifespan in a Ross-MacDonald type model, linking up with upcoming work in epiparameter to incorporate temperature dependency, e.g. from Mordecai et al (2017).

But this still leaves the central questions:

• how to convert the discrete data to continuous functions for the ODE
• how to ensure alignment with input dataset and input simulation window (perhaps with a check for min/max date, or user warning?)

For conversion function, the odin package has the option of various interpolating functions, including step-wise, linear and splines for incorporation of data-driven parameter changes over time. From past experience, we'd probably want a smooth-ish function as default, as having high variability on short timescales (e.g. using the raw daily temperature values, rather some multi-year or moving average, to scale transmission) would lead to numerical instability in the ODE solver and/or heavily slow down simulations.

[pratikunterwegs]

Thanks @adamkucharski - drawing @rozeggo and @BlackEdder's attention to this issue as well.

how to ensure alignment with input dataset and input simulation window (perhaps with a check for min/max date, or user warning?)

I think this could probably be handled within the frameworks we currently have for intervention and vaccination objects, which have a start and end time. These can be cross-checked against the maximum time of the epidemic model with a warning or error. A data-driven model should probably error if the data availability does not cover the entire simulation period, while a model not including real data should be allowed to continue but with a warning.

how to convert the discrete data to continuous functions for the ODE ... we'd probably want a smooth-ish function as default, as having high variability on short timescales (e.g. using the raw daily temperature values, rather some multi-year or moving average, to scale transmission) would lead to numerical instability in the ODE solver and/or heavily slow down simulations.

Data and model time-scales could be matched (say, daily time-scale for both) perhaps by interpolation, before passing the data to the model, and this interpolation is likely to be more convenient in R. The way the epidemic() function is set up, the user already knows the time period and increment at which the state will be reported (e.g. seq(0, 200, by = 1) for a 200 day period). I would imagine that the Harmonize data cube would eventually want to have its own interpolation functions for users with similar asks. This probably needs more thought and some initial examples to check what we'd be dealing with.

I had a few additional questions on how seasonality should be applied to epidemic models.

1. Would seasonality apply only to vector-borne models, or also to direct transmission models? What aspects of these models would a hypothetical <seasonality> class target - only the <infection> class parameters (e.g. time-varying $\beta$) or also population parameters such as the social contacts?

2. Would users want to take a model from the catalogue, and add their own seasonal forcing function to it? Or would we provide a set of models --- both vector-borne and direct-transmission --- that can include seasonal forcing in some specific way? The challenge here would be allowing users to define custom functions in R, and passing these to C++ where the magic happens.

Overall, happy to take a look at how this has been done before and workshop ideas so that we can build a general method that can be re-used for multiple vectors and diseases, and possibly for direct-transmission models too.

[pratikunterwegs]

Linking to this Discussion comment for references. https://github.com/orgs/epiverse-trace/discussions/79#discussioncomment-6593411

[adamkucharski]

1. Would seasonality apply only to vector-borne models, or also to direct transmission models? What aspects of these models would a hypothetical `<seasonality>` class target - only the `<infection>` class parameters (e.g. time-varying β) or also population parameters such as the social contacts?

The relationship between season (via temperature) is well-characterised for vector-borne infections so this seems like a good initial use case. The relationship between climate and transmission for influenza etc. seems more up for debate, although school holidays could be a key factor to explore for directly transmitted infections (e.g. work by @rozeggo et al on respiratory dynamics.

2. Would users want to take a model from the catalogue, and add their own seasonal forcing function to it? Or would we provide a set of models --- both vector-borne and direct-transmission --- that can include seasonal forcing in some specific way? The challenge here would be allowing users to define custom functions in R, and passing these to C++ where the magic happens.

In the vector-borne case, I expect most users would want to take a pre-defined Ross-MacDonald style model with human and vector components, rather than add temperature dependency to a non-climate model. Perhaps one with more complete biological complexity (i.e. multiple temperature dependent parameters) and one just with seasonally-varying transmission. The Mordecai et al paper shows that the latter is reasonable for certain temperature ranges, because the relationship with R0 is fairly linear (i.e. between about 23-28°C for Aedes Aegypti)

But if we're talking about seasonal variation more generally (e.g. school terms etc.) would be interested to hear others' thoughts on how to link together different use cases. Sounds like it might be easier to predefine common seasonal factors, which a user can then remove by setting certain parameters to zero, rather than try and allow users to add their own into catalogue models?

[pratikunterwegs]

Okay thanks, so my takeaway is that a separate vector-borne model with full-fledged dynamics that include seasonality would add the most value. That could also be a good comparator for results from the {iraca} package, and if it could be made sufficiently general, could also tackle some of the CEPI diseases of concern (RVF and chikungunya).

Sounds exciting - happy to get stuck in once pre-requisites are met; listing some here, please add as you know more:

1. Harmonize data cube, or other data-cube format data as an example (side question: the Harmonize data cube does not appear to be based on the <stars>-class, which is specifically designed for data cubes - is there a reason for this?)
2. General {epiparameter} integration with {epidemics} for infection parameters - this is already issue Integration with input distributions and potential for fitting #20.
3. {epiparameter} integration with Harmonize, or inclusion of climate-dependency in vector-borne disease parameters.
4. ... please add.

[rozeggo]

VBDs are not high on our priority list as there are other groups doing this within the wider Epiverse initiative. We can consider adding this functionality in the future when our priorities are met (~18m). Good to keep an eye on it so we maintain compatibility!

[pratikunterwegs]

Reopening and pinning for visibility.

[pratikunterwegs]

Closing this issue as the time-dependence feature request has been addressed with the addition of this feature for all models. The question of including VBDs in the package has been addressed in the thread.