Handle 'mid-growth stage' ["model"]

[cjbayesian]

Summary

The model was built in the context of the first few days of local outbreak. It is not well equipped to handle projections when there is a non-small number of current infections. There needs to be a way for the user/analyst to specify not only how many cases are currently hospitalized, but also how long it has been since the first case was hospitalized. In keeping with the goals of the application being as simple as possible while providing actionable projections in terms of hospital-level resource demands, the handling of 'mid-stage' starting points should be kept likewise simple.

Additional details

After the first week or so of spread, there is additional information contained in the combination of current hospitalized case counts and the number of days since the first case. These two quantities should be combined to provide an estimate of local doubling-time.

Suggested fix

• Add an input for 'Days since first hospitalized COVID-19 case' {t_{firstcase}}.
• Start SIR sim from that many days back
• Run argmin_{doublingtime} [abs(hospitalized census - predicted)] at time 0 + t_{fistcase}

[PhilMiller]

#257 provides an alternative potential solution

[PhilMiller]

It makes a present-day estimate of doubling time, rather than fitting to a history-based estimate.

[cjbayesian]

@PhilMiller Can you take a look at my notebook in branch fithxdoublingtime?

[PhilMiller]

@cjbayesian I just read through it. It seems to be sound.

From a user-oriented perspective, I'm still uncomfortable with asking for a doubling time parameter, since it's one that they'll either need to tediously try to compute, or guess. How about asking for total admissions to date, rather than current in-patients, and when total admissions had been half that?

[PhilMiller]

In general, current hospitalizations is kinda a finicky parameter to work with, because it doesn't reflect that some people may have died or been discharged. Early-stage, assuming those were zero seems to be pretty reasonable. Mid-stage, that's harder.

[cjbayesian]

Agreed. The idea here is to no longer ask the user to input a doubling time and instead compute it for them using the date of the first hospitalization and the # currently hospitalized (accounting for discharges since we're fitting to the back-casted census projection). The approach could easily be adapted to take cumulative total hospitalizations instead of current.

Also of note: All of this will of course only work while demand for hospitalizations can actually be met by supply.

[PhilMiller]

Ah, right, I missed that "days since (/ date of) first hospitalization" takes the place of doubling time as an input entirely. So, the number of inputs the model asks for stays the same, and a user-estimated parameter is replaced with user-provided data.

On that note, since we each have proposals for data inputs that would let us do parameter estimation, besides back-testing against data from further-advanced regions, would it make sense to display forecasts from the different possible estimated parameters, giving a sense of the uncertainty, and of which way they're trending?

[cjbayesian]

Ya totally. I've been encouraged (modeling-wise, not pandemic-wise) that this method results in an estimated 4-day doubling time to date using Penn downtown hospitals as inputs (n_days_since_first_hospitalized = 16, current_hospitalized = 15). This leads to very similar projections to what we're producing in the app now.

[PhilMiller]

How do the forecast values on the negative days match up with observations?

[cjbayesian]

I added in the back-casing comparisons for Penn's downtown hospitals. See https://github.com/CodeForPhilly/chime/blob/fithxdoublingtime/notebooks/Fit%20doubling%20time%20using%20time%20since%20first%20hospitalization.ipynb

[cjbayesian]

@PhilMiller Do you want to take a crack at implementing this?

[quinn-dougherty]

the basic idea of using minimization of loss between expected hospitalization given a doubling_time and actual hospitalization seems sound to me mathematically, but i'm so new to hospitals my opinion shouldn't matter.

code-wise,

1. i think brute force argmin is fine.
2. wrap cells 60 and 61 in functions and put them in SimSirModel obj
3. use the function based on cell 60 to update state of self.p.doubling_time while inside SimSirModel.

however:

• question: we need to give the user a choice of inputs because not everybody is going to know the days since first hospitalized. this conditional could make the code a little messy. not intractable but it's worth giving thought to the best way to do this independent of dash vs. streamlit.
• if we have some messy solution, its possible that it'll make switch to dash more difficult.
• so maybe we should focus on making this a CLI feature first, aiming to make it a FE feature second.
• if you're dead set on having it in prod monday we can try to work with that.

[cjbayesian]

I think that this is becoming increasingly relevant to most users since this also fixes the issue of accounting for current hospitalizations in the census projections.

Ideally we would like to give the user the ability to either define the doubling time themselves or infer it from time since first hospitalization, but we may be able to get around that by computing and presenting the user with the equivalent doubling time for a few 'time since first hospitalization's