Web-Based Hospital OPD Queue Token System with Live Counter Display

A hospital outpatient department (OPD) sees hundreds of patients a day across multiple counters, yet most still run their queues on paper tokens and shouted names. Patients arrive, stand in a registration line to collect a token, then sit in a crowded hall with no sense of when their turn will come. Reception staff maintain the order in registers, doctors get interrupted by patients peeking in to ask whether it is their turn yet, and a skipped no-show can quietly stall the whole line. This project replaces that chaos with a web-based queue token system built around three roles: a patient booking view that issues numbered tokens with estimated waiting times, a staff console that runs the queue — call next, mark served, skip, recall and walk-in issue — and a live counter display board with big "Now Serving" numbers that the entire hall can read from a distance. The queue is first-come and visible to everyone, which removes the arguments about whose turn it is.

This is a built-to-order software project: the patient booking portal, staff queue console, live display board and backend are developed fresh for you.

The problem
Walk into a busy hospital OPD at 10 AM and the queue problem is visible in the corridor: patients clustered around the reception desk asking the same question, staff answering it while also writing tokens into a register, and the doctor's room door opening every few minutes for someone checking whether their number has been called. Paper token systems fail in three specific ways. First, patients have no visibility — a token number means nothing without knowing how many are ahead and how long each consultation takes, so people either hover near the counter or wander off and miss their turn. Second, the queue is fragile — a no-show who never returns leaves a gap the staff must handle by memory, and there is no clean way to recall a skipped token or reorder a late arrival. Third, nothing is recorded — at the end of the day nobody can say how long patients actually waited, which counters ran slow, or where the bottleneck was. This project treats the OPD queue as a state machine with three views of the same state: the patient books into it, the staff advances it, and the display board reflects it in real time.

1. The patient opens the booking view, enters a name and mobile number, picks a department, doctor and slot, and submits — the system issues the next token number for that department's counter (e.g. C-174 for Cardiology) and stores it at the end of the queue.
2. The token ticket shows three things: the queue position, the token currently being served at that counter, and an estimated waiting time computed as position × the average consultation time (a design-target formula, stated as an estimate, not a measured value).
3. At the reception desk, the staff console shows the live waiting queue per counter with patient names and token numbers; one click calls the next token, marks the current one served, skips a no-show, or recalls a skipped token to the front.
4. Every state change is written to the backend, which pushes it over the real-time channel so all connected views update within seconds: the staff console, the booking view's "now serving" strip, and every display board in the hall.
5. Walk-in patients who arrive without a booking are issued tokens from the same console into the same queue, so booked and walk-in patients share one fair first-come order.
6. The display board — a full-screen dark view with oversized numbers — shows "Now Serving" and "Next" per counter and is meant to run on a wall-mounted screen or TV in the waiting area.

Tech stack:

• HTML5 · CSS3 · JavaScript (patient portal, staff console, display board)
• Node.js 20 · Express (REST API backend)
• MySQL 8 (token, queue, doctor and slot persistence)
• WebSocket / Firebase Realtime (live board updates)
• Responsive CSS layout (board view designed for wall-mounted screens)
• SMS gateway integration (optional reminders add-on)
• Apache / Nginx hosting
• Git

Requirements

• A PHP/MySQL-capable host is not required here — the stack is Node.js 20 + MySQL 8, so the host must allow a long-running Node process (a small VPS or Node-capable shared host), with approximately 200 MB disk space (expected).
• A wall-mounted screen, TV or projector browser for each display board view; any modern browser in fullscreen/kiosk mode works — no special hardware.
• No SMS gateway account is needed for the base build; the optional reminders add-on requires one (e.g. a Twilio or Indian SMS-provider account, credentials supplied by the buyer).

• [Patient self-booking] Book a token from a phone or kiosk: name, mobile, department, doctor and slot. The issued ticket shows the token number, queue position, currently-serving token and an estimated wait — no registration line needed.
• [Estimated wait on every ticket] Each token carries an estimated waiting time computed as queue position × average consultation time. This is a design-target formula shown as an estimate, not a measured or guaranteed figure.
• [Staff queue console] The reception desk view for one or many counters: call next, mark served, skip a no-show, recall a skipped token, and issue walk-in tokens — all in a few clicks with per-counter stats.
• [Live counter display board] A full-screen, big-number "Now Serving" board per counter that updates automatically as the staff advances the queue, readable from across a waiting hall. The demo simulates the channel with browser-local sync; the delivered project implements it with WebSockets or Firebase.
• [Multi-counter, multi-department queues] Separate first-come queues per department counter (General Medicine, Orthopedics, Pediatrics, Cardiology in the reference build), each with its own token series, running in parallel on one backend.
• [Queue transparency panel] Before visiting, patients can see the currently-serving token and waiting count per doctor, so they can time their arrival instead of sitting in the hall for hours.
• [Optional: SMS reminders] Text-message reminders when a patient's token is approaching are an optional add-on, quoted separately — they need an SMS gateway account and are not part of the base build or the demo.
• [Future scope: multi-hospital deployment] Running the system across branches or hospitals with a central admin dashboard and cross-branch analytics is a planned extension, not part of the base project.

• Complete source code for all three views: patient booking portal, staff queue console and live display board
• Node.js/Express backend with MySQL schema (.sql) covering tokens, queues, doctors, departments and slots
• Setup and deployment guide (Node hosting, database import, display-board kiosk setup)
• Project report PDF (background, requirements, database design, queue state-machine design, screenshots)
• PPT presentation for final review
• Viva Q&A preparation document (queue data structures, state machines, WebSockets vs polling, REST API design, concurrency in token issuance)