Emergency services resource deployment (ambulance dispatch, relocation & station planning)

Emergency medical services must reach patients within a statutory response time while demand is random and units are scarce. Dispatchers typically send the nearest free unit and leave idle units where they happen to be. Optimisation adds three things: forecast demand by place and hour, relocate idle units to keep coverage, and plan stations and fleet size strategically. Peer-reviewed studies report better coverage or shorter response times than static policies, but results depend on the system and data.

Problem & value

• Who: regional dispatch centres (Leitstellen, 112 control rooms), EMS and fire-service operators, and the public authorities or insurers that set response-time targets. In Germany, planning is anchored in the state EMS laws (Rettungsdienstgesetze der Länder) with a Hilfsfrist or Eintreffzeit that differs by state.
• Today: the dispatch system proposes the nearest available unit by distance or estimated travel time. Standby positions are mostly fixed by the station plan. Station and fleet planning is done every few years with static gap analyses and spreadsheets.
• Why it is hard: a dispatched unit leaves a coverage hole, so the "nearest unit" is not always the best choice for the next call. Demand shifts by hour, weekday, weather and events, and travel times vary with traffic.
• AI value: (1) spatio-temporal demand forecasts, (2) dispatch and relocation policies that keep coverage after each assignment, (3) simulation-based planning of stations, shifts and fleet. The literature (approximate dynamic programming, coverage and relocation models) reports gains in response-time compliance versus closest-unit rules; the size is system-specific and should be measured in simulation on your own data, not assumed [1][2][3].

Variants

• Real-time dispatch support: ranked unit proposal that accounts for post-dispatch coverage and the incident's priority.
• Dynamic relocation / dynamic ambulance management: repositioning idle units between standby points as demand and availability change.
• Strategic planning: station siting, shift patterns and fleet sizing evaluated by simulation against the statutory target; also used for rural coverage and air-rescue base planning.

How it works

1. CAD/ELS incident + AVL positions + unit status (streaming)
2. demand forecast (grid/H3 cell × hour; weather, events, calendar)
3. travel-time model (road graph + historic speeds)
4. decision layer: dispatch: rank units by response time + coverage loss after assignment relocation: assign idle units to standby points (MIP / learned policy)
5. dispatcher sees recommendation with reason and coverage impact
6. human accepts / overrides
7. ELS command
8. feedback logged Offline: discrete-event simulation of the real system
9. test policies, stations, fleet size

• Forecasting: gradient boosting or count-time-series models per spatial cell and hour; probabilistic output is preferred because rare high-priority calls matter most (see PRED-011).
• Optimisation core: classical coverage models (maximal covering, double standard, expected coverage) solved as MIP; relocation as an assignment problem with move limits; learned policies via approximate dynamic programming or reinforcement learning, trained in a simulator, then distilled to rules or a value function [1][2].
• Simulation: discrete-event model with realistic call arrival, on-scene and hospital times; it is the safety net to test any policy before go-live.
• LLMs: not in the decision loop. They may help dispatchers by summarising reasons or answering what-if questions on top of the solver (see OPT-018) and for call triage (CONV-021, SPEECH-016).
• Human-in-the-loop: the dispatcher decides every dispatch; relocation orders are proposals with a crew-workload cap and respect of mandatory breaks.

Data preparation

The core data are incident logs from the dispatch system (CAD/ELS: time stamps, location, priority, outcome), vehicle positions (AVL/GPS), shift plans and station master data, usually held by the Leitstelle, the rescue-service authority and sometimes in Excel files at the operator. Typical gaps: inconsistent or manually corrected time stamps, free-text locations without coordinates, missing hospital hand-over times, several systems per district, and strict access rights because the data are personal and health-related.

Preparation steps: 1. Inventory sources and owners (see PREP-001, PREP-004) and agree who may release which data. 2. Export through documented interfaces or connectors (PREP-005); geocode addresses and map them to a grid such as H3. 3. Clean time stamps, remove duplicate incidents, and harmonise priority and unit codes (PREP-019). 4. Pseudonymise patient-related fields before analysis (PREP-022) and check the legal basis (PREP-025). 5. Build the road graph from OpenStreetMap and calibrate travel times from historic AVL traces. 6. Keep a validation set of recent months for shadow-mode tests (PREP-018).

Roughly 40-50% of the project effort goes into data extraction, cleaning and legal clearance; the models themselves are the smaller part. See also DATA-003 and GUIDE-003.

Implementation paths

