Scientific methodology

From climate exposure to unmet care.

CHRS is a stochastic, discrete-time hybrid agent-based microsimulation that follows how climate-related exposure propagates through heterogeneous health need, care seeking, spatial accessibility and finite health-service capacity. Each process is a separate submodel, so a change in outcomes can be traced to an explicit mechanism instead of disappearing into a composite risk score.

Current stage. The framework is software-verified and exercised through a controlled synthetic benchmark and a Barcelona structural pilot whose behavioural and service mechanisms remain uncalibrated. Empirical calibration and historical validation are future work with defined gates.
Dailydiscrete simulation step
Hybrid ABMresident agents + service system
Finitecapacity + carry-over queues
Pairedreplication-level contrasts
Causal pathwayMechanisms remain distinct
Climate hazardexternal shock
Spatial exposureplace + time
Vulnerabilityresident variation
Care needbefore service
Seeking + accessbehaviour + mobility
Finite capacityqueue limits
Outcomesserved · delayed · unmet
Key design choice: need is generated before service constraints.Outcomes are collected after the daily state boundary.
01 / Research logic

Explore, describe and explain before prescribing.

The methodological logic of CHRS follows four stages. The first three interrogate the model and explain simulated system behaviour. Prescription is intentionally a later stage: it would require empirical calibration, withheld validation data and a defensible link between model outputs and real decisions.

Stage 01

Exploration

Identify plausible pathways, variables, feedbacks and constraints that may connect climate exposure to health need and service continuity.

Stage 02

Description

Characterise where, when and for whom care need, access barriers, queues and unmet care emerge within a declared scenario.

Stage 03

Explanation

Use controlled scenario contrasts and mechanism evidence to examine which pathways are responsible for changes in simulated outcomes.

Stage 04 · future

Prescription

Compare interventions for decision support only after the model has been constrained and challenged with appropriate empirical evidence.

Current position: CHRS is primarily an exploratory, descriptive and explanatory computational laboratory. It does not yet support prescriptive claims about real services or populations.
02 / Model architecture

A population microsimulation coupled to a finite service system.

The model represents heterogeneous residents, spatially differentiated exposure and a health-service network whose effective capacity can change over time. Residents are rule-based agents. Facilities are resource-constrained service entities. Interaction is mediated through care need, care seeking, accessibility, facility selection, queues and allocation.

Resident agents

Demographic, vulnerability, mobility, care-need, service and exploratory health-risk states are represented separately.

Spatial layer

The synthetic benchmark uses synthetic zones with a zone-to-zone travel matrix. The Barcelona pilot maps official districts into ten harmonised zones on the same machinery.

Service facilities

Type, location, opening hours, workforce, electricity, cooling and backup power contribute to effective capacity.

Discrete time

The simulation advances in daily steps. Warm-up is simulated but excluded from analysis-window estimands.

Resident state is multidimensional

care_need_statusCurrent essential-care need

No current need, routine, urgent or emergency.

access_statusAbility to reach an eligible service

Accessible, transport limited, geographically unreachable or service unavailable.

service_statusPosition in the service pathway

Not seeking, seeking, waiting, served, delayed or unmet.

health_risk_statusExploratory model state

Stable, heat stressed, clinically deteriorating or critical; these are not validated clinical diagnoses.

  • InteractionResidents do not directly interact with one another. Competition occurs indirectly through shared facility capacity and queues.
  • BehaviourCare seeking is rule-based and probabilistic. Agents do not learn, optimise, negotiate or anticipate future waiting time.
  • EmergenceQueues, overload, access-denied need, unmet care and subgroup differences arise from the interaction of agent states, spatial access and finite allocation.
  • Climate semanticsA declared heatwave episode and observed thermal-threshold exceedance are distinct model conditions; interventions and exposure-driven mechanisms do not use them interchangeably.
03 / Why separate states

Need is not seeking. Seeking is not access. Access is not capacity.

Most risk models collapse these into one number. CHRS refuses to, because each equality hides a different policy lever and a different kind of evidence. Keeping them distinct is what makes the model auditable — and what makes its data requirements demanding.

