Inspiration

Monthly average ambulance response times can hide the incidents and neighborhoods with the most severe delays. We wanted to explore how a health system could notice unusual response times sooner, investigate where patterns are occurring, and help teams understand the full journey from call to scene to hospital.

What it does

DIIS is a synthetic emergency-response prototype with connected views for callers, responders, and supervisors. A caller can create a demo incident and follow its shared tracking link. A responder can accept the incident, advance through scene arrival, review hospital options, and confirm the transport. The supervisor can review completed scene-response and hospital-transport durations separately, with charts and signals that highlight cases for investigation.

The app demonstrates how control charts can surface variation that averages may miss. A signal prompts review; it does not identify a cause or assign fault. The app does not contact 911 or EMS.

How we built it

We built the prototype with R and Shiny, using HTML, CSS, and JavaScript for the interface. Its statistical analysis uses Individuals and Moving Range charts, organized by zone, call priority, and response phase. Bundled synthetic datasets support stable-process, planted-delay, and edge-case demonstrations. The app is deployed as a web app on Posit Connect, with a progressive web app interface.

Challenges we ran into

Keeping one demo incident synchronized across caller, responder, and supervisor views required careful handling of shared state and milestones. We also had to distinguish the call-to-scene duration from the separate transport-to-hospital duration, and make charts understandable without overstating what a statistical signal means. Another challenge was ensuring our planted-delay scenario could be compared with an unchanged baseline.

Accomplishments that we're proud of

We brought the incident workflow and quality-monitoring dashboard into one prototype. The responder can confirm key milestones, and the same synthetic incident is reflected in the other roles. The supervisor can inspect individual response records and investigate signals rather than relying on a monthly average alone. We also documented reproducible datasets and the assumptions behind the analysis.

What we learned

We learned that the definition and quality of a response-time measure matter as much as the chart used to monitor it. A useful system needs clear event timestamps, stable and reviewed baselines, and a way to examine unusual cases in context. We also learned to treat statistical flags as prompts for investigation—not proof of a cause or a measure of individual performance.

What's next for Health Systems Emergency Response

Next, we would validate the workflow and measures with EMS and health-system stakeholders, test the interface with dispatch and response teams, and strengthen data quality, security, auditability, and durable storage. Any real-world integration would require appropriate authorization and rigorous operational validation. Live dispatch, GPS, traffic, weather, and hospital-capacity integrations are future work; the current app uses synthetic data and simulated routes.

Built With

  • codex
  • r
Share this project:

Updates

Submission history