Shobali Murari

Queue Cure '26 : Real-time Clinic Queue System

Most Indian clinics run on paper token slips and shouting. Patients wait two to three hours with no idea when their turn will come. My goal was not just to digitise the token list, but to fix the two things that actually hurt: patients having zero visibility, and receptionists managing everything from memory. That meant two screens that always agree with each other, an honest wait estimate, and an interface a busy receptionist cannot easily break. Before writing code I asked one question that shaped everything else: where does the truth live? My answer drove the whole architecture. Process I started by identifying the real problem: not just a digital token list, but two screens that always agree with each other. Before writing any code I decided the server would own the single source of truth, with clients only rendering what the server sends. That one architectural decision shaped everything else. I then built outward from the hardest part first — proving live sync worked between two browser tabs — before adding queue logic, wait-time learning, and mistake-proofing on top of a proven foundation. Results Both screens sync in real time with zero refresh. The wait-time estimate starts from a seed value set by the receptionist, then shifts to measured consultation data the moment the first patient is seen. No-shows are held in a visible skipped section and can be recalled when they return. The receptionist screen handles every real-world mistake a busy clinic would face: wrong calls, absent patients, and accidental double-clicks. Reflection I would add a small database from the start so the queue survives a server restart. I kept state in memory to move fast, which was the right call for a hackathon, but persistence is the first thing a real clinic would need. I would also add Socket.IO rooms from day one so multiple clinics could run independently on the same server without any extra work later.