need ≠ seekingA person can need care and never try to obtain it. Attendance-based data cannot see them at all.
seeking ≠ accessA person can decide to seek care and still fail to reach a suitable facility.
access ≠ utilisationReaching an eligible facility does not guarantee being served; capacity may be exhausted.
utilisation ≠ capacityHow many people were seen says nothing direct about how many could have been seen. Observed use must never be relabelled as capacity.
This distinction is also why the Barcelona pilot cannot calibrate from attendance counts alone — a point developed on the Barcelona evidence-gap page.
04 / Daily causal order

The sequence of events defines the estimand.

The engine executes a fixed thirteen-step causal schedule each simulated day. Causal ordering matters: care need is established before downstream behaviour, access support or service allocation, so the primary denominator never moves because an intervention changed utilisation.

One simulated dayFixed causal order · verified against simulation/model.py
00
Start-of-day state commit

Transient service flags from the previous day are cleared; served and delayed residents return to not-seeking.

01
Climate exposure

The day's zone temperatures, humidity and episode state are drawn from the climate source.

02
Infrastructure availability

Zone power and transport-disruption states are resolved for the day.

03
Facility workforce + effective capacity

Opening hours, workforce absence, cooling and electricity determine each facility's continuous effective capacity.

04
Care need + pre-allocation ledger

New need is generated, existing need resolves or escalates, and the pre-allocation demand ledger captures every resident with current need.

05
Provisional access

Unassisted accessibility is evaluated purely as a behavioural signal for seeking — not as the final outcome.

06
Care-seeking decision

Residents with current need draw for intention to seek; existing waiting residents stay queued.

07
Targeted transport selection

Bounded same-day transport support is offered to eligible genuine seekers.

08
Final support-aware access

Accessibility is recomputed with support applied — only if support actually changed; otherwise step 5 stands as final.

09
Demand accounting + queue/allocation

Access denial becomes explicit unmet demand; facility queues persist across days; allocation runs severity-first; the ledger reconciles to terminal categories.

10
Health-risk transitions

Exploratory risk-state updates occur after allocation and remain model-conditional.

11
End-of-day state commit

The day's state transition completes and is committed.

12
Outcome collection

Daily aggregates, subgroup tallies and mechanism-evidence counters are collected after the boundary.

Primary-denominator boundary: alive residents with current care need are counted in step 4 — after need generation, before seeking, intervention support, final accessibility, allocation or service receipt.
Why order matters causally: if need were measured after allocation, a capacity expansion would shrink the denominator and look like reduced need. Measuring need first keeps the estimand's meaning fixed across scenarios.
05 / Mechanisms + equations

The principal formulas the engine evaluates.

These formulas are verified against the current implementation. Every parameter that appears here is illustrative or assumed unless explicitly marked as an observed input — none has been fitted to data.

Synthetic climate baseline climate/exposure.py

The seasonal maximum-temperature baseline is a sinusoid plus seeded daily noise:

Tmax_base(t) = μ + A·sin(2πt / 365) + εₜ ,   εₜ ~ Normal(0, σ)

A declared heatwave episode adds a trapezoidal excess profile — linear ramp, plateau, linear decay:

excess(t) = peak·t/ramp  (t<ramp)  ·  peak  (plateau)  ·  peak·(D−t)/decay  (final decay)

Night-minimum temperature and relative humidity are attached to episode days as declared scenario properties.

Zone exposure and the heat multiplier vulnerability/profiles.py

Excess exposure above the cumulative threshold, by zone and day:

E_z(t) = max(0, T_z(t) − T_threshold)

Heat raises care-need pressure through a saturating multiplier:

H(E) = 1 + (M_peak − 1) · E / (E + E_half)

Zero excess leaves demand unchanged; pressure grows with exposure and asymptotically approaches the configured peak multiplier M_peak. The shape is mechanistic, not empirically calibrated.

Care-need cascade health_needs/needs.py

For a resident without current need, the engine first constructs three mutually exclusive interval widths. Heat scales all three; chronic burden scales the routine component only:

p_em = min(1, p_em,0 · H)    p_ur = min(1, p_ur,0 · H)    p_ro = min(1, p_ro,0 · H · m_chronicb)

One uniform draw then assigns at most one new need state:

u ~ U(0,1):  u < p_em → emergency  |  u < p_em+p_ur → urgent  |  u < p_em+p_ur+p_ro → routine  |  else no new need

