Waitlist Notification

PRD: Waitlist Notification & Prioritization System

1. Overview

The Waitlist Notification & Prioritization System is a new feature within our Electronic Health Record (EHR) system’s waitlist management functionality. Its primary purpose is to streamline the process of notifying patients on the waitlist when an appointment slot becomes available and to apply a prioritization mechanism to identify the most suitable candidates for the slot. This system aims to enhance operational efficiency and improve patient access to care.

Value Proposition

2. Problem Statement

Currently, notifying waitlisted patients about last-minute openings is a manual and time-consuming process. Front desk staff often have to call or email patients one by one when a cancellation occurs, leading to delays and sometimes leaving open slots unfilled. Without an organized priority mechanism, staff might not know which patient should be offered the slot first, resulting in potential confusion or perceived unfairness. The lack of prioritization can cause inefficient scheduling (e.g., less urgent cases taking slots over more urgent ones) and patient dissatisfaction (patients feeling the waitlist is not managed transparently). Therefore, a system that automates notifications and enforces a clear priority order is necessary to fill vacant appointments quickly and fairly, maximizing clinic utilization and enhancing patient trust in the waitlist process.

3. User Personas & Use Cases

User Personas

1. Front Desk Staff (Scheduler): The primary user managing day-to-day scheduling. They add patients to the waitlist, monitor notifications of openings, and confirm appointments. Their goal is to efficiently fill cancellations and keep the schedule full.

2. Scheduling Manager: Oversees appointment utilization and policy. Interested in configuring prioritization rules (e.g., urgency vs. first-come-first-serve) and monitoring metrics like how many slots are filled via the waitlist. They ensure the system meets clinic policies.

3. Patient: An individual waiting for an earlier appointment. Patients want a simple way to join the waitlist and timely notifications when a slot opens. They value fairness (knowing their place in line or priority) and a quick, easy way to accept an offered slot.

Primary Use Cases

1. Automatic Slot Notification: A patient cancels their appointment, creating an open slot. The system detects this availability and immediately identifies waitlisted patients who match the slot criteria (e.g., same provider or service). It then alerts the front desk via a dashboard notification and prepares notifications (email/SMS) to inform the relevant waitlisted patients of the opening.

2. Patient Accepts an Offered Slot: A waitlisted patient receives an SMS/email about an available appointment. They click a link to accept the new time. The system marks them as confirmed, books the appointment in the scheduler, and automatically removes them from the waitlist. Other patients are notified (or see via a status) that the slot is no longer available.

3. Priority-based Offer (Urgent Case): A high-priority patient (e.g., someone with an urgent medical need) is placed on the waitlist with a priority flag. When any earlier slot opens, the system highlights this patient to the front desk as the top candidate. The front desk can then immediately contact this patient or let the system send a notification to them first, before notifying others.

4. Manual Priority Override: A scheduling manager reviews the waitlist and manually adjusts the order due to special cases (e.g., a VIP patient or a prior cancellation reschedule is given higher priority). The system updates the priority ranking accordingly. Later, when a slot opens, the notifications follow the new priority order set by the manager, ensuring the intended patient gets first right of refusal for the opening.

4. Functional Requirements

Waitlist Notification System

1. Real-time Slot Detection: The system will monitor the appointment scheduler and detect when an appointment slot becomes available (due to cancellation or other openings) in real time.

2. Matching Waitlist Patients: Upon detecting an open slot, the system identifies all waitlisted patients who are suitable for that slot. Matching criteria may include the desired provider, appointment type/length, and availability preferences (dates/times a patient can come).

3. Staff Notification: The front desk staff receives an immediate alert or notification in their scheduling interface (e.g., a pop-up or highlighted message) indicating that a specific time slot is now free and listing the patients who match this slot.

4. Bulk Patient Notifications: The system can send out email and/or SMS notifications to one or multiple waitlisted patients about the opening. Staff can choose a mode: for example, notify patients sequentially (one at a time in priority order) or in parallel (multiple at once with first-come-first-serve response).

5. Response Handling: If notifications are sent to multiple patients simultaneously, the system handles responses on a first-come-first-serve basis. Once a patient accepts the slot, it should automatically lock the slot for that patient and gently notify others (e.g., "Sorry, the slot was taken").

6. Rate Limiting & Spam Prevention: To avoid bombarding patients, the system will implement rate limits. For example, a patient won’t receive more than X notifications within a certain timeframe. If a patient has recently been notified of an opening (or declined one), the system can either lower their priority temporarily or pause additional notifications to that patient for a short period.

7. Opt-In & Opt-Out: Ensure that only patients who have opted into the waitlist (and agreed to be contacted) are notified. Provide easy opt-out links or instructions in notifications so patients can be removed from the waitlist or stop notifications if they no longer want to receive them.

8. Audit Trail: Keep a log of notifications sent and patient responses. This helps staff track which patients were contacted, who accepted or declined, and how quickly slots are being filled.

