ER Voice Monitor is an AI-assisted monitoring system for emergency department waiting rooms. It was built for the 2026 Cornell Health Hackathon and is inspired by the event’s “Rethinking the Emergency Dept Waiting Room” challenge, with a strong connection to the Bridge2AI Voice track.

The project explores a simple idea: once a patient is triaged and sent back to the waiting room, their condition can still change. This app creates a lightweight monitoring workflow using periodic voice check-ins, AI analysis, and a live dashboard so staff can spot patients who may be worsening while they wait.

In many emergency departments, the waiting room is one of the least monitored parts of care. Patients may sit for long periods while:

• symptoms worsen
• pain increases
• breathing changes
• anxiety rises
• staff have limited visibility into those changes

This project was built as a hackathon prototype to address that gap without depending on a hospital EHR.

ER Voice Monitor supports a workflow like this:

1. Staff checks in a patient.
2. The patient receives or opens a check-in flow.
3. The patient records a short voice update about how they feel.
4. The system analyzes:
   • what the patient says
   • how the patient sounds
5. The app updates a live dashboard with risk indicators.
6. Staff can prioritize attention for patients who may be deteriorating.

• Real-time staff dashboard
• Staff check-in interface
• Kiosk/self-service check-in flow
• Voice recording and transcription
• AI symptom and urgency analysis
• Voice biomarker analysis service
• Risk scoring with alert states such as green, yellow, and red
• SMS-based patient check-in reminders
• Browser-based alerting for urgent changes
• Patient session history and monitoring timeline

This project was made for the Cornell Health Hackathon healthcare challenge area:

• Rethinking The Emergency Dept Waiting Room
• also relevant to Bridge2AI-Voice

The hackathon focus was on using AI and rapid prototyping to improve healthcare workflows, diagnostics, and patient experience. This prototype applies that idea to emergency waiting room monitoring.

• Next.js 14
• React 18
• Tailwind CSS
• Socket.IO client

• NestJS
• Prisma
• PostgreSQL
• Socket.IO

• OpenAI-compatible transcription and analysis flow
• voice analysis microservice in Python
• WavLM-style voice feature analysis service

• ClickSend or Twilio-style SMS integration, depending on environment configuration

apps/
  api/         NestJS backend
  web/         Next.js frontend

packages/
  shared/      shared package(s)

prisma/
  schema.prisma
  seed.ts

voice-model/
  Python voice analysis service

Before you run the project, make sure you have:

• Node.js 20 or newer recommended
• npm 10 or newer recommended
• Docker Desktop or Docker Engine
• PostgreSQL only if you are not using Docker for the database
• API credentials for AI services if you want full analysis features
• optional SMS provider credentials if you want reminder messages

git clone https://github.com/TONKAFREAK/cornell-hackathon
cd hackathon

npm install

Create a .env file in the project root.

If you already have an example environment file in your local copy, use that as the starting point. Otherwise, create one manually with values like these:

DATABASE_URL="postgresql://postgres:postgres@localhost:5432/er_voice_monitor"
APP_URL="http://localhost:3000"
NEXT_PUBLIC_API_URL="http://localhost:3001"

OPENROUTER_API_KEY=""
OPENROUTER_MODEL="google/gemini-2.0-flash"
OPENAI_API_KEY=""
OPENAI_API_URL=""

TWILIO_SID=""
TWILIO_TOKEN=""
TWILIO_NUMBER=""
CLICKSEND_USERNAME=""
CLICKSEND_API_KEY=""

These are the most important variables used by the app.

• DATABASE_URL
  PostgreSQL connection string for Prisma and the API

• APP_URL
  Frontend URL used for CORS and generated patient links

• NEXT_PUBLIC_API_URL
  Public API URL used by the frontend

At least one AI provider path should be configured for full functionality.

• OPENROUTER_API_KEY
• OPENROUTER_MODEL
• OPENAI_API_KEY
• OPENAI_API_URL

• WAVLM_SERVICE_URL
  Optional in Docker compose because it is wired internally there.
  If running services separately, this usually points to the Python voice service.

Optional, depending on whether you want reminder/check-in messages enabled.

• TWILIO_SID
• TWILIO_TOKEN
• TWILIO_NUMBER

or

• CLICKSEND_USERNAME
• CLICKSEND_API_KEY

There are two practical ways to run this project:

1. Local development with npm
2. Containerized run with Docker Compose

This is best if you want a development workflow for the frontend and backend.

At minimum, you need PostgreSQL.
If you want the full stack, you also want the Python voice service running.

If your local setup uses Docker for infrastructure, start the containers you need:

docker compose up -d

If you only want the database and prefer to run app services locally, you can still use Docker for Postgres and configure your environment accordingly.

npm run db:generate
npm run db:push

npm run db:seed

Run both frontend and backend together:

npm run dev

This starts the workspace development processes.

After startup, the main app URLs are:

• Frontend: http://localhost:3000
• Staff dashboard: http://localhost:3000/staff/dashboard
• Staff check-in: http://localhost:3000/staff/checkin
• Kiosk flow: http://localhost:3000/kiosk
• API: http://localhost:3001

If you want to run only one app at a time:

npm run dev:web
npm run dev:api

This is the easiest way to bring up the full stack in containers.

Confirm your root .env contains the values you want for:

• database
• frontend URL
• API URL
• AI provider keys
• optional SMS provider credentials

docker compose up --build

This starts:

• PostgreSQL
• Python voice analysis service
• NestJS API
• Next.js frontend

• Frontend: http://localhost:3000
• API: http://localhost:3001

A good way to understand the app is to run through the intended user journey:

1. Open the staff dashboard.
2. Check in a patient from the staff check-in page.
3. Send or open the patient check-in flow.
4. Record a voice sample describing symptoms or current condition.
5. Let the backend analyze the voice and transcription.
6. Watch the dashboard update with a new risk score and monitoring status.

Useful commands during development:

npm run db:generate
npm run db:push
npm run db:seed
npm run db:studio

To create production builds:

npm run build

This project is a hackathon prototype, not a production-ready medical device.

Important considerations:

• it is meant to demonstrate workflow and technical feasibility
• risk scores are assistive signals, not clinical decisions
• AI outputs can be imperfect
• SMS and AI capabilities depend on external credentials
• deployment for real clinical use would require security, compliance, validation, and human-centered testing

This prototype is intended for:

• hackathon judges and mentors
• students and collaborators
• developers exploring healthcare AI workflows
• teams interested in waiting room monitoring and voice biomarkers

ER Voice Monitor was built for the Cornell Health Hackathon 2026 as a prototype for the Emergency Department Waiting Room challenge. It combines voice check-ins, AI analysis, a live dashboard, and risk-based monitoring to help surface patient deterioration earlier while patients wait for care.

If you want to explore the project quickly, the simplest path is:

npm install
docker compose up -d
npm run db:generate
npm run db:push
npm run db:seed
npm run dev

Then open:

• http://localhost:3000/staff/dashboard

MIT