The configuration validator guards the reachable parameter region so the three interval widths cannot silently exceed probability one. For existing need, a separate resolution draw is evaluated first; if need persists, routine need may escalate to urgent and urgent need may escalate to emergency. Served need resolves immediately. These probabilities remain illustrative rather than empirically fitted.

Care seeking simulation/model.py · step 6

Seeking is a separate probabilistic event conditional on current need. The model begins with the baseline seeking probability, applies the transport limitation penalty multiplicatively, then adds the configured health-risk boost when the resident belongs to a boost-eligible risk state:

p ← p_base
if access = transport-limited:  p ← p · (1 − penalty_transport)
if risk_status ∈ boost_statuses:  p ← min(1, p + boost_risk)
U ~ U(0,1),  U < p → seeking

A person can therefore need care and not seek it — precisely why attendance alone cannot identify need. Residents already waiting are treated as expressed demand and are not silently subjected to a fresh seeking draw that could remove them from the queue.

Travel and access geography/zones.py · access/evaluation.py

Required travel time starts from the zone-to-zone base matrix and is modified by personal mobility, transport disruption and any same-day support:

personal = 1 × m_transit [if no private vehicle and public-transport dependent] × m_mobility [if mobility limited] × m_support [if support received]
m_disruption(d) = 1 + d · (m_disruption,max − 1),  d ∈ [0,1]
minutes(origin→facility) = base_minutes(origin,facility) × m_disruption(d_origin) × personal

After the minimum-cost eligible facility is selected, the resulting travel time is compared with severity-specific thresholds: accessible within the acceptable threshold, transport-limited between the acceptable and hard limits, and geographically unreachable beyond the hard limit. If no active eligible facility with positive effective capacity exists, the classification is service unavailable.

Facility effective capacity simulation/model.py · step 3

For an operating facility, nominal capacity is transformed by workforce availability, opening hours and cooling status, then capped by the configured maximum effective-capacity factor:

C_eff = min(C_nominal · f_max,  C_nominal × workforce_fraction × hours/24 × f_cooling)

Heat-related absenteeism is constructed from a baseline plus a bounded temperature-dependent increment:

absenteeism = base + min(heat_max − base,  β_heat · max(0, T_zone − 35°C))
workforce_fraction = max(0, 1 − absenteeism)

Scenario-level staff absenteeism can multiply that absenteeism term. Electricity loss without working backup closes an electricity-dependent facility outright; a cooling-dependent facility that remains operational without cooling is reduced by the cooling factor. Extended hours increase the hours term only when their intervention rules apply. Nominal capacity behaves as a 24-hour-equivalent daily quantity — a registry convention, not an observed Barcelona value.

Fractional-capacity resolution · RES-001 allocation/queueing.py

Effective capacity is continuous, but service events are indivisible whole-person visits. Immediately before allocation, each facility's capacity c is resolved stochastically:

n = floor(c) + Bernoulli(c − floor(c))   ⇒   E[n | c] = c

Concretely: a facility with c = 0.24 serves 1 person on roughly 24% of matched facility-days and 0 otherwise — unbiased across replications. Deterministic flooring was invalid at sampled scales because it silently converted small capacities into zero capacity. The continuous value remains authoritative for reporting and queue-limit rules; the realised integer governs only indivisible admission. This is numerical resolution, not calibration.

Equal-cost facility choice · FAC-001 access/evaluation.py

For each resident, day and requested service type:

candidates = {f : cost(f) ≤ min_cost + 1e−9}  →  stable-sort by facility_id  →  keyed uniform draw selects one

Queue length, utilisation and remaining capacity play no role in this choice. FAC-001 is deliberately not load balancing: it removes a deterministic first-facility bias that previously funnelled all same-cost demand into whichever facility happened to be listed first. The tie draw is keyed by (seed, replication, resident, day, service type) and excludes scenario identity, so paired scenarios share draws wherever their candidate sets coincide.

Exploratory health-risk transitions health_needs/risk.py

Health-risk states are exploratory model states rather than validated clinical endpoints. Heat-stress probability increases with excess temperature and individual vulnerability:

