tlo.methods.healthsystem module

class HealthSystem(name: str | None = None, resourcefilepath: Path | None = None, service_availability: List[str] | None = None, mode_appt_constraints: int | None = None, cons_availability: str | None = None, beds_availability: str | None = None, equip_availability: str | None = None, randomise_queue: bool = True, ignore_priority: bool = False, policy_name: str | None = None, capabilities_coefficient: float | None = None, use_funded_or_actual_staffing: str | None = None, disable: bool = False, disable_and_reject_all: bool = False, compute_squeeze_factor_to_district_level: bool = True, hsi_event_count_log_period: str | None = 'month')

This is the Health System Module. The execution of all health systems interactions are controlled through this module.

Parameters:

• name – Name to use for module, defaults to module class name if None.

• resourcefilepath – Path to directory containing resource files.

• service_availability – A list of treatment IDs to allow.

• mode_appt_constraints – Integer code in {0, 1, 2} determining mode of constraints with regards to officer numbers and time - 0: no constraints, all HSI events run with no squeeze factor, 1: elastic constraints, all HSI events run with squeeze factor, 2: hard constraints, only HSI events with no squeeze factor run.

• cons_availability – If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then

let no consumable be ever be available; if ‘all’, then all consumables are always available. When using ‘all’ or ‘none’, requests for consumables are not logged. :param beds_availability: If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no beds be ever be available; if ‘all’, then all beds are always available. :param equip_availability: If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no equipment ever be available; if ‘all’, then all equipment is always available. :param randomise_queue ensure that the queue is not model-dependent, i.e. properly randomised for equal topen

and priority

Parameters:

• ignore_priority – If True do not use the priority information in HSI event to schedule

• policy_name – Name of priority policy adopted

• capabilities_coefficient – Multiplier for the capabilities of health officers, if None set to ratio of initial population to estimated 2010 population.

• use_funded_or_actual_staffing – If actual, then use the numbers and distribution of staff estimated to be available currently; If funded, then use the numbers and distribution of staff that are potentially available. If ‘funded_plus`, then use a dataset in which the allocation of staff to facilities is tweaked so as to allow each appointment type to run at each facility_level in each district for which it is defined.

• disable – If True, disables the health system (no constraints and no logging) and every HSI event runs.

• disable_and_reject_all – If True, disable health system and no HSI events run

• compute_squeeze_factor_to_district_level – Whether to compute squeeze_factors to the district level, or the national level (which effectively pools the resources across all districts).

• hsi_event_count_log_period – Period over which to accumulate counts of HSI events that have run before logging and reseting counters. Should be on of strings 'day', 'month', 'year'. 'simulation' to log at the end of each day, end of each calendar month, end of each calendar year or the end of the simulation respectively, or None to not track the HSI event details and frequencies.

Bases: tlo.core.Module

PARAMETERS:

Item	Type	Description
Master_Facilities_List	DATA_FRAME	Listing of all health facilities.
Officer_Types_Table	DATA_FRAME	The names of the types of health workers (“officers”)
Appt_Types_Table	DATA_FRAME	The names of the type of appointments with the health system
Appt_Offered_By_Facility_Level	DATA_FRAME	Table indicating whether or not each appointment is offered at each facility level.
Appt_Time_Table	DATA_FRAME	The time taken for each appointment, according to officer and facility type.
Daily_Capabilities_actual	DATA_FRAME	The capabilities (minutes of time available of each type of officer in each facility) based on the _estimated current_ number and distribution of staff estimated.
Daily_Capabilities_funded	DATA_FRAME	The capabilities (minutes of time available of each type of officer in each facility) based on the _potential_ number and distribution of staff estimated (i.e. those positions that can be funded).
Daily_Capabilities_funded_plus	DATA_FRAME	The capabilities (minutes of time available of each type of officer in each facility) based on the _potential_ number and distribution of staff estimated, with adjustments to permit each appointment type that should be run at facility level to do so in every district.
use_funded_or_actual_staffing	STRING	If actual, then use the numbers and distribution of staff estimated to be available currently; If funded, then use the numbers and distribution of staff that are potentially available. If funded_plus, then use a dataset in which the allocation of staff to facilities is tweaked so as to allow each appointment type to run at each facility_level in each district for which it is defined. N.B. This parameter is over-ridden if an argument is provided to the module initialiser.
item_and_package_code_lookups	DATA_FRAME	Data imported from the OneHealth Tool on consumable items, packages and costs.
consumables_item_designations	DATA_FRAME	Look-up table for the designations of consumables (whether diagnostic, medicine, or other
availability_estimates	DATA_FRAME	Estimated availability of consumables in the LMIS dataset.
cons_availability	STRING	Availability of consumables. If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no consumable be ever be available; if ‘all’, then all consumables are always available. When using ‘all’ or ‘none’, requests for consumables are not logged. NB. This parameter is over-riddenif an argument is provided to the module initialiser.Note that other options are also available: see the Consumables class.
BedCapacity	DATA_FRAME	Data on the number of beds available of each type by facility_id
beds_availability	STRING	Availability of beds. If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no beds be ever be available; if ‘all’, then all beds are always available. NB. This parameter is over-ridden if an argument is provided to the module initialiser.
EquipmentCatalogue	DATA_FRAME	Data on equipment items and packages.
equipment_availability_estimates	DATA_FRAME	Data on the availability of equipment items and packages.
equip_availability	STRING	What to assume about the availability of equipment. If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no equipment ever be available; if ‘all’, then all equipment is always available. NB. This parameter is over-ridden if an argument is provided to the module initialiser.
equip_availability_postSwitch	STRING	What to assume about the availability of equipment after the switch (see year_equip_availability_switch). The options for this are the same as equip_availability.
year_equip_availability_switch	INT	Year in which the assumption for equip_availability changes (The change happens on 1st January of that year.)
Service_Availability	LIST	List of services to be available. NB. This parameter is over-ridden if an argument is provided to the module initialiser.
policy_name	STRING	Name of priority policy adopted
year_mode_switch	INT	Year in which mode switch is enforced
scale_to_effective_capabilities	BOOL	In year in which mode switch takes place, will rescale available capabilities to match thosethat were effectively used (on average) in the past year if this is set to True. This way,we can approximate overtime and rushing of appts even in mode 2.
year_cons_availability_switch	INT	Year in which consumable availability switch is enforced. The change happenson 1st January of that year.)
year_use_funded_or_actual_staffing_switch	INT	Year in which switch for use_funded_or_actual_staffing is enforced. (The change happenson 1st January of that year.)
priority_rank	DICT	Data on the priority ranking of each of the Treatment_IDs to be adopted by the queueing system under different policies, where the lower the number the higher the priority, and on which categories of individuals classify for fast-tracking for specific treatments
HR_scaling_by_level_and_officer_type_table	DICT	Factors by which capabilities of medical officer types at different levels will bescaled at the start of the year specified by year_HR_scaling_by_level_and_officer_type. Thisserves to simulate a number of effects (e.g. absenteeism, boosting capabilities of specific medical cadres, etc). This is the imported from an Excel workbook: keys are the worksheet names and values are the worksheets in the format of pd.DataFrames. Additional scenarios can be added by adding worksheets to this workbook: the value of HR_scaling_by_level_and_officer_type_mode indicates which sheet is used.
year_HR_scaling_by_level_and_officer_type	INT	Year in which one-off constant HR scaling will take place. (The change happenson 1st January of that year.)
HR_scaling_by_level_and_officer_type_mode	STRING	Mode of HR scaling considered at the start of the simulation. This corresponds to the nameof the worksheet in ResourceFile_HR_scaling_by_level_and_officer_type.xlsx that should be used. Options are: default (capabilities are scaled by a constaint factor of 1); data (factors informed by survey data); and, custom (user can freely set these factors as parameters in the analysis).
HR_scaling_by_district_table	DICT	Factors by which daily capabilities in different districts will bescaled at the start of the year specified by year_HR_scaling_by_district to simulate(e.g., through catastrophic event disrupting delivery of services in particular district(s)).This is the import of an Excel workbook: keys are the worksheet names and values are the worksheets in the format of pd.DataFrames. Additional scenarios can be added by adding worksheets to this workbook: the value of HR_scaling_by_district_mode indicates whichsheet is used.
year_HR_scaling_by_district	INT	Year in which scaling of daily capabilities by district will take place. (The change happenson 1st January of that year.)
HR_scaling_by_district_mode	STRING	Mode of scaling of daily capabilities by district. This corresponds to the name of the worksheet in the file ResourceFile_HR_scaling_by_district.xlsx.
yearly_HR_scaling	DICT	Factors by which HR capabilities are scaled. Each sheet specifies a ‘mode’ for dynamic HR scaling. The mode to use is determined by the parameter yearly_HR_scaling_mode. Each sheet must have the same format, including the same column headers. On each sheet, the first row (for 2010, when the simulation starts) specifies the initial configuration: dynamic_HR_scaling_factor (float) is the factor by which all human resoucres capabilities and multiplied; scale_HR_by_popsize (bool) specifies whether the capabilities should (also) grow by the factor by which the population has grown in the last year. Each subsequent row specifies a year where there should be a CHANGE in the configuration. If there are no further rows, then there is no change. But, for example, an additional row of the form `2015, 1.05, TRUE` would mean that on 1st January of 2015, 2016, 2017, ….(and the rest of the simulation), the capabilities would increase by the product of 1.05 and by the ratio of the population size to that in the year previous.
yearly_HR_scaling_mode	STRING	Specifies which of the policies in yearly_HR_scaling should be adopted. This corresponds toa worksheet of the file ResourceFile_dynamic_HR_scaling.xlsx.
tclose_overwrite	INT	Decide whether to overwrite tclose variables assigned by disease modules
tclose_days_offset_overwrite	INT	Offset in days from topen at which tclose will be set by the healthsystem for all HSIsif tclose_overwrite is set to True.
mode_appt_constraints	INT	Integer code in {0, 1, 2} determining mode of constraints with regards to officer numbers and time - 0: no constraints, all HSI events run with no squeeze factor, 1: elastic constraints, all HSI events run with squeeze factor, 2: hard constraints, only HSI events with no squeeze factor run. N.B. This parameter is over-ridden if an argument is provided to the module initialiser.
mode_appt_constraints_postSwitch	INT	Mode considered after a mode switch in year_mode_switch.
cons_availability_postSwitch	STRING	Consumables availability after switch in year_cons_availability_switch. Acceptable valuesare the same as those for Parameter cons_availability.
use_funded_or_actual_staffing_postSwitch	STRING	Staffing availability after switch in year_use_funded_or_actual_staffing_switch. Acceptable values are the same as those for Parameter use_funded_or_actual_staffing.

PROPERTIES:

Item	Type	Description
hs_is_inpatient	BOOL	Whether or not the person is currently an in-patient at any medical facility

Class attributes:

INIT_DEPENDENCIES : {‘Demography’}

__annotations__ : {}

capabilities_today : <property object at 0x30ca546d0>

hsi_event_counts : <property object at 0x30ca548b0>

never_ran_hsi_event_counts : <property object at 0x30ca54900>

use_funded_or_actual_staffing : <property object at 0x30ca547c0>

Functions (defined or overridden in class HealthSystem):

__init__(name: str | None = None, resourcefilepath: Path | None = None, service_availability: List[str] | None = None, mode_appt_constraints: int | None = None, cons_availability: str | None = None, beds_availability: str | None = None, equip_availability: str | None = None, randomise_queue: bool = True, ignore_priority: bool = False, policy_name: str | None = None, capabilities_coefficient: float | None = None, use_funded_or_actual_staffing: str | None = None, disable: bool = False, disable_and_reject_all: bool = False, compute_squeeze_factor_to_district_level: bool = True, hsi_event_count_log_period: str | None = 'month')

Parameters:

• name – Name to use for module, defaults to module class name if None.

• resourcefilepath – Path to directory containing resource files.

• service_availability – A list of treatment IDs to allow.

• mode_appt_constraints – Integer code in {0, 1, 2} determining mode of constraints with regards to officer numbers and time - 0: no constraints, all HSI events run with no squeeze factor, 1: elastic constraints, all HSI events run with squeeze factor, 2: hard constraints, only HSI events with no squeeze factor run.

• cons_availability – If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then

let no consumable be ever be available; if ‘all’, then all consumables are always available. When using ‘all’ or ‘none’, requests for consumables are not logged. :param beds_availability: If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no beds be ever be available; if ‘all’, then all beds are always available. :param equip_availability: If ‘default’ then use the availability specified in the ResourceFile; if ‘none’, then let no equipment ever be available; if ‘all’, then all equipment is always available. :param randomise_queue ensure that the queue is not model-dependent, i.e. properly randomised for equal topen

and priority

Parameters:

• ignore_priority – If True do not use the priority information in HSI event to schedule

• policy_name – Name of priority policy adopted

• capabilities_coefficient – Multiplier for the capabilities of health officers, if None set to ratio of initial population to estimated 2010 population.

• use_funded_or_actual_staffing – If actual, then use the numbers and distribution of staff estimated to be available currently; If funded, then use the numbers and distribution of staff that are potentially available. If ‘funded_plus`, then use a dataset in which the allocation of staff to facilities is tweaked so as to allow each appointment type to run at each facility_level in each district for which it is defined.

