In the Schisto module (#105), there is a "Mass Drug Administration" (MDA) in which - in real life - thousands of children in a district are provided with a drug. As implemented, there are some conceptual and computational issues to consider:
Original Implementation
In an original implementation this was represented by thousands of individual-level instances of an HSI_Event. The work done inside each HSI_Event was to call a function in on the Schisto module. The EXPECTED_APPT_FOOTPRINT for each of these HSI_Events was {"EPI": 1}. (Aside: this is because the EPI appointment is a very small appointment and we note that in the DHIS2 this how appointments to do with 'de-worming' are classified.)
This approach was done because:
- It enables us to capture that the consumables (the drug) are being used in a particular facility at a particular time.
- It records the HR resources used to deliver the MDA in a way that seems consistent with the DHIS2 data.
The problem with this approach is that was very inefficient (1000's of HSI_Event on the same day in the same facility doing the same thing.....!). So instead, we move to the "current approach"....
Current Approach
We now have a system wherein one instance of an HSI_Event does the work for a set of people in the same district. The target of the HSI_Event is one of these people (in order that the facility_info is picked up correctly), but an additional argument (beneficiaries) gives the list of person_ids of all the people who will benefit. The EXPECTED_APPT_FOOTPRINT is {"EPI": len(beneficiaries)} and the consumables request is for len(beneficiaries)-lots of the drug.
(N.B. This is not the a "Population Level HSI" -- which is something which is not tied to a particular facility and is probably going to be deleted as part of #169.)
Remaining Limitations
- The log of the HSI does not reflect work done for one person not many: it should give the set of persons (or some summary or
None)
- If that person dies, then the
HSI_Event would not run and the whole district would not get the effect: this requirement should be removed.
- One large
Appt_Footrprint for work in a whole district may not fit within the DailyCapabilities and so, under some modes of running HealthSystem would never be run: We should consider whether such a type of HSI_Event should be affected by these rules differently.
Possible Solution
Implement a form of HSI_Event that is not specific to a person but it specific to a particular district/facility. Let this enter the HSI Event Queue as normal but:
- run without a check on a particular person being alive
- be logged as pertaining to a set of people not one
- (possibly) whilst being subjected to different rules.
Applications
- Integrate this into the
Schisto module
- Look for other places where this could work? e.g.
GenericFirstAppt stuff.
In the
Schistomodule (#105), there is a "Mass Drug Administration" (MDA) in which - in real life - thousands of children in a district are provided with a drug. As implemented, there are some conceptual and computational issues to consider:Original Implementation
In an original implementation this was represented by thousands of individual-level instances of an
HSI_Event. The work done inside eachHSI_Eventwas to call a function in on theSchistomodule. TheEXPECTED_APPT_FOOTPRINTfor each of theseHSI_Eventswas{"EPI": 1}. (Aside: this is because theEPIappointment is a very small appointment and we note that in the DHIS2 this how appointments to do with 'de-worming' are classified.)This approach was done because:
The problem with this approach is that was very inefficient (1000's of
HSI_Eventon the same day in the same facility doing the same thing.....!). So instead, we move to the "current approach"....Current Approach
We now have a system wherein one instance of an
HSI_Eventdoes the work for a set of people in the same district. Thetargetof theHSI_Eventis one of these people (in order that thefacility_infois picked up correctly), but an additional argument (beneficiaries) gives the list ofperson_ids of all the people who will benefit. TheEXPECTED_APPT_FOOTPRINTis{"EPI": len(beneficiaries)}and the consumables request is forlen(beneficiaries)-lots of the drug.(N.B. This is not the a "Population Level HSI" -- which is something which is not tied to a particular facility and is probably going to be deleted as part of #169.)
Remaining Limitations
None)HSI_Eventwould not run and the whole district would not get the effect: this requirement should be removed.Appt_Footrprintfor work in a whole district may not fit within theDailyCapabilitiesand so, under some modes of runningHealthSystemwould never be run: We should consider whether such a type ofHSI_Eventshould be affected by these rules differently.Possible Solution
Implement a form of
HSI_Eventthat is not specific to a person but it specific to a particular district/facility. Let this enter theHSI Event Queueas normal but:Applications
SchistomoduleGenericFirstApptstuff.