HIMS issues tokens to walk-ins, checks appointments in against their slot, and orders both into a live queue for each doctor. The front desk sees waiting counts on the OPD dashboard and the doctor sees who is next from the consulting room.
Hospital queue management software replaces the token pad and the corridor headcount with a live, ordered queue for each doctor. A walk-in gets a token at the desk, a booked patient is checked in against their appointment, and both appear in the doctor's queue in the order the hospital has chosen. In HIMS this is built into the OPD module rather than sold as a separate token machine.
Because the token is attached to a registered patient, calling the next token opens the patient's record for the doctor. The waiting count per doctor sits on the OPD dashboard for the front desk, and the patient portal lets a patient see their booking. The queue is not a display gimmick; it is the order in which records reach the consulting room.
Most OPD friction is not the wait itself. It is not knowing where you are in the wait.
Appointments on a sheet and walk-ins on a pad, merged by whoever is standing at the door.
The consultant does not know whether six or sixteen patients are waiting and paces the morning by guesswork.
A patient steps out for a test and their number is lost; another is called twice by mistake.
Calling number 14 tells the doctor nothing about who number 14 is or what they came for.
A patient asks how long; the desk says soon, because there is no count to look at.
UHID found or created at the desk.
Walk-in receives a token; appointment is checked in to its slot.
Ordered with existing tokens and appointments for that doctor.
The doctor takes the next token and the record opens with it.
Consultation recorded; the token closes and the queue moves.
Lab, pharmacy and billing continue on the same record.
Workflow: The desk issues tokens as patients arrive; the dashboard shows the waiting count for each consultant, so a second doctor is asked to start early.
Result: Load is balanced from a number, not from noise.
Workflow: The token is still in the queue; when the patient returns the desk moves it to the next available place.
Result: Nobody loses their turn for getting a blood test.
Workflow: Checked in against the slot, the appointment takes its place ahead of later walk-ins as the hospital has configured.
Result: Booking means something.
Workflow: The roster shows the consultant from three o'clock; tokens for that session open only for that window.
Result: No tokens issued for a doctor who is not in.
Several consultants, several queues.
Visiting doctors on session rosters.
One queue, no receptionist argument.
Sample collection and scan queues.
An answer for every patient who asks how long.
It is the queue behind the display. HIMS issues and orders tokens per doctor and shows waiting counts on the OPD dashboard. If you want the queue shown on a screen in the waiting area, describe the setup on a call and it is scoped with the project.
Both feed the same queue for the doctor. The rule for how a checked-in appointment is placed relative to walk-in tokens is set to your hospital's policy during setup.
The patient app and portal let patients book and see their appointment. Notification workflows beyond that are discussed on the call so nothing is promised that your setup does not include.
Yes. The desk can move a token later in the queue when a patient steps out, transfer it to another doctor in the same department, or cancel it if the patient leaves.
Yes. Queues can be per doctor or per department, following the doctor rosters, so a general medicine queue can be shared by whichever consultants are on duty. See doctor management software.
No. It is part of the OPD module in HIMS, alongside registration, appointments and consultation. See hospital OPD software for the full flow.
Tell us how you work today. We will show you what the platform would look like for you, and give you a clear scope and timeline.
Founder-led · Chennai, India · Built and supported by the person who wrote it