Which path for whom

• public (dispatch centres, rescue-service authorities): C, because incident and position data are sensitive, the system is critical infrastructure, and the analytics layer runs on a CPU server (HW1) that the authority can operate itself.
• enterprise (private rescue operators, fleet and logistics firms): B, because the planning layer must connect to the existing CAD/ELS and fleet systems, and EU-region cloud services remove the need for own data-science operations.
• developer: C, because the open stack (OSM routing, OR-Tools, SimPy) is mature, fully inspectable and fast to prototype.

Path A — Buy (off-the-shelf)

• Dispatch (CAD/ELS) platforms with optimisation modules: Frequentis (Austria, EU), Eurofunk Kappacher (Austria, EU), Hexagon (HxGN OnCall Dispatch), Motorola Solutions, Zoll/Intterra-type products in the US. In Germany, ELS procurement is tied to the Leitstelle and regional rules; check which vendor your state uses.
• Specialist analytics and planning: Optima Predict (UK) for demand forecasting and dynamic deployment; consultancies and research institutes provide station-planning gap studies (e.g. public Rettungsdienstbedarfspläne).
• Choose A when: you already have a CAD vendor and the module covers forecasting and relocation. Always ask for procedures to export incident data and the explanation shown to dispatchers.

Path B — Build on cloud APIs (for the integrated planning layer)

• Data and ML: EU-region data platforms (Azure, AWS Frankfurt, STACKIT, IONOS, OVHcloud) with LightGBM / Prophet-style forecasting or managed forecasting services.
• Routing: OSRM, Valhalla or GraphHopper (EU company) on OpenStreetMap, or commercial matrix APIs (HERE, TomTom, both EU-based).
• Solver: Google OR-Tools, HiGHS, Gurobi or Timefold (Belgian, EU) for relocation and coverage models.
• Integration: read-only interfaces to the CAD/ELS first; write-back only after a validated pilot.
• Choose B when: you need custom logic on the existing dispatch system, or you do strategic planning for an authority.

Path C — Self-host (open source)

• Stack: OpenStreetMap + OSRM/Valhalla, H3 or custom grids, PostGIS, LightGBM/statsmodels, OR-Tools/HiGHS/CBC, SimPy or similar for discrete-event simulation, Kafka or MQTT for AVL streams.
• Hardware: HW1 is enough (CPU server); there are no large models. Dispatch-critical services need redundancy and 24/7 operations instead.
• Effort: mostly data engineering and validation, not compute. Public authorities often self-host because of data-protection and critical-infrastructure rules.

Path D — Custom training

Worth it for a learned dispatch/relocation policy (ADP or deep RL) when the system is large (many units, dense calls) and the simulator is faithful. Needs several years of incident logs with accurate timestamps and a calibrated simulator; start with rule-based and MIP policies as baseline, because learned policies must beat them in simulation and in shadow mode.

State of the art (2026)

• Research: approximate dynamic programming for ambulance redeployment improved response-time metrics versus static policies in the published setting [1]; reviews of EMS location and relocation models give a structured overview of coverage and relocation approaches and open issues such as uncertainty in travel times and demand [2][3]. Deep RL for dispatch and relocation is active, but reported gains come mostly from simulation.
• Practice: most operational systems still use closest-unit dispatch and fixed standby plans; forecasting-based deployment and strategic simulation are the common first adopted step. Gains depend strongly on the system's baseline.
• Limits and failure modes: demand shifts (pandemic, heat waves, big events) break forecasts; incident data is biased by past service levels (unmet demand is invisible); relocation raises crew workload and fuel; optimising a mean response time can hurt rural areas, so fairness and tail constraints must be explicit; unit status in the CAD is often stale or wrong; coverage optimisation without clinical priority can send the wrong resource.

Shared resources & combinations

• Components: OPT-001 (routing), PRED-011 (workload and call-volume forecasting), DATA-011 (geospatial analytics), OPT-003 (shift planning for crews).
• Upstream: CONV-021 and SPEECH-016 (call triage and 112 analysis) provide incident type and priority; keep the triage decision separate from the deployment decision.
• Shared stack: time-series forecasting, solver and simulation capabilities, and the geospatial pipeline are reusable across these use cases on HW1.

Effort, cost & KPIs

