Kiruthiga S

Queue Cure: Live token queue replacing paper slips for clinics

76% of India's 1.5 million clinics still run on paper token slips and verbal calling. Patients wait 2-3 hours with zero visibility into when they'll be seen — no way to know how many people are ahead or how long it'll take. Receptionists manage the entire queue from memory, with no dashboard to track who's next, who's been served, or how long consultations are taking. There's no live communication between the front desk and the waiting room — every update happens by shouting a name across a crowded room. Process I split the problem into two user needs: receptionists need control, patients need visibility. So I built two focused screens instead of one complex dashboard. For live sync, I chose Socket.io over polling — it updates instantly with no lag. Actions go through REST POST requests; state changes broadcast via one socket event to every connected screen. For wait time, I used tokens ahead × average consult time — simple and useful immediately. I kept state in-memory to ship fast, with persistence flagged as the next upgrade. Results Built a fully working two-screen system where receptionist actions sync to the patient waiting room in real time, with zero manual refresh. Replaced the 2-3 hour blind wait with live token status and an estimated wait time, calculated instantly from queue position and average consultation time. The receptionist workflow went from memory-based tracking to a single "Call Next" click that updates every connected screen in under a second. The architecture is lightweight enough to run on a basic clinic PC and a tablet/TV in the waiting room, with no extra hardware needed. Reflection I'd add persistent storage (a real database) so the queue survives a server restart — right now it resets in memory. I'd support multiple doctors/rooms running in parallel, since most clinics have more than one consultation room active at once. I'd add SMS/WhatsApp notifications so patients don't need to keep a screen in view. I'd also add basic authentication for the receptionist login, since right now anyone with the URL can manage the queue — fine for a prototype, not for production.