Appointment Waitlist Clearing¶

A drain process for human waitlists — instantiates Queue Draining

Works a scheduled-access waitlist down after capacity opens up by confirming who still wants a slot, offering in a fair order, and clearing entries that can no longer be reached.

A waitlist for scheduled access — a clinic, a school placement, a subsidised-housing list — is not a passive log; every entry is a person who may have moved, been served elsewhere, or lost eligibility since they joined. Appointment Waitlist Clearing drains such a list when capacity finally opens by running an offer-and-confirm loop: it revalidates each entry, offers the freed slots in a defined fair order, and prunes the ones it cannot reach — recording a reason for each removal. Its distinguishing move is that draining here is a conversation, not a computation: an item leaves the queue only when a real person accepts, declines, or cannot be contacted, and the mechanism's whole discipline is doing that outreach fairly and legibly.

Example¶

A dermatology clinic has a 900-name waitlist that built up over a year of running one physician short. A second dermatologist is hired, opening roughly 40 slots a week. Rather than calling names off the top, the clinic runs a clearing pass. Each entry is first revalidated — an automated message asks "do you still want this appointment?" and the record is checked for anyone since seen elsewhere. Confirmed entries are then ordered by a blend of wait time and referral urgency, and offers go out in that order with a 72-hour hold. If an offer is declined or unanswered after three attempts across two channels, the slot rolls to the next name and the stale entry is marked — declined, seen elsewhere, or unreachable — rather than silently deleted.

By the end of the first month the "900-name backlog" has resolved into ≈500 people who still genuinely want care, ≈250 who no longer do, and ≈150 the clinic could not reach — a far more honest picture than the raw count, and one it can act on without stranding real patients or padding a "waitlist reduced" statistic.

How it works¶

The pass turns a static list into a served-or-disposed outcome for every entry:

Revalidate before offering. Each entry is re-contacted or re-checked for whether the person still wants the slot and still qualifies — a year-old list is full of demand already met elsewhere.
Offer in a declared order. Freed slots are offered by an explicit fairness rule (wait time, urgency, or a hybrid), not by whoever happens to answer first.
Time-box each offer. An offer holds for a set window, then rolls to the next name, so one slow responder does not stall the drain.
Prune with a reason. Entries that decline or stay unreachable after a set number of attempts are removed with a recorded disposition, keeping the clear auditable.

Tuning parameters¶

Offer-order rule — pure wait-time (maximally fair to the patient) versus urgency-weighted (serves the sickest first); the trade is procedural fairness against clinical need.
Response window — how long a single offer holds before rolling on. Short windows fill slots fast but strand people who can't answer within hours; long windows are gentler but slow the drain.
Outreach attempts before pruning — how many tries, across how many channels, before an entry is marked unreachable. More attempts are fairer to the hard-to-reach but extend the clear.
Revalidation depth — a light "still want it?" ping versus a full eligibility re-screen. Deeper catches more stale entries but adds friction for everyone.

When it helps, and when it misleads¶

It works best exactly when a list has drifted out of sync with reality — capacity just changed, and nobody knows how much of the backlog is still live demand. The pass converts a scary number into a true one and fills new capacity in a defensible order.

Its sharp failure mode is that "unreachable" is not neutral: the people hardest to contact are disproportionately those without stable phones, addresses, or the target language, so an aggressive prune can quietly shed the neediest under cover of tidying the list. The classic misuse is running the clear to hit a "waitlist reduced by N" target rather than to place people — deletions dressed up as throughput. The discipline that guards against both is recording a disposition reason for every removed entry and periodically auditing the unreachable prunes for who is being lost.

How it implements the components¶

drain_order_rule — the declared fairness sequence (wait time / urgency / hybrid) in which freed slots are offered.
validity_and_staleness_rule — the per-entry revalidation, and the criteria for marking an entry declined, served-elsewhere, or unreachable.
stakeholder_notification_policy — the outreach itself: the offer messages, the response deadline, and the redirect for those not served.

It does not create the capacity it fills — a Surge Worker Pool or a scheduled Backlog Burn-Down does that — nor does it report drain progress (Drain Dashboard) or divert items that fail processing (Dead-Letter Queue Processing).

Instantiates: Queue Draining — it drains a human waitlist down to genuine, reachable demand.
Sibling mechanisms: TTL Expiration Sweep · Surge Worker Pool · Backlog Burn-Down · Drain Dashboard · Incident Backlog Cleanup · Dead-Letter Queue Processing · Graceful Queue Shutdown · Connection Draining · Maintenance Drain · Message Queue Drain