New Patient Reactivation for Clinics

Every established clinic is sitting on a list of people who were patients and are not any more, and almost none of them left deliberately. They moved house, changed jobs, had a baby, lost a card, meant to call back after a holiday, or simply never got a reminder because the last one went to an old cell number. The clinic's own records show them as active patients. Operationally they have vanished. Meanwhile the same clinic is paying to acquire new patients at the top of the funnel while a far warmer population sits in the practice management system doing nothing.

The specific operational failure is that recall is treated as a byproduct of the appointment system rather than as a process of its own. The practice management system can produce a list of patients due for a follow-up, a repeat screening, or an annual visit, and frequently does, but the list goes to a front-desk team that is already answering phones, and calling two hundred people is nobody's job this week. So the list is run quarterly at best, worked from the top until the day ends, and abandoned. The patients at the bottom of the list have been overdue for two years.

Money leaks in three measurable places. First, in unbilled visits that would have happened with a single well-timed message. The clearest and most immediate loss. Second, in clinical outcomes that are also revenue outcomes: a patient who misses a recall and presents later, worse, costs more to manage and is a poorer experience for everyone involved. Third, in acquisition spend that would not be needed at the current rate if the existing list were worked properly. The constraint on fixing it is not desire; it is that patient reactivation touches protected health information, and most clinics are rightly nervous about automating anything that does. That nervousness is the correct instinct. The answer is not to avoid the automation. It is to build it so that no clinical detail ever leaves the clinical system, and the messaging layer only ever knows that somebody is due to be seen.

The core design principle

Build this with a clear boundary. The practice management system or electronic health record holds the clinical reason a patient is due. The messaging platform holds only enough to send a neutral message and book an appointment. Nothing in the message, in a tag name, in a field name visible in a merge, in a form title, or in a calendar name states or implies a diagnosis, a condition, a test, a medication, or a service type. The patient knows why they are being contacted; the SMS does not need to say it, and the phone sitting on a kitchen table in front of other people must not.

Pipeline and stages

One pipeline, Recall and Reactivation. Stages are deliberately generic in name, since stage names appear in notifications and reports:

• Due List Imported: the record has arrived from the clinical system and is matched to a contact.
• Consent Verified: channel consent on file has been checked and found current.
• Outreach Wave 1: first contact attempt made.
• Outreach Wave 2: second attempt, different channel.
• Replied: Needs Staff: the patient has responded with something a person must handle.
• Appointment Booked.
• Appointment Completed.
• Declined: the patient has said they do not want to come in; recorded and respected.
• Unreachable: contact details appear to be wrong; routed to a records-correction task.
• No Consent on File: cannot be messaged; routed to a postal or in-person path instead.
• Suppressed: must not be contacted for this campaign, for any reason including a clinical one set by a clinician.

Calendars

• Recall Visit: Standard: the main bookable calendar, named without reference to any service type.
• Recall Visit: Extended: longer slots where the clinical system has flagged that more time is needed, with the flag carried as a duration code rather than as a reason.
• Nurse or Technician Slot: where the visit does not need a physician, so capacity is used properly.
• Callback Window: short blocks for patients who ask to be phoned rather than booked online.

Custom fields

Every field below is deliberately non-clinical in both its name and its contents. This is the most important design decision in the build.

• patient_id_external: the identifier from the clinical system, used to reconcile. Not a government identifier and not a full date of birth.
• last_visit_date: date only.
• recall_due_month: month and year the patient is due. Coarse by design.
• recall_type_code: an internal code such as R1, R2, R3 mapping to a recall category held in the clinical system. The code's meaning is documented internally and never merged into any outbound message.
• visit_duration_code: selects the calendar, again without stating why.
• assigned_provider: the clinician the patient normally sees, so continuity is preserved.
• preferred_language.
• consent_sms, consent_email, consent_voice: separate per channel.
• consent_captured_date and consent_source: how and when consent was obtained, so it can be evidenced.
• reactivation_wave: which batch this patient is in, for throughput control.
• outreach_attempts: count, capped by policy.
• contact_valid: yes, no, or unknown.
• staff_follow_up_reason: an internal-only field, visible to staff, never used in a merge field.

