Queue Cure — Real-Time Hospital Queue Management System
Built and deployed a real-time hospital queue system with zero-refresh sync across receptionist and patient display screens using Socket.IO.
2
Screens synced live
<1s
Queue update delay
7
Socket events built
Overview
Hospitals and clinics in India manage patient queues manually — receptionists call out names, patients crowd the front desk, and there's no visibility into wait times. This creates chaos for staff and anxiety for patients who don't know when they'll be called. Queue Cure solves this with two dedicated screens: a receptionist panel to manage the queue in real time, and a TV display for the waiting hall showing live token updates — no refresh, no polling, no confusion. Process Started by identifying the two core users: the receptionist who manages the queue and the patient who waits. Designed the system around a single server broadcasting state to all connected screens via Socket.IO WebSockets. Built the backend first — Express + Socket.IO with in-memory state and 7 socket events. Then built both React screens independently, connecting them to the same server. Deployed the server on Railway and the frontend on Vercel, handling CORS configuration for production. Receptionist screen (staff): https://queue-cure-peach.vercel.app/receptionist Patient display screen (TV): https://queue-cure-peach.vercel.app/display Results Queue Cure '26 is a real-time hospital queue management system with zero-refresh sync across multiple screens. The receptionist and patient-facing token display stay in perfect sync via WebSocket events — any update reflects instantly on all connected tabs without a page reload. The system handles the full consultation lifecycle: token assignment, live wait time estimates, a rolling average timer from the last 10 consultations, and a one-click day reset. Edge cases like empty queue calls, socket disconnects, and duplicate names are handled gracefully on both frontend and server. Reflection The biggest limitation is that all state lives in server memory — a restart wipes everything. In a real clinic, I'd add a lightweight database (PostgreSQL or SQLite) to persist the queue and store daily history for analytics. I'd also add basic authentication so only authorized staff can access the receptionist screen, and build a multi-doctor view for clinics with parallel queues. On the UX side, I'd add sound alerts on the display screen when a new token is called — useful in noisy waiting halls where patients might miss a visual update. Patient display screen (TV): https://queue-cure-peach.