CareQueue: The Hospital Queue That Treats Intake Like a Gate, Not a Line

A Spring Boot and React system that lets patients register from home, forces receptionist approval before queue entry, and sketches out a multi-hospital SaaS model.

8 min read • View on GitHub • More from PrashantSaxena100

A hospital front desk is drawn as a physical gate between two worlds. On the left, a patient submits a form from a phone at home. In the center, a receptionist controls a lever beside a stamped ledger. On the right, the active queue board only accepts patients after approval. The image explains that self-registration is not the same as entering the live line. — CareQueue’s core idea is not a queue. It is a gate that decides when a patient becomes eligible to join one.

Key Takeaways

CareQueue’s smartest move is to encode front-desk judgment into the data model, so a patient can exist without yet entering the live queue.
The repo is really a workflow system with a queue attached, not a scheduling app with a few status fields.
Its hospitalId design points toward multi-clinic SaaS, even though the rest of the stack still reads like an alpha build.
The security shortcuts are not incidental, because in healthcare they define the line between prototype and deployable software.

The front desk is the product

CareQueue’s most interesting idea is brutally simple: a patient can register from home and still not be in line. Self-registration lands them in PENDING, and only a receptionist can promote them into WAITING. That makes the front desk a gate, not a passive inbox.

That distinction changes the whole mental model. The software is not just recording demand. It is deciding when demand becomes operational reality.

The state machine is the product. It shows how CareQueue separates intent, approval, and live queue entry.

Two intake modes, one queue

The repo’s workflow is built around two entry points. registerSelf creates a patient record without letting them cut into the active queue. registerWalkIn does the opposite: a receptionist places the patient directly into WAITING because they are already standing at the desk.

Intake path	Queue entry	Who triggers it	Typical meaning
Self-registration	Delayed until approval	Patient	Remote intake that still needs front-desk review
Walk-in registration	Immediate	Receptionist	Physical arrival that is already validated
Approval step	Moves PENDING to WAITING	Receptionist	Manual triage gate
Emergency priority	Can outrank standard order	Staff	A route for urgent cases

A split scene shows two paths converging into one queue. On one side, a walk-in patient passes directly into the active line. On the other, a self-registered patient waits behind a barrier labeled PENDING until a receptionist releases the latch. The image explains that one system supports two different rules for entering the same queue. — One queue, two entry rules. Walk-ins skip the gate. Self-registrations do not.

Hospital-first architecture

CareQueue is not organized around a single clinic. It is organized around hospitalId. That matters because it hints at a SaaS shape from the start: one deployment, many hospitals, separate records, shared code.

The repository’s entity model reinforces that idea. HospitalAdmin sits at the top, and staff and patients inherit the hospital boundary through relational links rather than separate installs. That is a practical multi-tenant pattern for a small system that wants to grow up later.

What the backend already knows how to do

The backend follows a standard Spring pattern: controllers, JPA entities, MySQL persistence, and enum-driven status changes. That is not flashy, but it is coherent. The queue logic lives where you would expect it to live, in the controller and entity layer rather than buried in a tangle of UI state.

public enum PatientStatus {
    PENDING,
    WAITING,
    COMPLETED
}

// Conceptually, the controller flow looks like this:
// self registration -> PENDING
// receptionist approval -> WAITING + doctor assignment
// visit finished -> COMPLETED

That tiny state model does a lot of work. It captures the exact moment when a request becomes an active clinic obligation, which is the whole point of the product.

The production gaps are as revealing as the features

CareQueue also reads like an alpha system, and that is useful context rather than a flaw to hide. Plaintext password checks, no JWT or OAuth2, and Hibernate schema updates in place all signal a build that is still proving the workflow before hardening the platform.

In healthcare, those shortcuts are not cosmetic. They define how far the system sits from a real deployment. The idea is strong, but the trust model still needs the hard work.

Area	CareQueue today	Production expectation
Authentication	Plaintext password comparison	Hashed passwords with token-based auth
Database management	Schema updates in place	Versioned migrations
Queue access	Manual receptionist gate	Auditable workflow with permissions
Tenant isolation	hospitalId boundaries	Clear access controls and policy enforcement
Deployment posture	Demo or educational	Compliance-aware production system

What it is competing with

CareQueue is not trying to out-feature Qmatic, Clockwise.MD, or Waitwhile. Those products are mature, proprietary, and built for broad operational coverage. CareQueue is narrower and more interesting in a different way: it is an open, workflow-first sketch of the same problem.

System	Model	Strength	Trade-off
CareQueue	Open-source clinic workflow	Transparent intake gate and simple multi-tenant shape	Early-stage security and operational maturity
Qmatic	Enterprise patient flow	Deep deployment history and broad feature set	Proprietary and heavier
Clockwise.MD	Urgent care access platform	Strong patient-facing convenience	Less open and less customizable
Waitwhile	General queue SaaS	Flexible waitlist and virtual queue tools	Not built as a clinic-specific workflow model

That makes the repo valuable even if it never becomes a large product. It shows one clean idea: the front desk is not just where patients wait. It is where the system decides what waiting means.

Why CareQueue matters

CareQueue matters because it turns a messy human ritual into software rules without flattening the ritual itself. Patients can arrive remotely, staff can still make a judgment call, and the live queue stays under control. That is the right abstraction for clinic software.

The repo is strongest when you read it as an argument. A good healthcare system does not merely count people. It governs access, preserves context, and makes the handoff from intent to care explicit.