The number of recovered cases is lower than expected

[lisphilar]

The number of recovered cases is only 5 in total now. This is lower than expected because there were around 30,000 confirmed/suspected cases on 01Aug2022.

Notebook for calculation:
https://gist.github.com/lisphilar/ae24c369d21cfeb89a673de1f6edb2b9

Recovery period is estimated as 2-4 weeks and case fatality rate was 3-6%. This means about 30,000 cases could be recovered as-of 01Sep2022 with simple calculation.

Monkeypox is usually a self-limited disease with the symptoms lasting from 2 to 4 weeks. Severe cases can occur. In recent times, the case fatality ratio has been around 3–6%.
https://www.who.int/news-room/fact-sheets/detail/monkeypox

@aimeehan1 indicated as follows on #127 (comment).

"Active" versus "recovered/inactive" case status (no longer have the clinical symptoms of monkeypox, they have recovered from acute illness). Example, Italy, Andalusia cases have been reported as active case totals, but we are tracking cumulative totals. Reminder to curators to check cumulative counts (active + inactive). Due to limited metadata, we are not currently able to update individual case status to "recovered/inactive." https://www.rtvsol.es/noticias/andalucia/salud-y-familias-informa-de-que-actualmente-en-andalucia-hay-193-casos-activos-de-viruela-del-mono

We may need to revise data dictionary or curation system.

[lisphilar]

Is it possible to retrieve recovered data from the primary sources?
I know line list data was deprecated and just the number of cases (cumulative or daily new) is necessary.

[ksewalk]

WHO does not provide this information, so it is not possible cc: @jim-sheldon @Mougk

[jim-sheldon]

WHO data:

COUNTRY | ISO3 | WHO_REGION | WHO_REGION_SHORTNAME | CasesAll | CasesLast24Hours | CasesLast7Days | DeathsAll | DeathsLast24Hours | DeathsLast7Days | Latitude | Longitude | MPX_DataAvailable | LASTREPDATE

For my own edification, are there techniques to estimate the number of recovered cases, or is that a bad idea?

[lisphilar]

We can estimate cumulative number of recovery cases if "recovery period" [days] (the time period between case confirmation and recovery) is available.

recovery_period = 10 # For COVID-19, 7 - 21 days in my analysis
df["Recovered"] = (df["Confirmed"] - df["Fatal"]).shift(periods=recovery_period, freq="D")

https://github.com/lisphilar/covid19-sir/blob/2ae6e194884475b02fe418334b287d813d7f6550/covsirphy/engineering/_complement.py#L296
https://lisphilar.github.io/covid19-sir/02_data_engineering.html#5.2-Details-of-data-complement

Regarding Monkeypox, we may need to find papers later to select a specific value, but recovery_period could be 14 - 28 days.

Monkeypox is usually a self-limited disease with the symptoms lasting from 2 to 4 weeks.

https://www.who.int/news-room/fact-sheets/detail/monkeypox

Is this not a role of a database?

[jim-sheldon]

Ah, cool, thanks for that!

Could you clarify "is this not a role of a database"? Happy to add to our db if you want :)

[lisphilar]

Thank you for your positive comment!

One weak point of this method is that it highly depends on the accuracy of recovery period estimation. Because only five cases are listed in the (deprecated) line list, it is very difficult to decide the exact value of recovery period. Users may regard the recovery data as raw data mistakenly.

Alternatives:

• document how to calculate recovery data with "recovery period" and the number of confirmed/fatal cases
• provide script to calculate reocovery data

[jim-sheldon]

"Users may regard the recovery data as raw data mistakenly" In general this is a trap we try to avoid, while still providing as much data as possible. We also find it frustrating that this leads to incomplete data sets.

For the purposes of estimating numbers of recovered cases, we could make a script. Feel free to make a ticket with requirements and assign it to me. Of course, I want to be careful about how we label and share any forecasts and/or estimates. If we added this to our website we would need to clearly indicate to users what is data and what is probability.

[lisphilar]

If we added this to our website we would need to clearly indicate to users what is data and what is probability.

How about the following changes of directory tree at this repository? (I may not understand the current tree, please correct the followings.)

Currently:

• ./.github/workflows/**: the current GH Actions workflow to get/parse/save raw data from WHO and CDC
• ./s3_ui/**: update your website, deprecated?
• ./scripts/agency_ingestion/**: script to get CDC data, deprecated?
• ./scripts/gh_data_update/**: create GitHub data with WHO/CDC data, deprecated?
• ./scripts/map_time_series/**: current workflow to create time series data with WHO/CDC data
• ./case-definitions.json: references for case definitions of line list, deprecated
• ./cdc_latest.csv: the latest values of daily new cases (not historical) from CDC
• ./who_latest.csv: the latest values of daily new cases (not historical) from WHO
• ./latest.csv: line list created automatically updated by GitHub actions, deprecated?, latest.csv is empty #223
• ./latest_deprecated.csv: line list, deprecated
• ./data_dictionary.yml: details of variables in the line list, deprecated
• ./timeseries-confirmed-deprecated.csv: the number of confirmed cases (global), deprecated
• ./timeseries-country-confirmed-deprecated.csv: the number of confirmed cases (by country), deprecated

(Where is the time series data regarding the number of cases?)

One idea:

• ./_deprecated/**: all deprecated files, including scripts and GH Actions workflows
• ./latest_deprecated.csv: line list, deprecated
• ./timeseries-confirmed-deprecated.csv: the number of confirmed cases (global), deprecated
• ./timeseries-country-confirmed-deprecated.csv: the number of confirmed cases (by country), deprecated
• ./scripts/**: scripts to get new data from WHO/CDC
• ./.github/workflows/**: GH Actions workflow to run scripts saved in ./scripts/, will be deprecated with Move away from Github Actions #213?
• ./analysis/timeseries_estimated.py: Python script to estimate cumulative (and/or daily new?) number of recovered cases by country/global
• ./analysis/timeseries_estimated.csv: output file, estimated cumulative (and/or daily new?) number of recovered cases by country/global
• ./timeseries.csv: output file, cumulative (and/or daily new?) number of confirmed/fatal cases + population values (Population data with cumulative values #179) by country/global
• ./timeseries.yml: compressed CSV files data dictionary of time series data
• ./timeseries.csv.gz: compressed CSV files (Datasets with .csv.gz format #180)
• ./country_mapping.json: [{"iso_code": "USA", "region": "TX"}, ...] (Generate output with ISO3 codes for map #221)

For the purposes of estimating numbers of recovered cases, we could make a script. Feel free to make a ticket with requirements and assign it to me.

This project has many tasks and I would be happy to make a pull request, including new Python script for creating ./timeseries_estimated.csv with ./timeseries.csv, just let me know.

Of course, I want to be careful about how we label and share any forecasts and/or estimates. If we added this to our website we would need to clearly indicate to users what is data and what is probability.

For example, ./analysis/timeseries_estimated.csv will be create with recovery_period=21 [days]. Then, URL of the Python script and the warning (no information regarding exact value of recovery period at this time) will be documented on README file.

[jim-sheldon]

Unless it is marked as deprecated, everything in the repo is in use.
I intend on removing deprecated files soon; users can access them in the archives on S3, or look through the git commit history. I also need to update the data dictionary.

s3_ui is for accessing archived data. agency_ingestion takes CDC and WHO data and puts it in our database and S3 bucket, and puts ECDC data in our S3 bucket. gh_data_update takes CDC and WHO data and turns it into G.h data and stores it in the database and S3. map_timeseries creates a timeseries data file that our map visualization reads from S3.

latest.csv is the most up to date G.h data, using the most up to date WHO and CDC data.

Regarding forecasting and estimation, unfortunately I don't think documentation will suffice. I am interested in doing this work, but also want to take every possible precaution to ensure viewers of our outputs do not take it as data or prediction. The right balance might be doing that work in a private repo, only sharing it with trusted people, and any publicly-shared results would be carefully labelled (or limited to something like a timeseries graph with confidence intervals). @aimeehan1 @ksewalk @abhidg What do y'all think?

[abhidg]

@lisphilar @jim-sheldon We should not put estimated data in this repository. Furthermore using a single recovery_period will give incomplete estimates without knowing the standard deviation of the underlying distribution. The distribution of recovery times is necessary to produce a timeseries with confidence intervals. Modelling epidemics is usually done on variations of the SIR https://en.wikipedia.org/wiki/Compartmental_models_in_epidemiology#The_SIR_model_2 which are stochastic models to estimate number of infectious (and recovered) people.

[lisphilar]

@jim-sheldon @abhidg
Yes, thank you for discussion and we can mark this issue as not planned. The method highly depends on recovery period value and we do not have data to calculate representative values and standard deviation. My idea was to add a script (and CSV file(s)) with an example value in a separate directory (./analysis) from the raw data (cumurative number of confirmed/fatal cases) as I mentioned in the bullet list of the previous comment, but I agree with your comments to exclude totally the estimated data from this repository to avoid any troubles of users. This should be done at software engineering because libraries (packages) can provide interface to selecting recovery period, like df = complement_recovered(raw, recovery_period=21).

(Additionally, in latest.csv, only "_id", "Case_status" and "Location" column have non-NA values. This means we can calculate only cumulative number of cases. Cumulative number of fatal cases is un-avaliable at this time.)

(To simulate the number of cases with SIR-like models, ODE parameter values, including beta and sigma, are necessary. To estimate ODE parameter values, we require linelist or the set of cumulative number of confirmed/recovered/fatal cases. Regarding COVID-19, UK does not provide recovery data. The method and recovery period estimated with the other countries' data are very helpful to analyse UK data with SIR-like model and the same workflow as that for the other countries, surely with caution when analysing.)

@jim-sheldon
Thank you for clarifying the directory tree and I'm sorry for my misunderstanding.

[jim-sheldon]

@lisphilar all good, no need to apologize; thank you for the background and explanation!