Enable switching service availability in healthsystem module by sangeetabhatia03 · Pull Request #1802 · UCL/TLOmodel

sangeetabhatia03 · 2026-02-05T15:08:05Z

This pull request enables switching of service availability in the healthsystem module. Key changes include the addition of new parameters for service availability switching.

I have also created a scenario file for our initial analysis; would be great to get your feedback on this.

tbhallett · 2026-02-06T11:13:54Z

src/scripts/lcoa_inputs_from_tlo_analyses/scenarios_definitions.py

@@ -0,0 +1,45 @@
+"""The file contains all the definitions of scenarios for the TLO-LCOA project."""


just a quick look at this -- why not put this into your main scenario file?

tbhallett

Nice logic and nice test.

Personal taste but I would suggest simplifying the scenario file so that we have everything in one file. (The style of having it split across multiple files is useful when we have lots of scenario file drawing from the same 'base', but it feel a bit confusing here).

tbhallett · 2026-02-06T11:20:04Z

src/tlo/methods/healthsystem.py

+        if (self.sim.date.year == self.parameters['year_service_availability_switch'] - 1):
+            self._compute_factors_for_effective_capabilities()


This is fine. but its different to the pattern we have for other changes - which is to schedule an event to occur on the date we we want the switch to happen, and then let the event do this work. Don't feel strongly about this!

tbhallett · 2026-02-06T11:20:37Z

src/tlo/methods/healthsystem.py

+        # Don't increment the counter; log and return.
+        if not self.is_treatment_id_allowed(hsi_event.TREATMENT_ID, self.service_availability):
+            self.call_and_record_never_ran_hsi_event(hsi_event=hsi_event, priority=priority, clinic=clinic)
+            return


we don't need this 'return'

tbhallett · 2026-02-06T11:20:56Z

src/tlo/methods/healthsystem.py

+    def _compute_factors_for_effective_capabilities(self):
+        """Compute factor to rescale capabilities to capture effective capability.
+        Computation of these factors is split from the actual rescaling to facilitate
+        capturing them even when running the model in mode 1."""
+        self._rescaling_factors = defaultdict(dict)
+        for clinic, clinic_cl in self._daily_capabilities.items():
+            for facID_and_officer in clinic_cl.keys():
+                self._rescaling_factors[clinic][facID_and_officer] = self._summary_counter.frac_time_used_by_facID_and_officer(
+                    facID_and_officer=facID_and_officer, clinic=clinic
+                )
+        self._summary_counter._rescaling_factors = self._rescaling_factors
+


is this intended to be on this PR?

yes, so that we can log rescaling factors.

marghe-molaro

Hi @sangeetabhatia03, this is looking great, I've just added a few comments!
Summary:

I agree with Tim about having a single scenario file
I've suggested tightening the test just a little bit, it shouldn't take too long!

marghe-molaro · 2026-02-06T11:35:03Z

src/tlo/methods/healthsystem.py

+        # First check that the service the HSI needs is available. If not, don't add to queue.
+        # Don't increment the counter; log and return.
+        if not self.is_treatment_id_allowed(hsi_event.TREATMENT_ID, self.service_availability):
+            self.call_and_record_never_ran_hsi_event(hsi_event=hsi_event, priority=priority, clinic=clinic)


To be consistent with how HSIs are removed from the queue when the HSI is no longer available in the health system, I think here too never_ran should be scheduled for topen

marghe-molaro · 2026-02-06T11:40:03Z

src/scripts/lcoa_inputs_from_tlo_analyses/scenario_effect_of_treatment_ids.py

+        super().__init__()
+        self.seed = 0
+        self.start_date = Date(2010, 1, 1)
+        self.end_date = Date(2040, 1, 1)


I think to have full 15 years from the 1st of Jan 2026 you want to end this on the 1st of Jan 2041

marghe-molaro · 2026-02-06T11:41:03Z

src/scripts/lcoa_inputs_from_tlo_analyses/scenario_effect_of_treatment_ids.py

