Consent and Channel Choice for SMS, Email and WhatsApp Recalls

Ask a practice manager whether they can text a patient about an overdue check-up and you will usually get one of two answers. Either “yes, they ticked the box at registration,” or “no, they opted out of marketing in 2021.” Both answers come from the same file, and that file is the wrong one.

Recall contact is not governed by marketing consent. It is governed by a messaging preference record: a dated, per-channel, per-purpose statement of how a named patient has agreed to be contacted about their own care. Most UK practices do not hold one. They hold a marketing tick box from a paper registration form, a mobile number of unknown provenance, and a recall method field in the practice management system that nobody has audited since the software was installed.

That gap is survivable when a receptionist is manually working a recall list and applying judgement. It stops being survivable the moment an automated system is sending 3,000 messages a month across three channels without a human looking at any of them.

Three records, routinely collapsed into one

There are three separate things a practice needs on file, and they answer different questions.

Record	Question it answers	Where it usually lives
Identity and contact details	Is 07700 900412 actually this patient’s phone, and is it current?	Patient demographics, PMS
Messaging preference	Which channels may we use to contact this patient about their care, and when did they tell us?	Usually nowhere complete
Marketing permission	May we promote whitening, Invisalign, the new hygienist, the membership plan?	Registration form tick box

The middle row is the one that governs recalls. A patient can refuse every marketing message you will ever send and still expect, quite reasonably, a text when their six-month check-up is due. Conversely, a patient who happily consented to marketing in 2018 may have changed their number twice, moved to WhatsApp, and never told you.

PECR (the Privacy and Electronic Communications Regulations 2003) regulation 22 covers unsolicited direct marketing by electronic mail, which includes SMS and email. It requires consent, or the narrow “soft opt-in” where details were collected during a sale or negotiations for a sale. A genuine care recall, “your check-up is due, please call to book,” is not marketing under the ICO’s own test: it administers an existing care relationship rather than promoting something. It sits under UK GDPR Article 6(1)(e) or 6(1)(f), with Article 9(2)(h) covering the health data.

So why does this matter if recalls aren’t marketing anyway? Because practices use the marketing flag as a proxy for permission, and it fails in both directions. Suppressing recalls for everyone who declined marketing means under-recalling patients you have a clinical duty to contact at NICE CG19 intervals (three to twenty-four months for adults, three to twelve for under-eighteens). Meanwhile, the same practice sends a message that says “your check-up is due, and ask us about our £45 hygiene offer,” which is a marketing message wearing a recall’s coat, to a list that never consented to marketing at all.

Worth noting for NHS practices: soft opt-in is shaky ground when treatment is NHS-funded, because there is arguably no “sale” to hang it on. Mixed practices have the messier version of the problem, where the same patient has an NHS course of treatment and a private hygiene plan, and the recall run does not distinguish.

Two more confusions I see monthly. The National Data Opt-Out does not apply to direct care communications, so it is not a reason to suppress a recall. And completing the Data Security and Protection Toolkit by 30 June does not mean your consent records are sound; the DSPT asks whether you have a process, not whether your data is right.

What an audit actually turns up

Export three columns from your PMS and count. In Software of Excellence EXACT that means the contact preferences alongside the recall method field; in Dentally it’s the communication preferences block; in Carestream R4 and Systems for Dentists the fields are named differently but sit in the same place. Here is the shape of a real export from a two-site mixed practice with 4,200 active patients:

active patients                                   4,200
with a mobile number on file                      3,847
recall method set to SMS                          3,112
mobile verified in the last 24 months             1,004
dated, channel-specific messaging preference        631
marketing consent recorded with a date              418
opt-out flag set BUT still in the SMS recall run     87
mobile field containing a landline or duplicate     203

Read the fourth and fifth rows together. The practice was texting 3,112 patients and could evidence a current preference for 631 of them, about 20%. That ratio has been remarkably stable across the practices we have looked at: the number with a dated, channel-specific record is almost always under a quarter of the number being messaged.

The 87 in row seven are the genuinely dangerous ones. Someone opted out, reception updated the marketing flag, and nobody touched the recall method field, so the automated run kept firing. One of those patients complains to the ICO and you have a documented instruction you failed to act on. The penalty ceiling for PECR breaches used to be £500,000; the Data (Use and Access) Act 2025 aligned it with UK GDPR levels, up to £17.5m or 4% of turnover. Nobody expects a maximum fine against a two-surgery practice, but the enforcement appetite and the reputational exposure both changed shape last year.

