Ambulancify

available ambulance details
finding available ambulances
selected ambulance
live tracking the selected ambulance
available hospitals
hospital selected before the ambulance arrives
dashboard showing the live patient vitals
analysing live vitals of patient
level of patient vitals are analysed and sent to hospital
status of patient being dispatched

Inspiration

Road accidents kill over 1.2 million people globally every year, and in many cases, the delay isn't just in reaching the patient — it's in reaching the right hospital. Ambulances often arrive at hospitals that can't treat the patient's specific condition, and ERs frequently learn about an incoming patient only when they're wheeled through the door. We wanted to close that gap: what if the hospital could start preparing before the ambulance even arrives?

What it does

Ambulancify connects three sides of an emergency in real time: A user in distress can request the nearest available ambulance via live GPS matching Nearby hospitals receive the request (with patient details) and can accept or decline before the ambulance even reaches the pickup point, so the hospital is decided in advance, not after Once the patient is picked up, live vitals (pulse and SpO2) stream from an onboard sensor straight to the assigned hospital, so doctors can start preparing treatment and equipment while the patient is still in transit A dedicated driver view lets the ambulance crew control the trip status (en route, pickup complete, delivered) and updates the ambulance's live location on the map throughout

How we built it

We built Ambulancify as a modular system split across three parallel workstreams: GPS & dispatch module: live location tracking, nearest-ambulance matching using the Haversine distance formula, and a full status lifecycle (available → assigned → en-route → busy → available) Hospital coordination module: an accept/decline flow with timeout-based escalation, so a request never gets stuck waiting on one hospital Vitals & triage module: an ESP32 with a MAX30100/30102 sensor for real pulse and SpO2 readings, with a data simulator standing in for the hardware during early development so all three modules could be built and tested independently before integration The map itself runs on Leaflet with OpenStreetMap tiles, chosen specifically to avoid requiring API keys or billing setup, which kept the whole team unblocked and building fast.

Challenges we ran into

Getting three independently-built modules (dispatch, hospital, vitals) to agree on one shared data schema before writing code, so nothing broke on integration Handling the ambulance status lifecycle correctly so illegal transitions (like marking a pickup complete before the ambulance was ever en route) couldn't silently happen Deciding what to simulate versus build for real given hackathon time constraints — particularly blood pressure and respiratory rate, which need hardware we didn't have time to source Switching our map provider after running into Google Maps' billing requirement, and rebuilding on a free alternative without losing any existing functionality

Accomplishments that we're proud of

A working end-to-end flow: request → nearest ambulance assigned → hospital pre-alerted → live vitals streamed → patient delivered → ambulance released for the next call A real hardware-to-app pipeline for live pulse and SpO2 data, not just a mockup A full ambulance status lifecycle with proper validation, not just a happy-path demo A separate driver-facing interface, built specifically because we realized mid-build that someone actually needs to trigger these status changes in real use

What we learned

How much of a real-world emergency system's difficulty is in coordination and data-sharing between parties, not just tracking a vehicle on a map The value of freezing a shared data contract before splitting work across a team, and how much integration pain that step prevents later Where to draw the line between building real hardware integration and simulating it, so the core innovation (triage and hospital-matching logic) gets the most engineering time rather than the sensor plumbing

What's next for Ambulancify

Expand the triage score beyond pulse and SpO2 to include respiratory rate, consciousness level, and paramedic-reported factors like bleeding severity and suspected fractures, closer to a full NEWS2-style clinical score Add hospital capacity-awareness (bed/ICU/specialist availability) so matching considers more than just distance Build offline/SMS fallback for areas with weak network coverage Pilot with a real ambulance service and a small set of hospitals in one city to test real-world adoption, not just the technical flow