Waiting-list validation register for booking teams

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

Use this process to find waiting-list records that need an administrative action before the next booking run. It is for access teams, booking coordinators and clinic administrators who need a consistent register, not a clinical priority list.

Do not put identifiable patient information into the model. This is administrative work only, not clinical advice. Keep the link between each temporary row key and the patient record inside your approved local system.

1. Set the review boundary

Choose one clinic, service line or booking pool for each review. Do not combine different booking rules in one batch. A respiratory clinic, a diagnostics queue and a procedure list may each have different referral, contact and slot rules.

Write down the boundary at the top of your working sheet:

• Review date and queue name
• Records included, for example awaiting first appointment
• Records excluded, for example already booked, paused by service, or closed
• The local policy document and rule set being used
• The staff member responsible for applying the actions

Use the rules that were current on the review date. If a policy is unclear, flag the record for a named local decision maker. Do not ask the model to interpret clinical urgency or override a service rule.

2. Prepare a de-identified review extract

Create a temporary spreadsheet with one row per waiting-list record. Give each row an opaque review key, such as WL-001. Do not use a patient number, initials, postcode, date of birth, telephone number, free-text correspondence, or any identifier that can be traced back by the model.

Keep the mapping from WL-001 to the actual patient record outside the material you share. Remove free-text notes, since they often contain names, contact details and clinical information.

Include only the fields needed to check the administrative rules:

Field	Example values	Purpose
Review key	WL-001	Lets you apply the result locally
Queue type	new outpatient	Selects the correct rules
Wait band	0-4 weeks, 5-12 weeks, 13+ weeks	Orders operational follow-up
Latest contact outcome	confirmed, no reply, requested call back	Identifies contact work
Contact recency band	within 7 days, 8-28 days, over 28 days	Checks contact rules
Referral status	complete, missing document, expired, unclear	Identifies referral work
Booking status	slot offered, no suitable slot, not offered	Identifies booking work
Rule exceptions	interpreter needed, transport note present	Routes to a local process

3. Turn policy into explicit checks

Read the local booking policy and convert it into short, testable statements. Use administrative conditions only. For example:

• A record with referral status missing document needs referral follow-up before an appointment is offered.
• A record with no reply and contact recency over 28 days needs the next contact step in the local contact procedure.
• A record with complete referral status and not offered booking status needs a slot review.
• A record with unclear status must be checked by a coordinator, not assumed to be complete.

Avoid vague wording such as “review as needed”. State the trigger, the action and the owner. If your policy has a defined order of action, preserve it. If it does not, use a simple operational order: resolve missing referral requirements first, then required contact work, then booking availability, then data-quality checks.

4. Ask for a fixed register

Paste the rules first, then the de-identified rows. Ask for a table, not narrative commentary. This makes it easier to compare the output with the source sheet and to repeat the same review next week.

Use this prompt template:

You are checking de-identified waiting-list records for administrative action.

Apply only the booking rules below. Do not make clinical decisions, infer patient circumstances, or create facts missing from the data.

Rules:
1. [paste rule]
2. [paste rule]
3. [paste rule]

For each record, return a Markdown table with these columns:
review key | action priority | required action | rule triggered | evidence used | owner | human check needed

Use action priorities only: P1, P2, P3, or Check.
P1 means a required administrative step is overdue under the supplied rule.
P2 means an action is required but not overdue.
P3 means no immediate action, monitor at the next review.
Check means the data is unclear, conflicting, or outside the rules.

Do not include any patient identifiers. If a required field is absent, write Check and name the missing field.

Records:
[paste de-identified rows]

Available features and document handling can vary by version. Check the current guidance in the xAI documentation overview before changing a review process.

5. Check the register before using it

The output is a draft work product. Compare every P1 and every Check row against your source extract and the policy. Then sample at least several P2 and P3 rows, especially where the model has treated a blank field as meaningful.

Look for these common errors:

If you see this	Check this	Do this
A record marked P1 with no stated rule	The model may have inferred urgency	Change to Check or apply the actual rule
Complete referral but missing evidence field	The status may be stale	Verify in the approved system
No action despite an old contact band	The contact rule may be missing from the prompt	Add the rule and rerun the batch
Different actions for matching rows	A field may be inconsistent or the rules ambiguous	Standardise the fields and review the rule

6. Apply actions in the local system

Sort the checked register by action priority, then by queue type and review key. Use the local mapping to open the correct waiting-list record. Record the action in the patient administration system, not in the de-identified working sheet.

For each row, mark one of these outcomes in your local control log:

• Completed
• Sent for referral clarification
• Sent for contact follow-up
• Sent for slot review
• Escalated to coordinator
• Held pending missing information

Delete the temporary de-identified extract according to your organisation's retention process. Retain only the approved local audit record.

7. Repeat the same review cycle

Run the process on a fixed schedule that fits the queue's local rules. Keep the same fields, priority labels and output columns unless the policy changes. This makes it possible to spot recurring causes, such as incomplete referrals or records repeatedly left without a slot offer.

When the process does not work, stop using the output as a register. First check for missing policy rules, mixed queue types, unclear status values or accidental free text. Reduce the batch to a small set of de-identified test rows, correct the rule wording, and compare the revised output with a coordinator's manual review. If the rule itself is uncertain, send it to the policy owner rather than asking the model to decide.