Tags

Tag names are neutral. A tag named after a condition or a service is a disclosure waiting to happen. Tags surface in exports, in notification bodies, and on screens that patients can sometimes see.

• recall-due, recall-wave-1, recall-wave-2, recall-wave-3.
• recall-booked, recall-completed, recall-declined.
• needs-staff-call.
• contact-invalid.
• no-consent-sms, no-consent-email.
• sms-opted-out, email-opted-out.
• do-not-contact-campaign: a hard suppression a clinician or the privacy officer can apply for any reason, which no workflow may override.
• deceased-suppress: a specific and essential suppression, because a recall message to a deceased patient's family is the worst failure this build can produce.

Forms

• Contact and Consent Update: confirms mobile, email, preferred language, and captures per-channel consent with plain wording describing what the clinic will send. Collects no clinical information whatsoever.
• Callback Request: name, number, and a preferred window. No reason field; a free-text reason field is where patients volunteer clinical detail into a system that should not hold it.
• Pre-Visit Logistics: insurance or payer details, accessibility needs, and transport or interpreter requirements. Any clinical questionnaire stays in the clinical system's own patient portal, not here.
• Internal Suppression Request: a staff-only form for applying do-not-contact-campaign or deceased-suppress, with a required reason recorded internally.

BO's role and guardrails

BO's scope in a clinical setting is narrower than anywhere else in this knowledge base, and the narrowness is the point.

• BO may confirm identity at a basic level, offer appointment times, book, reschedule, cancel, give the clinic's address and hours, and confirm which clinician the appointment is with.
• BO may not discuss, confirm, speculate about, or acknowledge any clinical matter. Not symptoms, not results, not medications, not why the patient is due, not what the visit will involve clinically. If the patient raises any of it, BO's only move is to route to staff.
• BO never states or implies a reason for the recall, even if the patient asks directly. The correct reply is that a member of the team will confirm the details, followed by an immediate staff task.
• BO never quotes prices, fees, co-pays, or coverage.
• BO never gives advice of any kind, including reassurance that something is probably fine.
• BO escalates immediately and stops messaging on any mention of pain, a worsening problem, an emergency, or distress, with the inbound message routed verbatim to a named clinical contact and the patient directed to the appropriate urgent care route.
• BO operates only on channels where consent_sms or the equivalent is yes.
• BO's conversation logs contain whatever the patient chose to type, which may include clinical information the patient volunteered. Those logs therefore sit inside the protected scope and the access controls below apply to them.

Numbers and channels

• The clinic's existing main number for SMS, so messages arrive from a number patients recognize. A recall text from an unknown number is both ignored and alarming.
• Outbound voice capability for the callback path, with calls placed by staff rather than by an automated dialler for anything beyond a neutral appointment reminder.
• Authenticated email domain. Email content follows the same minimum-necessary rule as SMS: email is not more private than SMS in practice.
• A postal path for patients with no messageable consent on file. This is not a failure case, it is a designed path, and it is how the no-consent population gets reached at all.
• The patient portal of the clinical system remains the only place any clinical detail is exchanged. Every message in this build that needs to convey something clinical points the patient there or to a phone call.

