Real-Time Clinic Queue Management for Outpatient Healthcare

TL;DR

A Client approached us to solve a problem every outpatient clinic in Indian cities shares: patients wait 45–90+ minutes with zero visibility into how long the wait will actually be. We built a real-time queue management platform — a patient mobile app, a clinic reception dashboard, and a doctor dashboard — sharing one Supabase backend, delivered in a 30-day MVP build. The result: clinic staff can run a live, transparent queue instead of a paper list or a WhatsApp group, and patients can see exactly where they stand without calling the clinic or sitting in a waiting room.

<KeyTakeaways item1="Real-time queue visibility, delivered via Postgres change streams, removed the single biggest source of patient uncertainty at outpatient clinics." item2="A single-writer architecture — where only clinic reception can change queue state — eliminated a whole category of data-consistency bugs before they could happen." item3="Compliance (India's DPDP Act, Apple/Google health-category rules) was designed into the schema from day one, not retrofitted after launch."

The Problem: Invisible Waiting

Outpatient clinics in Indian cities run on a familiar, broken system: a paper register or a receptionist's memory decides who's next. Patients arrive, take a seat, and have no reliable way to know whether they're 10 minutes or 90 minutes from being seen.

Existing platforms in this space solve doctor discovery and appointment booking — finding a doctor, booking a slot — but none of them solve live queue visibility. Booking a 3pm slot doesn't tell a patient whether the clinic is running on time.

Outpatient wait times of 45–90 minutes are common across Indian metro clinics, largely because queue state is tracked manually and isn't visible to the patient until they physically arrive.

What We Built

The platform ships as three connected surfaces sharing a single backend:

1. Patient mobile app (iOS + Android, Flutter)

Patients sign up with phone number and OTP — no password, no email required. They can search clinics and doctors by specialty, view live queue length and estimated wait for same-day bookings, or book a future-dated slot. Once in a queue, their position updates in real time with no manual refresh, and they receive SMS notifications when their position moves — up or down.

2. Clinic reception dashboard (Next.js)

Reception staff log in via phone OTP and operate the queue through a simple three-button flow: check in, start consultation, end consultation. Ending a consultation automatically advances the queue and triggers patient notifications — no manual coordination required. An emergency-insert path handles urgent walk-ins without breaking the queue's integrity.

3. Doctor dashboard (Next.js)

Doctors see their live queue count and order, scoped to whichever clinic they're currently active at if they split time across locations. The dashboard is intentionally read-only: all queue state changes flow through reception, never the doctor.

If more than one role can change the same piece of state, you don't have a queue — you have a race condition waiting to happen. Designating a single "writer" role for queue state is one of the highest-leverage architecture decisions in a system like this.

The Architecture Decision That Mattered Most: Single-Writer Queue State

A tempting early idea is to let doctors advance their own queue — "mark patient done" from the doctor's own screen. We deliberately ruled this out.

Allowing two different roles (reception and doctor) to both modify live queue state creates race conditions that are extremely difficult to fully eliminate — two people can advance the same queue at nearly the same moment, and now the system has to reconcile a conflict that shouldn't exist in the first place.

Instead, the architecture enforces a single-writer principle: only clinic reception can change queue state. The doctor dashboard is read-only by design. This single decision removed an entire category of concurrency bugs before a line of code was written to handle them — because there was nothing to reconcile.

Real-time updates themselves are delivered via Postgres change streams over websockets (Supabase Realtime), scoped per clinic and per doctor rather than broadcast globally. This avoids the need for a custom Socket.io/Redis layer while still comfortably supporting the concurrency and scale a multi-clinic rollout requires.

Compliance Was Not an Afterthought

Healthcare applications carry a different compliance burden than typical consumer apps, and we treated this as an architectural constraint from the first schema design, not a pre-launch checklist:

• Versioned, granular consent — separate opt-ins for privacy policy, terms, and SMS communications, each timestamped and tied to a policy version, aligned with India's DPDP Act requirements for consent to be specific and unambiguous
• Row-Level Security enforced server-side — every query scoped so that even a compromised frontend cannot return another patient's or another clinic's data
• Notification content designed for lock-screen exposure — messages like "your appointment status has changed" rather than anything naming a doctor or revealing a queue position publicly
• Self-serve account deletion — a hard requirement for both Apple and Google health-category approval, implemented from day one rather than bolted on before submission

Both Apple and Google will reject a health-category app that requires users to email support to delete their account. If your team is planning a health app, build self-serve deletion into the very first release, not a "fast follow."

Results

• [X] pilot clinics onboarded in [City] within the first [X] weeks of launch
• [X]% of reception staff operating the live queue without ongoing reminders after [X] days — the leading indicator the team used to validate product-market fit
• Real-time queue position updates delivered with [X]-second average latency
• Zero cross-clinic data exposure incidents across [X] months of production use

Frequently Asked Questions

Appointment booking tells a patient when their slot is scheduled. Real-time queue management tells a patient where they actually stand right now, accounting for delays, no-shows, and walk-ins — which is the information patients actually need to decide whether to leave home, run an errand, or keep waiting. When only one role (clinic reception) can change queue state, the system never has to resolve a conflict between two simultaneous updates. This eliminates an entire category of race-condition bugs that would otherwise require complex conflict-resolution logic to handle safely. At minimum: India's DPDP Act 2023 for consent and data-protection obligations, OWASP-aligned security practices for data handling, and — if distributing via app stores — Apple's and Google Play's health-category guidelines, which require self-serve account deletion, accurate data-safety disclosures, and a published, accessible privacy policy. Through Row-Level Security policies enforced at the database layer, not just in application code. Every query is scoped so that a clinic's staff or a patient can only ever retrieve data belonging to their own clinic or their own record, regardless of what the frontend requests. A single Flutter codebase covers both iOS and Android from one build, which matters directly for a 30-day MVP timeline — it halves the mobile development surface area without compromising on native performance for a queue-and-booking use case.

---

Building a health-tech or regulated-industry product and want to talk through architecture or compliance decisions? Get in touch — we're glad to compare notes.