exposure_risk = max(0, T_zone − T_risk_threshold)
p_stress = clamp(p_stress,base + β_vuln · vulnerability · min(1, exposure_risk/5), 0, 1)

Unmet urgent and emergency need can additionally trigger deterioration or critical-state transitions through separate illustrative probabilities. Mortality remains disabled when the configured baseline mortality probability is zero. These states help inspect pathway consequences; they are not diagnoses, forecasts or validated clinical risks.

06 / Allocation + queues

Finite slots, ordered claims, bounded waits.

Allocation converts expressed, accessible demand into served, delayed, waiting or unmet care. Facility queues are authoritative and persist across daily boundaries; capacity is consumed in whole-person units only.

Allocation ordering

Within each facility, queued demand is ordered by three keys — severity first, then arrival, then identity:

descending
ascending
ascending

Emergency need is served before urgent, urgent before routine; within a severity tier, earlier queue entry wins, and agent id breaks remaining ties deterministically.

Queue and unmet semantics

When realised capacity cannot admit a claimant, two independent bounds govern whether they may remain waiting. The queue multiplier limits queue occupancy relative to the facility's continuous effective capacity; max_queue_days separately limits how long an individual may wait.

admit to waiting only if:  occupied < queue_multiplier × C_eff  AND  wait_days < max_queue_days

If either bound is exhausted, or final access is denied, the need is classified explicitly as unmet rather than left in an indefinite queue. Every pre-allocation need person-day ends the day in exactly one terminal ledger category; reconciliation is machine-checked and unresolved categories must remain zero.

  • Indivisible serviceAllocation admits whole residents only; fractional effective capacity is resolved by the RES-001 rule above.
  • Persistent queuesWaiting residents keep their queue position and entry day across days; a new seeking draw never silently evicts them.
  • Two queue boundsqueue_multiplier × C_eff limits concurrent queue occupancy, while max_queue_days independently caps individual waiting duration; exceeding either relevant bound leads to unmet care.
  • Ledger reconciliationNon-seeking, access-denied, served, delayed, waiting, capacity-unmet, rerouted, withdrawn and unresolved categories partition the pre-allocation denominator exactly.
07 / Estimand + accounting

The primary outcome is defined against pre-allocation need.

The primary estimand is unmet essential-care person-days per 1,000 pre-allocation care-need person-days. The denominator therefore includes residents who need care but do not seek it, alongside those later blocked by access or capacity.

Primary estimand
unmet essential-care person-days
pre-allocation care-need person-days
× 1,000
Numerator

All unmet pre-allocation need in the daily ledger: access-denied plus capacity- and queue-denied need.

Denominator

Alive resident-days with current essential-care need, captured at step 4 — before seeking, support, final access, allocation or receipt. Measuring here prevents the denominator from being contaminated by the very outcomes the model compares.

The daily demand ledger reconciles pre-allocation need into mutually exclusive terminal categories:
non-seekingaccess-deniedserveddelayedwaitingcapacity/queue unmetrerouted unresolvedwithdrawnunresolved/unclassified — must remain zero

Why person-days?

The unit preserves duration. Repeated unmet need contributes more than a single isolated day, while numerator and denominator remain directly inspectable.

Undefined denominators

If a rate or mean has a zero eligible denominator, it is treated as undefined rather than forced to zero. Strict JSON outputs record an explicit validity reason.

  • Primary numeratorunmet_person_days
  • Primary denominatorcare_need_person_days_pre_allocation
  • Secondary outcomesQueues, travel time, effective and nominal capacity, closures, mobile-service use, transport support, recovery and subgroup outcomes.
  • Distinct quantitiesNeed, expressed demand, accessible demand and utilisation are not interchangeable labels anywhere in the outputs.
08 / Equity estimation

Subgroup rates with honest denominators.

Equity tables treat the replication as the analysis unit. The headline subgroup rate is the unweighted mean of replication-level subgroup rates over the analysis window; a pooled person-day rate is reported separately because it answers a different weighting question when denominators vary between replications.

  • DimensionsSeven, fixed at population synthesis: age group, chronic-condition burden, disability status, socioeconomic group, vehicle access, social isolation and residential zone.
  • Reportable outcomesPer subgroup: alive, care-need, unmet, served, delayed and waiting person-days. The full daily outcome dictionary is collected at population level only — not every population-level outcome is subgroup-reportable.
  • Precision warningsSubgroup cells with low person-day denominators carry an explicit precision flag rather than a silently noisy estimate.
  • GapsFor each dimension, absolute and relative gaps against a reference group are computed from the same replication-level rates.