1. A scheduled export runs from the practice management system, producing the patients whose recall is due in the coming month. The export carries only the fields the messaging layer needs: external identifier, name, mobile, email, last visit date, recall due month, recall type code, duration code, assigned provider, and language. No diagnosis, no procedure, no notes.
2. The import matches each row to an existing contact by external identifier, creates one where there is no match, and writes the fields. Each record enters Due List Imported with reactivation_wave set, so the whole list is not messaged in one afternoon.
3. Suppression runs before anything else. Any record carrying do-not-contact-campaign, deceased-suppress, sms-opted-out or email-opted-out is routed to Suppressed or to the postal path and leaves the sequence entirely. Suppression first, always.
4. Consent is checked. Records with current consent move to Consent Verified. Records without it move to No Consent on File and go to the postal path, which invites them to update their details rather than attempting to message them.
5. Wave one sends: a short SMS saying the clinic is due to see them, with a booking link and nothing else. No condition, no test name, no service, no urgency language. The record moves to Outreach Wave 1 and outreach_attempts increments.
6. The patient taps the link and books a slot on Recall Visit: Standard with their usual clinician, selected by assigned_provider and visit_duration_code. The record moves to Appointment Booked.
7. A neutral confirmation goes out: date, time, clinic address, clinician name, and a line directing any questions to a phone call or the patient portal. The confirmation states no reason for the visit.
8. The Pre-Visit Logistics form follows, covering payer details, accessibility, interpreter and transport needs. Any clinical questionnaire is sent separately through the clinical system's own portal, not through this build.
9. Patients who did not respond to wave one receive a second, differently worded message four days later on a different channel: email if the first was SMS. Still neutral, still a single booking link.
10. Patients who still have not responded are listed for a staff phone call rather than receiving a third automated message. The call is where a human can, appropriately and privately, say more than a text ever should.
11. A patient who replies with a question, a concern, or anything clinical is routed to Replied: Needs Staff within the same minute, with the inbound message visible to staff and staff_follow_up_reason set internally. No automated reply attempts to answer it.
12. A patient who replies declining is moved to Declined, tagged recall-declined, and removed from this and future recall campaigns of this type until a clinician asks otherwise. Declines are respected, not retried next quarter.
13. Messages that bounce or fail repeatedly set contact_valid to no, apply contact-invalid, move the record to Unreachable, and create a records-correction task so the clinical system gets fixed rather than just the messaging platform.
14. Appointment reminders run at the clinic's standard intervals, neutral in content. After the visit, the record moves to Appointment Completed, the outcome is written back to the clinical system by the clinical team, and the patient is removed from the recall list by the next export rather than by a tag the platform set.
15. Monthly, the clinic reviews reactivation reporting: how many were due, reached, booked, seen, declined, and unreachable, by wave and by recall type code. The code is used internally for analysis and never appears in anything a patient sees.

Workflow 1: Due List Import, Matching and Suppression Gate

Trigger: scheduled, weekly, on receipt of the recall export from the clinical system. By a native integration where one exists, or by a scheduled file drop or an integration layer such as Zapier or Make where it does not. Whichever route is used, it must be covered by the same agreements and controls as the clinical system itself.

Conditions and branches: the entire workflow is a gate, and the order of the gates matters more than anything else in this build. Gate one: does the record carry deceased-suppress? Gate two: do-not-contact-campaign? Gate three: a channel opt-out? Gate four: is consent current for at least one channel? Gate five: is a contact method present and marked valid? Only a record passing all five gates proceeds. Branch on match quality: an exact external-identifier match updates the contact; a name-and-mobile match with no identifier creates a review task rather than merging, because a wrong merge in a clinical context means messaging one patient about another's care.

Actions in order:

• Import only the permitted fields. Reject any inbound column that is not on the agreed list, so a widened export cannot quietly start delivering clinical data into the messaging layer. This rejection step is worth building explicitly.
• Match on patient_id_external. On no match, create the contact. On ambiguous match, create a staff task and hold the record out of all sequences.
• Write last_visit_date, recall_due_month, recall_type_code, visit_duration_code, assigned_provider, preferred_language.
• Run the five suppression gates in order. Route failures to Suppressed, No Consent on File, or Unreachable as appropriate, and never into an outreach wave.
• Assign reactivation_wave by dividing the passing records into batches the front desk can actually absorb. A clinic with two staff on reception cannot handle the reply volume from four hundred messages sent at once, and the replies are the whole point.
• Move passing records to Consent Verified, apply recall-due, and trigger Workflow 3 for the current wave only.
• Produce an import report: rows received, matched, created, held for review, suppressed by each gate, and routed to post. Send it to the practice manager.

Stop and exit conditions: a record that fails any gate exits and is not reconsidered until the next export. The import aborts entirely rather than partially processing if the file structure does not match the agreed schema. A half-processed clinical import is harder to unwind than a failed one.

Workflow 2: Consent Capture and Refresh

