FastER

Inspiration

Emergency departments (EDs) get crowded unevenly. Most people go to the hospital that is closest or most familiar, so one ED can be overwhelmed while another a few minutes farther away has open clinicians and a short queue. A multi-vehicle highway accident makes this much worse: a wave of trauma patients arrives at one hospital, and everyone with a less urgent problem who heads there afterward waits longer and slows down care for everyone else.

We asked: if a person could be told, in plain language, which nearby ED can treat them quickly and appropriately right now, could we spread demand more evenly and reduce overcrowding? FastER is our attempt to build that decision-support experience.

What it does

FastER recommends an emergency department based on the patient's injury and on current conditions at nearby hospitals.

The user describes their injury in plain language (and optionally their age).
Gemini assigns an urgency level from 1 (needs immediate life-saving care) to 5 (non-urgent), in the spirit of the five-level Emergency Severity Index, and flags whether major trauma capability is likely needed. If Gemini is unavailable, the system assumes the patient is urgent rather than minor.
Our algorithm scores every hospital by estimated travel time plus estimated wait. Waits follow priority ordering: a patient only waits behind patients of equal or higher urgency, so a sprained ankle does not delay someone with a more serious injury. Hospitals without trauma volume are excluded for trauma cases.
Gemini chooses among the eligible hospitals and writes a short, plain-language run-down with practical next steps. If the closest hospital is in surge, Gemini explains why the patient is being sent elsewhere.
The backend validates Gemini's choice. If Gemini picks a hospital that is not on the eligible list, or fails, the system falls back to the algorithm's best hospital and labels the result accordingly.

The /triage page shows each hospital's current load (patients waiting, clinicians on shift, travel time, surge flag) and an approximate-position map, and highlights the recommended hospital.

We built two synthetic scenarios: a typical evening, and a multi-vehicle highway accident that floods the closest hospital. In our demo data, a patient with a minor injury is sent to the closest hospital normally (about 30 minutes total) but is redirected during the accident (about 31 minutes, compared with about 139 minutes at the surging hospital). Major-trauma cases still go to the trauma center, because it is the only hospital in our data with real trauma volume.

FastER is a simulation, not a medical device. A level-1 result always shows a "call 911" warning.

How we built it

Backend: Python FastAPI, packaged with Docker Compose. Gemini is called server-side only, so the API key never reaches the browser.
Databricks + SPARCS reference data: We used the 2024 New York State SPARCS inpatient discharge data in Databricks to give each hospital a data-driven profile: trauma admissions (a proxy for trauma capability), share of patients aged 0-17 (pediatric proxy), share of major or extreme severity cases, and mean inpatient length of stay relative to the state average (a proxy for bed occupancy and ED boarding pressure).
Synthetic live status: Queue and staffing numbers (patients waiting by urgency, clinicians on shift, travel minutes, surge flags) live in a Delta table in Databricks, gold_hospital_status_by_scenario. Changing a surge is one SQL UPDATE, with no code changes. If the query fails, the backend falls back to built-in scenarios and says so in the response.
Algorithm: For a patient of urgency $a$, the estimated wait at a hospital is

$$\text{wait} = \left\lceil \frac{\sum_{k \le a} n_k \, s_k}{c} \cdot b \right\rceil$$

where $n_k$ is the number of patients waiting at urgency $k$, $s_k$ is an assumed service time for that urgency, $c$ is the number of clinicians on shift, and $b$ is the SPARCS-derived boarding factor. The total score is travel time plus wait, plus a penalty if a child is sent to a low-pediatric-volume hospital.

Frontend: A single page with scenario buttons, hospital cards, and a map.
Testing: 19 automated tests cover the surge redirect, priority ordering, trauma routing during a surge, rejection of invalid Gemini picks, the Gemini-failure fallback, and the Databricks path (with mocked queries).

Challenges we ran into

SPARCS has no triage or wait times. We planned to learn triage times from it, but it is an inpatient discharge dataset with no arrival times or ED waits. We redesigned around what it does contain and used an assumed service time per urgency level, clearly labeled as an assumption in the code.
Keeping an LLM safe in the loop. The algorithm computes the eligible set and Gemini may only choose from it. Every response states whether Gemini or the fallback made the decision, and unknown urgency defaults to the more urgent level.
Messy data. Very long stays are recorded as text like "120 +", so we had to parse and cap length of stay before computing statistics.
Calibrating the demo. Our first synthetic data sent patients to a farther hospital even on a normal evening, because the closest hospital's longer inpatient stays raised its boarding factor. We tuned the scenario so the baseline is realistic and the surge produces a visible change.
Docker and environment problems. Compose failed on a missing .env file, the environment file wasn't loaded for local runs, a blank model setting silently disabled Gemini, and Windows line endings caused trouble under WSL.

Accomplishments that we're proud of

An end-to-end pipeline from Databricks data, through an algorithm, to a Gemini-written recommendation, where the language model is constrained and validated rather than trusted blindly.
A surge scenario that shows the goal of the project: patients are diverted from an overwhelmed ED while true trauma cases still reach the trauma center.
Priority-aware waiting, so recommendations reflect how EDs serve patients by urgency instead of first-come first-served.
Transparency throughout: every result reports where its data came from and whether Gemini or the fallback made the decision.
A test suite that exercises failure paths, not only the happy path.

What we learned

Check what a dataset actually contains before designing around it. Finding out early that SPARCS lacks wait times changed our whole approach.
Use an LLM for what it does well (understanding free-text injuries and explaining a decision) and keep the decision boundaries deterministic and validated.
Failure behavior is a design decision. Defaulting to "urgent" when urgency is unknown, and labeling every fallback, matters much more in a health setting.
Proxies are useful but must be named as proxies. Trauma admissions stand in for trauma capability, and inpatient stay length stands in for boarding pressure; neither replaces official designations or real-time data.
Small infrastructure details (environment files, line endings, container configuration) can block a project as thoroughly as a hard algorithmic problem.

What's next for FastER

Real-time data: Replace the synthetic scenarios with live hospital feeds, with freshness checks so stale numbers are never trusted.
Calibrated wait model: Fit service times and boarding effects to real ED operational data and validate against observed waits.
Real routing: Use live, traffic-aware travel times from the patient's actual location and show a real street map.
Clinical validation: Work with emergency clinicians to validate the urgency levels, safety rules, and recommendation wording.
Official capability data: Use official trauma and pediatric designations instead of SPARCS proxies, and add specialties like stroke, cardiac, and obstetrics.
Ambulance and dispatcher integration: Balance load across multiple simultaneous patients so the tool doesn't just move the surge to the next hospital.
Privacy, security, and regulation: Add authentication, audit logging, and privacy protections before handling any real patient information, and review the regulatory implications of clinical decision support.