​

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.

​

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).