Operatory and scheduling

Executive summary

The operatory module runs the clinic’s day: chairs as schedulable resources, appointments with their clinical requirements, a live board, waitlist, recall and confirmation workflows, and a briefing for each visit. Double booking is impossible at the database level, enforced by a GiST exclusion constraint rather than by application checks. Each row has exactly one state owner, and board changes stream to every open screen.

Overview

ProductionOperate · Operatory and scheduling
Schedule people, chairs and requirements correctly, and connect each appointment to the encounter it becomes.

Pipeline

Chairs are modelled as resources (ADR 0016) with opening hours and configuration audits.
Appointments carry type requirements; availability is computed against resources, staff and requirements, with conflict alternatives offered.
A GiST exclusion constraint rejects overlapping bookings for the same resource.
The lifecycle moves appointments through confirmation, arrival and completion; changes publish on a change bus and stream to the board over server-sent events.
Waitlist, recall and confirmation workflows (ADR 0018) fill gaps and bring patients back; each visit gets a structured briefing (ADR 0019).

Data owned

Resources and configuration audits
Holds
Chairs, rooms and every change to their setup
Appointments and type requirements
Holds
Bookings and what each type needs
Waitlist, recall, confirmations
Holds
Gap-filling and return workflows
Appointment–plan step links
Holds
Which plan steps an appointment delivers

Store	Holds
Resources and configuration audits	Chairs, rooms and every change to their setup
Appointments and type requirements	Bookings and what each type needs
Waitlist, recall, confirmations	Gap-filling and return workflows
Appointment–plan step links	Which plan steps an appointment delivers

Models and engines

This module makes no model calls. Everything it computes is deterministic code.

Guardrails

Overlaps are rejected by the database, not detected after the fact.
One state owner per row (ADR 0017); board mutations are enforced server-side (ADR 0023).
Clinic opening hours and time zones are resolved by the clinic’s own clock, not the server’s.

Rollout and status

ProductionScheduling, board, lifecycle, reminders
Live board over server-sent events
PilotOperatory programme features
Enabled per clinic through rollout grants

Interfaces

Consumes
What
Accepted treatment-plan steps
Consumes
What
Clinic configuration
Emits
What
Encounters at check-in
Emits
What
Board change events
Emits
What
Reminders and recall notifications

Direction	What
Consumes	Accepted treatment-plan steps
Consumes	Clinic configuration
Emits	Encounters at check-in
Emits	Board change events
Emits	Reminders and recall notifications

Invariants

Operatory scheduling invariants
ADRs 0016–0019, 0023

SOURCE OF TRUTH

server/services/scheduling/
server/services/appointmentLifecycle.ts
server/db/schema/operatory-scheduling.ts
docs/clinical-invariants/operatory-scheduling.md