-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Including scaling (const_HR_scaling
) in assumed daily capabilities
#1241
Conversation
… after the appropriate data table has been loaded, to avoid over-writing values of parameters already loaded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Brilliant, thanks Margherita.
Please see on q for your considration about the values for the "data" scenario.
Small changes only suggested: which I've proposed as commits here; but roll back if you prefer something else.
@@ -0,0 +1,48 @@ | |||
import pandas as pd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the data produced has some values greater than 1.0 (I think this speaks to systematic biases between HHFA and the official and CHAI data.) Should we cap at 1.0? If we allow this assumption to inflate the Min Time Available, it could be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I had mentioned in my initial description of this PR that there is this issue ("NOTE: Currently, the capabilities obtained from the 2018/2019 Malawi Harmonised Health Facility Assessment survey appear to exceed those assumed in our “actual” scenario in a number of cases (e.g. DCSA). Further discussion will be required before this mode can be included.") We're discussing with Wiktoria on the 14/02 to review this.
The reason I didn't include any >1.0 caps is in case we might want to use the same framework to look at boosting of capacities as well as absenteeism effects. E.g. if we wanted to look at capability expansion of specific cadres we would just need to set these factors to be > 1 where relevant. (Admittedly, if we were to do this it would be good to rename variables for consistency). If you think these should be dealt with separately then I agree the >1 cap would be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine! I get it, and sorry for missing your notes.
So maybe the solution is to use a more agnostic naming for this feature (e.g. "officer_minutes_scaler"), that would naturally and obviously accommodate those different options.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that sounds good - sorry should have named it so from the beginning.
…do without this as the key error that arises organically is good enough.
…not help with error checking and makes our own checking a bit awkward, I realise!)
…o include scenarios beyond absenteeism, which may therefore include factors greater than one 1
@tbhallett all absenteeism fncs now renamed const_HR_scaling (to differentiate it from dynamic scaling, which I will add to separate PR) |
const_HR_scaling
) in assumed daily capabilities
This PR allows users to include different “modes” of absenteeism in their scenarios. This was identified as a desired change in Issue #1204.
Each mode corresponds to a table of factors by which daily capabilities of each officer category at different facility levels should be scaled. The mode is specified by the healthsystem module parameter “absenteeism_mode”, and corresponds to a different sheet in the file resources/healthsystem/absenteeism/ResourceFile_Absenteeism.xlsx.
The “default” absenteeism mode, which is specified as the default assumption, assumes a constant factor of 1 for all officer categories, at all facility levels (i.e.
no absenteeism ever takes placeno changes relative to assumptions implicit in underlying data).The “custom” mode is an illustrative example of how users could customise the assumed factors for theoretical investigations on the impact this would have on the incurred health burden.
The “data” absenteeism mode reflects available data-driven estimates based on the 2018/2019 Malawi Harmonised Health Facility Assessment survey. These factors were obtained by comparing the survey’s processed data on the average minutes worked per day by different officer types at different facility levels (file resources/healthsystem/absenteeism/HHFA_amended_ResourceFile_patient_facing_time.xlsx
) with those assumed under the “actual” daily capabilities scenario (resources/healthsystem/human_resources/actual/ResourceFile_Daily_Capabilities.csv). The comparison was carried out using script src/scripts/data_file_processing/healthsystem/human_resources/formatting_absenteeism_factors_from_health_facility_assessment.py
NOTE: Currently, the capabilities obtained from the 2018/2019 Malawi Harmonised Health Facility Assessment survey appear to exceed those assumed in our “actual” scenario in a number of cases (e.g. DCSA). Further discussion will be required before this mode can be included (@wiktafesse).