• disable – If True, disables the health system (no constraints and no logging) and every HSI event runs.

• disable_and_reject_all – If True, disable health system and no HSI events run

• compute_squeeze_factor_to_district_level – Whether to compute squeeze_factors to the district level, or the national level (which effectively pools the resources across all districts).

• hsi_event_count_log_period – Period over which to accumulate counts of HSI events that have run before logging and reseting counters. Should be on of strings 'day', 'month', 'year'. 'simulation' to log at the end of each day, end of each calendar month, end of each calendar year or the end of the simulation respectively, or None to not track the HSI event details and frequencies.

read_parameters(data_folder)

Read parameter values from file, if required.

Must be implemented by subclasses.

Parameters:

data_folder – path of a folder supplied to the Simulation containing data files. Typically, modules would read a particular file within here.

pre_initialise_population()

Generate the accessory classes used by the HealthSystem and pass to them the data that has been read.

initialise_population(population)

Set our property values for the initial population.

This method is called by the simulation when creating the initial population, and is responsible for assigning initial values, for every individual, of those properties ‘owned’ by this module, i.e. those declared in its PROPERTIES dictionary.

By default, all Property``s in ``self.PROPERTIES will have their columns in the population dataframe set to the default value.

Modules that wish to implement this behaviour do not need to implement this method, it will be inherited automatically. Modules that wish to perform additional steps during the initialise_population stage should reimplement this method and call