Trigger: consent_sms or consent_email empty or older than the clinic's agreed refresh interval, or a record landing in No Consent on File.

Conditions and branches: branch on whether any messageable consent exists. With no consent at all, nothing may be sent electronically. The only permitted route is the postal path or an in-person update at the next visit. With consent for one channel but not another, use the consented one to ask about the other. Branch on preferred_language and serve the consent wording in that language, since consent presented in a language the patient does not read is not meaningful.

Actions in order:

• No-consent branch: add the record to the postal batch. The letter confirms the clinic would like to update their contact details and invites them to call or use the portal. It does not state a clinical reason, because a letter can be opened by anybody in a household.
• Partial-consent branch: send on the consented channel: “We're updating patient contact details. Could you confirm yours and let us know how you'd prefer we reach you? [Contact and Consent Update link]”
• On form submission: write consent_sms, consent_email, consent_voice, stamp consent_captured_date, set consent_source to form, set contact_valid to yes, and remove the relevant no-consent tags.
• Wait 7 days. One reminder on the same channel if the form is not returned. Then stop: chasing consent repeatedly is itself a problem.
• Create a front-desk task to capture or refresh consent at the patient's next in-person visit, which is by far the highest-yield moment for this and should be built into the check-in routine rather than left to the automation.
• Write the consent event to an audit record: channel, date, source, exact wording presented, and language.

Stop and exit conditions: consent captured, one reminder sent, or opt-out received. A record with no consent never enters an outreach wave regardless of how overdue the patient is. Overdue is not a justification; being overdue is the clinic's problem to solve through permitted channels.

Workflow 3: Outreach Wave 1

Trigger: record enters Consent Verified and its reactivation_wave is the active wave.

Conditions and branches: branch on consented channel, SMS preferred where available. Branch on preferred_language. Branch on quiet hours in the patient's time zone. Branch on visit_duration_code and assigned_provider to select which booking link is sent, so the link only ever offers slots that are genuinely appropriate. Critically, do not branch the message wording on recall_type_code: one neutral message for all recall types is both safer and, in practice, no less effective.

Actions in order:

• Apply recall-wave-1, move to Outreach Wave 1, increment outreach_attempts.
• Send SMS, minimum necessary: “Hi [first name], it's [Clinic]. Our records show you're due to be seen. You can book here: [link]. Or call us on [number]. Reply STOP to opt out of texts.” That is the whole message. It names no condition, no test, no service, and no date of a previous visit.
• Wait 3 days. If no booking and no reply, send one gentle follow-up on the same channel: “Just a reminder from [Clinic]: you're still due for a visit. Book here when it suits: [link]”
• On a booking: apply recall-booked, move to Appointment Booked, trigger Workflow 6.
• On any inbound reply that is not a booking: trigger Workflow 5 immediately. Do not send any further automated message on this thread until staff have handled it.
• On a delivery failure or hard bounce: set contact_valid to no, apply contact-invalid, move to Unreachable, and trigger Workflow 7.
• Wait 4 days after the follow-up. If still nothing, move to Workflow 4.

Stop and exit conditions: booking, reply, opt-out, delivery failure, or completion of two sends. Hard stop on any suppression tag appearing at any point, including mid-sequence, since a clinician may apply one after the wave has started.

Workflow 4: Outreach Wave 2 and Staff Call List

Trigger: record completes Workflow 3 without a booking or reply.

Conditions and branches: branch to a different channel from wave one: email if SMS was used, SMS if email was. Branch on outreach_attempts against the clinic's policy cap, which should be set explicitly and should be low; three to four total attempts across all channels is a reasonable ceiling and more than that becomes harassment of someone who has not responded. Branch on recall age: a patient overdue by more than a defined period, two years say, should go straight to the staff call list rather than receiving more messages, because at that distance a message is unlikely to work and a call might.

Actions in order:

• Apply recall-wave-2, move to Outreach Wave 2, increment outreach_attempts.
• Send on the alternate channel. Email subject: “A reminder from [Clinic]”. Nothing more specific, because subject lines appear on lock screens and in shared inboxes. Body: that the patient is due to be seen, the booking link, the clinic's number, and a line that any questions are best handled by phone or through the patient portal.
• Wait 5 days. No further automated send after this one.
• If no booking and no reply, apply needs-staff-call, add the record to the daily call list, and create an assigned task for the front desk with a due date.
• Equip the call list with what staff actually need: name, number, last_visit_date, assigned_provider, preferred language, and a pointer to look up the clinical reason in the clinical system. Do not copy the clinical reason onto the call list; staff should read it from the source system where access is logged.
• Cap the daily call list at a number the team can genuinely complete, and roll the remainder rather than issuing a list of two hundred that gets abandoned at thirty.
• Record every call outcome: booked, declined, no answer, wrong number, or asked to be called later. A no-answer after three call attempts routes to the postal path.

Stop and exit conditions: booking, reply, opt-out, attempt cap reached, or suppression. Once the attempt cap is reached with no response, the record leaves active outreach and waits for the next natural recall cycle. Grinding on the same non-responder every month is both ineffective and, on any reasonable reading, not minimum necessary.

Workflow 5: Inbound Reply Triage and Clinical Escalation

Trigger: any inbound message on a recall thread, on any channel.

Conditions and branches: this is the workflow that keeps the build safe, and it should be built before the outreach waves rather than after. Branch one: urgent clinical language: pain, bleeding, worsening, breathing, chest, emergency, or any distress signal. These route instantly to the named clinical contact and the patient receives one message directing them to the clinic by phone or to urgent care, with no further automated interaction. Branch two: a clinical question that is not urgent, anything about results, medication, symptoms, or why the recall was issued. These route to staff with the message quoted, and BO replies only that a member of the team will call. Branch three: a logistics message. A date, a time, a request to be called back, a change of number. BO may handle these. Branch four: an opt-out or decline, which routes to Workflow 8.

Actions in order:

• Suspend every scheduled send on this contact immediately, before any classification happens. A reminder landing after a patient has written in about pain is the failure this ordering prevents.
• Urgent branch: notify the named clinical contact by SMS and in the team channel with the message verbatim. Create a high-priority task due within 15 minutes. Send the patient one message: “Please call us on [number] now, or if this is urgent go to [urgent care route]. We don't handle medical questions by text.” Then stop messaging entirely.
• Non-urgent clinical branch: apply needs-staff-call, move to Replied: Needs Staff, write staff_follow_up_reason internally, create a task due within 4 business hours, and send one reply: “Thanks. One of the team will call you about that. We don't discuss medical details by text.” BO answers nothing.
• Logistics branch: BO answers within scope: offers two named appointment times, books, reschedules, cancels, or captures a callback window and a corrected phone number.
• In every branch, log the inbound message in the conversation record with the same access restrictions as the rest of the build, since the patient may have volunteered clinical information.
• Wait 4 business hours on the non-urgent branch. If the task is untouched, escalate to the practice manager.
• Once staff have handled it, they set the outcome, which either books the patient, moves the record to Declined, or returns it to the appropriate wave.

Stop and exit conditions: staff task completed, or the patient booked, or an opt-out. Automated messaging never resumes on a thread that reached the urgent branch; it stays with people permanently.

Workflow 6: Neutral Confirmation, Reminders and Attendance

Trigger: an appointment is created on any recall calendar.

Conditions and branches: branch on consented channel and on preferred_language. Branch on interpreter or accessibility needs recorded on Pre-Visit Logistics, which generate internal tasks rather than patient messages. Branch on lead time: a booking made for tomorrow gets a compressed reminder ladder. Every message in this workflow is checked against one rule before it is built. Could this text, read by somebody other than the patient, reveal anything about their health? If yes, rewrite it.

Actions in order:

• Immediately: confirmation SMS. “Booked: [day] [date] at [time] with [clinician] at [Clinic], [address]. Reply R to change it or call [number].” No reason, no service name, no department name that implies one.
• Immediately: confirmation email with the same content, plus parking and access notes, and a pointer to the patient portal for anything clinical.
• Send Pre-Visit Logistics: payer details, accessibility, interpreter, transport. If a clinical questionnaire is needed, send the patient portal link and let the clinical system collect it there.
• Wait until 7 days before: one reminder, same neutral wording.
• Wait until 48 hours before: reminder asking for a one-character confirmation.
• Wait until 2 hours before: final reminder, logistics only.
• Interpreter or accessibility branch: 48 hours before, create an internal task to arrange it and confirm arrangements by phone rather than by message.
• After the appointment: staff mark it attended, canceled, or not attended. On attended, move to Appointment Completed, apply recall-completed, and let the next clinical export remove the patient from the due list.
• On not attended: one neutral rebooking message, then route to the staff call list. Do not run a marketing-style no-show campaign on a patient.
• Optional, and only if the clinic has decided it is appropriate: a review request after an attended visit, worded with no reference to care received, sent only to patients with marketing consent, and never to anybody whose record shows a sensitive visit type. Many clinics should simply not do this, and that is a legitimate decision.

Stop and exit conditions: appointment attended, canceled, or not attended with the staff path triggered. Reminders for a confirmed appointment are transactional and continue through a marketing opt-out, but stop on a full communications opt-out.

Workflow 7: Bad Contact Detail Recovery

Trigger: a hard delivery failure, a repeated soft failure, an invalid-number response, or a staff-recorded wrong number.

Conditions and branches: branch on whether an alternate consented channel exists. If one does, try it once. If none does, the record goes to the postal path, which is the only remaining route. Branch on whether the clinic holds a secondary contact on the clinical record, and if so, note carefully that contacting a family member or alternate contact about a patient's appointment is a disclosure and needs its own authorization on file. Do not message a listed emergency contact as a convenient fallback.

Actions in order:

• Set contact_valid to no, apply contact-invalid, move to Unreachable.
• Suspend all electronic outreach on this record immediately.
• Alternate-channel branch: one send only, on the other consented channel, inviting the patient to update their details.
• Create a records-correction task so the correction is made in the clinical system, not only in the messaging platform. A number fixed in one system and not the other guarantees the same failure next quarter.
• Add to the postal batch with a neutral letter inviting the patient to call and update their details.
• Flag the record for an in-person detail check at the next visit if one ever occurs.
• Report monthly on the count of unreachable records by wave, which is the clearest available measure of data quality in the clinical system.

Stop and exit conditions: details corrected and contact_valid set to yes, or the postal attempt made. No further electronic sends while contact_valid is no.

Workflow 8: Opt-Out, Decline and Hard Suppression

Trigger: opt-out language on any channel, a patient declining, or the Internal Suppression Request form being submitted by staff.

Conditions and branches: branch on what is being declined, and be precise about it, because in a clinical context the distinctions genuinely matter. A marketing opt-out is not a refusal of appointment reminders for an appointment the patient has booked. A decline of this recall is not a refusal of all future care. A request to stop all contact is a different and broader instruction. Branch on the source: a clinician-applied or privacy-officer-applied suppression overrides everything and is never cleared by a workflow. Branch on ambiguity: “not right now” is a deferral, not a decline, and should be treated as a deferral with a date rather than guessed at either way.

Actions in order:

• SMS opt-out: apply sms-opted-out, set the platform-level suppression rather than relying on the tag, set consent_sms to no, stamp the date, and send one confirmation: “You're unsubscribed from texts from [Clinic]. We'll contact you by post or phone instead if we need to.” That last clause matters. The patient should not be left thinking the clinic can no longer reach them about their care at all.
• Decline of this recall: move to Declined, apply recall-declined, record the date, and exclude the record from this recall type's campaigns. Notify the assigned clinician, because a declined recall is clinically relevant information and should not sit only in a marketing system.
• Deferral branch: record a review date and re-enter the record on that date only, with the attempt count reset but the policy cap unchanged.
• Full contact stop: suppress every electronic channel, and create a task for staff to confirm by phone or post how the clinic may contact the patient about their care, since a blanket stop and a continuing clinical relationship need reconciling by a person.
• Staff suppression branch: apply do-not-contact-campaign or deceased-suppress, record who requested it and the internal reason, remove the record from every workflow immediately, and block re-entry permanently until a named person removes it manually.
• Write an audit line for every one of the above: channel, date, verbatim wording where the patient supplied it, and who actioned it.

Stop and exit conditions: terminal in every branch except the deferral. No workflow in this build re-enrolls a suppressed or opted-out record. Re-entry requires a fresh, documented consent captured on the Contact and Consent Update form or in person, with consent_source and consent_captured_date written.

Afterwards, recall stops being a quarterly scramble and becomes a weekly process that runs whether or not anybody remembers it. The due list arrives, suppressions are applied before anything is sent, the consented population is messaged in manageable waves, the people who reply are triaged within minutes, and the people who do not respond to two messages reach a call list that is short enough to actually complete. The front desk spends its time on conversations rather than on dialling through a list, and the clinic can state, with evidence, how many of its overdue patients were contacted and what happened to each one.

The second change is a compliance posture that is better than what preceded it, not worse. Before the build, recall messaging typically happens ad hoc, with staff texting patients from whatever device is nearest and clinical detail appearing in message bodies because it was convenient. After the build, every message is a reviewed template, every clinical detail stays in the clinical system, consent is a field with a date and a source rather than an assumption, suppressions are enforced mechanically, and every send is logged. Automating the process is what makes it auditable.

The third change is visibility of data quality. The count of unreachable patients is usually a shock the first time it is measured, and it is the cheapest problem on this list to fix.

Metrics to watch, monthly:

• Reach rate: share of the due list that could be contacted at all, which is really a measure of consent and contact-detail quality rather than of messaging.
• Consent coverage: share of active patients with current per-channel consent on file. Track this as a standing number and make capturing it part of check-in.
• Booking rate by wave: wave one, wave two, and staff call, measured separately. If wave two adds almost nothing, cut it and move those patients to the call list sooner.
• Attendance rate for recall-booked appointments compared with routine bookings.
• Median days from due date to appointment attended. The headline clinical-operational metric for this build.
• Decline rate, watched for increases, which usually mean the messaging is landing badly rather than that patients have changed their minds.
• Opt-out rate, which in a clinical setting should be very low; anything above a trickle means the frequency or tone is wrong.
• Unreachable count and correction rate: how many bad records were found and how many were actually fixed in the clinical system.
• Inbound reply triage time, split between the urgent and non-urgent branches. The urgent figure should be measured in minutes and reviewed by name.
• Staff call list completion rate: the honest measure of whether the list size was set realistically.

Before anything is built

This build touches protected health information, and the sequencing of the preparation matters more here than in any other guide in this knowledge base. The following should be settled before the first workflow is created, not alongside it.

• A signed business associate agreement must be in place with the platform provider, and with any other vendor in the path that will handle protected health information. The messaging carrier arrangement, any integration layer used to move the due list, any storage the export passes through, and any tool used to read or report on the data. No protected health information should flow into any system until that system's agreement is executed. A business associate agreement is not a formality; it is what defines the vendor's obligations, what they may do with the data, how they handle a breach, and what happens to the data when the relationship ends. If a vendor in the chain will not sign one, that vendor must be removed from the path rather than used anyway.
• A minimum-necessary determination, written down: which fields the messaging layer receives, and why each one is needed to do the job. Build the import to reject anything else. The practical test to apply to every field is whether the message or the booking could be delivered without it. If it could, the field does not belong in the messaging layer. A diagnosis, a procedure code, a test name, a medication, a clinical note, and a free-text reason all fail that test.
• A message-content standard, agreed with whoever is accountable for privacy at the clinic, stating plainly that no outbound message may name or imply a condition, a test, a treatment, a medication, a department that implies one, or a reason for the recall. Every template gets reviewed against that standard before launch, including subject lines and the text of any link. The working test is simple: if a family member, a flatmate, or a colleague picked up the phone and read the message, would they learn something about the patient's health? If so, rewrite it.
• Per-channel consent, documented, with a date and a source. Decide what the clinic treats as valid consent for SMS, for email, and for voice, and how it is captured and refreshed. Patients with no consent on file are reached by post or in person, not messaged anyway on the grounds of being overdue.
• A named clinical contact for escalations, with a defined response commitment, and a named deputy. The urgent branch of Workflow 5 is only as good as the person it reaches.
• Role-based access: decide who can see the recall records, the conversation logs, and the reporting. Conversation logs contain whatever patients typed, which may be clinical, so they belong inside the restricted scope. Use individual logins, never a shared one, so activity is attributable.
• Audit logging and retention: confirm that access to records and messages is logged, that the logs are retained per the clinic's policy, and that someone reviews them periodically rather than only after an incident.
• A retention and disposal rule for the data held in the messaging layer. The messaging platform is not the medical record and should not become a shadow copy of one; hold the recall working data for as long as the campaign needs it, then dispose of it per policy.
• A breach response plan that covers the messaging layer specifically, who is told, within what time, if a message goes to the wrong patient or a list is sent to the wrong place. The most likely incident in this build is a mis-merged contact, so test the matching logic deliberately before launch.

