use_funded_or_actuall_staffing switch not always compatible with rescaling by population size

[marghe-molaro]

"actual" and "funded" assumptions around staffing are based on 2018 data.
If wishing to expand them with population growth, they would therefore need to start rescaling from 2019 onwards.
This clashes with the option to switch from "actual" to "funded" (or vice versa) at an arbitrary year year_use_funded_or_actuall_staffing_switch. E.g. if deciding to switch in 2024, capabilities in that year would not have benefitted from the population expansion that should have occurred from 2019 onwards, but rather will be the values assumed from the 2018 data + 1 year of population rescaling.

[tbhallett]

Good point. So, maybe inside this function ....

TLOmodel/src/tlo/methods/healthsystem.py

Lines 934 to 944 in e8c94e4

	def setup_daily_capabilities(self, 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"""
	# * Store 'DailyCapabilities' in correct format and using the specified underlying assumptions
	self._daily_capabilities = self.format_daily_capabilities(use_funded_or_actual_staffing)
	# Also, store the set of officers with non-zero daily availability
	# (This is used for checking that scheduled HSI events do not make appointment requiring officers that are
	# never available.)
	self._officers_with_availability = set(self._daily_capabilities.index[self._daily_capabilities > 0])

.... we need to also effectively do any scaling that has been called from within RescaleHRCapabilities_ByDistrict and ConstantRescalingHRCapabilities and DynamicRescalingHRCapabilities.

One way that I occurs to me or doing this would be:

• When those functions recursively develop the scaling-factors (on minutes of time per officer and per district), they're saved to a "scaling_matrix" rather than directly operating on self._daily_capabilities.
• When we call self._daily_capabilities, what we want returned is actually self._original_daily_capabilities * scaling_matrix (where self._original_daily_capabilities is the original version of scaled/funded capabilities)
• This way, we can swap in different values for self._original_daily_capabilities and still the scaling that has "already happened" will update them.

There are probably a million other ways though, and you've probably also already solved it.

[marghe-molaro]

Yes there's quite a possible few solutions. Notice that in the case of scaling with population growth this still wouldn't solve the issue of having to rescale the 'new' post-switch staffing by a factor of pop_in_year_of_switch/pop_in_2018 - i.e. we'd have to store the pop in 2018 somewhere.

I think for me there's a more fundamental issue with mixing the switch in staffing and the rescaling: the latter (in all its forms, whether as a one-off or dynamic) was designed to be a proportional rescaling of initially assumed resources, which ensures it is always safe to take place at any place and in no matter what order. But in this case we want to change the initially assumed resources halfway, even if those were being potentially rescaled before that switch. Even conceptually this is a bit odd: what do we mean by switching from actual to funded if the actual resources were already been scaled e.g. by GDP growth? What if by the time we invoke the staff switch they had already been rescaled to an amount greater than funded?