`python super().initialise_population(population=population) `

at the beginning of the method, then proceed with their additional steps. Modules that do not wish to inherit this default behaviour should re-implement initialise_population without the call to super() above.

TODO: We probably need to declare somehow which properties we ‘read’ here, so the simulation knows what order to initialise modules in!

Parameters:

population – The population of individuals in the simulation.

initialise_simulation(sim)

Get ready for simulation start.

Must be implemented by subclasses.

This method is called just before the main simulation loop begins, and after all modules have read their parameters and the initial population has been created. It is a good place to add initial events to the event queue.

on_birth(mother_id, child_id)

Initialise our properties for a newborn individual.

Must be implemented by subclasses.

This is called by the simulation whenever a new person is born.

Parameters:

• mother_id – the person id for the mother of this child (can be -1 if the mother is not identified).

• child_id – the person id of new child

on_simulation_end()

Put out to the log the information from the tracker of the last day of the simulation

setup_priority_policy()

process_healthsystem_organisation_files()

Create the data-structures needed from the information read into the parameters: * self._facility_levels * self._appointment_types * self._appt_times * self._appt_type_by_facLevel * self._facility_by_facility_id * self._facilities_for_each_district

setup_daily_capabilities(use_funded_or_actual_staffing)

Set up self._daily_capabilities and self._officers_with_availability. This is called when the value for use_funded_or_actual_staffing is set - at the beginning of the simulation