Waitlist Prioritization Mechanism

●    Priority Framework: The system will rank waitlisted patients based on defined rules. Possible prioritization criteria include:

● The framework can combine criteria (e.g., primarily by urgency, then by waitlist time for those of the same urgency level).

Priority Score Calculation Formula: Priority Score = (0.4 Urgency Score) + (0.3 Wait Time Score) + (0.2 Cancellation Bonus) + (0.1 Provider Preference Score)

● Dynamic Reordering & Manual Adjustments: Front desk staff or managers can manually adjust a patient's priority. For example, they could drag-and-drop a patient to a higher position on the waitlist or mark someone as "VIP". The system will respect these manual overrides while still applying the standard rules to others.

●    Sorting & Filtering: The waitlist view in the interface will allow staff to sort entries by priority, wait time, or other attributes. Filters might be available (e.g., show only high-priority patients, or filter by a specific provider's waitlist).

●    Automatic Removal on Booking: Once a patient on the waitlist successfully accepts an appointment and it’s booked, the system automatically removes that patient’s entry from the waitlist. This ensures they don’t receive further notifications for other openings. If the patient had multiple waitlist requests (for different providers or days), only the relevant entry is removed.

●   Decline/No-Response Handling: If a patient declines an offered slot (or doesn’t respond within a set timeframe), the system can either keep them on the waitlist for future opportunities (maintaining their position or perhaps moving them slightly down if using first-in-line method) or mark that they were unresponsive this time. Repeated no-responses might trigger a prompt to the staff to confirm if the patient should remain on the waitlist.

●  Capacity for Multiple Waitlists: In case the clinic has separate waitlists (e.g., per provider or department), the prioritization mechanism should operate within the relevant waitlist scope. A patient only competes for priority against others waiting for the same type of appointment or provider category unless configured otherwise.

5. Technical Considerations

Data Structures

●  Patients Table: Contains patient information (name, contact details like email and phone, consent for notifications, etc.). Each patient record has a unique ID.

Example Data:

●    Appointments Table: Records all scheduled appointments. Key fields include appointment ID, patient (who is scheduled), provider, date/time, duration, status (scheduled, canceled, completed, etc.).

Example Data:

●  Waitlist Table: Stores entries for patients waiting for an appointment. Each waitlist record would include:

○       Waitlist ID (unique),

○       Patient ID (link to Patient),

○       Desired provider or service (if the patient is waiting for a specific doctor or service type),

○       Date added to waitlist,

○       Priority level or score (which can be numeric or a rank order),

○       Status of the waitlist entry (active, notified-pending-response, fulfilled, removed).

○       Maybe a field for patient availability/preferences (e.g., days or times they can come, or earliest date they want).

● ProviderPreferences/Availability: If needed, a table or fields that indicate patient preferences for certain providers or time windows. This can be part of the Waitlist entry or a separate entity linking the patient to the provider with notes.

Example Data:

● Notification Log Table: Stores each notification event sent to a patient (with fields like waitlist entry, time sent, type of message, and response/outcome). This helps in auditing and rate-limiting logic.

Example Data:

Sequence Diagram:

ER Diagram:

Data Flow:

Adding to Waitlist: A patient who wants an earlier appointment is added to the waitlist (either by front desk through the scheduling interface or by the patient via a portal). The Waitlist entry is saved with relevant details (patient, preferred provider, etc.).

Cancellation/Open Slot Event: When an appointment is canceled or an open slot is otherwise created:

1. Trigger: The scheduling system (Scheduler) emits an event or calls a function indicating a specific appointment slot is now available (including details like time, provider, duration).

2. Find Matches: The Waitlist system intercepts this trigger. It queries the Waitlist table for patients whose preferences match the open slot (e.g., anyone waiting for that provider or service, who can make that time window). It also applies the prioritization rules to rank those matched patients.

3. Notify Staff: The system generates an alert on the front end (Waitlist Management Window) showing: "Slot open on [Date/Time] with [Provider]. Waitlist matches: [Patient A (High priority), Patient B, ...]". Staff can review and confirm sending notifications or let the system handle it automatically based on pre-set rules.

4. Send Patient Notifications: Based on configuration, the system either automatically sends out notifications to the top candidate(s) or waits for staff approval. Suppose the policy is "first-come-first-serve with parallel notify to top 3 waitlist patients." In that case, it sends an email/SMS to the first 3 patients in priority order, informing them of the available slot.

5. Patient Response: The notification to patients includes a way to respond (for example, a secure link or a prompt to reply "YES" via text). When a patient accepts the offer:

○       The system immediately books that patient into the open appointment slot (creating a new Appointment entry or updating the canceled one with the new patient's ID).

○       The system sends a confirmation to that patient and updates their waitlist entry status to "fulfilled".

○       It then notifies any other patients who were alerted that the slot is no longer available (or if they try the link after it's taken, they see a polite message that they weren't fast enough this time).

6. No Response/Decline: If the top candidate declines or fails to respond within a defined timeframe (e.g., 15 minutes), the system moves to the next patient in line. This may involve sending a new notification to the next person or extending the offer to someone else automatically. The patient who did not respond remains on the waitlist (unless they explicitly decline, in which case staff might remove or mark them accordingly).

7. Completion: Once the slot is filled (or if it’s too close to appointment time and no one took it), the event is considered handled. The system would log the outcome. If still unfilled and time remains, staff might decide to call patients manually as a last resort or leave it open.

Edge Cases:

●    If multiple slots open at once (e.g., a provider cancels a whole day of appointments), the system should batch-process each available slot in a sensible order, avoiding spamming the same patient with multiple simultaneous offers. It might handle one slot at a time or group notifications by patient so each patient gets at most one offer at a time.

● If a patient is on the waitlist for multiple different appointment types or providers, the system should ensure that accepting one appointment removes them only from relevant lists. They might remain on another waitlist if applicable (unless clinic policy is one waitlist at a time per patient).

●    In case of system downtime or notification failure (e.g., SMS service is down), have a fallback procedure for staff alerts so they can make calls manually if needed.

● If a patient calls the office to accept (instead of using the link), staff should be able to manually mark them as accepted for the open slot, and the system should treat it the same way (book the appointment and remove it from the waitlist).

Key Interactions

●    Front End (UI): The scheduling calendar and waitlist management window on the staff’s application allow viewing the waitlist and any notifications. Staff can:

○       View the list of waiting patients with their priority status.

○       Adjust priorities or remove patients from the waitlist.

○       See real-time alerts when openings occur.

○       Trigger notifications (if not fully automated) with a click.

●    Back End (Server Logic): Contains the business logic for matching slots to waitlist entries and enforcing priority rules. It:

○       Listens for appointment change events (openings or cancellations).

○       Queries the database for matching waitlist entries and computes priority ordering.

○       Interfaces with the Notification service to send out messages.

○       Exposes APIs for the front end to retrieve and update waitlist information.

●    Database: Stores all persistent data (patients, waitlist entries, appointments, etc.). The back end uses it to read/write the state of the waitlist and appointments.

●    Notification Service: Could be an internal module or external service (like an email/SMS gateway). The back end calls this service to actually deliver messages to patients. It may also handle incoming responses (e.g., SMS replies or link click events).

●   External Interfaces: If patients receive a link to confirm an appointment, that link might open a lightweight web page or trigger an API call (without requiring full login) that marks their waitlist entry as accepted. That public-facing endpoint must securely verify the patient (via a token in the link or similar) and then inform the back end to book the appointment.

API structure:

6. Success Metrics

North Star Metric: Slot Fill Rate – This is the single most critical indicator of the system’s success, as it directly measures the efficiency of converting open slots into booked appointments.

7. Open Questions & Assumptions

●    Patient Availability Preferences: What level of detail will we capture for when a patient can come in? The current design assumes basic matching on provider or appointment type. We might need to allow patients to specify times or days they are available so we don’t notify someone for a time they can’t make it. This is assumed in matching but needs clarity.

●    Notification Consent & Channels: We assume patients consent to be contacted via email/SMS when they join the waitlist. We need to confirm how consent is obtained and what happens if a patient prefers one channel over another. (e.g., Some may want only a phone call, others are fine with text.)

●    Parallel vs Sequential Notification Policy: It’s assumed the system can either notify multiple patients at once or one-by-one based on configuration. An open question is which approach the clinic will use by default. This affects design: parallel notifications are faster but risk multiple people responding; sequential (first in line) is orderly but could delay filling the slot if the first person is slow to respond.

●    Integration with Existing Systems: We assume the scheduling system can provide real-time events or API hooks for cancellations. If not, we need to determine how the waitlist system will poll or get updates. Also, integration with an SMS/email service (like Twilio or SendGrid) is assumed for notifications but needs confirmation of which service and any constraints (costs, limits).

●    Handling Multiple Appointments per Patient: Can a patient be on the waitlist if they don’t have an existing appointment scheduled? (In some systems, the waitlist is only for those who already booked a later appointment and want an earlier one. In others, it could be a true standby list even without a scheduled appointment.) We assume it can handle both scenarios, but this needs to be defined in policy.

●    Manual Booking Overrides: If a front desk staff fills a slot manually (e.g., they call someone outside the system or a walk-in takes the spot), how do we sync that with the waitlist system? We may need a way for staff to mark a slot filled and remove relevant waitlist entries to avoid redundant notifications. This process is assumed to be addressed via staff training or an interface action, but details are TBD.

●    Dependencies: The project assumes that required subsystems (like the central scheduling calendar, patient database, and notification gateways) are available and reliable. Any downtime or lack of these services will directly impact the waitlist system’s functionality. We should clarify who is responsible for those systems and what constraints (e.g., message sending limits per day) might exist that the waitlist feature needs to work within.

MVP Version: