Recall & Recurring Visit Program

Some care only works on a schedule. A quarterly lab that has to land inside a window. An injection given every eight weeks, where a late dose is a clinical problem and not just an inconvenience. A six-month recheck, a device follow-up, a monitoring panel tied to an ongoing therapy. In every one of these the practice has already done the hard part (the patient is enrolled, consented, authorized and committed) and the remaining job is purely operational: get them back on time, every time, for as long as the program runs.

Almost no practice has a system for that job. What exists instead is a recall list that is really three things pretending to be one: a report someone runs from the clinical system when they remember, a spreadsheet a nurse keeps because the report is not trustworthy, and the personal memory of whichever staff member has been there longest. Patients leave the visit with "call us in three months," which transfers the scheduling burden to the person least equipped to carry it. Nobody books the next visit at checkout because checkout is the busiest ninety seconds in the building. The due date arrives, nothing fires, and the patient drifts.

The drift is where the money and the clinical outcome both go. A patient who misses one dose in a series is far more likely to miss the next one, and a patient who is four months past a quarterly draw usually does not come back at month five. They come back never, or they come back somewhere else, or they come back when something has gone wrong. The practice sees a soft schedule and blames demand. What is actually happening is a retention failure inside an already-won patient population, invisible because nothing in the stack knows the difference between a patient who is on cadence, a patient who is due, and a patient who lapsed six weeks ago. This build makes those three states explicit, computes them every day, and attaches a worked outreach path to each one.

Pipeline: Recall & Series Adherence

One card per patient per program enrollment, not one card per visit. The card persists for the life of the program and moves between states as the cadence clock turns. A patient in two programs has two cards, each with its own clock.

• Enrolled: Cadence Set: program, interval and tolerance window written; the first next_due_date computed.
• Next Visit Booked: a future appointment exists on the right calendar inside the due window. This is the healthy resting state and most cards should live here.
• Due Window Open: Unbooked: the window has opened and there is no booking. The card is now on the daily recall worklist.
• Recall Outreach Active: the outreach ladder is running on this card.
• Readiness Hold: the patient wants to come but something upstream is not ready: authorization expired, order not placed, supply not on hand. Held deliberately rather than silently failing.
• Rebooked: outreach worked; a new appointment exists. Returns to Next Visit Booked once confirmed.
• Overdue: past the window close, tiered by days_overdue.
• Lapsed: Re-engagement: past the lapse threshold the practice sets per program; worked by a slower, more human campaign.
• Reactivated: a lapsed patient returned and completed a visit. Cadence clock restarts.
• Program Complete: the series finished as designed. A positive terminal state, counted separately from everything else.
• Withdrawn / Closed: patient declined, transferred care, moved, or the clinician ended the program. Always closed with a captured reason.

Second pipeline: Visit Readiness

Advanced programs fail on logistics as often as on patient behavior, so readiness gets its own short pipeline that runs ahead of each booked visit: Readiness Due → Auth Checked → Order Placed → Supply Confirmed → Ready, with a Blocked lane that notifies a named owner. A visit that reaches its date without passing through Ready is a visit that wastes the patient's trip.

Calendars

• Series Visit: one calendar per program, short slot length, nurse-staffed where the visit does not require a provider. Separating this from provider calendars is what makes same-week rebooking possible.
• Lab Draw: high-volume short slots, early-morning weighted for fasting draws, with a per-day cap matched to actual draw capacity.
• Program Follow-Up: provider slots for the periodic review visits a program requires on a different cadence than its routine visits.
• Telehealth Check-In: for the interim touchpoints that do not need a body in the building, which keeps the in-person calendar for visits that must be in person.
• Recall Call Block: staff-facing. Two protected blocks a day where the named recall owner works the worklist. Without this block the recall list is a document nobody reads.
• Checkout Booking Desk: optional but powerful: a staff calendar representing the person whose entire job during clinic hours is booking next visits at checkout.

Custom fields

This build lives or dies on these fields. Every workflow below reads them, so name them exactly once and never improvise a variant.

• Program definition: program_code (a short internal code, not a clinical name: see the PHI note below), program_enrollment_date, cadence_interval_days, cadence_tolerance_early_days, cadence_tolerance_late_days, visits_in_series_total, visit_sequence_number, program_owner_clinician
• Cadence clock: last_completed_visit_date, next_due_date, due_window_open_date, due_window_close_date, next_visit_booked_datetime, booked_at_prior_visit (switch. The single most important adherence lever in the build), days_until_due, days_overdue
• Adherence state: adherence_status (on cadence, due, overdue, lapsed, complete, withdrawn), lapse_tier (none, 30, 60, 90, 180), on_time_visit_count, late_visit_count, missed_visit_count, longest_gap_days
• Readiness: authorization_required, authorization_status, authorization_expires_date, order_status, supply_confirmed, readiness_blocked_reason, readiness_owner
• Outreach: assigned_recall_owner, recall_attempt_count, recall_last_attempt_date, recall_last_channel, preferred_recall_channel, best_time_to_reach, barrier_reason (schedule, transport, cost, childcare, work, moved, wants different location, other: logistical categories only), reengagement_outcome, withdraw_reason
• Consent and contact: sms_consent, sms_consent_timestamp, email_consent, mail_consent, ok_to_leave_voicemail, ok_to_contact_alternate, alternate_contact_name, communication_consent_signed