and when the assumption when the underlying assumption for use_funded_or_actual_staffing is updated

format_daily_capabilities(use_funded_or_actual_staffing: str) → tuple[Series, Series]

This will updates the dataframe for the self.parameters[‘Daily_Capabilities’] so as to: 1. include every permutation of officer_type_code and facility_id, with zeros against permutations where no capacity is available. 2. Give the dataframe an index that is useful for merging on (based on Facility_ID and Officer Type) (This is so that its easier to track where demands are being placed where there is no capacity) 3. Compute daily capabilities per staff. This will be used to compute staff count in a way that is independent of assumed efficiency.

_rescale_capabilities_to_capture_effective_capability()

update_consumables_availability_to_represent_merging_of_levels_1b_and_2(df_original)

To represent that facility levels ‘1b’ and ‘2’ are merged together under the label ‘2’, we replace the availability of consumables at level 2 with new values.

get_service_availability() → List[str]

Returns service availability. (Should be equal to what is specified by the parameter, but overwrite with what was provided in argument if an argument was specified – provided for backward compatibility/debugging.)

get_cons_availability() → str

Returns consumables availability. (Should be equal to what is specified by the parameter, but overwrite with what was provided in argument if an argument was specified – provided for backward compatibility/debugging.)

get_beds_availability() → str

Returns beds availability. (Should be equal to what is specified by the parameter, but overwrite with what was provided in argument if an argument was specified – provided for backward compatibility/debugging.)

get_equip_availability() → str

Returns equipment availability. (Should be equal to what is specified by the parameter, but can be overwritten with what was provided in argument if an argument was specified – provided for backward compatibility/debugging.)

schedule_to_call_never_ran_on_date(hsi_event: HSI_Event, tdate: datetime)

Function to schedule never_ran being called on a given date

get_mode_appt_constraints() → int

Returns mode_appt_constraints. (Should be equal to what is specified by the parameter, but overwrite with what was provided in argument if an argument was specified – provided for backward compatibility/debugging.)

get_priority_policy_initial() → str

Returns priority_policy. (Should be equal to what is specified by the parameter, but overwrite with what was provided in argument if an argument was specified – provided for backward compatibility/debugging.)

load_priority_policy(policy)

schedule_hsi_event(hsi_event: HSI_Event, priority: int, topen: datetime, tclose: datetime | None = None, do_hsi_event_checks: bool = True)

Schedule a health system interaction (HSI) event.

Parameters:

• hsi_event – The HSI event to be scheduled.

• priority – The priority for the HSI event: 0 (highest), 1 or 2 (lowest)

• topen – The earliest date at which the HSI event should run.

• tclose – The latest date at which the HSI event should run. Set to one week after topen if None.

• do_hsi_event_checks – Whether to perform sanity checks on the passed hsi_event argument to check that it constitutes a valid HSI event. This is intended for allowing disabling of these checks when scheduling multiple HSI events of the same HSI_Event subclass together, in which case typically performing these checks for each individual HSI event of the shared type will be redundant.

_add_hsi_event_queue_item_to_hsi_event_queue(priority, topen, tclose, hsi_event) → None

Add an event to the HSI_EVENT_QUEUE.

enforce_priority_policy(hsi_event) → int

Return priority for HSI_Event based on policy under consideration

check_hsi_event_is_valid(hsi_event)

Check the integrity of an HSI_Event.

static is_treatment_id_allowed(treatment_id: str, service_availability: list) → bool

