Rapid Triage

Real-time patient monitoring for smarter, faster emergency triage.

Comment

Rapid Triage

Real-time wearable triage for mass-casualty incidents — continuously monitoring patients, prioritizing care, and helping responders find who needs them most.

Inspiration

In a mass-casualty incident, one of the biggest challenges is simple: there may be far more patients than available medical responders.

Traditional triage gives responders a snapshot of a patient's condition at one moment in time. But a patient who initially appears stable can deteriorate while responders are helping someone else. With dozens of patients spread across an incident site, continuously reassessing everyone becomes extremely difficult.

We wanted to ask:

What if every patient could continue being monitored after their initial assessment, even when no medic was standing beside them?

That inspired Rapid Triage — a wearable monitoring and response system designed for situations where medical resources are limited.

A responder can place a Rapid Triage device on a patient and move on. The wearable continuously collects vital signs and sends them through a local network to our backend. Rapid Triage analyzes those measurements over time, detects concerning trends, calculates patient priority scores, and gives responders a live view of which patients may require attention first.

Instead of triage being a one-time decision, Rapid Triage turns it into a continuous process.

What it does

Rapid Triage connects patients, incident commanders, and responders through one coordinated system.

Each patient receives an ESP32-based wearable containing multiple sensors for collecting physiological measurements such as heart rate, blood oxygen saturation (SpO₂), body temperature, and ECG data.

The device transmits measurements over a local Wi-Fi network to our backend, where they are timestamped and stored in Tiger Data as time-series data.

But individual measurements alone do not tell the whole story.

Our Python processing pipeline continuously transforms incoming measurements into clinically relevant monitoring features such as recent averages, changes over time, persistence of abnormal readings, and physiological trends.

Those features are passed into our Triage Engine, which converts multiple signals into an explainable patient priority score. This allows the system to consider not only whether a measurement is abnormal, but also how severe it is, how long it has remained abnormal, and whether the patient's condition is worsening.

The Next.js command dashboard provides a real-time overview of monitored patients, their latest vitals, trends, status, and relative priority. This gives responders a centralized view of the incident rather than forcing them to manually revisit every patient.

Rapid Triage also extends beyond monitoring.

Responders use our iOS application to receive patient assignments and access the information they need in the field. Once assigned, the app can use the wearable's Bluetooth Low Energy (BLE) signal strength as a proximity aid to help the responder locate the correct patient.

When the responder reaches the patient, they can review the patient's status, provide care, mark the patient as treated, and continue through the response workflow.

The result is an end-to-end loop:

Sense → Transmit → Store → Analyze → Prioritize → Assign → Locate → Treat → Reassess

Rapid Triage is not intended to replace medical professionals or make autonomous medical diagnoses. It is designed as a decision-support and coordination prototype that helps responders manage limited attention during chaotic, high-patient-volume situations.

How we built it

Rapid Triage combines embedded hardware, real-time networking, time-series data engineering, analytics, web development, and mobile development.

Wearable firmware and hardware

The patient device is built around an ESP32, giving us both Wi-Fi and Bluetooth Low Energy connectivity in a compact platform.

We integrated multiple sensors and components into the wearable, including:

  • Heart rate and SpO₂ sensing
  • Body temperature sensing
  • ECG acquisition
  • Display
  • LED and buzzer feedback
  • Physical user interaction controls
  • Wi-Fi communication
  • Bluetooth Low Energy

The firmware handles sensor acquisition, device state, patient identification, local feedback, and communication with the backend.

Rather than requiring an Internet connection, the ESP32 devices can communicate through a portable local Wi-Fi network. This was important to our design because disaster environments cannot always be assumed to have reliable Internet infrastructure.

Python + Flask backend

Our backend is built in Python with Flask and is separated into multiple processing stages.

The first pipeline acts as the ingestion layer. It receives messages from the ESP32 devices, validates and parses the incoming measurements, associates them with the correct patient and timestamp, and writes the resulting data to Tiger Data.

The second pipeline is our analytics and Triage Engine.

Instead of classifying patients directly from a single raw measurement, we process their time-series history into higher-level features. This allows Rapid Triage to capture concepts such as:

  • Current physiological state
  • Recent averages
  • Severity of abnormal measurements
  • Rate of change
  • Persistence of abnormal readings
  • Short-term trends
  • Multi-signal deterioration

The engine evaluates these features and generates patient-level priority scores that can be stored and updated as new measurements arrive.

This architecture means that the patient's priority is not static — their triage state can evolve as their physiological condition changes.

Tiger Data

Tiger Data is the core time-series data layer of Rapid Triage.

Our wearable devices continuously generate timestamped physiological measurements, making the project a natural time-series problem.

We use Tiger Data to store both incoming patient measurements and derived triage information. The backend can then efficiently query recent windows of data to calculate trends and features rather than treating every sensor measurement independently.

This gives us a history of each patient's condition and allows our system to answer much more meaningful questions:

Is this patient's SpO₂ low right now?

becomes:

How low is it, how long has it been low, and is it continuing to fall?

