Currently the sections of the database only allow for the delay distributions of direct human-to-human transmission. To include vector-borne diseases changes need to be made (e.g. addition of extrinsic incubation period and host species).

Currently there are a handful of pathogens that need to be checked as input for the pathogen_summary() function. It is better to generate all possible pathogen dynamically to ease development as the number of pathogens included in the package grows instead of manually adding to the selection.

The fit_function_weibull_range() uses pweibull which has the arguments shape and scale, but the typo has the scale argument twice https://github.com/epiverse-trace/epiparameter/blob/main/R/extract_param.R#L120.

I think it would be worth defining the scope of what types of parameters we are aiming to include - only distribution of delays, or also e.g. reproduction numbers etc.?

Relatedly, we probably want to flag (or limit) if we only include data and summary statistics (e.g. mean of an observed distribution of delays etc) or also modelled estimates.

It might be worth thinking about what we want to store (e.g. individual data points if available, or only summary statistics, sample size) and how to store them - csv probably fine for now but if we want to invite external contribution something like a curated google sheet might be more amenable (and could easily be imported here, or regularly updated).

Add a styler/linter to check that the tidyverse style is before conformed to throughout the package.

It may happen that a serial interval distribution is best described by a discretized Gamma, but with an offset to allow some negative values. This is not currently handled by the distcrete package. I am not sure if it would belong there or in epiparameter. It will have possibly complicated repercussions on the estimation process: I am not sure the problem remains identifiable as the offset and the mean may interact (e.g. higher mean, lower offset).

The code currently uses some piping operators %>%. I would recommend not using them in packages as they can make debugging quite hellish.

The pathogen is sometimes not explicitly mentioned in a report and only the disease is stated. In these cases it may be useful to record the parameters if suitable under the disease name and leave the pathogen ID unspecified.

For the inclusion of a genus, it may be useful both the the user and the developer to have the genus of each pathogen included in the database. For the user, it may be that they only know the genus (e.g. Ebolavirus) but not a specific strain (e.g. Zaire ebolavirus), in which case epiparameter can list all available pathogens/strain/species. For the developer it may help guide the search towards specific viruses that are missing from the database.

This relates to and should resolve issue #3.

Mentioned in epiverse-trace/blueprints#7 was the use of checkmate as a package for input checking that will likely be used throughout epiverse packages.

The package includes some initial functionality to extract distribution parameters from median and percentiles via extract_param(). However, extraction from values such as mean, variance or COV should be possibly analytically for several distributions.

One existing example is epitrix::gamma_shapescale2mucv – if epitrix is not going to be maintained long-term, similar extraction functions could be implemented locally for gamma, lognormal etc.

For now the database is stored in the R package and is read by epiparameter functions. This presents a few issues for development.

• How do people easily contribute (pull requests, google sheet which then requires being transferred into the R package manually or by a dependency)?
• How do epi folks who work in Python or Julia get access to this data for their analyses?

The three initial ideas for development are:

1. keep the data stored in the R package
2. keep the data on zenodo and pull the data into R using epiparameter functions. This method has been used by socialmixr
3. use a server store the data and write API functions in epiparameter to access the data

Each method has pros and cons. It might also be possible to implement multiple options (though likely not). This is not a priority for epiparameter development, and this issue is to keep an open discussion of people's preferences going forward.

The parameters currently stored in the epiparameter library are point estimates without any uncertainty. I propose we add the boot R package as a dependency to calculate the confidence intervals of delay distributions parameters and summary statistics. This can be accomplished using the boot.ci() function in the boot package. This should be flexible to the CI calculate (given inherent flexibility of bootstrapping) and can calculate parametric and nonparametric bootstrap CIs which should accomodate either when we have the parameters and distribution reported (parametric) or the raw data to estimate the parameters (nonparametric).

Other packages that could be used are bootstrap.

Alternatively, the CIs could be calculated using a different method (normal approximation).

Idea is to provide a class for storing delay distributions. I am assuming we only handle discrete distributions, for which the distcrete package will come in handy.

Easiest approach would be an S3 class which would use a list to store:

• a distcrete object (contains: type of distribution, parameters, and functions for $d $q $r $p)
• information on the type of distribution, e.g. incubation, serial_interval etc.
• any relevant info on the source (e.g. DOI)
• optionally the matched call, if we want to know how the distribution was created

Additional features would be:

• a print method
• a summary method
• a plot method
• accessors for the content of the object so that users do not need to interact directly with the data structure

A set of functions (fit_function_gamma, fit_function_lnorm, fit_function_weibull) return named numerics but the name is an empty string. Not really a problem, I just think it will be cleaner if the output of the these functions is unnamed.

To ensure contributions, both internal and external, are correct a data dictionary should be added to the package to provide metadata on the library of epidemiological parameters. See Global.Health's ebola data dictionary for an example

Currently the title of epidist is a bit vague, and the description very succinct: "Parameter probability distribution by day". It would be helpful to provide context and explain when this is useful, what it can be used for, and possibly add a @detail section as needed. I would recommend checking this for all important user-facing functions. Functions to check include:

• epidist
• extract_param

Both list_distributions() and pathogen_summary() both read in the parameters data, filter the data and return a data frame. The main difference between the functions is pathogen_summary() calculates the mean and standard deviation. It might be simpler to reduce them into a single function.

Add a function that easily allows users to retrieve the details required to cite the original source of data stored in the library

It'd be very helpful if the documentation of extract_params() could explicitly say what parameters exactly are returned depending on what distribution has been picked.

This is related to #36 but it would be nice to have this information even before having to run the function.

It will also probably be superseded by #39 but it's an easy & helpful change from the time being.