09 / Stochastic + statistical design

The replication is the analysis unit.

Stochasticity is governed rather than hidden. Persistent named streams are derived from the base seed, replication identifier and stream name; scenario identity is deliberately excluded. Separate keyed draws are used for order-independent events such as capacity integerisation and equal-cost facility ties.

Paired scenario contrasts
Rep 01S1 ↔ S5/S6
Rep 02S1 ↔ S5/S6
Rep 03S1 ↔ S5/S6
…matched rep ID
Three alignment cases: exogenous persistent streams such as climate noise and facility dependencies start aligned across scenarios; state-dependent persistent streams such as care need, seeking and health risk may drift after scenarios create different states; keyed draws such as capacity_resolution and facility_tiebreak are scenario-independent for the same key, although FAC-001 can still select differently when the eligible/tied candidate set itself changes.
Paired effect size
Differences live at replication level.
Dᵣ = Y_policy,r − Y_S1,r    d_z = mean(D) / SD(D)

For the bundled intervention contrasts, extreme heat without additional intervention (CHRS-S1) is the comparison baseline; CHRS-S0 remains the reference-conditions scenario. Paired analyses report mean difference, relative change, Cohen's dz and, where requested, Holm-adjusted inferential tests across matched replication IDs. A null result is reported as a null rather than smoothed away.

Monte Carlo intervals describe stochastic variation under a fixed model specification and declared assumptions. They are not real-world epidemiological confidence intervals and say nothing about intervention effectiveness in any actual city.

Scenario-level summaries

Numerator, denominator and rate travel together. Secondary summaries cover demand decomposition, travel, queues, service capacity, disruption and intervention-mechanism activation.

Mechanism activation checks

An intervention counts as active only when declared in the scenario, enabled in configuration, and visible in generated mechanism events — checked automatically per run.

10 / Scenario design

Scenarios are mechanism contrasts, not fitted policy effects.

The seven bundled scenarios are versioned synthetic contrasts. CHRS-S0 provides reference conditions; CHRS-S1 is the extreme-heat baseline against which the intervention and compound-disruption contrasts are normally evaluated. The scenarios test whether declared mechanisms activate and how those mechanisms alter pathways under otherwise controlled conditions. Parameters are not tuned to force a preferred direction.

CHRS-S0ReferenceNo declared heat episode, infrastructure disruption or intervention.
CHRS-S1HeatwaveDeclared synthetic heat episode with exposure-driven effects.
CHRS-S2Extended hoursAdditional opening hours inside the declared episode window.
CHRS-S3Mobile unitsFinite mobile urgent-care reach and capacity; induced demand is possible.
CHRS-S4Targeted transportBounded same-day transport support before final accessibility.
CHRS-S5Combined accessExtended hours, mobile units and targeted transport together.
CHRS-S6Compound disruptionHeat, electricity outage and transport disruption.
The Barcelona pilot reuses this machinery with BCN-S0/BCN-S1 contrasts over official city structure — still under assumed mechanisms, as described on the Barcelona page.
11 / Two implementations

What is synthetic, what is observed, what is pending.

The generic benchmark and the Barcelona pilot share one engine but stand on different evidence. Keeping the split explicit prevents the most damaging confusion — treating an observed input as a calibrated parameter.

Generic synthetic benchmark

Everything declared, nothing observed

synthetic populationsynthetic zonesillustrative parameterssynthetic climatecontrolled mechanism exploration
Barcelona structural implementation — observed inputs

City structure and context

population-register marginsofficial geography + crosswalksfacility identity · type · locationarea-level SES contexthistorical vulnerability proxyAEMET weather evidence + episode parameterisation
Barcelona — still assumed or uncalibrated

Mechanisms awaiting evidence

care needcare seekingnominal capacityqueuesheat-response mechanismsdaily synthetic climate inside the enginegeometric travel proxy
Available but not yet integrated

Acquired ≠ integrated

