Recare, Reactivation & Benefit Timing
A continuous system that books the next hygiene visit before the patient leaves, reactivates overdue patients with a real reason, and contacts the right patients before their benefits expire.
- Tier
- Flagship
- Build order
- 6th of 7 for dental practices
- Shape of it
- 9 steps, 1 stop rule
- At launch
- Built against your stages, then proven before it runs alone
The problem this solves
"Recall due" is a database status. "Recare booked" is production. Most practices measure the first and assume it means the second. A patient who is due, has received three reminders, and has no future appointment is not in the schedule. They are in a report.
Underneath that, several separate failures get lumped together:
The patient left without a future appointment, so recall is doing work that should have been done at the chair.
The interval in the system is a default rather than the interval the clinician actually recommended.
A cancelled recare visit was never rebooked.
The patient is overdue and sits in a passive queue receiving reminders that nobody follows with a conversation.
A perio maintenance patient is being scheduled and coded as a routine prophylaxis, which is both a clinical problem and a claims problem.
The patient moved or changed their number and the record was never cleaned, so the overdue list is partly fiction.
And separately from all of it: annual maximums and flexible spending accounts reset on a completely predictable date, unused benefit is genuinely lost to the patient, and most practices contact nobody about it until December.
How it works, step by step
Every wait, threshold and branch below is a value we set with you during the build, against your stages and your language. None of it is a default we impose.
- What starts it
- A stop rule, so nothing closes itself
Step 1Trigger
The next recare appointment is booked before the patient leaves, at the clinician's recommended interval. Every system above feeds this one.
Step 2
Every patient carries a status that distinguishes booked, due, overdue, contacted, reactivated, unreachable, and left without booking. That last category is the one most practices cannot see, and it is the one that predicts everything else.
Step 3
Overdue patients are contacted inside the frequency limits in the compliance section, and the message is about their care, not about an offer.
Step 4
Reactivation carries a reason drawn from the record: an interval that has passed, a treatment plan still outstanding, a perio maintenance interval, or a benefit that resets. Not a discount with no argument attached.
Step 5
Benefit timing runs on a schedule, not a campaign. Patients with diagnosed unscheduled treatment and remaining benefit are contacted early enough to actually use it, with the remaining amount checked first rather than asserted.
Step 6
Perio maintenance patients are handled as their own population with their own interval, and never folded into the routine prophylaxis list.
Step 7Stop rule
Anyone contacted twice with no response is rested rather than pursued, and flagged for a person to decide about.
Step 8
Contact details that bounce or fail create a task to clean the record, so the overdue list stops being partly fiction.
Step 9
Review requests go only to patients whose visit actually went well, and never to a patient with an open complaint or an unresolved clinical issue.
How it gets built
Built inside what you already run
- Dentrix
- Eaglesoft
- Open Dental
- Curve
- or whatever your office already runs on
Nothing to log into and nothing to license. If a system needs a record your platform does not hold, we add the field to your platform rather than starting a second one beside it.
This is the actual build order, in the phases its own steps fall into. It runs in supervised mode first, with you approving what goes out, until you are happy with the tone.
- 1
Build
Reconcile the recall population before anything else: booked, due, overdue, and unreachable. The number will not match what the practice believes, and the difference is the first month of value.
Built inside the software you already run, against your stages and your language.
- 2
Build
Make booking recare a required step at appointment close, from System 5.
- 3
Build
Fix the intervals so they carry the clinician's recommendation rather than a system default.
- 4
Build
Separate the perio maintenance population and agree its handling with the hygienist.
- 5
Agree
Write the reactivation reasons from the record and have the dentist approve the ones they consider honest.
The thresholds, the wording and the names are yours. We write them down with you and get the consequential ones signed off.
- 6
Build
Build the benefit-timing schedule against the practice's actual plan mix, and verify remaining benefit before contacting anyone about it.
- 7
Agree
Set the rest rule after two attempts.
- 8
Build
Build the record-cleaning tasks from delivery failures.
- 9
Build
Connect review requests to visit outcome, and exclude any patient with an open issue.
What changes after it goes live
How it runs today
"Recall due" is a database status. "Recare booked" is production. Most practices measure the first and assume it means the second. A patient who is due, has received three reminders, and has no future appointment is not in the schedule. They are in a report.
After this one is live
Recall stops being a list and starts being a schedule. The overdue population shrinks because fewer patients join it, not because more are chased. Benefit timing becomes a planned piece of work in October rather than a panic in December. And the practice can finally distinguish patients who left without booking from patients who are genuinely due, which are two entirely different problems with two entirely different fixes.
How to measure whether it worked
Your arithmeticRun with your numbers, not ours
Three numbers the practice already has: the share of patients who leave without a future hygiene appointment, the size of the overdue population and its historical reactivation rate, and the value of diagnosed unscheduled treatment belonging to patients with remaining benefit this plan year. The first is the leading indicator and almost never measured.
We agree the baseline before anything is built, and we do not take credit for things that were going to happen anyway. There is no figure on this page claiming what we have produced for somebody else, because there is no verified figure to publish.
What we will not do
This is from the same delivery document as everything above it. It is on the page because a supplier who has not thought about it will not tell you, and you would find out later.
Every system here touches protected health information and sends automated messages to patients in the United States. Two separate regimes apply and satisfying one does not satisfy the other. HIPAA governs the information and the vendors. The TCPA governs the calls and texts.
HIPAA
A dental practice transmitting claims or eligibility electronically is a covered entity, and its patient information is PHI.
- A signed Business Associate Agreement with every vendor that creates, receives, maintains or transmits PHI, before that vendor touches any of it. This includes the messaging platform, the SMS gateway, the hosting provider, the CRM, any analytics tool and any AI service in the path. The narrow conduit exception covers transmission-only services with no routine access; it does not cover an ordinary patient-engagement or automation platform.
- Minimum necessary. Send the fields the system needs, not the chart. A reminder needs a date, a provider and a contact number. It does not need a diagnosis.
- What goes in an unencrypted message. HIPAA does not ban PHI in SMS or email, and HHS explicitly permits appointment reminders without authorization. What does not belong in one: diagnoses, clinical findings, procedure names that reveal sensitive treatment, radiographs or images, medication details, insurance or balance information, and anything about a second patient.
- Offer and honour confidential communication requests. A patient can ask to be contacted a different way, and that request has to reach every system.
- Treatment, payment and operations do not need an authorization. Recall, appointment reminders, pre- and post-operative instructions, and a request to schedule treatment already recommended are ordinarily treatment-related. Promotion is different. "Book this month and save" is marketing whatever list it went to, and calling a sequence a recall does not make it one if the purpose is to sell.
- Financial remuneration changes the analysis. If a third party pays the practice or a vendor for a communication, HIPAA's marketing rules can apply to something that would otherwise be operations.
- Audit logs, role-based access, retention limits, a documented risk analysis and an incident response procedure, all of them boring and all of them the first thing asked for if anything goes wrong.
TCPA
HIPAA permission is not TCPA consent.
The FCC's healthcare treatment exemption can reduce the consent standard for messages from a covered entity, but it is narrow and it comes with hard conditions that shape every sequence in this playbook:
- Only to the wireless number the patient gave the practice.
- The provider's name and contact information in the message.
- Concise: generally no more than 160 characters for a text.
- No cost to the patient.
- One message per day, and no more than three per week, counting calls and texts together.
- An easy opt-out, honoured immediately.
That frequency limit is a design constraint, not a footnote. It is substantially stricter than what a normal marketing automation would send, and it means every sequence in this document has to be sparse and every message has to earn its place. A five-touch week is not an aggressive cadence here. It is non-compliant.
The exemption does not cover advertising, promotional offers, solicitation of new services, billing or debt collection, or anything unrelated to the patient's care. Those need consent on the ordinary standard, captured and documented per channel and per purpose. A phone number in the chart is not blanket permission for promotional automation.
The line that is never crossed
No automated system answers a clinical question. Ever. Not whether it will hurt, not whether a symptom is normal, not what medication to take, not whether treatment is needed. Every one of those routes to a clinician, and the patient is told a person is being reached. Every classifier in this playbook errs toward escalation, and every one of them is tested against deliberately ambiguous messages before it goes live.
Nothing in this document is legal, clinical or regulatory advice. State privacy and telemarketing law, dental board advertising rules, payer contracts and the exact sending technology can each add requirements, and this area has moved more than once recently. Every template stating a clinical or commercial term requires review by the practice's own counsel before it goes live.
Nothing here is legal advice. Rules in this area have moved more than once recently, and every template that states a commercial term or a guarantee goes to your own counsel before it goes live.
Seven systems fordental practices.
We build one at a time and prove it moved before starting the next. The tiers are the dependency order, not a price list.
Tier 1Foundational
Nothing arrives late or unowned. These come first because everything above them assumes they are true.
Tier 2Growth
The recoverable money. These work the pools the foundational systems have made visible for the first time.
Tier 3Flagship
One connected system end to end, plus what the owner reads on a Monday. Only once the pieces are proven individually.
- 5The Complete New Patient JourneyThe flagship, once the pieces are proven individually.
- 6Recare, Reactivation & Benefit Timingyou are hereCompounds everything above, and depends on the required booking step System 5 introduces.
- 7The Owner's Morning BriefOnly meaningful once there are systems to report on.
The tiers are the dependency order for dental practices, not a price list. Most firms do not start at the first one, because the order is a default and the call is where it gets changed.
A note on sequencing this trade
Do not build all seven at once.
Each stage is proven against its agreed measure before the next begins.
One sequencing note specific to dentistry. System 4's existing backlog should be worked by hand in week one, before any of it is automated. It is the fastest money in the engagement, it proves the value of the whole programme before a single sequence goes live, and working it manually is what tells you what the five branches should actually say.
Back to the dental practices overview for the stage map and where these fit.
Is this the oneyou need first?
Often it is not. On the call we look at what is actually costing you most right now, which is frequently a different system from the one that brought you to this page. If there is nothing worth building yet, we will say so.