Tags

• State: program-active, due-now, overdue-30, overdue-60, overdue-90, lapsed, reactivated, series-complete
• Risk flags: no-book-at-checkout (applied whenever a patient leaves without a next visit. The leading indicator of lapse), two-late-in-a-row, prior-lapse
• Readiness: auth-pending, auth-expiring, order-needed, supply-hold
• Handling: call-only, voicemail-ok, no-voicemail, mail-only, interpreter-needed, needs-human-now

Forms and surveys

• Program Enrollment & Communication Consent: captures the cadence the clinician set, the patient's preferred recall channel, whether voicemail may be left, whether an alternate contact may be used and who, and separate SMS, email and mail consents. This is the form that makes everything downstream defensible.
• Recall Preferences: a short standing-preferences form the patient can update at any time: best time to reach, channel, location preference. Keeping it patient-editable is cheaper than discovering the preference by failing.
• Barrier Survey: sent only to overdue and lapsed patients, offering logistical options only: hard to get here, cost concern, work schedule, childcare, I moved, I prefer another location, I would rather talk to someone. Any free-text reply is routed to a human and never parsed by an automation, because a patient answering that question may volunteer clinical detail.
• Withdrawal / Decline: an internal form so the card closes with a real reason instead of going quiet.

BO's role and guardrails

BO runs the high-volume, low-stakes end of recall: confirming, rescheduling, and answering "when am I due." BO's constraint in this build is tighter than in intake, because a recall message can disclose a condition simply by naming the program.

• BO does: confirm or move a booked visit, offer open slots from the correct program calendar, capture preferred_recall_channel and best_time_to_reach, record a logistical barrier_reason from the fixed list, and tell the patient a human will call when the answer is not logistical.
• BO never: names the program, the medication, the lab, the condition or the body system in any message; explains why the visit matters clinically; discusses what happens if a dose is late; interprets a result; or quotes cost. The permitted phrasing is "your next scheduled visit with {{clinician}}" and nothing more specific.
• Hard escalation triggers: any clinical question, any mention of symptoms or a reaction, any request for results, any mention of stopping treatment, any emotional distress, any third party contacting the practice on the patient's behalf, any mention of cost as a barrier (routes to a human who can discuss financial assistance), or two requests for a human.
• Fixed clinical-deflection copy: "I'm not able to answer medical questions by text. I'm flagging this for {{clinician_or_team}} and someone will call you. If this is an emergency, call 911."
• BO does not decide adherence. Whether a late patient is safe to simply rebook or needs clinician review before rebooking is a clinical rule the practice writes into the workflow as a branch, not a judgment BO makes in conversation.

Nightly cadence engine

A scheduled job that runs once daily before the recall block opens and does the arithmetic the rest of the build depends on: recompute days_until_due and days_overdue from last_completed_visit_date and cadence_interval_days; set adherence_status; set lapse_tier; move cards whose window has opened into Due Window Open: Unbooked; move cards past window close into Overdue; raise readiness cards for visits inside the next 14 days; and publish the day's worklist. Nothing in this build relies on a human noticing a date.

Reporting

A program dashboard with one row per program and one drill-down per patient: active enrollments, share of active cards sitting in Next Visit Booked, on-time visit rate, median days late, book-at-checkout rate, due-window capture rate, recall contact rate by channel and attempt number, lapse rate by tier, reactivation rate, and series completion rate. A second view lists every card by days_overdue descending. The single screen the recall owner works from.

One patient through one full cycle

