TriageAI

AI-powered emergency triage that combines contactless vitals, clinical reasoning, and real-time patient prioritization to help care teams make faster, more informed decisions.

Comment

Inspiration

The idea for TriageAI came from watching The Pitt, where the emergency department becomes increasingly overwhelmed as more patients arrive throughout the day.

What stood out to us was the pressure placed on triage nurses. Every patient enters with a different combination of symptoms, vital signs, medical history, pain level, and risk factors, yet nurses have only a short amount of time to determine who needs care first.

That problem becomes even harder when emergency departments are overcrowded or operating during extreme weather, disasters, or mass-casualty events.

A patient who appears stable may actually have warning signs of a serious condition. At the same time, another patient with more visible symptoms may be medically stable. Making the correct prioritization decision quickly requires processing a huge amount of information while keeping track of many patients at once.

We asked ourselves:

What if technology could organize that information, identify potential warning signs, and give clinicians a second set of eyes without taking away their judgment?

That question became TriageAI.

TriageAI is designed to reduce the cognitive burden of emergency triage while keeping clinicians fully in control of the final decision.

What it does

TriageAI is an AI-assisted emergency triage platform that takes a patient from intake to prioritization through one connected workflow.

Patient intake

A clinician can enter:

  • Chief complaint
  • Age and demographics
  • Pain level
  • Medical history
  • Allergies and medications
  • Blood pressure
  • Temperature
  • Oxygen saturation
  • Heart rate
  • Respiratory rate

Contactless vital signs

We integrated Presage directly into the intake workflow.

Using a camera, TriageAI can:

  • Detect whether a patient is properly positioned in frame
  • Monitor signal quality
  • Perform an optical vital-sign scan
  • Capture heart rate
  • Capture respiratory rate
  • Apply those measurements directly to the patient's intake form

If the scan fails or the camera is unavailable, the clinician can still enter the values manually.

AI-assisted triage

After intake, the patient's information is stored in Tiger Data/PostgreSQL and sent to our Google Gemini-powered triage engine.

Gemini analyzes the patient's information using the Emergency Severity Index framework and returns structured results including:

  • ESI level: 1–5
  • Confidence score
  • Clinical reasoning
  • Critical warning flags
  • Recommended actions
  • Estimated wait time
  • Patient summary

Real-time prioritization

The patient is then added to a priority queue where higher-acuity cases are surfaced first.

Clinicians can review the AI's reasoning, monitor patient status, and override the suggested ESI level whenever their own clinical judgment differs.

ER analytics

TriageAI also includes an analytics dashboard that provides visibility into:

  • Current patient volume
  • ESI distribution
  • Patient statuses
  • Wait times
  • Emergency department activity

The AI recommends. The clinician decides.

How we built it

We designed TriageAI as a complete application rather than a standalone AI demo.

Frontend

The frontend was built with React and Vite.

We created separate workflows for:

  • Patient intake
  • Presage scanning
  • AI triage assessments
  • Patient details
  • Priority management
  • Analytics
  • Clinician overrides

We also used Recharts for analytics, Framer Motion for interaction and transitions, and Axios for communication with our backend.

Backend

Our backend is built with Python and FastAPI.

It handles:

  • Patient creation and retrieval
  • Triage requests
  • Patient status updates
  • Clinician overrides
  • Analytics
  • Database communication

Database

We integrated Tiger Data/PostgreSQL as our cloud database using SQLAlchemy and asynchronous PostgreSQL drivers.

Patient records include demographic information, vital signs, triage results, AI reasoning, critical flags, timestamps, status information, and clinician overrides.

We also kept a SQLite fallback for local development so our team could continue working when a cloud connection was unavailable.

AI

We used the Google Gemini API as the reasoning layer behind TriageAI.

One of our most important technical decisions was requiring Gemini to return structured data rather than unrestricted text.

Instead of receiving a long AI-generated paragraph, our backend receives predictable fields such as:

{
  "esi_level": 2,
  "confidence": 0.94,
  "reasoning": [],
  "recommended_actions": [],
  "critical_flags": [],
  "estimated_wait_minutes": 10,
  "brief_summary": ""
}

That means the AI output can immediately become part of the application workflow.

Infrastructure

Our deployed architecture combines:

  • Vercel — frontend deployment and API routing
  • Vultr — backend cloud infrastructure
  • Tiger Data — PostgreSQL database
  • Google Gemini — AI triage reasoning
  • Presage — contactless vital-sign capture
  • GoDaddy — domain infrastructure

Instead of using sponsor technologies as isolated demos, we tried to make each one serve a specific role in the same end-to-end system.

Challenges we ran into

Integrating Presage

The hardest part of the project was integrating Presage.

Most APIs we had worked with before followed a familiar pattern:

send request → receive response

A live camera-based sensing system was completely different.

