Big picture goals for this package

[kgostic]

Goals

This package is a work in progress. We need to make some big decisions about scope, audience, and architecture

Who

The target users of this package are

• Statistical epidemiologists with existing knowledge of the methods and the ability to write custom code in stan, brms, etc?
• Epidemiologists who need a tool to pull off the shelf and run?
  Proposal: get something working for the first group as an initial goal, then come back and edit to make it more user friendly

What

User stories

• Use this package for retrospective (e.g. academic) analyses (low priority)
• Use this package to estimate epidemiological delay parameters in real time in response to outbreaks
  • Sometimes this will involve small, individual-level data (e.g. from contact tracing). In these cases the latent variable method for double interval censoring and right truncation is probably best, as it provides individual-level flexibility (e.g. in the width of primary or secondary censoring window)
  • Sometimes this will involve large data (e.g. dates scraped from EMR records). In this case, we will want an aggregated likelihood (e.g. evaluate the likelihood once per delay length and primary cohort; assume everyone has the same interval censoring window length). This is not yet developed and may take some work. Should probably be developed in stan, not brms. An intermediate thing that could work is to multi-thread the latent variable method we already have.
• Do we have any use for the other models in the delay paper (e.g. naive?)
• There are some models in the delay paper that aren't currently working and should be deleted (KG will fill in the details after looking at local code)
• Ideally there would be functionality for distributions other than lognormal. Architecting this elegantly in a way that can interface with post-processing will take some thought. It's possible we could do this with custom brms families but it would be complicated.

Other requirements

• There should be an inference test for each model that we include?
• There should be unit tests too
• Reduce dependencies on magic string to improve test-ability

Other needs / training

Some vignettes or examples that we can pull off the shelf and share in an emergency

Proposal:

v0.1

• Delete all models except keep https://github.com/epinowcast/epidist/blob/4306d40e752b41134df3ed55b30be9fdd98c3469/R/models.R#L155
  • Delete all others. Can always pull them back in from the paper code
• Prepare to add functionality to infer gamma delays, not just lognormal. Read about classes and brms families to think through how best to do this. Can we use these tools to streamline the model fit and postprocessing, or is it easier just to hardcode two versions of the functions (one for lognormal and one for gamma) for now? First step here is to read, think, then write an issue proposing something so that we can discuss.
  • Aiming to develop functions that can: {define a model to estimate the delay}, {convert brms estimates into mean/sd; distribution parameter estimates on natural scale, and possible distribution parameter estimates on log scale}, {return quantile-based summaries of estimates}, {plot resulting estimates}, {plot resulting distribution}
  • In a separate package, will need functions to take distribution estimates and convert them into (discrete) double-censored probability mass vectors, plot, and compare to (discrete) observed data
• Review pre- and post-processing functions and decide what should be kept there (@seabbs we didn't discuss this)
• Write roxygen2 documentation and tests for all functions
• Write an inference test (verify that we infer the right distribution when passing synthetic data)
• Implement the Gamma functionality.

v0.2

• Add truncation censoring adjusted delay model back in (this could support delay-level rather than individual-level data)
• Other methodological improvements

v 0...

• Consider re-adding the dynamic adjustment model
• Clean up the Docker container so that we can help others with install in an emergency?

[seabbs]

@parksw3 for visibility. This is thinking about what to do with some potential developer resource that is coming up to get things in a working state here for potential users who might have urgent asks in the near term

[parksw3]

Thanks! I will be able to engage more with this after my defense next week.

[kgostic]

Good luck @parksw3! (Not that you need it 🙂). I'm going to schedule a call to discuss.

[parksw3]

Thanks! Looking forward to it!

[seabbs]

I don't think luck will really be needed but anyways good luck!

[parksw3]

thanks!!! definitely needed!!

[seabbs]

As a first step to this I think we need to map some of these desires into issues and organise those issues using labels and milestones into releases and into types of work (i.e methodology, validation, core package infrastructure, package infra improvements etc.)

[kgostic]

Do you think we're ready to do that or are we likely to change direction with input from @parksw3?

[parksw3]

I feel like a lot of these steps are quite important and will be robust to any changes in direction. I also don't think there will be major changes in direction, and I'm pretty happy with the steps written down.

I don't know much about milestones and labels, but putting some of these into issues seem like a good idea.

[athowes]

Are we missing the updates from last Friday's meeting in the OP here? As I mentioned on Teams, happy to give input on issues if they're added, but also happy to have a go at creating issues if you'd prefer.

[seabbs]

I think having a stab at the issues would be great.

[kgostic]

I agree. I ran out of time but can at least add the meeting notes here.

[athowes]

Yes please add meeting notes and I'll give it a go.