← Work

AI engineer

Which hospital can actually treat this patient right now?

PulseRoute — Predictive Emergency Dispatch

Golden-hour routing: predicts a patient's care needs in transit and sends the ambulance to a hospital that can actually treat them.

Role
AI engineer
Outcome
Built for a national-level competition
Built with
Python · FastAPI · XGBoost · Streamlit · Pandas · NumPy · Scikit-Learn
The PulseRoute clinical cockpit: a scene photo upload, patient vitals fields for age, heart rate, blood pressure, SpO2, respiratory rate and GCS, the ambulance location, and a Predict Severity & Route action

A golden-hour routing system for ambulance dispatch, built for a national-level competition. Given patient vitals and a live hospital resource grid, it predicts care needs in transit and assigns the ambulance to a facility that can actually treat the patient now. The interesting part is not the map ETA but the constraint problem around it: which hospital can absorb this patient under ICU, ventilator, specialty, and load limits, and how that assignment holds up when many patients arrive at once.

Problem

Nearest-hospital dispatch is a poor proxy for care. An ambulance can arrive at a full ICU, a missing ventilator, or an off-duty specialist and lose minutes that matter inside the golden hour. Mass-casualty events make this combinatorial: one trauma center floods while capable facilities nearby sit underused. The practical question is how to predict needs before arrival and rank feasible hospitals fast enough for a live dispatch loop.

Approach

PulseRoute runs XGBoost triage on EMT-reported vitals to predict severity and resource needs, then ranks hospitals with a weighted constraint engine over ICU beds, ventilators, specialties, ER load, and travel time. A FastAPI backend serves inference and routing; a Streamlit command center shows the chosen destination and why it won. When connectivity drops, an edge build falls back to a local student model, a shadow-cached hospital grid, and an OSMnx road graph so the tablet can still route without the API. Batch mode redistributes multiple patients across the city grid instead of dumping them on the nearest facility.

Screens

Launch film · 21 seconds, with sound.
The PulseRoute clinical cockpit: a scene photo upload, patient vitals fields for age, heart rate, blood pressure, SpO2, respiratory rate and GCS, the ambulance location, and a Predict Severity & Route action
Intake. Everything the crew can report from the roadside — vitals, position, a scene photo — on one screen, because it is filled in while moving.
The lower half of the intake panel, showing the road status controls for reporting a closure or clearing all roadblocks so routes recalculate en route
Road status. A closure reported mid-transit re-runs the route, so the assignment survives the road actually changing.
The analysis results: predicted severity and resource needs for ICU, ventilator and surgery, a recommended facility and an alternative shown side by side with distance, free ICU beds, free ventilators and a score, above a navigation map with the route drawn to the chosen hospital
The verdict, with its reasoning next to it: predicted needs on the left, and each candidate hospital's free capacity and score — so the destination is arguable rather than asserted.
Additional alternative facilities listed with their distance, free ICU beds, free ventilators and score, including one with a negative score, above a broadcast action to nearby hospitals
The rest of the ranking, negative scores included. A facility being closer is visibly not enough to win.
The dispatch API responding with a status of ok
The FastAPI service behind it, answering.

System architecture

System architecture
The row along the bottom is the argument: the tablet carries its own severity model, router and hospital cache, so losing the API degrades the dispatch rather than stopping it.
Describe the diagram

The full PulseRoute system, in three columns. On the left, the client layer: an EMT dispatch tablet that submits vitals, a scene photo, roadblocks and broadcasts, and an ER inbound radar that polls for incoming patients. In the centre, the FastAPI service. It fans out to a scene classifier for the accident photograph, and to a routing pipeline holding two stages — a severity engine that triages the patient, and a hospital ranker that combines a soft score with a hard resource filter, so a facility that cannot treat the patient is excluded rather than merely ranked low. A separate routing and ETA engine computes travel over a city road graph, and a resource store and broadcast store hold hospital state. On the right, a hospital command center updates its own resources and accepts or rejects inbound patients, alongside the external mapping providers. Along the bottom runs the edge failover path: the same tablet, but wired to a local severity model, a local OSMnx routing engine and a shadow cache of the hospital grid, so dispatch continues when the central API cannot be reached.

GitHub