mitey: Estimation of mean serial interval distribution using symptom onset data

[kylieainslie]

Description

I’ve recently been using a method developed back in 2014 by Vink and colleagues that uses symptom onset data to estimate the mean and standard deviation of the serial interval distribution. As far as I’m aware, this method is not available in any package, so I’ve written a small package mitey that includes this method. See this article for more details and validation of the method using historic datasets.

I thought it would be quite useful to incorporate into one of the existing epiverse packages (not sure which one).

Typical end-users

Epidemiologists

Potential contributors

epiverse-trace team

Key collaborators

none

Inputs

symptom onset data converted to index-case to case intervals

Outputs

estimated mean and sd of serial interval distribution

Imports

• the mitey packages already includes data

Used by

NA

Related projects

not sure

Usage

library(mitey)
library(fdrtool)

# Generate simulated ICC intervals
set.seed(1234)
N <- 10000; hmu<-15; hsigma<-3; hw1 <- 0.2; hw2 <- 0.5; hw3 <- 0.2; hw4 <- 0.1

CP <- rhalfnorm((hw1*N),theta=sqrt(pi/2)/(sqrt(2)*hsigma))
PS <- rnorm(hw2*N,mean=hmu,sd=hsigma)
PT <- rnorm(hw3*N,mean=2*hmu,sd=sqrt(2)*hsigma)
PQ <- rnorm(hw4*N,mean=3*hmu,sd=sqrt(3)*hsigma)

sim_data <- round(c(CP,PS,PT,PQ))

# Estimate mean and sd of serial interval distribution assuming underlying Normal distribution
results<- si_estim(sim_data, dist = "normal")

Additional comments

...

[chartgerink]

Welcome @kylieainslie to Epiverse and thanks for opening up this discussion 🙌 I pinged our topic experts to look into this and provide a response shortly 😊

[adamkucharski]

Thanks for sharing this package! Would be great to link up with tools for parameter estimation, as our core Epiverse toolkit is currently limited to the known parameter -> analysis step, so bringing in ability to estimate-then-store-then use with {epiparameter} etc. would be really nice.

A few thoughts/questions:

• I'm not so familiar with the Vink paper, so wondered how it relates to the EpiEstim method (which is probably the first point of call for many people wanting quick non-stan SI estimation in R)? Is the main difference the ability to handle multi-modal distributions in {mitey}? Tagging @annecori who may also have thoughts. There are also some more advanced options for handling truncation/censoring coming down the line with {epidist} by @seabbs et al. Could add a brief 'related R packages' section, like at the bottom of the {epichains} README? In our training materials, we're trying to offer a suite of options for users, emphasising strengths and weaknesses (e.g. fast-but-approximate options as well as more advanced-but-computationally-intensive methods with more dependencies).
• This would probably make most sense as a standalone package to keep it light, as users will probably want to use on its own as well as linking with {epiparameter}, {EpiNow2} etc. (but we can of course work on aligning inputs/outputs to make this smoother, like we've been doing for other packages). This package could either remain on your repo or move over here if you think it would benefit from more collaborative development. In any case, we could add a howto to show integration with other tools.
• We've also got some transmission chain simulation tools in {simulist}. You've already got some nice simulation validation in the vignette, but could consider a fuller data generation process further down the line (e.g. so user can visualise the transmission chain and offspring distribution etc. as well as calculating SI).

[athowes]

Thanks for the tag @jamesmbaazam.

Yes epidist uses a Bayesian approach. It provides a front-end to brms and currently supports one model. This one model is that of Ward et al. (2022) (see Park et al. [2024]) and is called latent_individual in the package.

We are designing the package in order to be extensible to other models. For example, latent_individual.R contains the model specific methods for the latent_individual model. Soon (#386) we will implement a simple "pass through" model to which does not perform any corrections. This will illustrate a minimal viable product of implementing a new model.

In this sense, I think that epidist may be soon be well set up to include further models. However, as you point out, inference for these models would be conducted in Stan (using HMC, pathfinder, Laplace, or ADVI) and they must be able to be specified using brms syntax (possibly with custom Stan code injections).

From the sounds of it, extension/modification of the Vink et al. methodology to a Bayesian framework might be a research project in itself (i.e. non-trivial).

[kylieainslie]

Looking at all of the possibilities for merging, there doesn’t appear to be a natural fit. {epidist} uses a completely different statistical framework and get_pariwise() is within a package that deals with contact data. The strength of the proposed method is that you don’t need detailed data, just date of symptom onset. However, I do think creating another stand alone package runs the risk of having many packages that essentially do the same thing, just in different ways or using different data. It seems most useful to include this method in a package that already offers methods to estimate SI and provide this as an alternative. Is there a particular philosophy within the Epiverse project on this issue? Thoughts?

[adamkucharski]

Generally, we have a preference for a clearly defined package focus with minimal dependecies, and have tried to ensure clear communication of when a package is suitable for a task, and what the alternatives are (e.g. in README, vignettes, training materials, howto guides). For example, {epichain} and {superspreading} can both provide probability of an outbreak, with a simulation-based and analytical method; {epidemic} and {finalsize} can both generate an SIR attack rate, again with a simulation-based and analytical method. But because underlying approaches were different, we decided to keep separate.

Agree can be risky to have lots of packages doing apparently same thing without clear distinction (or info on whether one can be a special case of another). But as you say, I'm not sure there are many other SI calculation packages already available that would be a natural home - and if they are, data requirements might quite be different (we've noticed this with CFR package options). So could be useful to give users the option of both a simpler method for sparser data (in {mitey}) as well as more advanced Bayesian options? (And from a training point of view, can be nice opportunity to show why one might be preferred to the other in different situations).

[Bisaloo]

Hi Kylie and all 👋,

As an addition to Adam's comment, we don't have a specific policy on merging alternative methods for the same task into a specific package. As you mention Kylie, there are two main risks/downsides but they can be mitigated:

• lack of interoperability: as much as possible, packages focusing on the same task should use the same data formats or classes and a similar interface so that it is easy for users to switch from one to the other
• lack of discoverability: following rOpenSci's recommendation, we usually add a "Related packages" to our READMEs. In particular, packages focusing on the same task would likely benefit from linking to one another, with a short explanation of how they differ.

[kylieainslie]

Thanks @adamkucharski and @Bisaloo for weighing in on the discussion. It looks like leaving {mitey} alone is the best way forward. What are the next steps? (Feel free to link to some howto doc that I probably should, but haven't found, rather than type it all out).

[kylieainslie]

@adamkucharski thanks for the input! I guess a little more background on the package (and its name).

I created the package as a companion to a manuscript I’m working on that focuses on estimating epidemiological parameters for scabies (hence the name mitey). I’m using methods or implementations of methods that I didn’t think were available elsewhere, so I thought at the very least, the package could be useful for reproducing the paper analyses as well as showcasing the methods if others want to use them. If the consensus is to keep the package separate, it would definitely benefit from some support from those with more package development experience (proper testing, maintenance, etc), so moving it to the epiverse-trace GitHub might be better.

@jamesmbaazam I have been trying to implement an Rt estimation method from Wallinga and Teunis using a slightly different approach to that of EpiEstim, but it is still in development and needs to be validated.

As for your other questions/comments @adamkucharski, I will have a closer look at the various links and reply in a separate comment.

[adamkucharski]

In case useful, Anne Cori and I put together an R script plotting different Rt estimation methods (WT, WL, EpiEstim and EpiNow2) as part of our review paper.

[Bisaloo]

@kylieainslie, it is a very active area of discussion but we don't currently have defined a formal mechanism for onboarding packages to Epiverse.

Until this is resolved, I wonder if that'd make more sense to keep the package under your account.

However, this doesn't mean we can't collaborate yet. As a starting point, maybe you could open issues pointing out to the specific areas where you'd like to receive help (setting automated checks, preparing for CRAN submission, etc.). If the most useful at this point is a packaging review, we could look into this as well.

How does this sound?

[kylieainslie]

That sounds great, thanks @Bisaloo. Would it be best to assign you or someone else in the Epiverse team once I've made the issues just so they're on your radar?

[Bisaloo]

For now, could you tag the issues as "help wanted" and report back in this thread when it's done please? Thanks!