1. At the visit where the clinician starts the program, the enrollment form is completed with the patient present. It writes program_code, cadence_interval_days (say 84), cadence_tolerance_early_days (7) and cadence_tolerance_late_days (7), visits_in_series_total, preferred_recall_channel, ok_to_leave_voicemail, and the three separate channel consents. A card is created in Enrolled: Cadence Set.
2. The cadence engine computes the clock from last_completed_visit_date: next_due_date at day 84, due_window_open_date at day 77, due_window_close_date at day 91.
3. Before the patient leaves the building, checkout books the next visit on the Series Visit calendar inside that window. next_visit_booked_datetime and booked_at_prior_visit = true are written, and the card moves to Next Visit Booked. This step is the whole build's center of gravity; everything after it exists to handle the cases where it did not happen.
4. The patient leaves with a printed and texted confirmation carrying date, time, location and clinician name. No program name, no medication, no reason.
5. At 14 days before the booked visit, a Visit Readiness card is raised. The readiness owner checks authorization_status against authorization_expires_date, confirms order_status, and confirms supply_confirmed. All three clear, the card reaches Ready, and no patient-facing message is needed.
6. The reminder ladder runs off next_visit_booked_datetime: a confirmation request at seven days, a reminder at two days, and an arrival reminder the morning of, each carrying logistics only.
7. The patient attends. The front desk marks the visit complete, which is the event that drives the next cycle: last_completed_visit_date updates, visit_sequence_number increments, on_time_visit_count increments, and the engine recomputes the whole clock forward by 84 days.
8. Completion also fires the checkout prompt again. A task on the front desk's screen that will not clear until either a next appointment exists or a reason is recorded. If the patient walks without booking, booked_at_prior_visit = false and the no-book-at-checkout tag is applied, which is how the card ends up on the pre-due warm-up list instead of resting quietly.
9. Cycle repeats. When visit_sequence_number reaches visits_in_series_total, the card moves to Program Complete and a different conversation (maintenance, next program, discharge) is handed to the clinician rather than to an automation.

The cycle where it breaks, which is the cycle that matters

1. This time the patient leaves without booking. booked_at_prior_visit = false, no-book-at-checkout applied.
2. At day 63 (three weeks before due) the warm-up workflow starts because the card is unbooked. A short text invites the patient to pick a time. No reply.
3. At day 70, email with two concrete slots. No reply. At day 74, a second text. No reply.
4. At day 77 the due window opens. The nightly engine moves the card to Due Window Open: Unbooked, sets adherence_status = due, applies due-now, and places the card on the day's recall worklist with assigned_recall_owner set.
5. The recall owner works it in the protected Recall Call Block, reaches the patient on the second attempt, and learns the real reason: the only slots offered were mid-morning and the patient works. barrier_reason = work schedule is recorded, and the patient is booked into an early slot on the Lab Draw calendar. Card moves to Rebooked.
6. Because the barrier is now a known field, the preference persists: every future offer for this patient leads with early slots, and the practice can report on how many of its lapses were caused by its own availability rather than by patient behavior.
7. Had the patient not been reached, the card would have passed due_window_close_date at day 91 into Overdue, climbed the lapse_tier ladder at 30, 60 and 90 days past due, and dropped into Lapsed: Re-engagement, where the cadence of automated messaging slows sharply and the work shifts to a human call, a physical letter, and a clinician-signed outreach, because by that point another text is noise and a different channel is the only thing left that works.

Workflow 1: Enrollment & Cadence Initialization

Trigger: Program Enrollment form submitted.

1. Create the Recall & Series Adherence card in Enrolled: Cadence Set. Apply program-active.
2. Write program_code, program_enrollment_date, cadence_interval_days, cadence_tolerance_early_days, cadence_tolerance_late_days, visits_in_series_total, visit_sequence_number = 1, program_owner_clinician, authorization_required.
3. Write the contact preferences: preferred_recall_channel, best_time_to_reach, ok_to_leave_voicemail, ok_to_contact_alternate, alternate_contact_name, plus sms_consent, email_consent, mail_consent and their timestamps.
4. Compute the clock: next_due_date = last_completed_visit_date + cadence_interval_days; due_window_open_date = next_due_date − cadence_tolerance_early_days; due_window_close_date = next_due_date + cadence_tolerance_late_days.
5. Assign assigned_recall_owner and readiness_owner by program, not by round robin: cadence programs reward a single familiar voice.
6. Branch on authorization_required. If true, create a Visit Readiness card immediately in Readiness Due so the first authorization is confirmed before the first booked visit rather than after.
7. Send the enrollment confirmation. SMS: "You're all set, {{first_name}}. Your visits with {{clinician}} are every {{interval_weeks}} weeks and we'll always book the next one before you leave. Reply STOP to opt out." Email carries the same plus the practice's number and the preference-update link.
8. Hand immediately to Workflow 2 so the first next-visit booking happens at this visit, not later.

Exit conditions: card created and clock populated. This workflow runs once per enrollment.

Workflow 2: Book the Next Visit at Checkout

Trigger: a program visit is marked complete, or an enrollment is created.

This is the most important workflow in the build. Every other workflow below is remediation for this one failing.

