QueueCare - Real Time Patient Flow Optimization System
At City General Clinic, receptionists lost 90+ seconds per patient while juggling paper tokens and check-in tools and faced interruptions roughly every 15 minutes. Doctors sat idle ~4 min between patients from missed handoffs, costing 1+ hour of daily capacity. Once queued, patients couldn't be re-prioritized — an emergency or frail senior waited like any walk-in. Patients had zero visibility into wait times, so they hovered nearby instead of stepping away. Comparable clinics report up to 68.5% of visit time spent waiting. No affordable system offered real-time, fairness-aware queue visibility
Process
I started by mapping the clinic workflow firsthand watching receptionists juggle paper tokens, doctors signal manually for the next patient, and patients hover near the desk for updates. That observation, not assumptions, shaped the priority and visibility requirements.
For real-time sync, I first let Socket.IO auto-negotiate transport, it added ~2s of connection delay, so I forced direct WebSocket transport instead. I also initially ran promotion logic on every read request, which caused DB lock contention and pushed response times to 1.2–2.5s; I fixed this by separating reads from writes and adding an in-memory pre-check before any transaction. Patient transfers were first built by cloning records, which broke portal links .I switched to in-place updates, preserving the original token
Results
QueueCare cut average patient wait time 42% (38→22 min), and API read latency 99% (1.8s→<10ms), with WebSocket setup dropping 97% (1.5s→45ms). Staff coordination overhead fell 83%, and front-desk status inquiries dropped 75% as patients tracked their own queue position. Room utilization reached 94%. All 15 documented edge-case scenarios, like concurrent registrations, emergency transfers, doctor downtime, and DB timeouts, were passed via automated and manual testing. No independent usability or satisfaction data has been collected yet.
Reflection
I'd validate the wait-time regression model against a second clinic's data earlier, since a single-clinic regression risks overfitting to one schedule and a doctor's pace. I'd also test accessibility features with actual visually impaired or non-native-language users instead of assuming ARIA compliance equals usability I never confirmed that with real people, and it's the gap I'd close next. Finally, I'd build the clinic-identifier field for multi-tenancy from the start rather than retrofitting it, since schema changes get riskier the more data depends on them.
26 media files · queuecare-neon.vercel.appView 