OPD is the first thing a patient experiences and, for most tier-2 and tier-3 hospitals, still the most manual part of the building. A reception register, a paper token pad, a whiteboard with doctor names, and a queue that only the person standing at the desk can actually see. OneCity's OPD and appointment queue module replaces that with a single doctor-wise queue, live token display, and registration that can pull a patient's ABHA number in seconds instead of retyping a name and phone number the hospital already has on file somewhere else.
This is not a generic appointment-booking widget bolted onto a website. It is built around the specific way an Indian OPD actually works: a mix of pre-booked appointments and walk-ins sharing the same doctor's time, multiple departments running in parallel, and a front desk that needs to manage all of it without a second screen or a second system.
The problem this actually solves
Walk into most tier-2 or tier-3 hospital OPDs and the same three things go wrong on a normal day. A walk-in patient and a pre-booked patient both believe they are next, because nothing on the desk actually shows an ordered queue. A patient who registered an hour ago at the front desk has to repeat their name, age and complaint to the nurse, and again to the doctor, because none of those three points share a screen. And when a doctor runs late or steps out for a procedure, the queue simply stalls with no visible update, so patients keep asking the same question at the desk instead of watching a display.
None of this is a staffing problem. It is a visibility problem. The front desk usually knows exactly what is happening; the patients standing in the waiting area do not, and neither does the doctor's room three corridors away. Fixing that does not require adding people. It requires one queue that every screen in the building reads from.
How the queue actually works
Registration issues a token the moment a patient checks in, whether they walked in or had a slot booked in advance. Both paths land in the same doctor-wise queue, ordered by a rule the hospital sets, not by whoever shouts loudest at the desk. A pre-booked patient's slot stays protected; a walk-in is slotted into a genuine gap rather than triggering an argument about who was actually first.
The queue itself shows on a waiting-area display, refreshes as the doctor calls the next token, and can push an SMS or WhatsApp update to a patient's phone when their number is getting close, so people waiting outside for their turn are not glued to a screen inside the building. If a doctor is delayed, the queue reflects that immediately instead of staying frozen on whatever number it last showed.
ABHA-linked registration at the desk
India's Ayushman Bharat Digital Mission already gives most returning patients an ABHA number, a digital health ID that can carry their basic details and consented health records across providers. OneCity's OPD registration screen can scan a patient's ABHA QR code and pull their demographic details directly, instead of a receptionist retyping a name, age and phone number the patient has already given to some other hospital or clinic. Linkage is optional at the desk, exactly as ABDM itself treats it nationally; a patient without an ABHA number is registered normally and can link one later if they choose to.
This matters more than it sounds. Every manually retyped registration is a chance for a misspelt name or a wrong digit in a phone number, and those small errors are what make a patient's record hard to find six months later when they come back with a follow-up complaint. Hospitals that are also weighing a fuller ABDM and ABHA integration across the rest of their systems will find the OPD desk is usually the first place patients actually interact with it.
What this actually looks like for a patient
A patient arrives, and the front desk scans their ABHA QR code or looks them up by phone number if they do not have one handy. Registration takes the visit reason and issues a token in under a minute, whether this is a walk-in or the patient had booked online the night before. The token appears on the waiting-area display immediately, in the correct position relative to whoever is already in the queue for that doctor. The patient is free to sit down, step outside for a phone call, or wait in the pharmacy queue next door, because the system texts or WhatsApps them once their token is within a few places of being called, instead of requiring them to watch a screen the entire time. When the doctor calls the next token, the display updates, the nurse's station shows the same patient details the front desk captured, and the consultation starts without the patient repeating their name and complaint for the third time that morning.
After the consultation, the token closes and the visit becomes a record in the patient's file rather than disappearing once the queue moves on. If the doctor books a follow-up, that follow-up appointment is what generates the next token when the patient returns, keeping the whole visit history, from token to consultation to follow-up, inside one system instead of scattered across a register, a diary and a doctor's memory.
Doctor-wise scheduling that handles the real calendar
Each doctor's OPD schedule sets consultation slots, break windows, and leave days, and the queue respects all three automatically instead of a receptionist having to remember which doctor is off on a given Thursday. Multi-department hospitals run separate queues per department, each visible on its own display, so a cardiology patient is not watching the general medicine queue count down and wondering why their token never moves. Departments can share a common registration desk while keeping their queues entirely separate downstream.
For hospitals running telemedicine sessions alongside in-person OPD hours, the same doctor-wise schedule that manages the physical queue can flag which slots are video consultations, so a patient booking online sees only the slots that are actually available in the mode they want. See our telemedicine software page for how that side works when a hospital runs both models together.
Handling the conflicts a real OPD actually has
A doctor-wise queue only earns its keep once it can handle the situations that break a naive first-come-first-served list. A pre-booked patient arriving five minutes before their slot should not lose their place to a walk-in who arrived a moment earlier; the system protects booked slots as reserved positions in the queue rather than treating them as a suggestion. Senior citizens and emergency cases need a priority path that moves them ahead without the rest of the queue feeling arbitrarily reshuffled, so priority tokens are visibly marked as such on the display rather than simply jumping the line with no explanation. And when a doctor is called away mid-session for a procedure or an emergency, the queue can be paused and resumed cleanly, with waiting patients shown an updated status instead of a token count that silently stops moving and leaves everyone guessing whether the doctor left for the day.
None of these are edge cases in a real OPD. They are the normal Tuesday morning, and a queue system that only works when nothing goes wrong is not actually solving the problem hospitals have.
What administrators see that they could not see before
Every token, wait time and no-show is a data point the paper register never captured in a usable form. Administrators get a daily view of patient footfall by department and by doctor, average wait time from token issue to consultation, and how many booked patients simply did not show up, broken down by department so a consistently overbooked doctor's schedule can actually be adjusted instead of guessed at. Over a longer period, this turns into a genuine planning tool: which departments need a second doctor on which days, which time slots go consistently under-used, and whether a new doctor's schedule is actually being filled the way it was designed to be. None of this requires a separate reporting system or a manual tally at the end of the month; it is a byproduct of the queue already running.
Where this connects to compliance, not just convenience
The 2017 amendment to Karnataka's KPME Act requires hospitals to display rates, registration numbers and the treating doctor's details on a physical board at the premises. OneCity's queue display can mirror that same information on the digital screen patients are already looking at while they wait, which reinforces the statutory board rather than replacing it. The board still has to be physically installed; the digital display just makes sure the same information is genuinely visible, not buried on a wall patients rarely look at. Our full guide to KPME registration in Karnataka covers the display-board rule and the rest of the documentation in detail.
On the data side, every hospital that registers with the Health Facility Registry under ABDM is expected to be discoverable and, where the facility chooses to integrate further, to exchange patient records with consent. An OPD desk that already captures ABHA-linked registrations is a shorter path to that integration than one starting from a paper register.
Why this matters more for tier-2 and tier-3 hospitals specifically
A large metro hospital can sometimes absorb OPD chaos with sheer headcount: more reception staff, more nurses relaying updates, more people to smooth over the gaps a manual system leaves. A 50 to 150-bed hospital in a smaller city rarely has that spare capacity. One overloaded reception desk on a busy morning becomes the entire patient experience for that day, and a bad first twenty minutes at the front desk colours how a patient feels about the rest of their visit, including the parts the hospital actually did well. We go into this in more depth in our guide to choosing hospital ERP for tier-2 and tier-3 hospitals, where OPD is consistently one of the first modules hospitals ask to fix.
How it compares to a booking-only tool
Consumer appointment platforms are built to solve discovery: helping a patient find a doctor and book a slot from outside the hospital. That is a real problem and a different one from what happens once the patient is standing at the OPD desk. A booking platform generally cannot see the walk-in patient standing in the waiting area, cannot merge that patient into the same live queue as someone who booked online, and has no view into the hospital's own registration or clinical records once the appointment is made. OneCity's OPD module is built from the reception desk outward, not from a search results page inward, which is the core difference worth understanding before treating the two as interchangeable. Our detailed comparison against Practo goes through this distinction feature by feature.
What happens after the token closes
A queue system that stops at the consultation room door is only solving half the problem tier-2 and tier-3 hospitals actually have. Once a doctor sees a patient, the visit needs to flow into whatever happens next, a prescription, a lab order, a referral to another department, without the patient walking to a second desk and repeating their details a third time. OneCity's OPD module hands the closed token directly into the patient's visit record, so a prescription written during that consultation is immediately visible to the pharmacy counter, and a lab order raised at the same time reaches the laboratory desk without a paper slip changing hands. This is what separates an OPD queue tool from an OPD system: the queue is the front door, not the whole building, and it only earns its value if what happens inside connects back to it.
For hospitals running multiple departments, this connection also means a patient referred from general medicine to cardiology mid-visit gets a new token in the cardiology queue automatically, generated from the referral itself rather than requiring the patient to walk back to the main registration desk and start over. The queue stays accurate because it is generated from actual clinical events, not from a receptionist manually re-entering a patient who technically never left the building.
What rollout actually looks like
A single-department OPD with one or two doctors can be live within days: registration screen, token display and doctor login configured, with a short session for reception staff on the new flow. A multi-specialty hospital with several departments and an existing patient database takes longer, mainly because of data migration from whatever paper or spreadsheet system is currently in use, and because each department's schedule, break pattern and queue rule needs to be set up individually rather than assumed to be identical across departments. Our implementation and migration services page covers how that data migration and staff training is actually sequenced for hospitals moving off a paper register or an older system.
Built for a waiting room, not a browser tab
Most patients in a tier-2 or tier-3 hospital's waiting area are reading the display in Kannada, Hindi, or whichever language they are most comfortable in, not necessarily English, and the queue display supports that directly rather than forcing every patient to interpret an English-only screen. Token numbers and doctor names render large enough to read from across a waiting room, not scaled for a desktop monitor a patient will never sit in front of. And because the display only needs a screen and a network connection, hospitals do not need to install specialised waiting-room hardware to get it running; a standard television or monitor already mounted in the OPD area is normally enough.
Frequently asked questions
Does OPD queue software replace my reception desk staff?
No. It removes the guesswork from what your reception staff already do: manually calling out tokens, telling walk-ins to wait, and cross-checking which doctor is free. The queue display and SMS or WhatsApp alerts handle the repetitive part so staff can focus on patients who need help at the desk, not the ones who are fine waiting for their number.
Can walk-in patients and pre-booked appointments share the same queue?
Yes. The system blends both into one doctor-wise queue rather than running two separate lists, so a pre-booked patient's slot is protected while walk-ins are slotted into genuine gaps instead of causing a queue-jump dispute at the desk.
Is ABHA linkage mandatory to use the OPD module?
No, ABHA linkage is optional per patient, matching how ABDM itself works nationally. A patient without an ABHA number can still register and be queued normally; the option to scan and link is offered at the desk, not forced.
Does the display board satisfy KPME's rate-display requirement?
The queue display can show the same rate and registration information the 2017 KPME amendment requires on a physical board, but the statutory board itself still has to be physically installed and visible at the premises. The two are complementary, not a substitute for each other. See our KPME registration guide for the full display-board rule.
How long does OPD queue software take to go live in a working hospital?
It depends on doctor count, department structure and whether patient data is migrating from a paper register or another system. A single-department OPD can be live within days; a multi-specialty hospital with several departments typically needs a short, planned rollout rather than a same-day switch.