Health Impact of Realistic Consumable Availability Scenarios #1367
Conversation
- some CMD and Reproductive health consumables were classified as "not relevant to regression analysis" and therefore assume not change to availability. This has been removed. We now assume that their availability changes in proportion to the average increase in the odds of availability across all consuamables.
- this equates the probability of availability to be equal to that of the 75th, 90th and 99th percentile facility (in terms of the mean vale of `available_prop` within the corresponding level; only availability of facilities in levels 1a and 1b are updated
- {'Facility_ID', 'month', 'item_code', 'available_prop'} only need to be a subset of all the columns because there may be additional scenario columns
- specify all scenarios
- previously for each level of care, one best performing facility was chosen based on the average consumable availability across all item_codes; Now a different best performing facility is chosen for each level for each item_code, giving a greater improvement in available_prop
|
Final set of consumable availability under various scenarios. All scenarios only affect levels 1a and 1b:
The following figures summarise:
|
…nsumable_scenarios # Conflicts: # resources/healthsystem/consumables/ResourceFile_Consumables_availability_small.csv # resources/healthsystem/consumables/ResourceFile_consumables_matched.csv
…ilability scenarios
…health systems methods
…el 2 changes when levels 1b and 2 are collapsed
This reverts commit 6cbe0ee.
…sed on the mean from the full dataframe rather than the summarised dataframe
…tem in the list of items in the category is not found in the index. - the valid items included in the index are considered.
Add README explaining various consumables scenarios.
…arios' into sakshi/impact_of_consumable_scenarios
…to drop month column
…tion.py and generate_consumable_availability_scenarios_for_impact_analysis.py
|
Hi @tbhallett. I have just done a final update of the ResourceFiles after running the data_file_processing scripts. I've compared the latest files with the older version and a change is recorded because some item_codes undergo a <1.5% change in the probability of availability in scenarios 12-15, which I think is due to a minor update in the categorisation of consumables into programs. |
| @@ -0,0 +1,3 @@ | |||
| version https://git-lfs.github.com/spec/v1 | |||
There was a problem hiding this comment.
should this file be on this PR, or the costing one?
There was a problem hiding this comment.
Good point, Tim. The script that generates this resource file (consumable_availability_estimation.py) is in under this PR (#1367) but it's used in the costing module and I had manually imported it there (which is probably not best practice). I can undo this commit in the costing PR #1637 and merge it in from here perhaps? The RF on this PR (PR #1367) is the final one and should override the one in costing.
There was a problem hiding this comment.
Ok -- if this is the final version of the file we want then I would propose the simplest thing to do would be :
- we leave this one here and we'll merge it imminently.
- then in the costing branch, when we merge in master, we make sure this version (which becomes the master version) over-writes the out-dated version on the costing branch.
Does that sound ok?
# Conflicts: # resources/healthsystem/consumables/ResourceFile_Consumables_availability_small.csv # resources/healthsystem/consumables/ResourceFile_consumables_matched.csv # src/tlo/methods/consumables.py
…ed during simulation, and avoid recomputing of item codes ste.
This PR estimates the health impact of increasing consumable availability to realistic levels. Realistic levels lie somewhere between
defaultandallas predicted by the regression model or by assuming that all facilities perform as well as the facility at the nth percentile in terms of consumable availability.Changes:
ResourceFile_consumables_matched.csvto include a crosswalk between names of consumables in the TLO model and that under HHFAhealthsystem.pyandconsumables.pyto accommodate specification of which consumable availability estimates to usePending tasks: