Scheduling

No double bookings. No forgotten recalls. No silent no-shows.

The healthcare-flavored module. Same Accelerando spine — git as system of record, SQLite as projection, audit log as the database that survives every other failure — applied to the patient-access lifecycle.

Operations only. No clinical decision support, no dosing, no diagnostic algorithms. That line is deliberate: everything in this module is unregulated software. Clinical lives behind the *"for the radiologist to confirm"* gate in the radiology module.

The three views

Today's calendar — appointments for today, grouped by provider. Inline no-show / cancel actions per row.

Patients — registered patients with their reliability score and insurance card. Search by name or MRN.

Recall queue — follow-up outreach pending response, with attempt count and overdue filter.

The double-booking rule

ValidateSlot runs before the booking writes. A slot is in conflict if any existing non-cancelled appointment for the same provider overlaps the proposed window. Cancelled and no-show appointments don't count — those slots are free again.

RULE double_booking_prevention {
  WHEN SchedulingContext.double_booking_detected == true
  THEN FLAG "double_booking_blocked_slot_already_occupied"
  SEVERITY critical
  PRIORITY 100
}

The validation is separate from the write so the check cannot be skipped — the executor calls slotConflicts() in src/scheduling.ts and refuses to call createAndProject on conflict.

No-show classification — the patient isn't always the failure

A no-show without a sent reminder is a process gap, not a patient compliance issue. The system tracks both, and only the *with-reminder* case dings the patient's reliability score.

| Event | Patient hit | Process flag | |---|---|---| | No-show, reminder sent | -15 | — | | No-show, no reminder | 0 | process_flag=true | | Late cancel (<24h) | -8 | — | | Arrived as scheduled | +2 | — |

The score is clamped to [0, 100]. Bands: ≥90 *reliable*, ≥75 *watch*, ≥60 *concerning*, otherwise *review* (provider-review flag fires).

Recall escalation — the scheduled follow-through

Recalls are the loss-bearing part of an operations workflow most systems forget about. Annual mammograms, post-op checks, six-month follow-ups — when these don't happen, the system doesn't fail loudly. It just stops generating revenue and stops catching downstream conditions.

The escalation ladder:

attempt 1 → wait 14d → attempt 2 → wait 21d → attempt 3 → wait 30d → escalate to provider

Any responded=true attempt closes the recall as completed. After three attempts without response, the recall flips to escalated and a provider-review flag fires — *the patient may be unreachable for non-compliance reasons.*

What's wired

| Entity | Purpose | |---|---| | Patient | MRN, demographics, insurance card, reliability score | | Provider | NPI, specialty, credentials | | Appointment | Slot booking with the double-booking guard | | NoShowRecord | Classified no-show event — with or without reminder | | RecallTask | Follow-up outreach with attempt log |

Tools (11): list_patients, register_patient, list_providers, register_provider, list_appointments, schedule_appointment, cancel_appointment, mark_no_show, list_recalls, schedule_recall, record_recall_attempt.

Why this stays unregulated

Software-as-a-Medical-Device (SaMD) is FDA's territory: clinical decision support, diagnostic algorithms, dosing calculators. None of that is here.

What *is* here:

• Slot math
• Outreach tracking
• Patient demographics + insurance card
• Reliability scoring (operational, not clinical)
• Recall escalation cadence

That's the same shape as the scheduling module of any non-FDA-regulated practice management system. The compliance surface that *does* apply — HIPAA (PHI handling), PCI (card data on the billing side) — is operational, not pre-market.

The clinical line stays in the radiology module, and even there the AI flags for the radiologist to confirm and communicate. The system flags for review; it does not auto-escalate clinical findings.