Integrations and provisioning

• A route from the practice management system or electronic health record to the platform for the due list. A native integration is preferable. Where a file export and an integration layer such as Zapier or Make is the only option, that layer sits inside the protected path and needs its own agreement, its own access controls, and encryption in transit and at rest.
• The clinic's existing main number enabled for SMS, so messages come from a number patients recognize.
• Calendar connections for every clinician whose slots appear on the recall calendars, two-way, with durations matched to visit_duration_code.
• Authenticated email sending domain with SPF, DKIM and DMARC.
• A working postal path: whether a mail-merge process, a print vendor, or letters produced in-house. Without it the no-consent population is simply not reached, which is the quiet failure mode of most recall automations.
• The clinical system's patient portal as the only channel for exchanging anything clinical, referenced from the neutral messages.

Messaging compliance

• A2P and 10DLC registration completed before any volume of SMS is sent in the United States. Register the brand and the campaign, describe the use case accurately as appointment and recall messaging, and submit the actual message templates. Healthcare campaigns attract scrutiny; registering with accurate, non-clinical sample copy is both the honest answer and the one most likely to be approved. Unregistered traffic gets filtered silently, which in this build means patients never hear from the clinic and nobody knows.
• Opt-out handling on every channel, honoured immediately, suppressed at platform level, evidenced with date and verbatim wording, and with opt-out instructions in the first message of any sequence. Handle Spanish and other language opt-out terms if the patient population uses them.
• Quiet hours in the patient's time zone, set conservatively. There is no version of this build where a recall message needs to arrive in the evening.
• Attempt caps: set an explicit ceiling on contact attempts per recall cycle and hold to it. Repeated unanswered outreach is both counterproductive and hard to defend as minimum necessary.
• Marketing versus transactional: keep these as separate consent fields. A recall message is generally treated as care-related rather than marketing, but the line moves depending on jurisdiction, on how the message is worded, and on whether anything is being promoted, so get the classification confirmed rather than assumed, and keep promotional content out of recall messages entirely.
• Review requests: if the clinic chooses to send them at all, they must reference no care received, go only to patients with marketing consent, and be excluded entirely for sensitive visit types. Review-platform terms also prohibit incentivized or gated reviews.

Operational discipline after launch

• Review every template quarterly against the message-content standard, because templates drift as staff edit them.
• Re-test the import's field rejection whenever the clinical system is updated or the export is changed by anybody.
• Audit a sample of sent messages monthly against the no-clinical-content rule.
• Review the access list whenever staff join or leave, on the day, not at the next review.
• Keep the suppression lists current, particularly deceased-suppress, and make updating it part of the clinical team's routine rather than an afterthought.

None of the above is legal advice, and this guide describes operational practice rather than compliance obligations. Privacy rules, messaging registration requirements, consent standards, state and national health-information law, and retention obligations vary by jurisdiction and change over time, and how they apply depends on the specific clinic, its covered status, its vendors, and its patient population. Confirm the specifics. Business associate agreements, what counts as minimum necessary for this clinic, consent wording, message content, retention periods, and breach obligations. With the clinic's own counsel and privacy officer before anything goes live. To scope a build for a specific clinic, book a call at bookings.appbo.io.