Expanding the HealthSeekingBehaviour module

[marghe-molaro]

The HealthSeekingBehaviour module currently only captures the behaviour of individuals following the onset of new symptoms; in particular, it determines whether individuals will act on those symptoms by seeking care or not. If individuals do seek care at this stage, it is then assumed that they will always follow the chain of referrals captured by the HSIs that have been scheduled for them.

There are a number of limitations with the current approach:

1. It doesn't consistently model the behaviour of individuals following an 'incomplete' appointment along the referral pathway (e.g. in the case where consumables or equipment are unavailable during the appointment).
   Current approach: each disease module independently models this behaviour; this increases the probability of inconsistent assumptions and may weaken constraints on assumed parameters.

2. It doesn't model the behaviour of individuals who have been forced to miss an appointment along the referral pathway due to external circumstances (e.g. due to mode 2 resource constraints or climate disruptions).
   Current approach: This is currently modelled ad-hoc in the HealthSystem module. Options are however limited to postponing or completely cancelling the HSI event under consideration. Notice that if the HSI is cancelled, the individual may either completely default from care (if each subsequent HSI was scheduled by the preceding one) or simply skip a single appointment (if subsequent HSIs for that individual had been scheduled at the same time). These diverging outcomes arise unintentionally due to design choices, rather than reflecting deliberate modelling of patient behaviour.

3. It doesn't model the possibility that individuals may default from care at intermediate stages of their referral pathway due to non-clinical reasons (e.g. referral to a harder-to-reach clinic, economic hardship due to increasing amount of time off work, etc).
   Current approach: not captured at all. Capturing these effects may however be particularly important both from an equity perspective, and in the future modelling of service integration and/or clinics, where these may act as mitigating factors to these effects. This effort would go hand-in-hand with improving spatial resolution of health-seeking behaviour (PR Added code to assign each individual facilities at different levels #1614).

[RachelMurray-Watson]

I will also add, that the current PR #1604 is working on point 2. raised here, by building in a mechanism of "delayed" appointments. The PR is currently handling it in two ways.

1. Appointments are cancelled.
2. Appointments re-enter the queue. This will depend on the healthcare seeking behaviour of the individual (a WIP).

[RachelMurray-Watson]

I will also add, that the current PR #1604 is working on point 2. raised here, by building in a mechanism of "delayed" appointments. The PR is currently handling it in two ways.

1. Appointments are cancelled.
2. Appointments re-enter the queue. This will depend on the healthcare seeking behaviour of the individual (a WIP).

I have expanded on this, slightly, more as a proof-of principal.

So. If it has been determined that a climate disruption has happened, the model then "assesses" the healthcare seeking behaviour of individuals (using the self.hsb_linear_models from the HealthCareSeekingBehaviour module, with no modifications). This involves a random number generator, so won't necessarily be the same outcome as before (i.e., they had already sought healthcare, so will again).

Then, if they are predicted to seek healthcare, the appointment is delayed a month (this should be modified). If not, the appointment is cancelled, and never ran is called. This will cause the loss of chain of referrals that Margherita mentioned, so either could be rectified OR just happen at a very small probability.

[RachelMurray-Watson]

As discussed in meeting on 11/11/2025:

Issue: when the weather-related delay happens, the individual comes off of treatment. The HSIs repeat prescription are still scheduled, but are blank. The person cannot “reseek” health care, so they fall off of treatment completely. This means that the HSI

Potential fixes:

1. Introduce a new did_not_run_weather, where there is a separate logic. So the person still comes off of treatment, but there is a certain probability of a new “HSI_CardioMetabolicDisorders_StartWeightLossAndMedication” being scheduled. However, the original chain would still exist: so each patient that did reseek healthcare would have one empty chain (the original that was disrupted) and one new chain. (At least - this could happen many times.)
2. Could change the logic of the HSI_CardioMetabolicDisorders_Refill_Medication. Currently, it returns a blank footprint if the individual is not on medication. So, could just have it so that it checks if the individual is on medication, and then only runs the HSI if they are.

[marghe-molaro]

In both HSIs the stated (i.e. in the comments) assumption is that if someone cannot get medications and their treatment status is set to False (as they would be, for HSI_CardioMetabolicDisorders_Refill_Medication, if did_not_run was invoked), they come back the following day to get a refill.

I think the issue is that whereas this works for HSI_CardioMetabolicDisorders_StartWeightLossAndMedication, it doesn't for HSI_CardioMetabolicDisorders_Refill_Medication, because there is no mechanism to set the person back on treatment if consumables are now available - i.e. there is a "bug" in the original implementation.

I think the simple approach for HSI_CardioMetabolicDisorders_Refill_Medication is to fix this bug - i.e. ensure that if people come back not on treatment and the consumable is available, they are 1) back on treatment and 2) the appt footprint is not blank.

We would also need to add a never_ran function to deal with cancelations. There we would need to get a bit more creative!

[RachelMurray-Watson]

Ah yes, sorry, the issue is with HSI_CardioMetabolicDisorders_Refill_Medication. The logic behind scheduling a HSI_CardioMetabolicDisorders_StartWeightLossAndMedication is because we were considering following the logic of HIV (where there is a parameter probability_of_seeking_further_art_appointment_if_appointment_not_available). So here, that would mean modifying the did_not_run to have a draw, based on this parameter, and then decide if a HSI_CardioMetabolicDisorders_StartWeightLossAndMedication is scheduled?

Agree re never_ran, for all appointments really!

[marghe-molaro]

I think the issue with HSI_CardioMetabolicDisorders_Refill_Medication under climate delays (i.e. when invoking did_not_run) can be fixed "organically" by fixing what appears to be a bug in the logic of that HSI (people not on treatment coming to that appointment should be able to be put back on treatment). So I don't think there is any need to modify the did_not_run function itself.

[RachelMurray-Watson]

Ah yes, sorry, I think that I was trying to do it in a light-touch way that didn't impact how CMD ran for other scenarios. So, by perhaps introducing a new did_not_run_weather (suggested by Tim), that could happen... I agree that changing the actual logic is probably better, but not having written the module I was unsure what to be doing