1. Update the clock: write last_completed_visit_date = today, increment visit_sequence_number, recompute next_due_date, due_window_open_date, due_window_close_date.
2. Branch on series position. If visit_sequence_number > visits_in_series_total, move to Program Complete, apply series-complete, notify program_owner_clinician, and exit: do not generate another recall.
3. Create an immediate, blocking task on the checkout screen: "Book next {{program_code}} visit: window {{due_window_open_date}} to {{due_window_close_date}}". The task cannot be cleared without one of two outcomes: an appointment, or a recorded reason.
4. Wait 15 minutes. Branch on whether an appointment now exists in the window.
5. Booked: write next_visit_booked_datetime, set booked_at_prior_visit = true, move card to Next Visit Booked, send confirmation SMS: "Booked, {{first_name}}, {{appointment_day}} at {{appointment_time}} with {{clinician}}, {{location}}. Reply R to change it.": and exit.
6. Not booked: set booked_at_prior_visit = false, apply no-book-at-checkout, and send a same-day self-booking link within two hours of the visit, while the appointment is still fresh: "{{first_name}}, we didn't get your next visit on the calendar today. Here are open times in your window: {{booking_link}}"
7. Wait 48 hours. If still unbooked, create a call task for assigned_recall_owner: not a text. A patient who left without booking has already demonstrated that the text path is not working for them.
8. Wait 5 days. If still unbooked, hand the card to Workflow 3 at its first step regardless of how far away the due date is.

Exit conditions: appointment exists in the window, program complete, or card withdrawn. Stop condition worth naming: if the clinician has flagged that the next interval needs to be re-set at a review visit, this workflow books the review visit instead and does not compute a cadence it was not given.

Workflow 3: Pre-Due Warm-Up (unbooked cards only)

Trigger: nightly engine finds a card where days_until_due = 21 and no next_visit_booked_datetime.

Global conditions: exits instantly on any booking. Quiet hours enforced, 8:00am–8:00pm local. Channel selection follows preferred_recall_channel; if that is "call," every SMS step below becomes a call task instead.

1. Day −21, 10:00am. SMS: "Hi {{first_name}}, it's about time for your next visit with {{clinician}}. Pick a time that works: {{booking_link}}"
2. Day −14, 9:30am. Email: subject "Time to schedule your next visit". Body names the clinician, the location, two concrete open slots inside the window, and the self-booking link. No program, medication or condition named anywhere in the subject line or the body. An email subject line is visible on a lock screen.
3. Day −7, 2:00pm. SMS: "{{first_name}}, {{clinician}} has {{slot_1}} and {{slot_2}} open. Reply 1 or 2 and I'll hold it for you." A numeric reply books directly and exits.
4. Day −3, 11:00am. Call task for assigned_recall_owner, 15-minute slot on the Recall Call Block.
5. Day 0 (due_window_open_date). Hand to Workflow 4.

Exit conditions: booking created, sms-stop, card withdrawn, or clinician pauses the program.

Workflow 4: Due-Window Recall

Trigger: nightly engine moves a card into Due Window Open: Unbooked.

This is the workflow with the highest clinical value, so it is the one that escalates to humans fastest.

1. Set adherence_status = due, apply due-now, move card to Recall Outreach Active, add the card to today's published worklist, notify assigned_recall_owner.
2. Day 1, 9:00am. SMS: "{{first_name}}, you're due for your visit with {{clinician}} this week. {{booking_link}}, or reply and I'll find you a time."
3. Day 1, afternoon. Call attempt 1 from the Recall Call Block. Branch on ok_to_leave_voicemail: if true, leave the approved script: "This is {{staff_name}} from {{practice_name}} calling for {{first_name}}. Please give us a call back at {{number}} to get your next visit scheduled. Thank you." Nothing more; the voicemail names no program and no reason. If false, no message is left and only the missed-call record goes on the card.
4. Increment recall_attempt_count, write recall_last_attempt_date and recall_last_channel on every attempt, every time. Attempt history is what makes the next attempt smarter and the reporting honest.
5. Day 3. Email with two slots. Day 4. Call attempt 2, deliberately at a different time of day than attempt 1, guided by best_time_to_reach.
6. Day 6. SMS: "{{first_name}}, I don't want you to fall behind on your visits. Is there a day or time that would actually work for you? Just reply and tell me." An open-ended ask here outperforms another link, because the patient's obstacle is usually not the booking link.
7. Day 8. Call attempt 3. Branch on ok_to_contact_alternate: if true and the patient has not been reached in three attempts, call alternate_contact_name with the minimum-necessary script. Ask them to have the patient call the practice, disclose nothing about why.
8. Day 10. Send the Barrier Survey as a single question with fixed logistical options. Any option captured writes barrier_reason and routes to the matching fix: transport to the location-change branch, cost to a human call about financial assistance, work schedule to the extended-hours slot list, childcare to the slots with the shortest wait.
9. Day 12. Notify program_owner_clinician that the patient is inside the window and unreached. A clinician-signed message is a different thing than a front-desk message, and in cadence programs it is frequently the thing that works.
10. At due_window_close_date: hand to Workflow 6.

