Appointment schedule from clinic constraints

Nothing here is clinical advice, and nothing here should touch identifiable patient information.

Prepare a proposed schedule without putting patient names, contact details, record numbers or clinical information into the conversation. This workflow is for clinic managers, outpatient administrators and scheduling teams who need a workable session plan for operational approval.

You will produce a dated schedule proposal, an exceptions list and a short approval note. It supports administrative planning only. It does not make clinical decisions or replace local booking, staffing or safeguarding processes.

1. Set the planning boundary

Start with one scheduling period. A week is usually easier to review than a month, particularly where clinician availability changes often.

Write down:

• Planning period: for example, Monday to Friday and the dates covered.
• Clinic scope: the service, site and sessions included.
• Schedule unit: whole sessions, appointment slots, or both.
• Decision owner: the operational lead who can approve, reject or amend the proposal.
• Fixed constraints: closures, protected meetings, room outages, staffing exclusions and mandatory breaks.
• Flexible constraints: preferred rooms, desirable templates and work that may move to another session.

Do not ask the model to infer which demand should take priority from a diagnosis, referral reason or patient history. Give it an operational priority rule instead, such as existing booked slots first, then waiting-list capacity, then reserve capacity.

2. Build four de-identified input tables

Create four small tables in a spreadsheet or document. Use a session identifier such as Tue-AM-01, rather than a clinician name if your local policy treats names as restricted information. Use roles or initials only where permitted.

Input table	Required fields	Example use
Demand	appointment type, requested slots, priority band, permitted days	identifies capacity needed
Availability	session ID, clinician role, available minutes, exclusions	identifies usable clinician time
Rooms	room ID, available sessions, equipment or access features	prevents unsuitable room allocation
Appointment rules	type, slot length, room requirement, staff requirement, buffer	turns demand into slots

Keep each row operational. For example, write new assessment, 6 requested, 30 minutes, room type A rather than any patient-level information.

Reconcile the figures before drafting. If the demand table says 18 follow-up slots are needed but the appointment rules imply 20 because of a local buffer rule, resolve that difference first. The model should not choose between conflicting source figures.

3. State the allocation rules in order

The schedule will only be defensible if the allocation order is explicit. Put your local rules into a numbered list. Use rules that an approver can check against the four tables.

A practical order is:

1. Keep fixed, already committed operational sessions in place.
2. Remove sessions where the clinician, room or required equipment is unavailable.
3. Allocate appointment types that need a specific room or staff role.
4. Allocate demand with the highest operational priority band.
5. Fill remaining capacity with eligible flexible appointment types.
6. Leave unallocated demand visible as an exception, rather than forcing it into an unsuitable slot.
7. Apply required buffers, breaks and session end times.

Name any local exceptions. For example, a room may be usable only for a particular appointment type, or a clinician may require a named support role. Do not reduce these rules to vague instructions such as “make the best use of capacity”.

4. Ask for a schedule proposal in a fixed format

Give the model the four tables, the rule order and the required output layout. File handling and available features can vary, so check the relevant guidance in the xAI documentation overview before using attachments or a particular workflow.

Use a request like this:

Prepare a proposed operational clinic schedule for [planning period].

Use only the aggregate data below. Do not infer patient information, clinical priority or missing availability. Apply the allocation rules in the stated order.

Return four sections:
1. Schedule table: date, session ID, clinician role, room ID, appointment type, slot length, number of slots, total minutes, notes.
2. Capacity summary by appointment type: requested slots, allocated slots, unallocated slots.
3. Constraint exceptions: each unmet demand, conflicting rule or missing input, with the reason.
4. Approval note: assumptions made, decisions needed and checks for the operational approver.

If a rule cannot be met, leave the demand unallocated and explain why. Do not create extra staff time, rooms or sessions.

[Paste de-identified demand, availability, rooms and appointment-rule tables]

Ask for tables, not a narrative. A table makes clashes and missing capacity easier to find. If there are many sessions, ask for one site or one service at a time, then combine the approved outputs in your local schedule document.

5. Check the proposed schedule against the source tables

Treat the first output as a draft. Check it in the scheduling team before it goes to an operational approver.

Test each schedule row:

• The session appears in the availability table.
• The clinician role is permitted for that appointment type.
• The room is available and meets the stated requirement.
• Slot count multiplied by slot length, plus any buffer, fits within available minutes.
• The appointment type is allowed on that day or session.
• No fixed exclusion, break or closure has been overwritten.

Then total the schedule by appointment type. Compare allocated slots with demand. Unallocated demand is not necessarily an error. Hidden or unexplained unallocated demand is an error.

6. Spot output that is wrong

The output is wrong when it looks tidy but breaks a source constraint. Common signs include a full session whose minutes exceed clinician availability, the same room assigned to two concurrent sessions, an appointment type placed in a room without its required feature, or demand silently disappearing from the summary.

Also look for invented assumptions. If the source tables do not say whether a room is available, the proposal should mark this as unknown. It should not treat the room as available. If the model changes your priority order, rejects an explicit rule, or uses language such as “likely suitable”, return to the input and make the rule measurable.

Use this quick review table during approval.

If you see	Check	Action
More slots than requested	demand total and duplicate session rows	remove duplicate allocation or correct demand
A room clash	room ID, date and session	move one appointment type or mark it unallocated
Excess minutes	slot length, buffers and session minutes	reduce slots or use another eligible session
Missing demand	capacity summary and exception list	add an explicit unallocated row and reason

7. Package the handover for approval

Move the checked proposal into the team’s approved schedule template. Keep the model output as a working draft, not the authoritative booking record.

Send the operational approver:

• the proposed schedule table;
• the capacity summary;
• the exceptions list, ranked by operational impact;
• the assumptions that need a decision;
• the source-table date and the person who completed the checks.

Ask for a clear outcome: approve, approve with named changes, or return for revision. Record approved changes in the local scheduling system and retain the approval record under your organisation’s process.

When the workflow does not work

Stop and rebuild the input tables if the proposal repeatedly produces clashes or unexplained gaps. The usual cause is incomplete availability, inconsistent appointment lengths, or rules stated only in free text.

If demand exceeds eligible capacity, do not ask the model to make the schedule fit. Produce the exception list, show the capacity shortfall and send it to the operational decision owner. If a source contains identifiable patient information, remove it and restart with a de-identified aggregate table.