WhatsApp is a permission, not a channel setting

This is where practices get caught fastest, because WhatsApp feels like an upgrade to SMS and is legally nothing of the sort.

Meta’s Business Messaging Policy requires opt-in obtained on any channel, but it must be explicit that the patient will receive messages on WhatsApp, and it must name your business. “I consent to be contacted electronically” does not cover it. Neither does a mobile number harvested from an FP17. If you import 3,100 mobiles into Twilio, 360dialog or Infobip and start sending a utility template, you are sending to people who never agreed to WhatsApp specifically.

The mechanics punish you quickly. WhatsApp assigns your sender a quality rating of High, Medium or Low, driven largely by block and report rates. Messaging limits step through 250, 1,000, 10,000 and 100,000 unique recipients per 24 hours. A cold import that draws blocks pushes you to Medium, then Low, and your limit drops back to 250 per day, which is useless for a recall book of 3,000. Template category matters too: a recall framed as a reminder can pass as Utility, but add an offer and Meta reclassifies it as Marketing, which costs more and carries stricter opt-in expectations.

On cost, UK SMS through an aggregator like Textlocal, Firetext or TextAnywhere runs roughly 2.5p to 4p per message part, and a recall with a booking link usually spills past 160 GSM characters into two parts at 153 each. Three thousand recalls a month, two parts, 3.2p: about £192. WhatsApp utility templates in the UK land in a similar per-message range under Meta’s current pricing. The channel decision is not really about cost. It is about which permission you can actually evidence.

Where AI front-desk tools walk into the gap

Automated recall systems are built to escalate. No email open after 72 hours, send an SMS. No SMS reply after 48 hours, try WhatsApp. That cascade is exactly the behaviour a messaging preference record exists to constrain, and most tools will happily run it against whatever fields you mapped during onboarding.

I have seen a practice map a single “contactable: Y/N” column into a recall platform and then wonder why patients who had explicitly asked for post only were receiving WhatsApp templates. The tool did nothing wrong. It was given one bit of information and asked to make a three-channel decision. If you are building out wider front desk and recall automation, the preference schema is the thing to fix before the workflow, not after.

The same principle applies to the AI stack more broadly. Triage bots that message patients about symptom follow-up, and clinical-note tools like Kiroku, sit inside the same lawful basis question. Radiograph AI such as Pearl’s Second Opinion, Overjet or VideaHealth does not touch messaging at all, but the reporting layer bolted on top of it often does: “your radiographs showed early caries, book a review” is a care communication that needs a channel permission behind it.

Rebuilding the record

Start with the field structure, not the data. You need, per patient: channel (SMS, email, WhatsApp, post, phone), purpose (care recall, appointment reminder, treatment follow-up, marketing), permission state, the date it was captured, and the method of capture. Five fields, four of which most PMSs can hold in custom fields if the native ones are too coarse.

Capture happens at the chairside and on the confirmation, not on a registration form nobody reads. When a patient books their next check-up, the question is one line: “we’ll remind you when it’s due, is text still best, or would you prefer email?” Log the answer with today’s date. Within a single recall cycle you will have refreshed preferences for most of your attending base, and the non-attenders are precisely the cohort you should be reviewing anyway.

For the backlog, run a one-off preference confirmation to your existing SMS list before you automate anything. It is a service message about how you communicate, it belongs to the care relationship, and it gives every recipient a genuine opt-out. Expect somewhere between 8% and 15% of numbers to hard-fail on delivery, which tells you something useful about the 203 landlines-in-mobile-fields sitting in your export.

Then ask your vendor three questions with numbers attached. How many distinct permission states can the system store per patient? What happens to a queued message when a preference changes mid-cycle? And can you produce, for a single named patient, a timestamped log of every message sent and the permission record in force at the time of sending? If the answer to the third is no, you cannot answer an ICO subject access request about your own recall system, and that is a procurement problem rather than a compliance one.

The practices that get this right tend to discover something they were not looking for: recall response rates climb, because messages arrive on the channel the patient actually reads.