No-show Prediction

How the model works, what it uses, live proof it works, and where it stops.

PriorAuthIQ estimates the probability that a scheduled appointment will end in a no-call/no-show so front-desk teams can intervene early. The scoring pipeline is a calibrated logistic-regression model with isotonic post-calibration; an LLM only drafts patient outreach copy and never influences the score.

1. Architecture at a glance

Two layers cooperate:

• On-write scorer. Every time an appointment is created or updated, a rules-based scorer runs in-process and stores a 0–100 risk_scoreplus the top contributing factors.
• Nightly recompute. A cron job re-scores upcoming appointments so scores reflect fresh history (recent no-shows, cancellations, reschedules) without waiting for the next edit.

2. Inputs (features)

All features are derived from data your clinic already stores. No third-party enrichment, no demographics-based proxies.

• Prior no-shows for this patient (last 12 months) — strongest signal.
• Prior late-cancels and same-day reschedules.
• Lead time between booking and appointment (very short and very long both raise risk).
• Day-of-week and hour-of-day patterns for the clinic.
• Appointment type (new patient vs. follow-up, procedure vs. consult).
• Confirmation status — whether the patient has confirmed via SMS/email.
• Distance / travel signal when a ZIP is on file (coarse bucket only).
• Insurance/auth state — pending prior-auth raises risk of last-minute cancel.

3. Output

• Risk score: integer 0–100. Higher = more likely to miss.
• Band: Low (0–39), Medium (40–69), High (70–100). High shows a red flag in the schedule.
• Top factors: up to three human-readable reasons (e.g. "2 prior no-shows", "booked 21 days out", "unconfirmed").
• Suggested action: none, reminder, or Rescue outreach.

4. Where the LLM fits

When a High-risk appointment triggers a Rescue action, an LLM (Gemini 2.5 Flash via the Lovable AI Gateway) drafts a short, patient-appropriate SMS or email using only the appointment's non-PHI-sensitive fields (first name, appointment time, clinic name, confirm link). Staff review and approve every message before it sends — the model never messages a patient autonomously and never influences the score.

5. Closing the loop: interventions & outcomes

A risk score is only useful if it changes behavior. PriorAuthIQ lets staff apply an intervention directly from the appointments table — SMS reminder, email, live phone call, reschedule offer, or waitlist rescue. Each action is stored with the predicted no-show probability at the time it was applied.

When the appointment reaches a terminal status (completed, no-show, or cancelled), the system records the actual outcome for every intervention on that appointment. The dashboard then reports the real-world show rate for each intervention type, so clinics can see which tactics actually recover revenue.

• Every outbound Rescue message requires staff approval.
• Staff can override the band on any appointment; overrides are logged.
• Feedback (actual outcome: showed / no-showed / cancelled) is written back to the appointment and feeds the next recompute.
• A daily cron job auto-applies Tier 1 SMS reminders to scheduled high-risk appointments in the next 7 days.

6. Model improvement from real outcomes

Once a clinic has ≥50 appointments with recorded outcomes, the "Train model" flow in Settings → Automation retrains the logistic-regression weights on that clinic's own data. The new weights are versioned in model_weights, evaluated against a held-out test set, and stored in model_evaluations. Predictions are persisted in model_predictions so the "Why is this risky?" dialog and the efficacy dashboard stay fast and auditable.

7. Limitations

• Not a diagnosis. The score is an operational triage signal, not a clinical judgment. Do not use it to deny care, restrict scheduling, or price services.
• Cold-start. For a brand-new patient with no history, the score leans on lead time, appointment type, and confirmation status only. Expect wider error bars in the first few visits.
• Rules-based, not learned. Weights are hand-tuned per clinic patterns. This is intentional — it keeps the model auditable and avoids training on PHI — but it will not capture subtle interactions a supervised model might.
• Data quality bounds accuracy. Missing outcomes, unrecorded cancellations, or duplicate patient records will degrade scores.
• No protected-class features. Race, ethnicity, gender, age, and payer identity are not inputs. ZIP is used only as a coarse travel-distance bucket, never as a demographic proxy.
• Drift. Seasonal or panel changes shift baselines. Review the calibration report in Settings → Analytics monthly.

8. Privacy & safety

All feature computation happens inside your clinic's tenant, gated by Postgres Row-Level Security on clinic_id. LLM prompts for Rescue drafts contain only the minimum necessary fields and are never used to train third-party models (Lovable AI Gateway contract prohibits training on customer data). Full details in the Privacy Policy.

9. Turning it off

Admins can disable risk scoring per clinic in Settings → Automation. When disabled, scores stop computing, red flags disappear from the schedule, and Rescue drafts are not offered.

10. Questions

Product: product@priorauthiq.com · Security: security@priorauthiq.com.