Include task-shifting

[marghe-molaro]

Initial task-shifting implementation, currently assuming that the health-system adopts a "global policy" on task shifting. We will potentially transition to treatment-specific after health-econ discussion on 8th March.

PR includes test (test_task_shifting_in_mode_2)

Other notes:

• We assume ranking in preferred option for task-shifting (e.g. first choice for task-shifting pharmacists are nurses, followed by clinicians);
• We assume that task-shifting occurs immediately when appt is extracted from the queue (i.e. we don't wait until the end of the day to check if we could have performed extra appts by allowing task-shifting). This seems consistent with the fact that appts are ranked by priority: earlier appts in the queue are higher priority, and therefore the health system does everything possible, including task-shifting, to complete them first.
• We assume that tasks performed by different medical officers don't have to be performed simultaneously, i.e. if appt requires both nurse and pharmacist, nurse will be able to perform own task and that of pharmacist if the latter is no longer available.
• Currently we have no way of logging occurrences of task-shifting (although of course in mode 2 it will impact the number of appts performed) because we don't have appt_footprints that reflect the task shifting. We can discuss whether we want to address this or not.

[tdm32]

@marghe-molaro we maybe do want some measure of the amount of task-shifting which occurs during a simulation so we could quantify for example, what would we gain if nurses were allowed to spend 25% of their time on pharmacy tasks? Or conversely, if global task-shifting is permitted, how much nurses time would be required to fill the gaps through pharmacists being under-resourced? We could do this through counterfactuals of course, but having direct measures is always useful as counterfactuals quickly diverge making run-by-run comparisons tricky.

[tdm32]

@marghe-molaro also noting here the important role that DCSAs may play when we consider task-shifting - they are already doing MDA and child health days for example.

[tbhallett]

Thanks so much for this, @marghe-molaro

This is all very nice and seems to work well.

My suggestions boil-down to three things:

1. In the test, I think we should repeat that experiment with/without global task shifting and see the difference.

2. Interface-wise, I think let this only and fully controlled by a csv ResourceFile describing the global task shifting we want (If it's blank it means we don't want any). And let's not have the key-word argument thing, as it's not necessary.

3. Logic and logging-wise: I thought that we could perhaps store onto the HSI Event itself the 'task-shifted' appointment and then manufacture that this is returned from the HSI_Event (as the 'ACTUAL_APPT_FOOTPRINT`). That way the updating of capabilities and the logging of what actual is used all happens automatically. In addition we could have a flag that this is a "task shifted" appointment, which would also flow into the logs.

[tbhallett]

why a module keyword argument and a module Parameter? I think best to stick to it being ONLY a Parameter, if possible.

[tbhallett]

I think more pythonic to write as we don;t then rely on ordering of these two lists, and the relationship between the numbers (1.5, 1.0) and strings ('Nursing', 'Clinical') is made explicit. (Also when it's used you're using zip to iterate through these things together, but if it were a dict, you could just use .items())

Suggested change

	self.global_task_shifting = {
	'Pharmacy': (['Nursing_and_Midwifery', 'Clinical'], [1.5,1]),
	}
	self.global_task_shifting = {
	'Pharmacy': {'Nursing_and_Midwifery': 1.5, 'Clinical': 1.0},
	}

[tbhallett]

Also - shouldn't think be read in from a .csv ResourceFile, so that we can edit this in different simulations?

Structure of .csv file:

Nursing_and_Midwifery,1.5
Clinical,1.0

This would actually made the Parameter (include_task_shifting) redundant, because if we didn't want to allow any (global) task shifting rules, then this file would be blank.

[tbhallett]

Suggested change

	if self.sim.modules['HealthSystem'].include_task_shifting:
	if self.module.include_task_shifting:

[tbhallett]

why unpack only to zip in the following line? I think we can skip this line.

[tbhallett]

Suggested change

	# options
	# options for other officers to task-shift to.

[tbhallett]

indeed, this would be another reason to let the HSI return actual footprint that its provided with

[marghe-molaro]

See reply to comment above

[tbhallett]

as above, it seems duplicative to me to provide two ways to modify this behaviour. I think it should just be through Parameters.

[marghe-molaro]

yes you are right, the reason this wasn't optimised at this stage is that we're still not sure whether we wanted to allow for a global and HSI-specific task-shifting approach (in which case e.g. include_task_shifting could be categorical - None, Global-level, HSI-level and we would have an additional resource file in case of global taskshifting, one for HSI-based on etc)

[tbhallett]

I think it's always the case that we should modify the behaviour of the module through Parametees rather than kwargs though, as that it has the Scenario class expects to pass through changes.

[tbhallett]

To strengthen the test and see the impact of task-shifting versus no task-shifting, I think it would be good to repeat this for with/without global task-shifting so we can see the difference.

[sakshimohan]

Thanks for adding me to this @marghe-molaro. I'm unable to offer comments on the code, but the approach sounds right to me.

[marghe-molaro]

Many thanks @tdm32 and @tbhallett for your comments!

Tara's points:

• I take your point about the need to log the amount of task-shifting - how we do it will depend on whether we go down the "global" or "HSI-specific" task-shifting I think. Notice however that we currently don't cap the amount of task-shifting that specific cadres can do (25% in your example); if we wanted to include that it would have to be implemented quite differently I think.
• The current task-shifting set up was only an example, I take your point about including DCSAs.

Tim's points:

1. No problem about adding the alternative scenario in the test;
   2.-3. I think these points will depend on how the specifics of the scenarios we want to implement, in particular whether we opt to go for a global approach to the task-shifting or make it HSI-specific. I think for this reason it might be best to wait until the discussion at the Health Econ meeting next friday to decide how we answer these.

I replied to some of your comments directly Tim.

[marghe-molaro]

Hi @tbhallett and @tdm32,

(Note: Tests are failing on github but running fine locally.)

Following the discussion on Wed, I have now made the following modifications to this PR:

_appt_times (which links appt_footprints to the officers&times required to perform the appointment) is now inflated in pre-processing to include new appt_footprints, which account for all possible task-shifting that may take place given the policy specified by global_task_shifting.
The name of the new appt_footprints is the original appt_footprint followed by "_withTS_xxxx-yyyy_and_xxxx-yyyy..." where xxxx are the first four letters of the officer which will be task-shifted, and yyyy are the first four letters of the officer taking over the tasks. E.g. "Under5OPD_withTS_Phar-Nurs_and_Clin-DCSA" is an Under5OPD appt where the tasks originally assigned to a Pharmacist are performed by a Nurse, and where tasks assigned to a Clinician are performed by a DCSA instead. Times required are updated to reflect TS taking place.

At the time of running HSIs in mode 2, if task-shifting is required a tag "withTS..." with all relevant task-shifting info will be added to the actual_appt_footprint returned by the HSI, such that times requested from each officer can be quickly looked-up from the expanded _appt_times (and hence subtracted from daily capabilities) rather than having to be recalculated for each HSI at run time. In doing so the TS can be logged as having occurred with details of how that took place directly as part of the logged appointment footprint.

It is difficult to say whether this approach will be faster than the one we had implemented before, as this will very much depend on how much TS actually takes place. It shouldn't impact runs where TS is not included. This approach however allows us to easily log TS as having taken place in all relevant detail.

[marghe-molaro]

@tbhallett following today's Health Econ discussion I would suggest pausing review of this PR until we have a clearer idea of how we want to enforce task-shifting, in particular if we want this to be more HSI-driven.

[tbhallett]

Found this ResourceFile on another approach (#1296) but not here.
I removed it from #1296 during review
ResourceFile_GlobalTaskShifting.xlsx