We had to work through:

  • Browser camera permissions
  • Live video streams
  • Patient positioning
  • Face/patient detection
  • Signal quality
  • Scan timing
  • Asynchronous results
  • Failed scans
  • Applying measurements back into our intake form

We also had to consider what happens when something goes wrong.

What if the patient is not in frame?

What if camera access is denied?

What if the scan cannot obtain a reliable signal?

What if the external sensing service is unavailable?

Instead of assuming the ideal case, we added support for rescanning, error states, signal feedback, and manual vital entry.

That was one of the biggest lessons of the project: real-world software has to work when things fail, not just when everything goes perfectly.

Connecting the entire system

Our second major challenge was deployment.

TriageAI combines several independently running components:

React Frontend
      |
      v
FastAPI Backend
   /       \
  v         v
Tiger     Gemini
Data       API
  ^
  |
Presage Sensor Workflow

Something working locally did not mean it would automatically work after deployment.

We had to debug:

  • Environment variables
  • API routes
  • CORS
  • PostgreSQL connection strings
  • Async database drivers
  • Vercel rewrites
  • Vultr networking
  • Camera permissions
  • Communication between frontend and backend services

Getting every component to operate together was significantly harder than building each component independently.

Accomplishments that we're proud of

We built a workflow, not just a chatbot

One of our biggest accomplishments is that TriageAI does not simply send a prompt to an LLM and display the response.

We built an end-to-end workflow:

Patient Intake → Contactless Vitals → Database → AI Assessment → Clinician Review → Priority Queue → Analytics

Every part of the system contributes to that flow.

We integrated Presage into an actual use case

Presage is not a separate demonstration inside TriageAI.

The camera scan is part of the patient intake process, and its measurements flow directly into the same patient record used by the AI triage engine.

Getting a physical-world input into our clinical workflow was one of the most technically challenging and rewarding parts of the project.

We made Gemini's output actionable

Instead of using Gemini as a chatbot, we use it as a structured reasoning engine.

Its output feeds directly into:

  • ESI classification
  • Clinical reasoning
  • Critical alerts
  • Recommended actions
  • Wait-time estimates
  • Patient prioritization

We connected multiple technologies into one architecture

We successfully combined:

Tiger Data + Presage + Vultr + Gemini + Vercel + GoDaddy

into a single application instead of building separate sponsor-track demos.

We kept the human in control

For a system dealing with medical decisions, we did not want the model to become a black box.

Clinicians can see the recommendation, understand the reasoning, and override the AI whenever necessary.

That design became one of the most important parts of TriageAI.

What we learned

AI is only one part of an AI product

The biggest lesson we learned is that adding an LLM to a website does not automatically create a useful AI application.

Gemini is only one component of TriageAI.

For the application to actually work, we also needed:

  • Reliable patient data
  • Persistent storage
  • Sensor input
  • Predictable AI output
  • Error handling
  • Prioritization logic
  • Analytics
  • Cloud infrastructure
  • A usable interface

The value comes from how those pieces work together.

Physical-world software behaves differently

Presage pushed us into an area of development we had never explored before.

When software depends on a camera and a real person standing in front of it, suddenly things like lighting, positioning, permissions, signal quality, and timing matter.

That forced us to think beyond normal API development.

Deployment exposes problems that localhost hides

Connecting Vercel, Vultr, Tiger Data, Gemini, and Presage taught us how many assumptions disappear once an application leaves a local machine.

We learned a lot about networking, configuration, asynchronous systems, and debugging distributed applications.

High-stakes AI needs human oversight

The most important product lesson was understanding that AI should not hide the reasoning behind a high-stakes recommendation.

TriageAI provides information and prioritization support, but the clinician remains responsible for the final decision.

The goal is not to replace nurses. It is to give them better tools.

What's next for TriageAI

There is a lot we would continue building beyond the hackathon.

Clinical integration

We would add:

  • Hospital EHR integration
  • FHIR support
  • Secure clinician authentication
  • Role-based access control
  • Detailed audit trails

Expanded sensing

We want to deepen the Presage integration and explore additional contactless measurements and more robust signal-quality handling.

Emergency response

One of the areas we are most interested in is taking TriageAI outside the traditional emergency department.

Potential environments include:

  • Field hospitals
  • Disaster-response centers
  • Mass-casualty incidents
  • Ambulances
  • Remote medical facilities
  • Temporary emergency shelters

In these situations, teams may have limited equipment, limited staff, and many patients who need to be assessed quickly.

Smarter hospital operations

Future versions could also help coordinate:

  • Bed availability
  • Medical resources
  • Ambulance-to-hospital handoffs
  • Multi-hospital patient loads
  • Changes in patient condition over time

Ultimately, we want TriageAI to become more than an intake tool.

We want it to help clinicians turn a crowded room of unknown patients into an organized, explainable, and constantly updated picture of who needs help first.

Our goal is simple: give clinicians better information, faster, so they can spend less time sorting through data and more time caring for patients.

Built With

Share this project:

Updates

Submission history