+        self.seed = 0
+        self.start_date = Date(2010, 1, 1)
+        self.end_date = Date(2040, 1, 1)
+        self.pop_size = 100


Assuming this is a relic from local tests, but just to remind ourselves I think we said we were going to go up to 250k?

marghe-molaro · 2026-02-06T11:44:21Z

src/scripts/lcoa_inputs_from_tlo_analyses/scenarios_definitions.py

+                    'yearly_HR_scaling_mode': 'historical_scaling',
+                },
+
+                "ImprovedHealthSystemAndCareSeekingScenarioSwitcher": {


Just checking - did you check that these are compatible with the suspend/resume on Azure?

As discussed with @marghe-molaro parking this check for now because switching to max_healthsystem_function and max_healthcare_seeking is the same across all draws for our current analysis.

marghe-molaro · 2026-02-06T11:45:07Z

src/scripts/lcoa_inputs_from_tlo_analyses/scenarios_definitions.py

+                    'year_of_switch': self.YEAR_OF_SERVICE_AVAILABILITY_SWITCH,
+                },
+
+                "ImprovedHealthSystemAndCareSeekingScenarioSwitcher": {


As above, would be good to double check that this is compatible

marghe-molaro · 2026-02-06T11:49:18Z

src/scripts/lcoa_inputs_from_tlo_analyses/scenario_effect_of_treatment_ids.py

+            scenario_definitions.baseline(),
+            {
+                'HealthSystem': {
+                    'service_availability_postSwitch': list(self._scenarios.values())[draw_number],


I guess you've tested locally that the conversion into a list here makes the different service_availability configurations accessible via draw_number? Just struggling to wrap my head around it without running it

marghe-molaro · 2026-02-06T11:51:14Z

tests/test_healthsystem.py

+            level="0",
+            treatment_id="ThisEventShouldNotRunPostSwitch",
+        )
+        ## These events open after service availability switch


To tighten this test a little bit, it would be good to schedule say 60% of these treatment_IDs before the switch, and 40% after. You then want to double check that 60% did go ahead (and all with dates < switch), and that 40% were never ran.

The "risk" of treatment_IDs "slipping" into the post-switch period and affecting the health outcome is I think higher than treatment_IDs being scheduled in that period at all!

…odel into sb/lcoa-inputs-from-tlo

sangeetabhatia03 added 3 commits February 5, 2026 14:35

Move lcoa changes to latest copy from master

9810cff

Scenario files from old branch

d057065

Resource file

b53448e

sangeetabhatia03 requested a review from marghe-molaro February 5, 2026 15:08

Resource file

e5e2298

tbhallett reviewed Feb 6, 2026

View reviewed changes

Merge branch 'master' into sb/lcoa-inputs-from-tlo

9634323

tbhallett reviewed Feb 6, 2026

View reviewed changes

marghe-molaro requested changes Feb 6, 2026

View reviewed changes

sangeetabhatia03 added 13 commits February 9, 2026 14:05

Single scenario file and small edits to healthsystem

5ff3732

Merge branch 'sb/lcoa-inputs-from-tlo' of https://github.com/UCL/TLOm…

ab186f0

…odel into sb/lcoa-inputs-from-tlo

Additional imports

42c67aa

Prep for submission

730542c

Modify scenario setup

10b70a3

Uncomment actual scenarios for azure run

4474b1a

Initial figures

aa092a4

Minor edits

6ba0046

Series empty;debugging

f8e060f

Figures for ContraceptionRoutine only; deaths empty; debugging

373081a

Edits to read partially completed jobs

3dec55b

Analysis figures; WIP

592fc9e

post PR 1819 merge

06b78da

		@@ -0,0 +1,45 @@
		"""The file contains all the definitions of scenarios for the TLO-LCOA project."""

		if (self.sim.date.year == self.parameters['year_service_availability_switch'] - 1):
		self._compute_factors_for_effective_capabilities()

Conversation

sangeetabhatia03 commented Feb 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tbhallett left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marghe-molaro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tbhallett left a comment •

edited

Loading