The Queue Number Is the problem: introducing vitalpass

so what's the issue?

Has your Clinical Exam taken you almost the whole day? Four hours waiting in a chair. A nurse fielding complaints from a dozen people at once, getting blamed for a clinic that can’t finish on time. Most of that cost comes from the queuing. Because a traditional system doesn’t know much about the patient. It doesn’t know you’re pregnant and may require a different clinical workflow. It doesn’t know you’ve been fasting since 8PM and that your exam package requires blood extraction before you eat. A clinical exam isn’t one service. It’s a sequence of services. And when that sequence looks the same for everyone, stations pile up; patients bunch at one station while another sits idle. This is why we built VitalPass. Instead of a single queue number, VitalPass personalizes the station route for each patient based on their package, relevant patient information, and standard station prerequisites. Piled up station? VitalPass can offer a reroute - while keeping the patient within their required workflow. It offers. It never forces. The patient understands their own situation better than any prediction does. VitalPass doesn’t just hand you a number. It accommodates each patient personally.

WHats the solutions? Every patient gets their own route

When a patient registers, VitalPass does not put them in a line. It generates a path — an ordered, personal sequence of exactly the stations that patient needs. That path is produced by three filters, applied in sequence, and the order they run in matters. First, eligibility. The patient's package determines which stations they are entitled to. A basic package has no X-ray, so X-ray never enters consideration. This is a business rule, and it is settled before any clinical thinking begins. Second, clinical modifiers. This is where the path becomes medical rather than administrative. Two rules run today, both drawn from clinic interviews rather than invented: a pregnant patient skips X-ray, and a fasting or diabetic patient has blood extraction prioritised. The detail worth pausing on is what happens to the skipped station. It is not deleted. It is recorded as waived, reason: pregnancy, and it stays in the record. A station that is missing and a station that was deliberately skipped are different clinical facts, and a chart that cannot tell them apart is a chart that cannot be trusted six months later when someone asks why there was no X-ray. Third, ordering. With the right set of stations established, VitalPass sorts them using Kahn's algorithm — a topological sort over the dependency graph. Registration first. The labs in any order among themselves, because they do not depend on each other. The physician's exam only once every lab it depends on is complete. The certificate last. The sort is deterministic by design: when several stations are simultaneously available, the tie is broken consistently, so the same patient with the same package always receives the identical path. Two patients in the same situation are never routed differently for no reason, and when something does go wrong it reproduces. If the station configuration ever contains a circular dependency — A waiting on B while B waits on A — the system refuses to produce a path at all and fails loudly, naming the stations involved. This is deliberate. A cycle means the configuration is corrupt, and quietly emitting some path would mean sending a patient to a station they are not ready for. Refusing is the safer failure. The summary a clinic administrator actually needs: what is this patient allowed to do, what should they medically do, and in what order can it actually be done.

The path is not fixed — this is the part that matters

A route computed at registration is correct for about ten minutes. Then the floor changes: a station gets slow, a walk-in surge arrives, a technician steps away. A static plan degrades into the same jam it was meant to prevent. So VitalPass re-evaluates. Every time a staff member completes a station, the system reconsiders every waiting patient and asks whether there is a better next step available right now. It only makes an offer when four conditions all hold. Has the patient settled? A cooldown prevents constant re-routing — three minutes for patients with normal mobility, six for assisted, ten for slow. Those numbers came from clinic interviews. Someone with reduced mobility needs longer, both to physically get there and to avoid being pinged while still walking to the last place they were sent. Is there anywhere to go? At least two eligible stations must exist, or there is no choice to offer. And a patient currently being served is never a candidate, regardless of how attractive the arithmetic looks. You can move someone who is waiting. You do not pull someone out of a blood draw. Is the gain worth the walk? The predicted saving must exceed five minutes. Wait time is estimated as queue length divided by staff capacity, multiplied by the rolling average service time at that station. Below the five-minute floor, staying put wins — sending a patient across a clinic to save two minutes is a net loss, and the walk itself is time the model does not even count. Is it still safe? A final check confirms the destination's prerequisites are met. This check is redundant; the eligibility filter already guaranteed it. It exists anyway, fail-closed, so that if a future change ever breaks the earlier filter, the system refuses rather than routes a patient somewhere they are not ready for. Redundant code that protects a patient is inexpensive insurance. When all four pass, the patient receives an offer — not an instruction. They can accept or decline, and it expires in five minutes. That choice is deliberate and worth stating plainly. The prediction is an estimate. The patient knows things the system does not, such as already being halfway to the station in question. And a system that forces people around a clinic based on a forecast loses their trust the first time the forecast is wrong. VitalPass suggests. The patient decides

What the staff and the administrator see

For staff, the ambiguity disappears. Each station has its own queue showing who is next, who is being served, and who is waiting, with each patient's mode marked — walk-in or corporate campaign. A patient arrives, staff scan their QR code, and the patient's profile opens with their information and the option to serve them at their current station. No paper, no asking which line they came from. For the administrator, the floor becomes legible. Live queue depth per station, throughput, average service time, completion rate, and station utilisation — all visible at once, filterable by any date range. The value is not the dashboard itself; it is knowing that X-ray has been the bottleneck every Tuesday for a month, which is a staffing decision no one could previously see well enough to make.

Corporate exam days, without the spreadsheet

Company physicals are where a queue-number system suffers most: fifty employees arriving in one morning, all needing the same package. VitalPass handles the batch as a campaign. HR's employee roster uploads as a CSV. Each employee receives a secure magic-link invitation by email — the link itself is the credential, so there are no default passwords to distribute or reset. As employees redeem invitations, the campaign shows exactly who has enrolled and who has not. Crucially, corporate patients occupy their own queue lane at each station. A company patient's routing decisions are calculated against their own campaign's queue, not the shared walk-in pool — so a busy walk-in line does not distort routing for a corporate group being processed alongside it. At the end, each patient's medical certificate is issued with a verification code and a QR code. An employer can confirm a certificate is genuine by scanning it, without needing access to any medical record. The certificate proves itself.

Built for records that have to hold up

Clinical software is judged on a standard ordinary software is not: someone may need to reconstruct what happened, and when, long after everyone has forgotten. Patient records are encrypted at rest with AES-256 authenticated encryption. The keys live in the server environment, never in the database — so a stolen database dump, on its own, is unreadable. Passwords use Argon2id, deliberately slow and memory-hard, so a leaked credential table cannot be brute-forced at scale. Encrypted data normally cannot be searched, which would make login impossible. VitalPass solves this with a keyed fingerprint stored alongside each encrypted email — the same email always produces the same fingerprint, making lookup instant, but the fingerprint is one-way and keyed with a server-side secret. Without that key, an attacker holding the database cannot test guessed addresses against it. Access is role-based across four fixed roles — patient, staff, admin, super admin — enforced both in the application and by a constraint in the database itself, so an invalid role cannot be written by any path. An administrator can create staff accounts but cannot create or promote another administrator, which caps what a compromised admin account can do. Every action writes to an audit log where each entry carries a cryptographic fingerprint of the entry before it. Alter or remove an entry and every subsequent one fails verification. The precise claim is tamper-evident, not tamper-proof: the goal of an audit log is not to be impossible to touch, but to make it impossible to touch quietly. For a clinic that is the property that matters, because the realistic risk is not an outsider breaking in — it is a record being adjusted after the fact. Accounts are deactivated, never deleted. Clinical records cannot be orphaned, and the audit log's structure enforces this at the database level: a user with history cannot be removed. Under the Data Privacy Act of 2012, the clinic — not the software vendor — is the party answerable for patient data. VitalPass is built to give a clinic the technical controls that responsibility requires.

Why rules, and not AI

The obvious question about routing software in 2026 is why none of this uses machine learning. The answer is deliberate. Machine learning needs training data from a clinic already operating this way, which is a chicken-and-egg problem at the outset. More importantly, medical routing has to be explainable. When a patient asks why they were sent to X-ray before blood extraction, VitalPass points at the exact rule. A model reporting 0.87 confidence cannot be defended to a physician, cannot be audited, and cannot be corrected by a clinic that disagrees with it. The rules in VitalPass came from clinic interviews and a doctor-validated dependency topology. Every decision traces back to a human decision. Machine learning is a reasonable direction once real operational data exists — but as a starting point it would trade accountability for sophistication that cannot yet be justified.

Where it stands

VitalPass is live at vitalpassph.xyz, deployed on AWS with a managed PostgreSQL database via supabase. It was nominated Best Thesis at its capstone defense. It has been load-tested at fifty concurrent sessions with page loads holding under three seconds. What has not been done — and should be said plainly — is a controlled study measuring actual end-to-end wait-time reduction in a working clinic. The mechanism is demonstrable: the system identifies shorter queues and moves patients to them. Quantifying the hours that saves across a real exam day is the next study, not a claim to make yet. The wager underneath all of it is simple. An annual physical is not a line. It is a set of tasks with dependencies, exceptions, and a floor that changes by the minute — and the reason exam day fe