It would be useful to have a delay_distn column returned by epiparameter::list_distributions(), to allow users to see range of functions available.

Also, at present it seems like epiparameter::list_distributions() = epiparameter::list_distributions("incubation") – should the function with NULL argument return the full list of available distributions?

What's listed as pathogen_ID at the moment is a mixture of pathogens (MERS-CoV, RSV) etc. and diseases (measles, ebola). We might want to make it one or the other, or possibly both as e.g. incubation periods could be different for different diseases caused by the same virus.

Why such a big change in these values?

Originally posted by @Bisaloo in #44 (comment)

The documentation for most functions is minimal and some of the function examples fail. The documentation for the functions and arguments can be expanded, and the examples can be updated to ensure they run without error.

A vignette that describes the functionality of epiparameter.

Function pgamma uses shape and scale arguments, but https://github.com/epiverse-trace/epiparameter/blob/main/R/extract_param.R#L96 has meanlog instead of shape.

Descriptive studies often report summary values such as median, range, or percentiles (e.g. 95%) for estimated incubation periods. We already have functionality to extract parameters for an assumed distribution and its cdf from a reported percentiles using least squares in extract_param, e.g.
extract_param(type = "percentiles", values = c(5.9,21.4), distribution = "lnorm", percentiles = c(0.025,0.975))

However, it would also be useful to be able to extract parameters for an assumed distribution g(x) from a reported median. If we defined our observed median, range and number of samples as vals = c(median, min, max, n), then one option for a function to minimise over two parameters for a lognormal distribution, a and b would be:

fit_function_lnorm_range <- function(param, val) {
  
  # Median square residual
  median_sr <- (plnorm(val[1], meanlog = param[["a"]],sdlog = param[["b"]]) - 0.5)^2 

  # Probability of obtaining min, max and range:
  min_p <- dlnorm(val[2], meanlog = param[["a"]],sdlog = param[["b"]])
  max_p <- dlnorm(val[3], meanlog = param[["a"]],sdlog = param[["b"]])
  range_p <- (plnorm(val[3], meanlog = param[["a"]],sdlog = param[["b"]]) - plnorm(val[2], meanlog = param[["a"]],sdlog = param[["b"]]))^(val[["n"]]-2)
  
  # Range log likelihood
  range_sr <- -log(min_p*max_p*range_p)
  
  # Total value to be minimised
  range_sr + median_sr 
  
}

This seems to be able to recover the correct expected median and range for a given sample size in bootstrap simulations from the estimated distribution. But there may be a more elegant way of defining the function to be minimised.

With this feature the package would estimate a delay distribution from the data. The procedure is not entirely trivial as most distributions will need to be discretized: fitting to a continuous distribution and discretising it may be a good first approximation, but no there are no guarantees that this will produce the same estimate as fitting the discrete version directly.

Some related work:

• epitrix::fit_disc_gamma, which implements the procedure but only for a discretized Gamma distribution
• fitdistrplus, a reference package for fitting distributions; it does not seem to handle discretization though
• the distcrete package, which discretizes any distribution

Some nice additional feature would be to be build wrappers for linelist objects.

In order to the clearly convey how stable functions in the package are I suggest we start using the lifecycle badges provided by lifecycle. This is a tidyverse initiative to help the inform the user and developer community around the package whether functions are "under warranty".

The future dependency on distributional which also imports lifecycle would mean it is already part of the dependency chain.

Currently the extract_param() function returns a named vector with the names "a" and "b". These refer to the two parameters of either the shape and scale for the gamma distribution, or the mu and sigma for the lognormal distribution. The names of the vector should be changed to correctly label the parameters that are being output.

The implementation of distribution data has been done by several packages (https://cran.r-project.org/web/views/Distributions.html) and the conversion functions that are shipped with them (https://pkg.mitchelloharawild.com/distributional/reference/index.html). I would be good to utilise one of these packages to minimise the dev load on the distribution side of the package and instead have most of the dev focus on epidemiological data storage and extraction.

The data/ folder is usually used to store .RData files which can be loaded using data(...) once the package has been attached. I think the first question is: do we want the user to access the raw data files from R, or are these data more meant to be accessed internally by our functions? My impression is this the latter, but may be wrong.

If this is the case, I would suggest moving the data to the inst/ folder, e.g. inst/extdata/, which can then be accessed internally using:

system.file("extdata", "some_file.csv", package = "epiparameter")

Note that subfolders names have restrictions as R uses some internally.

Relevant read on this topic:

• https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Data-in-packages
• https://stackoverflow.com/questions/13463103/inst-and-extdata-folders-in-r-packaging

The current functions need to be tested to ensure that any breaking changes during development can be picked up by identifying broken tests.

Currently a function like epidist() can specify a pathogen, delay distribution and study. However, when the same delay distribution is reported for a pathogen more than once from a study (e.g. https://pubmed.ncbi.nlm.nih.gov/32145466/#:~:text=Limiting%20our%20data%20to%20only,than%20its%20median%20incubation%20period.) the function cannot differentiate between the two.

There needs to be another argument added to the function in order to fix this issue and potentially allow users to select which data to use that isn't based on sample size (the default filtering is done by largest sample size when study is not specified).

It was mentioned in epiverse-trace/blueprints#7 that we should not use the tidyverse pipe. Currently at least one function in {epiparameter} uses the pipe. My suggestion would be to replace these with the base R pipe (|>) which would leave the code largely unchanged. If anyone feels differently or would prefer the code to be written without any pipes please let me know.

EpiNow2 is being installed from github while archived from CRAN. Will revert back to CRAN installation once it's back to adhere to CRAN policy for submitting epiparameter.