Exit conditions: appointment booked (move to Rebooked, clear due-now, reset recall_attempt_count), patient declines on the Withdrawal form, sms-stop (SMS steps stop, call and mail steps continue. An SMS opt-out is not an opt-out from care), or clinician pauses the program.

Workflow 5: Visit Readiness Check

Trigger: nightly engine finds a booked program visit 14 days out.

1. Create a Visit Readiness card in Readiness Due, assigned to readiness_owner.
2. Branch on authorization_required. If true: check authorization_status and authorization_expires_date. If the authorization expires before the appointment date, apply auth-expiring, create an urgent renewal task, and set a hard check at 7 days out.
3. Check order_status. If not placed, task the clinical team. Check supply_confirmed. If not confirmed, task whoever owns ordering and apply supply-hold.
4. All three clear: move to Ready. No patient-facing message: silence is correct when everything is fine.
5. Any item unresolved at 7 days out: move the readiness card to Blocked, set readiness_blocked_reason, move the adherence card to Readiness Hold, and notify both the readiness owner and the clinician.
6. Any item unresolved at 3 days out: create a call task to speak to the patient by voice and offer a date that the practice can actually honor. The message is a call, not a text, and it is made by a person. A patient who travels for a visit that cannot happen is a patient the program loses.
7. On resolution, return the adherence card to Next Visit Booked and let the reminder ladder resume.

Exit conditions: readiness Ready, visit completed, or visit rescheduled (which raises a fresh readiness card).

Workflow 6: Overdue Escalation and Lapse Detection

Trigger: nightly engine, on every active card past due_window_close_date.

1. Recompute days_overdue. Set adherence_status = overdue. Move card to Overdue.
2. Set lapse_tier by days_overdue: 1–29 → none; 30–59 → 30 and apply overdue-30; 60–89 → 60 and apply overdue-60; 90–179 → 90 and apply overdue-90; 180+ → 180.
3. At tier 30: one SMS: "{{first_name}}, you're past due for your visit with {{clinician}}. Can we get you back on the schedule? {{booking_link}}": plus one call attempt and a notification to the clinician. Increment missed_visit_count once, here, not on every nightly pass.
4. At tier 60: stop the SMS cadence entirely. The channel has demonstrated it does not reach this patient. Switch to a scheduled human call and a mailed letter if mail_consent allows, the letter signed by the clinician and carrying no clinical detail on the envelope or the first visible line.
5. At tier 90: move card to Lapsed: Re-engagement and hand to Workflow 7. Apply lapsed and prior-lapse: the second tag persists forever, because a once-lapsed patient gets a more attentive cadence for the rest of their enrollment.
6. Clinical branch, defined by the practice, not by the automation: for programs where a long gap changes what the next visit must be, the nightly engine flags the card for clinician review at a threshold the clinician sets, and self-booking is disabled on that card until a clinician clears it. Rebooking a patient into a visit that is no longer the right visit is worse than not rebooking them.

Exit conditions: visit completed (hand to Workflow 8), withdrawal recorded, or card closed by the clinician.

Workflow 7: Lapse Re-engagement

Trigger: card enters Lapsed: Re-engagement.

A slower campaign on purpose. The automated channels have already failed; the job now is one good human contact, not more volume.

1. Week 1. Scheduled call from assigned_recall_owner on the Recall Call Block. A real 15-minute slot, not a spare moment. Script leads with the question, not the pitch: "We noticed we haven't seen you. What got in the way?"
2. Week 1, if unreached. Mailed letter, clinician-signed, if mail_consent allows.
3. Week 3. Email: subject "We'd like to get you back on the schedule". Body offers three concrete options (a different location, an early or late slot, a telehealth check-in first) because the lapse was usually caused by one of those three being unavailable.
4. Week 5. Call attempt 2, at a different time of day. If ok_to_contact_alternate is true, attempt the alternate contact with the minimum-necessary script.
5. Week 8. Final SMS if sms_consent is still true: "{{first_name}}, the door's open whenever you're ready. {{booking_link}}"
6. Week 10. Write reengagement_outcome and move the card to Withdrawn / Closed with withdraw_reason = unreachable. Notify the clinician, who decides whether anything further is clinically required. A decision that stays with the clinician and never with a workflow.
7. On any successful contact: capture barrier_reason, book the visit, move to Reactivated, and set the card's future cadence to the attentive variant: warm-up starts at 28 days out instead of 21, and the checkout task is marked mandatory.

Exit conditions: visit booked and completed, withdrawal recorded, or week 10 reached.