That temporal context is fundamental to our triage approach.

Tiger Data also provides a unified PostgreSQL-based data layer that can support both high-frequency sensor information and the relational information needed to connect devices, patients, scores, and responder workflows.

Next.js command dashboard

We built the monitoring interface using Next.js.

The dashboard acts as the incident command view of Rapid Triage. Instead of displaying patients as an unordered list, the interface is designed around prioritization.

Responders can see incoming patient information, current vitals, historical trends, triage information, and which patients may require attention.

This transforms hundreds or thousands of individual sensor readings into something actionable: who should we look at next?

iOS responder application

We also built an iOS application for responders in the field.

The app bridges the gap between identifying a high-priority patient on the server and actually reaching that person.

A responder can receive a patient assignment, view relevant patient information, and use BLE RSSI-based proximity information from the patient's ESP32 to help locate the assigned wearable.

Once the responder reaches the patient, they can update the patient's workflow state, including marking them as treated and proceeding to the appropriate next step.

Together, the dashboard and mobile application allow Rapid Triage to coordinate both the command-level view of an incident and the responder-level workflow on the ground.

Challenges we ran into

One of our biggest challenges was integrating several very different systems into one functioning prototype.

On the hardware side, physiological sensors behave very differently from clean simulated data. Sensor placement, movement, contact quality, sampling frequency, and electrical noise can dramatically affect readings. ECG in particular produces a waveform rather than a simple value, which required us to think differently about acquisition and processing.

Networking created another challenge. We needed multiple wearable devices to continuously communicate with a server while keeping the architecture practical for an emergency environment. This led us toward a local-network design where the system does not fundamentally depend on every wearable having Internet access.

We also had to determine how to turn raw measurements into useful triage information. Simply labeling individual values as "good" or "bad" loses valuable context. We therefore designed our pipeline around time-series features, persistence, trends, and multi-signal scoring.

Finally, we had to connect embedded firmware, Python services, Tiger Data, a Next.js frontend, and an iOS application into one coherent workflow. Making the system behave like one product rather than several disconnected demos was one of the most difficult — and rewarding — parts of the hackathon.

Accomplishments that we're proud of

We're especially proud that Rapid Triage became much more than a sensor prototype.

We built an end-to-end system spanning physical hardware, embedded firmware, networking, time-series storage, backend processing, triage analytics, a web dashboard, and a responder mobile application.

We're proud that our architecture preserves the patient's historical measurements instead of reducing them immediately to simple labels. This allows the system to reason about change over time, which is one of the most important ideas behind Rapid Triage.

We're also proud of the responder workflow. Detecting that someone needs attention is only useful if a responder can act on that information. By combining patient prioritization, assignments, BLE-assisted proximity, and treatment status, we were able to connect analytics to real-world action.

Most importantly, we designed the project around a difficult constraint:

When there are more patients than responders, how can technology help humans allocate their limited attention more effectively?

What we learned

Rapid Triage taught us that building a useful health-monitoring system is not just about collecting more sensor data.

Context matters.

A single abnormal reading may be noise. A measurement that remains abnormal for several minutes is much more meaningful. A measurement that is both abnormal and rapidly worsening may deserve even more attention.

That changed how we approached our architecture. Instead of treating the wearable as the intelligence layer, we treated it as a reliable data-collection node and moved temporal analysis into the backend, where historical information can be analyzed.

We also learned how well time-series databases fit real-world IoT systems. Tiger Data allowed us to think of patient data as a continuously evolving timeline rather than isolated database records.

On the embedded side, we learned a great deal about integrating multiple sensors, I2C devices, physiological signal acquisition, Wi-Fi communication, BLE, and device feedback on a resource-constrained microcontroller.

Finally, we learned that the most important part of a system like Rapid Triage is not any individual technology. It is the workflow connecting them.

The ESP32 collects the signal.
The network transports it.
Tiger Data preserves its history.
Python turns history into features.
The Triage Engine turns features into priorities.
The dashboard makes those priorities visible.
The iOS application gets a responder to the patient.
And the responder makes the actual care decision.

What's next for Rapid Triage

Our hackathon prototype demonstrates the architecture, but there is much more we would like to explore.

The next step would be improving the physical wearable into a smaller, battery-powered, rugged enclosure that can be deployed rapidly and comfortably during an emergency.

We would also like to improve signal-quality detection so the system can distinguish physiological deterioration from poor sensor contact or motion artifacts.

On the analytics side, we want to expand the Triage Engine with additional validated physiological features while keeping every priority recommendation explainable to responders.

The system could also support additional emergency-response information such as responder availability, patient location, treatment history, and changing incident conditions.

Longer term, Rapid Triage could explore edge-first operation, allowing local triage and coordination to continue even when external Internet connectivity is completely unavailable, with cloud synchronization occurring once connectivity returns.

Our vision for Rapid Triage is simple:

Give every patient a continuous digital voice — even when there aren't enough responders to stand beside every patient.

Built With

Share this project:

Updates

Submission history