Determine if a treatment_id (specified as a string) can be run (i.e., is within the allowable set of treatments, given by self.service_availability. The rules are as follows:

• An empty list means nothing is allowed

• A list that contains only an asteriks [‘*’] means run anything

• If the list is not empty, then a treatment_id with a first part “FirstAttendance_” is also allowed

• An entry in the list of the form “A_B_C” means a treatment_id that matches exactly is allowed

• An entry in the list of the form “A_B_*” means that a treatment_id that begins “A_B_” or “A_B” is allowed

schedule_batch_of_individual_hsi_events(hsi_event_class, person_ids, priority, topen, tclose=None, **event_kwargs)

Schedule a batch of individual-scoped HSI events of the same type.

Only performs sanity checks on the HSI event for the first scheduled event thus removing the overhead of multiple redundant checks.

Parameters:

• hsi_event_class – The HSI_Event subclass of the events to schedule.

• person_ids – A sequence of person ID index values to use as the targets of the HSI events being scheduled.

• priority – The priority for the HSI events: 0 (highest), 1 or 2 (lowest). Either a single value for all events or an iterable of per-target values.

• topen – The earliest date at which the HSI events should run. Either a single value for all events or an iterable of per-target values.

• tclose – The latest date at which the HSI events should run. Set to one week after topen if None. Either a single value for all events or an iterable of per-target values.

• event_kwargs – Any additional keyword arguments to pass to the hsi_event_class initialiser in addition to person_id.

appt_footprint_is_valid(appt_footprint)

Checks an appointment footprint to ensure it is in the correct format. :param appt_footprint: Appointment footprint to check. :return: True if valid and False otherwise.

get_blank_appt_footprint()

This is a helper function so that disease modules can easily create their appt_footprints. It returns an empty Counter instance.

get_facility_info(hsi_event) → FacilityInfo

Helper function to find the facility at which an HSI event will take place based on their district of residence and the level of the facility of the HSI.

get_appt_footprint_as_time_request(facility_info: FacilityInfo, appt_footprint: dict)

This will take an APPT_FOOTPRINT and return the required appointments in terms of the time required of each Officer Type in each Facility ID. The index will identify the Facility ID and the Officer Type in the same format as is used in Daily_Capabilities. :params facility_info: The FacilityInfo describing the facility at which the appointment occurs :param appt_footprint: The actual appt footprint (optional) if different to that in the HSI event. :return: A Counter that gives the times required for each officer-type in each facility_ID, where this time

is non-zero.

get_squeeze_factors(footprints_per_event, total_footprint, current_capabilities, compute_squeeze_factor_to_district_level: bool)

This will compute the squeeze factors for each HSI event from the list of all the calls on health system resources for the day. The squeeze factor is defined as (call/available - 1). ie. the highest fractional over-demand among any type of officer that is called-for in the appt_footprint of an HSI event. A value of 0.0 signifies that there is no squeezing (sufficient resources for the EXPECTED_APPT_FOOTPRINT).

Parameters:

• footprints_per_event – List, one entry per HSI event, containing the minutes required from each health officer in each health facility as a Counter (using the standard index)

• total_footprint – Counter, containing the total minutes required from each health officer in each health facility when non-zero, (using the standard index)

• current_capabilities – Series giving the amount of time available for each health officer in each health facility (using the standard index)

• compute_squeeze_factor_to_district_level – Boolean indicating whether the computation of squeeze_factors should be specific to each district (when True), or if the computation of squeeze_factors should be on the basis that resources from all districts can be effectively “pooled” (when `False).

Returns:

squeeze_factors: an array of the squeeze factors for each HSI event (position in array matches that in the all_call_today list).

record_hsi_event(hsi_event, actual_appt_footprint=None, squeeze_factor=None, did_run=True, priority=None)

Record the processing of an HSI event. It will also record the actual appointment footprint. :param hsi_event: The HSI_Event (containing the initial expectations of footprints) :param actual_appt_footprint: The actual Appointment Footprint (if individual event) :param squeeze_factor: The squeeze factor (if individual event)

write_to_hsi_log(event_details: HSIEventDetails, person_id: int, facility_id: int | None, squeeze_factor: float, did_run: bool, priority: int)

Write the log HSI_Event and add to the summary counter.

call_and_record_never_ran_hsi_event(hsi_event, priority=None)

Record the fact that an HSI event was never ran. If this is an individual-level HSI_Event, it will also record the actual appointment footprint :param hsi_event: The HSI_Event (containing the initial expectations of footprints)

write_to_never_ran_hsi_log(event_details: HSIEventDetails, person_id: int, facility_id: int | None, priority: int)

Write the log HSI_Event and add to the summary counter.

log_current_capabilities_and_usage()

This will log the percentage of the current capabilities that is used at each Facility Type, according the runnning_total_footprint. This runs every day.

remove_beddays_footprint(person_id)

find_events_for_person(person_id: int)

Find the events in the HSI_EVENT_QUEUE for a particular person. :param person_id: the person_id of interest :returns list of tuples (date_of_event, event) for that person_id in the HSI_EVENT_QUEUE.

NB. This is for debugging and testing only - not for use in real simulations as it is slow

reset_queue()

Set the HSI event queue to be empty

get_item_codes_from_package_name(package: str) → dict

Helper function to provide the item codes and quantities in a dict of the form {<item_code>:<quantity>} for a given package name.

get_item_code_from_item_name(item: str) → int

Helper function to provide the item_code (an int) when provided with the name of the item

override_availability_of_consumables(item_codes) → None

Over-ride the availability (for all months and all facilities) of certain consumables item_codes. Note that these changes will not persist following a change of the overall modulator of consumables availability, Consumables.availability. :param item_codes: Dictionary of the form {<item_code>: probability_that_item_is_available} :return: None

_write_hsi_event_counts_to_log_and_reset()

_write_never_ran_hsi_event_counts_to_log_and_reset()

on_end_of_day() → None

Do jobs to be done at the end of the day (after all HSI run)

on_end_of_month() → None

Do jobs to be done at the end of the month (after all HSI run)

on_end_of_year() → None

Write to log the current states of the summary counters and reset them.

run_individual_level_events_in_mode_0_or_1(_list_of_individual_hsi_event_tuples: List[HSIEventQueueItem]) → List

Run a list of individual level events. Returns: list of events that did not run (maybe an empty list).

class HealthSystemScheduler(module: HealthSystem)

This is the HealthSystemScheduler. It is an event that occurs every day and must be the LAST event of the day. It inspects the calls on the healthsystem and commissions event to occur that are consistent with the healthsystem’s capabilities for the following day, given assumptions about how this decision is made.

N.B. Events scheduled for the same day will occur that day, but after those which were scheduled on an earlier date.

The overall Prioritization algorithm is: * Look at events in order (the order is set by the heapq: see schedule_hsi_event) * Ignore if the current data is before topen * Remove and do nothing if tclose has expired * Run any population-level HSI events * For an individual-level HSI event, check if there are sufficient health system capabilities to run the event

If the event is to be run, then the following events occur:

• The HSI event itself is run.

• The occurrence of the event is logged

• The resources used are ‘occupied’ (if individual level HSI event)

• Other disease modules are alerted of the occurrence of the HSI event (if individual level HSI event)

Here is where we can have multiple types of assumption regarding how these capabilities are modelled.

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

Bases: tlo.events.RegularEvent, tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

Functions (defined or overridden in class HealthSystemScheduler):

__init__(module: HealthSystem)

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

static _is_last_day_of_the_year(date)

static _is_last_day_of_the_month(date)

_get_events_due_today() → Tuple[List, List]

Interrogate the HSI_EVENT queue object to remove from it the events due today, and to return these in two lists:

• list_of_individual_hsi_event_tuples_due_today

process_events_mode_0_and_1(hold_over: List[HSIEventQueueItem]) → None

process_events_mode_2(hold_over: List[HSIEventQueueItem]) → None

apply(population)

Apply this event to the given target.

This is a no-op; subclasses should override this method.

Parameters:

target – the target of the event

class HealthSystemChangeParameters(module: HealthSystem, parameters: Dict)

Event that causes certain internal parameters of the HealthSystem to be changed; specifically:

• mode_appt_constraints

• ignore_priority

• capabilities_coefficient

• cons_availability

• beds_availability

• equip_availability

• use_funded_or_actual_staffing

Note that no checking is done here on the suitability of values of each parameter.

Create a new event.

Note that just creating an event does not schedule it to happen; that must be done by calling Simulation.schedule_event.

Parameters:

• module – the module that created this event. All subclasses of Event take this as the first argument in their constructor, but may also take further keyword arguments.

• priority – a keyword-argument to set the priority (see Priority enum)

Bases: tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

Functions (defined or overridden in class HealthSystemChangeParameters):

__init__(module: HealthSystem, parameters: Dict)

Create a new event.

Note that just creating an event does not schedule it to happen; that must be done by calling Simulation.schedule_event.

Parameters:

• module – the module that created this event. All subclasses of Event take this as the first argument in their constructor, but may also take further keyword arguments.

• priority – a keyword-argument to set the priority (see Priority enum)

apply(population)

Apply this event to the given target.

Must be implemented by subclasses.

Parameters:

target – the target of the event

class DynamicRescalingHRCapabilities(module)

This event exists to scale the daily capabilities assumed at fixed time intervals

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

Bases: tlo.events.RegularEvent, tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

current_pop_size : <property object at 0x30ca54bd0>

Functions (defined or overridden in class DynamicRescalingHRCapabilities):

__init__(module)

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

_get_most_recent_year_specified_for_a_change_in_configuration() → int

Get the most recent year (in the past), for which there is an entry in parameters[‘yearly_HR_scaling’].

apply(population)

Do the scaling on the capabilities based on instruction that is in force at this time.

class ConstantRescalingHRCapabilities(module)

This event exists to scale the daily capabilities, with a factor for each Officer Type at each Facility_Level.

Create a new event.

Note that just creating an event does not schedule it to happen; that must be done by calling Simulation.schedule_event.

Parameters:

• module – the module that created this event. All subclasses of Event take this as the first argument in their constructor, but may also take further keyword arguments.

• priority – a keyword-argument to set the priority (see Priority enum)

Bases: tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

Functions (defined or overridden in class ConstantRescalingHRCapabilities):

__init__(module)

Create a new event.

Note that just creating an event does not schedule it to happen; that must be done by calling Simulation.schedule_event.

Parameters:

• module – the module that created this event. All subclasses of Event take this as the first argument in their constructor, but may also take further keyword arguments.

• priority – a keyword-argument to set the priority (see Priority enum)

apply(population)

Apply this event to the given target.

Must be implemented by subclasses.

Parameters:

target – the target of the event

class RescaleHRCapabilities_ByDistrict(module)

This event exists to scale the daily capabilities, with a factor for each district.

Create a new event.

Note that just creating an event does not schedule it to happen; that must be done by calling Simulation.schedule_event.

Parameters:

• module – the module that created this event. All subclasses of Event take this as the first argument in their constructor, but may also take further keyword arguments.

• priority – a keyword-argument to set the priority (see Priority enum)

Bases: tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

Functions (defined or overridden in class RescaleHRCapabilities_ByDistrict):

__init__(module)

Create a new event.

Note that just creating an event does not schedule it to happen; that must be done by calling Simulation.schedule_event.

Parameters:

• module – the module that created this event. All subclasses of Event take this as the first argument in their constructor, but may also take further keyword arguments.

• priority – a keyword-argument to set the priority (see Priority enum)

apply(population)

Apply this event to the given target.

Must be implemented by subclasses.

Parameters:

target – the target of the event

class HealthSystemChangeMode(module)

This event exists to change the priority policy adopted by the HealthSystem at a given year.

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

Bases: tlo.events.RegularEvent, tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

Functions (defined or overridden in class HealthSystemChangeMode):

__init__(module)

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

apply(population)

Apply this event to the given target.

This is a no-op; subclasses should override this method.

Parameters:

target – the target of the event

class HealthSystemLogger(module)

This event runs at the start of each year and does any logging jobs for the HealthSystem module.

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

Bases: tlo.events.RegularEvent, tlo.events.Event, tlo.events.PopulationScopeEventMixin

Class attributes:

__annotations__ : {}

Functions (defined or overridden in class HealthSystemLogger):

__init__(module)

Create a new regular event.

Parameters:

• module – the module that created this event

• frequency (pandas.tseries.offsets.DateOffset) – the interval from one occurrence to the next (must be supplied as a keyword argument)

apply(population)

Things to do at the start of the year

log_number_of_staff()

Write to the summary log with the counts of staff (by cadre/facility/level) taking into account: * Any scaling of capabilities that has taken place, year-by-year, or cadre-by-cadre * Any re-scaling that has taken place at the transition into Mode 2.