Patient Queue and Appointment System
A clinic where patients arrive, submit a card at reception, and wait without knowing their position or how long it will be. Doctors run late; the waiting room finds out by waiting.
The problem
The clinic's most visible failure to patients is not clinical, it is the waiting room. And the clinic has no data on it, so it cannot fix it.
In scope
- Appointment booking
- Walk-in queue with triage priority
- Queue display
- Reminders
- No-show tracking
- Wait-time reporting
Out of scope
- Clinical records
- Prescribing
- Billing
- Pharmacy
- Patient identity here is deliberately light — enough to call someone forward, not a full record — and it hands over to the Hospital Operations & Patient Flow Platform cleanly when that exists.
What this would cover
Grouped by module — open the ones you want to read.
Appointments
- By doctor, clinic session and slot, with slot lengths configurable per clinic type
Walk-in queue
- Arrivals joined to the queue with a triage priority set by a nurse, so urgency overrides arrival order transparently
Queue display
- A screen in the waiting room showing position and currently-serving, and a number given at reception; position without names, for confidentiality
Reminders
- Appointment reminders by message, with confirmation, reducing no-shows
Doctor view
- The clinician sees their own list and marks a patient as seen, which advances the queue
No-show and rescheduling
- Recorded, with repeat no-shows visible
Reporting
- Average and worst wait by session, day and clinician; arrival patterns against staffing; no-show rate
Data model
- Patient (light identity)
- Appointment → Slot → Session
- QueueEntry → TriagePriority
- Clinician
- WaitEvent
- Reminder
Invariants
- Queue position derives from arrival time and triage priority together, and the rule is displayed — an unexplained reordering is read as favouritism.
- Every state change stamps a time, because wait-time reporting is the point.
- Patient names are not shown on the public display.
Offline behavior
Reception and queue advance should survive a short outage with a local queue, since a clinic cannot stop admitting patients. Reminders require connectivity and can wait.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Measuring waiting time measures the clinicians, and that is why these systems get quietly abandoned.
The reports will show which doctor starts late and which session overruns. If that data is used punitively, the queue stops being marked accurately within a month and the tool dies. The recommendation is to agree in Phase 2 that the first quarter's data is diagnostic rather than evaluative, and that the clinicians see their own numbers before management does.
A triage priority that lets a later arrival go first will be challenged in the waiting room.
The display must show that priority exists and why, or reception staff absorb the conflict.
End state
What would be true about their day once this is running.
- A patient knows their position and roughly how long.
- Urgency is handled visibly rather than by argument at the desk.
- The clinic can see which sessions overrun and where arrivals cluster, and can staff against real numbers.
This is a deliberate first step toward Hospital Operations & Patient Flow Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review