Predictive Ambulance Deployment Engine

Overview#

An emergency medical service that waits for the radio to get busy is already behind, because by the time demand becomes visible the nearest available ambulance is often in the wrong place. The Predictive Ambulance Deployment Engine turns the service's own electronic patient care record history into forward-looking deployment guidance, so operations managers can act before the surge rather than after it.

The engine works in three connected tiers. It forecasts hourly call volume for each geographic area up to fourteen hours ahead, it ranks which on-duty vehicles should be repositioned right now to shrink weighted response time across the predicted demand hotspots, and it derives a recommended staffing level for every station for every hour of every day of the week. Each tier is grounded in the service's real encounter data and scoped privately to the operating organisation, and forecast quality is measured continuously so the guidance improves over time. The net effect is proactive pre-shift planning that lowers response times while avoiding both under-staffing and over-staffing by station and by hour.

Key Features#

• Hourly Call-Volume Forecasting: A moving-average slot model learns the typical call rate for each hour-of-day and day-of-week combination from the last ninety days of encounter history, projecting demand per area for up to fourteen hours ahead with a confidence score for each forecast point.

• Blended Intensity Profiling: When a temporal prediction service is available, the statistical forecast is blended with a Neural Hawkes Process intensity profile, capturing self-exciting demand patterns such as clustered incidents while keeping a deterministic statistical baseline.

• High-Acuity Share Estimation: Each forecast separates predicted high-acuity demand from routine volume, derived from the share of prehospital emergency encounters in the window, so planners can anticipate not just how many calls but how serious they are likely to be.

• Demand-Weighted Vehicle Repositioning: For every on-duty vehicle and candidate station the engine estimates current versus relocated expected response time across all predicted hotspots, ranks the moves by expected response-time improvement weighted by demand, and returns the highest-value relocations.

• Coverage Map: A map-ready view brings together station locations, live vehicle positions, predicted hotspots, and per-station demand within coverage radius, giving controllers a single picture of where cover is strong and where it is thin.

• 24x7 Station Staffing Grid: For each station the engine produces a recommended vehicle count for all one hundred and sixty-eight hour-of-week slots, using an Erlang-C queuing approximation tuned to keep expected queue wait below an operational target.

• Skill-Mix Recommendations: Each staffing slot splits the recommended crew into advanced paramedics and paramedics based on the station's historical high-acuity share, with a minimum advanced floor, so the right clinical capability is planned, not just the right headcount.

• Gap Reporting and Accuracy Back-Testing: Shift managers see actual rostered vehicles against recommended levels per station and hour for any date, while built-in MAPE and RMSE back-testing scores forecast accuracy over any window to close the continuous improvement loop.

Use Cases#

Emergency Medical Service Operations#

• Pre-Shift Deployment Planning: Operations managers review the next fourteen hours of predicted demand and the ranked repositioning recommendations before a shift change, so vehicles start the shift in the right places rather than chasing demand once it arrives.

• Dynamic Repositioning During Quiet Periods: When crews are clear and available, controllers act on demand-weighted relocation suggestions to pre-position cover near areas forecast to go busy, reducing the distance to the next likely call.

Resource and Roster Planning#

• Station Establishment Reviews: Planners use the 24x7 staffing grid to set how many vehicles and what skill mix each station needs for each hour of each day, replacing flat fixed rosters with demand-shaped establishment levels.

• Roster Gap Analysis: Shift managers compare planned rosters against recommended levels for upcoming dates, identifying under-covered and over-covered slots before they become a response-time or cost problem.

Performance and Assurance#

• Forecast Assurance: Service analysts run MAPE and RMSE back-tests over recent periods to confirm the forecasts track reality, and to evidence the value of predictive planning to clinical and finance stakeholders.

• Demand Trend Monitoring: Regional aggregate forecasting rolls per-area predictions into a service-wide view, supporting longer-range capacity conversations.

Integration#

The engine exposes every capability through both REST and GraphQL, so a customer can plug it into existing control-room dashboards, rostering tools, and reporting pipelines without bespoke glue. All access is authenticated and scoped to the organisation's tenant, with each request carrying the caller's identity.

• REST endpoints: Forecasting, repositioning, coverage mapping, station recalculation, gap reporting, and accuracy back-testing are available under /api/v1/deployment/ paths, for example /api/v1/deployment/forecasts/hourly, /api/v1/deployment/repositioning/generate, /api/v1/deployment/coverage-map, /api/v1/deployment/stations/recalculate, and /api/v1/deployment/forecasts/accuracy. Each returns normalised structured payloads suited to direct rendering or downstream storage.

• GraphQL surface: A typed schema lets a console fetch forecasts, active recommendations, coverage data, staffing grids, gap reports, and accuracy scores in a single request, and the relocation and recalculation actions are exposed as typed operations. This lets a customer assemble exactly the deployment view they need without over-fetching.

• Authentication: Access is secured with OAuth2 bearer tokens and signed JWTs, with tenant isolation enforced on every read and write so one service can never see another's operational data.

• Data inputs: The engine reads the service's electronic patient care records, crew rosters and shifts, and unit status position events that the customer already produces, meaning the predictive value comes from data they own rather than from any external feed they must purchase.

• Normalised models: Forecasts, recommendations, coverage cells, and staffing slots are returned as consistent typed records, so an integrator maps them once and reuses the shapes across REST and GraphQL alike.

Open Standards#

• Erlang-C queuing theory (ITU-T E.501 / teletraffic engineering): The station staffing tier applies an Erlang-C queuing approximation over offered load in Erlangs to determine the minimum vehicle count per station slot such that expected queue wait stays below an operational target, defaulting to eight minutes at eighty-five percent occupancy.

• Haversine formula (ISO 6709 spherical-Earth approximation): Station-to-hotspot and vehicle-to-hotspot distances are computed with the haversine great-circle formula on WGS 84 latitude and longitude, feeding the demand-weighted response-time scoring that ranks repositioning moves and the per-station coverage radius calculation.

• Eircode (Irish postal routing code): The Eircode routing-key prefix, the first three characters, is used as the geographic area partitioning unit for demand forecasting and hotspot resolution, aligning predicted demand with the recognised national postal geography of the service area.

• REST over HTTP: All deployment capabilities are reachable as resource-oriented HTTP endpoints returning structured JSON, the lingua franca for control-room and rostering system integration.

• GraphQL (June 2018 specification): The deployment domain publishes a typed schema so consoles and analytics tools can request precisely the forecasting, repositioning, coverage, and staffing data they need in one round trip.

• OAuth2 and JWT (RFC 6749 / RFC 7519): Bearer-token authorisation and signed JSON Web Tokens carry tenant and user identity into every call, anchoring the per-organisation data isolation the engine enforces.

Security & Compliance#

Every forecast, recommendation, coverage view, and staffing calculation is partitioned by the operating organisation, and that boundary is enforced on every database read and write so operational patterns, vehicle positions, and patient-derived demand never cross tenant lines. All requests require authenticated platform access, repositioning recommendations record who accepted them and when for a clear operational audit trail, and forecasts carry a model version and confidence so consumers can reason about how each number was produced. Because the engine derives its guidance from the service's existing clinical and rostering records rather than introducing new collection, it fits within the data governance the service already operates.

Last Reviewed: 2026-05-26 Last Updated: 2026-05-26