Scheduling

The solver evaluates provider availability, exam-room availability, MA capacity, and equipment dependencies (BP machine, otoscope, ECG) at minute resolution. It returns the three best feasible windows and explains why other windows were rejected — room conflict, MA overload, lunch block. The agent picks 2:14 pm; the visit is booked across all needed resources atomically.

"Established Adult Office Visit" is defined as: Check-in (3 min, FrontDesk) → Waiting (0–5 min, WaitingRoom) → Rooming/Vitals (7 min, MA + ExamRoom) → Provider Eval (18 min, Provider + ExamRoom) → Nurse Follow-up (5 min, RN) → Checkout (4 min, FrontDesk). Stages are first-class objects; the same exam room is held across rooming + provider stages; the MA is released after rooming. Practices configure their own stage compositions.

An established patient opens the Patient Portal, picks "Annual Physical with Dr. Lee," and sees the next ten resource-feasible openings filtered by network and self-scheduling policy. They book; an eligibility check fires automatically, a confirmation goes out by SMS (TCPA-compliant opt-in), and a Good Faith Estimate appears if the patient is self-pay.

See the spec & demo: Patient Portal module · Patient demo dashboard · Self-scheduling demo flow

A walk-in with acute symptoms enters a triage priority and complaint type. The scheduler searches the next 90 minutes for the smallest insertable window that does not push any booked patient past the committed wait-time SLA. If a slot is found, the walk-in is booked; if not, the system offers a same-day telehealth slot or next-morning option.

A 9:00 am no-show is auto-detected at the 10-minute mark. The slot is released, and the waitlist is queried for matching patients (same provider, similar visit type, opted-in to short-notice). The top match receives a 5-minute SMS offer. If accepted, the slot is rebooked and eligibility runs automatically.

A live status board shows who is roomed, who is waiting, and who is over scheduled time — updated within 2 seconds of any stage transition. Display-mode supports back-office wall screens so the whole team stays coordinated.

An encounter chain is a sequence of related appointments that must occur in a defined order — for example, new-patient intake → follow-up in 2 weeks → annual physical in 6 months. Each chain carries chain rules: minimum and maximum intervals between steps, required ordering, and recurrence patterns (e.g., quarterly A1c checks for diabetics). When a visit in the chain completes, the scheduler auto-suggests the next appointment in the sequence at a resource-feasible time that respects the interval constraint. The patient and provider see the full chain timeline — not just the next slot — so care gaps are visible before they happen.

Chains are configured per VisitType in the stage composer. A practice can define a "New Patient Comprehensive" chain as: Step 1 — 45-min intake, Step 2 — 20-min follow-up within 14 days, Step 3 — 30-min annual wellness within 6 months. The solver respects chain rules alongside resource constraints, so the suggested follow-up is both clinically appropriate and operationally feasible.

A minute-resolution grid showing every provider, room, and MA across the day — the visual surface behind the solver's placement decisions. Each row is a resource; each column is a time increment (configurable from 1 to 15 minutes). Booked stages render as colored blocks labeled by patient and VisitType; gaps render as open windows. The grid shows the practice's day as a graph of resources, not a provider calendar — so the front desk can see that Room 3 is empty while Dr. M is between patients, and the MA is free to room the next visit.

Resources are graphed and optimized: the solver places each encounter chain on the grid to minimize provider idle time and room turnover gaps. The result is a packed day where the provider walks into a roomed patient every time. Staff can drag-and-drop reschedule within the day view — moving a block from 10:20 to 10:40, for example — and the solver re-validates resource conflicts in real time. If the move would double-book a room or overload an MA, the drop is rejected with an explanation; if an adjacent block shifts to accommodate, the cascade is shown before confirmation.