Propagating uncertainty from estimate_truncation()

[jrcpulliam]

Hi! I'm interested in understanding how to propagate the uncertainty associated with data truncation into R estimates and forecasts. According to the Estimate Truncation of Observed Data page, the estimated truncation distribution from estimate_trunction() can be fed into regional_epinow(), epinow(), etc, but I haven't found any examples that show how to do this. (There is a link from that page to this gist, but the gist stops short of feeding the nowcasts into the $R_t$ and forecasting framework.)

Also, can I just double-check my understanding that the thing that is called reporting_delay (for example on the main EpiNow2 page is really the time from onset to the event that is the thing you want to count in your epi curve (e.g., for our use-case the x-axis of the epi curve is sample collection date, so it would be time from onset to sample collection)? Thus, for retrospective analyses that have complete data (or if you're counting by actual report date), it's ok to just run the estimation / forecasting without a nowcasting step, but for real-time use, an estimate_truncation() step is needed?

Thanks in advance for your help!

[seabbs]

Hi @jrcpulliam,

Thanks for asking for clarification on this and doing so in public. Sorry, this has been unclear.

I've expanded on both you points below and tried to give some options based on what it sounds like you are doing. Hopefully they are fairly clear but very happy to expand or reword anything said below. I am also opening an issue to try and find improvements in the documentation to help users avoid the issues you are having (for very understandable reasons) connecting the dots.

Uncertainty in estimate_truncation()

So you should have an output from estimate_truncation() that includes the estimated reporting delay and uncertainty. You should then be able to pass this to estimate_infections() (or its parent functions epinow() and regional_epinow()) via the truncation option. This will then apply the reporting delay to your data using the estimated posterior as a prior.

There is an example of passing a truncation distribution in the docs for estimate_infections(). You should be able to get a distribution in the right format from the dist list object returned by estimate_truncation().

If you wanted to do this as a joint model then epinowcast (which I also develop) has support for this but does not yet support forecasting. You can see an example of this here. If this is of interest then the helper functions used here may make it easier to get your data in the format the package currently accepts

The answer above is based on the assumption you want to correct for right truncation in your data (for example if only some cases are currently reported). If you instead want to estimate the delay between onset and your observation when this occurs for your whole time series then you need to pass the estimated delay as a reporting delay to delay_opt(). This is because it will be applied to the whole time series this way rather than just the most recent data to correct right truncation. This example walks through how to do this. The model equations (which need fleshing out/expanding) may help if the above was just confusing.

Definition of reporting_delay

Also, can I just double-check my understanding that the thing that is called reporting_delay (for example on the main EpiNow2 page is really the time from onset to the event that is the thing you want to count in your epi curve (e.g., for our use-case the x-axis of the epi curve is sample collection date, so it would be time from onset to sample collection)

So in this context yes it would be.

Thus, for retrospective analyses that have complete data (or if you're counting by actual report date), it's ok to just run the estimation/forecasting without a nowcasting step, but for real-time use

For many of the questions we have looked at we rarely have onsets and so use the reporting delay both in real-time and retrospectively to model them latently. If you have them (either partially or fully) then instead you could either use the same approach (i.e the approach taken in the nowcasting example I've linked above) or model onsets directly and correct them for right truncation using the truncation option and estimate_truncation() as I outlined above.

Just to muddy the waters if you did have onsets and reports and wanted a real-time estimate using a joint model you could also use epinowcast. The advantage of this approach is more flexibility about model specification, the ability to model missing onsets (though this is experimental), and a more robust inference framework. The disadvantages are more complex model, and the current lack of forecasting.

[jrcpulliam]

Thanks so much for this detailed response, @seabbs! I had missed the truncation option somehow, but that is exactly what I was looking for.

I'm optimistic about having onset dates for this particular use-case but haven't received the first data drop yet, so we'll see... If so, the approach I'm thinking of taking is to estimate the delay distribution of onset to sample collection dates using bootstrap_dist_fit() from the line list and use that (along with incubation period) in the delay options (and the truncation distribution through the truncation option as you describe). I think this will get us up and running more quickly that the epinowcast version (and we want forecasts). Will plan to circle back to epinowcast in a week or two, once the initial crunch of getting a minimally viable product is done.

Thanks again!

[seabbs]

All sounds sensible to me. Something to note is that the estimate_delay() and similar functions don't currently adjust for right truncation (this is coming in the 2.0.0 release) so you may instead want to use estimate_truncation() as we do in the example I linked (this also isn't my absolute ideal model (more on that coming soon!) but it does at least adjust for right truncation).

You would want this adjustment if the data was conditioned on the second observation and if you thought that prior to the end of observation (i.e maybe now) growth was fast.

[sbfnk]

Small correction

time series then you need to pass the estimate delay as a reporting delay to dist_opt(). This is because it will be applied to the

should be

time series then you need to pass the estimate delay as a reporting delay to delay_opts(). This is because it will be applied to the

[jrcpulliam]

Got it - thanks!

[seabbs]

Good spot. I've updated it above.

[sbfnk]

There's now also a workflow vignette which doesn't contain an example for estimate_truncation but describes how this would be done with truncated data.