Workflow 8: Visit Completion and Cycle Restart

Trigger: program visit marked complete.

1. Write last_completed_visit_date. Increment visit_sequence_number.
2. Branch on timing. Completed inside the window: increment on_time_visit_count. Completed after due_window_close_date: increment late_visit_count, update longest_gap_days, and if the previous visit was also late, apply two-late-in-a-row and notify the clinician.
3. Clear due-now, overdue-* and lapsed tags. Reset recall_attempt_count to 0. Set adherence_status = on cadence.
4. Recompute the full clock forward from the new last_completed_visit_date.
5. Hand to Workflow 2 so the next visit is booked before the patient leaves. The loop closes here, and this handoff is why the build compounds instead of decaying.

Exit conditions: none. This workflow is the hinge and runs on every completed visit for the life of the program.

Workflow 9: Reminder and Confirmation Ladder

Trigger: scheduled relative to next_visit_booked_datetime.

Global conditions: appointment still booked; readiness not Blocked (a blocked visit sends the readiness message instead); quiet hours enforced; every message carries date, time, location and clinician name only.

1. T-7 days. SMS: "{{first_name}}, confirming your visit with {{clinician}} on {{appointment_day}} at {{appointment_time}}. Reply C to confirm or R to reschedule." R sends slots inside the due window only: never a slot that would push the patient past due_window_close_date, which is the difference between a reschedule and a lapse.
2. T-2 days. Email with full logistics, directions, and any prep instruction the program requires stated in neutral operational terms: "please don't eat after midnight" rather than anything naming the test.
3. T-1 day, 4:00pm. SMS reminder.
4. T-2 hours. SMS arrival note with parking or check-in instruction.
5. No confirmation by T-2 days: add the patient to the front desk's confirmation call list. A booked-but-unconfirmed cadence visit is the highest-value call the front desk can make that day.

Exit conditions: visit completed, canceled, or sms-stop.

Workflow 10: Same-Day Cancellation Backfill

Trigger: a program visit is canceled with less than 48 hours' notice.

1. Return the canceling patient's card to Due Window Open: Unbooked and immediately offer three alternative slots inside the remaining window.
2. Query cards where adherence_status is due or overdue, sms_consent = true, and no booking exists: ordered by days_overdue descending, so the most overdue patient gets first offer.
3. Send to the top five only: "{{first_name}}, a slot just opened with {{clinician}} on {{day}} at {{time}}. First to reply YES gets it."
4. First YES books and the others receive "That one's taken, but I can still get you in this week: {{booking_link}}". Over-offering and then disappointing people is worse than leaving the slot empty, which is why the list is capped at five.
5. No reply in 90 minutes: release the slot to public self-booking.

Exit conditions: slot filled, or 90 minutes elapsed.

Workflow 11: Daily Worklist and Owner Accountability

Trigger: nightly, 30 minutes before the first Recall Call Block.

1. Publish the day's worklist to assigned_recall_owner: cards in Due Window Open: Unbooked, then Overdue by days_overdue descending, then readiness cards in Blocked.
2. Cap the list at what the protected blocks can actually absorb. An uncapped list is abandoned by Thursday.
3. Notify the practice manager with three numbers only: cards due today, cards overdue past 30 days, and yesterday's book-at-checkout rate.
4. Escalate any card with recall_attempt_count ≥ 5 and no contact to the manager for a decision: different person, different channel, or clinician involvement.
5. Escalate any readiness card in Blocked for more than 48 hours to the manager, because a blocked readiness card is an appointment about to be wasted.

Exit conditions: none: runs every clinic day.

Workflow 12: Consent, Opt-Out, Quiet Hours and PHI Guard

Trigger: runs ahead of every outbound message in every workflow above.

1. STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT: apply sms-stop, set sms_consent = false, remove from every SMS step, send the single required confirmation. Critical branch: an SMS opt-out does not close the adherence card and does not stop the call, mail or clinician paths. It changes the channel and nothing else. Set preferred_recall_channel = call and continue.
2. START or UNSTOP: restore sms_consent with a fresh timestamp and source.
3. HELP: reply with practice name, phone number and opt-out instruction.
4. Before any send: suppress if the relevant channel consent is not true, and fall back to the next consented channel.
5. Before any send: enforce 8:00am–8:00pm local, queueing anything that comes due inside quiet hours to 8:05am.
6. Before any send: run the disclosure check. The template must come from the approved library and must not contain program_code, a program or brand name, a medication, a lab or test name, a diagnosis, a body system, a result, or a dose. Permitted payload is date, time, location, clinician name and a link, and this applies to email subject lines and voicemail scripts as strictly as to SMS bodies, because both are read and heard by people other than the patient.
7. Before any voicemail: check ok_to_leave_voicemail. If false, no message. Before any alternate-contact call: check ok_to_contact_alternate and use the minimum-necessary script, which asks the patient to call the practice and discloses nothing else.
8. Suppress all program messaging for any contact flagged deceased, transferred out, or clinician-paused. A recall text to a deceased patient's family is the worst message this build could ever send; the suppression check is not optional and is verified in testing.

