Nidhi A

NoParchi: Real-Time Clinic Queue Sync

Currently, 76% of Indian clinics rely on paper token slips. The friction is immense. As one clinic receptionist noted during my initial research, "I have 40 frustrated patients staring at me, and I'm just guessing who is next based on a messy pile of paper slips." Patients suffer 2–3 hour waits with zero visibility into their actual turn. The business gap is clear: clinics desperately need a real-time, zero-friction digital queue system that eliminates cognitive load for staff while ending waiting room anxiety for patients. I started by mapping user journeys with a focus on speed. Initially, I designed a standard list-view UI for the receptionist. However, that didn't work—it required too much scrolling and manual data entry. I scrapped it and chose a Bento-grid layout because it surfaces critical actions (Call Next, No-Show) instantly without cognitive overload. For the backend, my first iteration relied on REST API polling every 5 seconds. I quickly realized this caused UI lag and occasional race conditions with multiple terminals. I pivoted to WebSockets (Socket.io) because it guarantees true 0-latency centralized state. Finally, hardcoded wait-times failed during edge cases (like patient no-shows), so I engineered a rolling-average algorithm to ensure predictions remained strictly data-driven. The final prototype successfully delivers 0-latency live updates across Receptionist and Patient screens using WebSockets. It entirely eliminates paper tokens by introducing a 1-step QR code scan for patients to track their live position. The dynamic wait-time algorithm successfully adjusts predictions based on real data rather than static guesses, seamlessly handling edge cases like "No-Shows" without skewing the average. The UI proved highly effective in keeping crucial actions front and center, minimizing cognitive load and manual data entry for busy clinic staff. While the real-time sync works flawlessly under good network conditions, Indian clinics often face spotty internet. If I were to iterate on this, I would heavily invest in "Offline First" resilience. I would implement local state caching (using IndexedDB or localStorage) for the receptionist dashboard. This would allow them to continue adding patients even if the Wi-Fi drops, with the system automatically batch-syncing to the server upon reconnection. Additionally, I would integrate an SMS fallback (e.g., via Twilio) for patients who do not have smartphones capable of scanning the onboarding Q