> ## Documentation Index > Fetch the complete documentation index at: https://docs.rxscale.com/llms.txt > Use this file to discover all available pages before exploring further. # Managing appointments > Review and cancel patient appointments, and manage scheduling configuration from the admin portal # Managing appointments Admins can review scheduled patient appointments and manage the scheduling configuration from the admin portal. The appointment overview is designed for support and operations teams that need to check upcoming bookings or cancel a booking on behalf of a patient or provider. ## Where to find appointments Use the global appointment overview to see bookings across your organisation. You can also open a patient profile and review that patient's appointments from the patient detail page. By default, the overview shows future active appointments. ## Filters You can filter appointments by: * Doctor * Patient * Status * Date range ## Appointment statuses * `held` means the slot is temporarily reserved but not confirmed yet. * `confirmed` means the appointment is booked. * `cancelled` means the appointment was cancelled. * `expired` means a temporary hold expired before confirmation. * `completed` means the appointment has finished. * `no_show` means the patient did not attend. ## Cancelling appointments Admins can cancel active `held` and `confirmed` appointments. A cancellation reason is required. The reason is stored with the appointment so support and operations teams can understand why the booking was cancelled. Admin cancellations are operational actions and are not limited by the patient-facing minimum notice period. Patient and partner cancellation rules remain separate. ## Booking token secrets If your organisation mints **patient booking tokens** from a partner backend (for example a Shopify storefront), each token is signed against a secret that RxScale issues to you. Manage these from your organisation settings: * **Create a secret.** RxScale returns a `key_id` (used in the JWT `kid` header) and the secret value. The value is stored encrypted at rest. Admins can reveal it again any time from the Settings → Booking secrets page, so re-pasting it into a new minter doesn't require re-provisioning. * **Revoke a secret.** Revocation is immediate. Any tokens signed by the revoked key are rejected on the next call. ### Rotating a secret 1. Create a new secret. You now have two active secrets. 2. Update your minter to sign new tokens with the new `key_id`. 3. Wait for tokens signed with the old key to expire (typically a few minutes given the short token TTL). 4. Revoke the old secret. Because each token is routed by its `kid` header, you can rotate without downtime. ## Provisioning appointment types and meeting rooms Appointment types and persistent meeting rooms are configured by the RxScale team during onboarding and on request: * **Appointment types** define duration, hold TTL, cancellation notice, and rebooking rules. * **Meeting rooms** are pre-configured per doctor (`persistent_per_provider` strategy), so the patient and the doctor always land in the same Jitsi room. Reach out to support if you need to add a new appointment type or change meeting room configuration. ## Doctor availability windows **Doctors manage their own bookable windows.** Each doctor sees an Availability page in their portal where they can add, edit, or remove weekly recurring slots that drive the patient booking page. As an admin you can review (read-only) a doctor's current windows from the doctor detail page — useful when troubleshooting why patients don't see slots, or when auditing coverage. To make changes, ask the doctor to update their own availability or coordinate with support. ## Rebooking on behalf of a patient You can move an existing appointment to a new slot from the appointment detail page. Rebooking honours the appointment type's `rebooking_mode` (same doctor vs. any doctor) and minimum notice window. Admin rebooks are recorded as a new appointment linked to the original via `previous_meeting_uid`, so the audit trail is preserved. ## Appointment reminders You configure reminders **per appointment type**. Each reminder rule has: * a recipient group — `patient`, `doctor`, or `admin`, * a `minutes_before` offset (e.g. 60 = one hour before the appointment), * `send_email` and `send_sms` toggles — when both are off, the event still publishes (partners can subscribe) but RxScale won't dispatch anything itself. You can stack multiple reminders per group, for example a doctor reminder 24h before plus a second 15 minutes before. The maintenance manager runs every minute and publishes one `APPOINTMENT_REMINDER_DUE` event per resolved recipient. Idempotency is guaranteed by an internal `appointment_reminders_sent` row so the same reminder never fires twice for the same appointment. To receive these events on your own systems, subscribe `APPOINTMENT_REMINDER_DUE` from the notification subscriptions page — the existing webhook subscription mechanism handles signing, custom headers, and retries the same way it does for prescription events. ## Doctor phone numbers for SMS reminders If your reminder rules turn on `send_sms` for the doctor recipient, RxScale needs a mobile number on the doctor's profile to deliver the SMS. Doctors can set their own number from the Settings page in the Doctor Portal; admins can also edit it on the doctor detail page (the "Mobile phone number" field, separate from the prescription phone field).