Exit conditions: none. This guard never turns off.

What is different afterwards

• The practice has three distinct, computed populations instead of one vague list: patients on cadence, patients due, and patients lapsed. Each has a different workflow and a named owner, and the counts are available every morning without anyone running a report.
• The next visit gets booked while the patient is still in the building, which is the single change that moves adherence most. Cards that leave checkout unbooked are flagged as the known risk they are, rather than disappearing into the schedule's blind spot.
• Due dates fire on their own. No staff member has to remember that a quarterly draw is coming, and no patient has to be the one keeping track of a schedule the practice set.
• Lapse becomes a detected event with a response, not something noticed months later. The response changes channel as the lapse deepens, instead of sending a fifth text that will perform exactly like the first four.
• Logistics stop silently killing visits. Authorization expiry, missing orders and supply gaps are surfaced fourteen days out, while there is still time to fix them or move the appointment honestly.
• The reasons patients fall off become data. barrier_reason turns "patients are non-compliant" into a distribution the practice can act on, and a meaningful share of it usually turns out to be the practice's own hours, locations and slot availability.
• Canceled slots get refilled from the patients who most need them, ordered by how overdue they are, rather than sitting empty or going to whoever called first.

Metrics to watch

• Book-at-checkout rate: the share of completed visits where booked_at_prior_visit = true. Watch this first and watch it weekly. It predicts everything downstream, and it is the one number a front-desk habit change moves within days.
• Share of active cards in Next Visit Booked. In a healthy program this is the large majority. A falling share is an early warning that arrives weeks before the overdue count rises.
• On-time visit rate: visits completed inside the due window, as a share of all completed program visits, and median days late for those that fall outside it.
• Due-window capture rate: of cards that entered the window unbooked, the share booked before due_window_close_date. This measures the recall ladder specifically.
• Contact rate by attempt number and channel. If attempt 4 almost never reaches anyone, stop at three and spend the effort on a different channel.
• Lapse rate by tier (30, 60, 90, 180) and reactivation rate out of the lapsed pool, by channel. This is where you learn whether letters and clinician-signed outreach earn their cost.
• Series completion rate: of enrollments that have had time to finish, the share reaching Program Complete. The headline outcome of the whole build.
• Readiness block rate and block resolution time, plus visits lost to a readiness failure. A block rate that will not fall points at an upstream process, not at the workflow.
• Barrier distribution from the survey and from recorded calls. Review it monthly against your own slot availability by hour and location.
• Opt-out rate and complaint rate per program. Cadence programs message the same people repeatedly for years, which makes them the most likely place to wear out a channel.
• Recall worklist completion: the share of each day's published list actually worked. If this sits below full, the constraint is staffing or the protected block, not the automation.

Baseline every one of these for a full cadence interval before changing the cadence of the outreach itself, or you will mistake a seasonal effect for a result.

Clinical definitions you must have in writing first

This build cannot be configured from guesses. Before anything is created, get the following from the clinician who owns each program, in writing:

• The exact interval, in days, and whether it counts from the last completed visit or from a fixed enrollment anchor.
• The acceptable early and late tolerance in days. The due window. A window is not optional; without one, every visit is either early or late.
• The total number of visits in the series, or an explicit statement that it runs indefinitely until the clinician ends it.
• The gap threshold at which a late patient can no longer simply be rebooked into the same visit type and requires clinician review first, and who performs that review.
• Which visits a nurse can deliver and which require a provider, since this determines whether short-notice rebooking is even possible.
• What the practice is willing to say in a message. Agree the neutral vocabulary up front: "your next scheduled visit with Dr. X," never the program, medication, test or condition.

Integrations and data

• Clinical system connection or a reliable scheduled export for completed visits. The entire cadence engine keys off last_completed_visit_date, so if visit completion does not reach the platform the same day, every clock in the build drifts. If a live connection is not available, a nightly export and a named human who confirms it ran is an acceptable launch state, but it has to be named.
• Provider and resource calendars for every program calendar, including nurse and draw-room capacity, so offered slots are real.
• Authorization and supply sources for the readiness pipeline. If these cannot be read programmatically, the readiness workflow still works as a task queue with a human checking. What matters is that the check happens fourteen days out and is logged.
• Secure forms and e-signature for enrollment and consent, with an audit trail.
• Print and mail path for the tier-60 and lapse letters, including who signs them and how returned mail is recorded.
• Historical backfill. Decide what happens to the patients who are already enrolled and already overdue on day one. Loading them all at once produces an outreach wave no front desk can absorb: stage the backfill over several weeks, most-overdue first.

