Architecture · FS-01
Practice Operations Command Center
ARCHITECTURE · $8K–$15K PROJECT BANDPer-slot insurance eligibility checked ahead of the visit, no-show risk scored per appointment with a different response per band, a recall pipeline with money attached to it, and per-provider capacity the owner can steer during the day.
Every figure in this console is sample data, shown to demonstrate the interface. It is not real client data and not a performance claim.
The problem this is shaped around
A practice discovers an insurance problem when the patient is already in the chair, and discovers a recall leak never — because nothing counts the patients who quietly stopped coming.
How work moves through it
Stage 1
Appointment booked
Slot created against a provider's real capacity rather than a nominal column, so the schedule reflects what can actually be delivered.
Stage 2
Eligibility checked ahead
Coverage verified two days out. A denial becomes its own callout ticket that morning instead of a surprise at the front desk.
Stage 3
No-show risk scored
Each appointment carries a score. Bands get different treatment — a reminder, or a phone call — because treating a high-risk and a low-risk booking identically is the actual problem.
Human step
Front desk works the exceptions
Denials and high-risk appointments arrive as a worklist, not as a report someone has to think to open.
Stage 5
Recall pipeline surfaces daily
Patients due and overdue appear at the top of the owner view with value attached, so the leak is visible while it is still recoverable.
Gold marks a step a person takes. There is always at least one, on purpose: the system prepares and displays, a human confirms and executes. That is the rule for money movement and for anything a model extracted from a document, and it is not negotiable on a build.
Decisions taken at the schema, not retrofitted
Cancellation reasons are captured at cancel time
Asked later, nobody remembers. Captured in the moment, the pattern is readable in a weekly digest — and the pattern is what changes anything.
Risk scores are stored per appointment, not per patient
The same patient is high-risk for an 8am Monday and low-risk for a Thursday afternoon they asked for. A patient-level score throws away the variable that carries the signal.
Integration credentials belong to the client
Google, the payment processor, the bank aggregator, the messaging bot — each is registered under the client's own account and authorised by them through the provider's own flow. We never hold their password and they can revoke access at any moment without asking us. It costs an extra onboarding step and it means the client is never locked in by a credential they do not control.
One database per client, not shared tables
Each build runs in its own container against its own database with its own credentials. Isolation by table prefix inside a shared database is the mistake this replaces: it works until one missing filter in one query shows a business its competitor's numbers, and by then the whole schema depends on it.
Where it breaks, and what it does about it
Anything can be made to work on a good day. This is the list that decides whether a system survives a bad one — and the honest cost of each answer, because none of them are free.
| When this happens | The system does this | What that costs to build |
|---|---|---|
| The eligibility check returns nothing | The appointment is flagged as unverified rather than assumed covered. Unverified appears on the same worklist as a denial, because from the front desk's point of view they need the same phone call. | A third state everywhere coverage is displayed. Two-state booleans are how 'unknown' silently becomes 'yes'. |
| A reminder is sent to a wrong number | Delivery failures write back to the appointment, so the front desk sees that the reminder did not land in time to make a call. A send is not a delivery. | Requires webhook handling from the messaging provider rather than fire-and-forget sending. |
| The risk model is wrong about a patient | The score is advisory and visible, with the factors shown. Staff override it and the override is recorded, which is also how the model gets corrected. | Explainability work — a bare number nobody trusts gets ignored within a fortnight. |
What this deliberately does not do
- It is not a clinical record and does not touch clinical data. It handles the operations around the appointment.
- It does not submit claims. It catches the coverage problem before the visit so the claim is submittable.
- The no-show score is a probability, presented as one. It is never described to a patient and never used to refuse a booking.
Book an architecture scoping session
An hour on your actual operation — where the work currently queues, what gets re-keyed, which step everyone has quietly built a spreadsheet around. You leave with a diagram like the one above drawn for your stack, whether or not you build it here. Scope is written before any payment, always.
The linked walkthrough is an interactive demo, not a deployment: it runs entirely in your browser with sample data and resets when you refresh it. This page describes the architecture built when a business commissions the system — not a claim that this particular one is running anywhere. Systems are built on infrastructure we operate, and your data stays yours and is exportable on request at any time, including if you leave.
FS-01 · practice-operations