• Path A: months for procurement and integration; the module usually comes as licence or subscription of the CAD vendor.
• Path B/C: 6–18 months from data audit to shadow-mode pilot; main costs are data engineering, validation and domain experts, not compute.
• KPIs: share of incidents reached within the statutory Hilfsfrist/target (by priority and region, including rural tails), median and 90th-percentile response time, coverage of the population by idle units, number of relocations and crew workload, unit utilisation, dispatcher acceptance rate of recommendations, forecast error (e.g. pinball loss per cell and hour).

People & change

Start with management and the head of the dispatch centre (department-lead), who define goals such as response-time targets. Involve the data protection officer and IT security before any data leave the CAD system, and the data owners (CAD vendor, authority) for exports. Dispatchers (end-users) join early in workshops and later as the pilot group, because they must trust the reasons shown with each recommendation.

Works council / staff council: yes. In public bodies the staff council (Personalrat under BPersVG or the state act) co-determines; in private operators the works council does under section 87(1) no. 6 BetrVG, since position data and dispatch decisions are objectively suited to monitor crews and dispatchers (BAG case law). Section 90(1) no. 3 requires early information, and section 80(3) allows an AI expert. Conclude a works agreement that excludes individual performance ranking and limits relocation workload.

Data protection: the data are personal and often health data, so a DPIA (Art. 35 GDPR) is likely, with AVV for every processor. AI literacy: AI Act Art. 4 requires measures that support literacy; train dispatchers on what the forecast can and cannot do (GUIDE-006). Run a shadow-mode pilot first (GUIDE-009), communicate openly (GUIDE-008). Typical concern: "the system decides who gets help." Answer: the dispatcher decides every dispatch and can override. See GUIDE-004 and GUIDE-005.

Risks, regulation & compliance

• EU AI Act: high risk. Annex III point 5(d) lists AI systems intended to dispatch, or to establish priority in the dispatching of, emergency first response services (police, firefighters, medical aid) and emergency healthcare patient triage. A unit-recommendation or relocation system for a Leitstelle falls into this scope; a purely strategic offline station-planning study with no link to operational dispatch is usually outside it, but assess case by case. Provider and deployer duties apply: risk management, data governance, logging, human oversight, accuracy and robustness, deployer fundamental-rights impact assessment where public bodies apply it [4].
• Art. 5: no prohibited practice is intended; do not combine with profiling of individuals or prioritisation by personal characteristics.
• GDPR: incident logs contain health data (Art. 9) and location of patients; use pseudonymisation or spatial aggregation for forecasting and research, legal basis in state EMS and data-protection laws, data processing agreements, DPIA. Crew GPS tracking is employee data and needs works-council involvement in Germany [5].
• Sector rules: state EMS laws and planning ordinances, ELS standards and interfaces, KRITIS/NIS2 obligations for operators of critical services, medical-device rules if the software has a clinical purpose.
• Mitigations: recommendations only, overridable; fallback to closest-unit rules when the service fails; explanations (coverage impact) shown; bias and rural-tail monitoring; versioned models and decision logs; cybersecurity hardening and air-gapped or segmented deployment.

Getting started

1. Audit the incident data: timestamps, coordinates, priority and unit status quality; reconstruct the current response-time compliance per district.
2. Build a descriptive baseline: demand heat maps by hour, travel-time matrix, coverage map of the current station plan.
3. Build a discrete-event simulator and calibrate it against last year's actual response times.
4. Test closest-unit versus coverage-aware dispatch and a simple MIP relocation policy in the simulator; report mean and tail effects.
5. Run in shadow mode next to the dispatchers with DPIA, works-council agreement and AI Act high-risk assessment completed before any live use.

Sources

1. Maxwell, Restrepo, Henderson, Topaloglu — Approximate Dynamic Programming for Ambulance Redeployment, INFORMS Journal on Computing (2010) — https://doi.org/10.1287/ijoc.1090.0351
2. Brotcorne, Laporte, Semet — Ambulance location and relocation models, European Journal of Operational Research (2003) — https://doi.org/10.1016/S0377-2217(02)00364-8
3. Aringhieri, Bruni, Khodaparasti, van Essen — Emergency medical services and beyond: Addressing new challenges through a wide literature review, Computers & Operations Research (2017) — https://doi.org/10.1016/j.cor.2016.09.002
4. Regulation (EU) 2024/1689 (AI Act), Annex III point 5 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2016/679 (GDPR), Art. 9 — https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. Google OR-Tools — https://developers.google.com/optimization
7. Timefold Solver — https://timefold.ai
8. Open Source Routing Machine (OSRM) — https://project-osrm.org