Numbers and messaging registration

• Provision a dedicated messaging number per location that patients can also call back and reach a human. Recall messaging generates return calls by design.
• Complete A2P 10DLC registration before launch: brand registration first, then a campaign. Register this program's care-coordination and appointment-reminder messaging as its own campaign, separate from marketing, and expect a review lead time: start it in week one of the build.
• Submit the real consent evidence with the registration: the enrollment form showing the separate SMS consent checkbox and its exact wording. Cadence programs send to the same numbers for years, so a weak registration eventually shows up as silent filtering on the messages that matter most.
• Verify the email sending domain (SPF, DKIM, DMARC) and warm it before sending to a large backfilled list.
• Test STOP, START and HELP on every number, and test specifically that an SMS opt-out moves the card to the call path rather than closing it.

Consent, quiet hours and opt-out

• Capture SMS, email and mail consent as three separate, unbundled checkboxes at enrollment, each with its own language naming the sender, the message types, the expected frequency over the life of the program and the opt-out instruction.
• Capture two things most practices forget: whether a voicemail may be left, and whether an alternate contact may be called and who that is. Both are used by the workflows above and both are indefensible without a record.
• Log consent timestamps and source for every channel. Re-capture consent when a program's cadence or channel mix materially changes.
• Set quiet hours to 8:00am–8:00pm in the patient's own time zone and make the guard workflow the only path to the send step, so no future workflow can bypass it.
• Decide a maximum total touches per card per week across all channels and all workflows, and enforce it centrally. The failure mode in a cadence build is a patient landing in three workflows at once and receiving six messages in two days.

Protected health information: operational practice

This section describes operational practice, not legal advice. Cadence recall carries more disclosure risk than new-patient intake, because the existence of the recall itself can reveal a condition. Confirm every decision below with your practice's own compliance counsel and risk assessment before launch.

• Executed business associate agreements before any patient data loads: the platform, the messaging path, the form and signature tool, the print-and-mail vendor, and any storage or reporting layer that touches the data. Keep them where the compliance officer can produce them on request.
• The program name is the disclosure risk. A text naming an injectable therapy, a specific lab panel or a program title can reveal a diagnosis to anyone who sees the screen. Use the internal program_code for staff-facing views only and keep it out of every patient-facing template, including email subject lines, voicemail scripts and the outside of mailed envelopes.
• Minimum necessary in every channel. Permitted patient-facing payload is date, time, location, clinician name and a link. Prep instructions are stated operationally rather than by naming what is being tested. Anything beyond logistics is a link into the secure path or a phone call.
• Voicemail is a disclosure channel. Use one approved script that identifies the practice and asks for a callback, and leave nothing when ok_to_leave_voicemail is false. The same logic governs alternate contacts: ask them to have the patient call, disclose nothing about why.
• Never solicit clinical detail by reply. The Barrier Survey offers logistical options only. Any free-text or clinical reply is routed to a human with the standard deflection: "I'm not able to discuss medical details here; I'm having someone from the care team call you": and the thread is treated as part of the record.
• Split the stores deliberately. The platform holds cadence state, consent, outreach history and attribution. The clinical system holds the chart, the orders, the results and the identifiers. Readiness fields in the platform are statuses and switches, never underlying clinical data.
• Deceased, transferred and paused suppression must be tested, not assumed. Verify it with a deliberate test case before launch and re-verify after any change to the nightly engine.
• Constrain BO in writing: permitted topics, named escalation triggers, fixed deflection and emergency copy, and an explicit prohibition on naming the program. Review the prompt with the compliance officer, re-review on every change, and sample transcripts weekly for the first month and monthly thereafter.
• Access, audit and retention. Least-privilege roles, two-factor everywhere, access review when staff change, logging on views and exports, and a decided retention period for threads, call recordings, voicemail records and survey responses.
• Call recording carries its own disclosure and consent requirements that vary by state. Decide before enabling it on the recall block.
• Wrong-number handling. Cadence programs run for years and numbers get reassigned. Build an explicit path for "you have the wrong number" replies: stop all messaging on that number immediately, flag the card, and route to a human to re-verify contact details.
• Breach and incident path defined and rehearsed once, before launch, so nobody is inventing it during an incident.

Scope and pricing

Programs differ enormously in cadence, readiness complexity, clinical review rules and number of calendars, and the historical backfill is its own project. This build is scoped per practice and per program rather than priced from a list. Book a call and we will map your actual cadence rules, your clinical system connection and your compliance constraints before quoting anything.