static T-Mobilitat GTFS (two variants, local)curated annual AQuAS benchmark indicatorsother external context layers under provenance review
12 / Scientific readiness ladder

Five rungs, honestly occupied.

Each rung demands different evidence. Climbing is slow by design: no rung can be skipped, and status language comes from the repository's own audits rather than marketing preference.

Software verification✓ complete

Deterministic execution, fixed event order, ledger reconciliation, capacity bounds and artifact integrity pass the repository test suite.

Structural city implementation✓ with conditions

Official structure and context incorporated; behavioural and capacity mechanisms labelled as assumptions. Structural Stage C is conditionally permissible as a mechanistic diagnostic, but empirical interpretation remains blocked.

Empirical calibrationpending

Blocked by missing need anchors, dated utilisation targets and operational-capacity evidence.

Historical validationpending

Requires a leakage-locked holdout, model-equivalent targets and pre-registered acceptance criteria.

Operational / predictive useunsupported

No individual triage, dispatch, resource allocation or forecast claim is supported at any rung below full validation.

13 / Verification + validation

Internal correctness is not empirical validity.

CHRS separates verification from validation. Verification asks whether the implementation behaves according to its declared design and accounting rules. Validation asks whether the model adequately represents observed phenomena for a stated use. The current release answers the first question; the second awaits evidence.

Verification

Implemented and checked

The repository test suite covers deterministic execution, configuration governance, event ordering, access, finite capacity, queues, accounting and output artifacts — including dedicated regression tests for the RES-001 and FAC-001 remediations.

Configuration bounds and configuration identity
Deterministic named random streams
Daily causal ordering and state boundaries
Capacity bounds, queue integrity, tie-resolution uniformity
Demand-ledger reconciliation and estimand accounting
Artifact completeness and strict serialization
Empirical validation

Not yet established

Calibration is intentionally disabled. No observational target is currently accepted by the configured calibration pathway, and no historical holdout has been opened.

Observation correspondence for each target
Provenance-recorded empirical data
Observation model and unit/time/geography harmonisation
Identifiability analysis and accepted parameter bounds
Frozen historical and external validation splits
Independent assessment of city-specific and transfer validity
Implication: passing verification supports claims about implementation consistency and reproducibility. It does not support claims about predictive accuracy, real intervention effects, clinical validity or operational usefulness.
14 / Current boundaries

Important simplifications remain explicit.

The model is intentionally narrower than a real urban health system. Its present value is making assumptions and mechanism interactions inspectable — not claiming behavioural, epidemiological or operational realism.

No empirical calibration

Bundled populations, facilities, climate and parameter values are synthetic, assumed or illustrative; Barcelona adds observed structure, not calibrated behaviour.

Zone-based spatial access

Travel uses a zone-to-zone matrix rather than street-network routing, scheduled public transport or time-dependent congestion.

Daily temporal resolution

Within-day timing, overnight thermal recovery and continuous-time queue dynamics are not separately represented.

Rule-based seeking

Seeking does not learn, optimise, negotiate or respond to expected waiting time, fear, social networks or informal care.

Simplified need dynamics

Spontaneous resolution and escalation probabilities are single illustrative values, not severity-specific empirical models.

Exploratory health-risk states

Risk labels are internal simulation states, not validated diagnoses, individual risk predictions or clinical endpoints.

Partial CRN alignment

State-dependent random streams diverge after scenarios diverge; paired replications give partial, not exact, trajectory matching.

No operational deployment

The model must not be used for individual triage, emergency dispatch, automatic service denial, surveillance or real resource allocation.

Detailed boundaries and interpretive warnings live in the governed documentation distributed with the research repository — including the limitation, scope, outcome-dictionary and verification documents referenced below.

15 / Scientific documentation

The webpage is a readable layer over governed definitions.

This page summarises the scientific design but is not the sole specification. Exact definitions, output semantics, parameter ownership, assumptions and validation boundaries should be traced to the versioned documentation in the research repository and to run provenance.

See the model in motion

Examine the model through an inspectable synthetic benchmark.

The worked example exposes its population, service network, scenario contrasts, replication summaries, subgroup outputs and run provenance. It makes the methodology concrete — and shows exactly where evidence is still needed.