A text to a patient looks like the smallest possible thing — eleven digits and a sentence. Under UK GDPR it is processing of personal data, and the moment the patient replies “tooth pain since last night”, it is processing of special category health data. If a tool sends those texts in your practice's name, your practice carries the obligations. Here is what needs to be in place, in plain English.

This article is educational, not legal advice. Our own privacy notice and terms carry a “draft — pending solicitor review” banner for exactly that reason: written diligence first, professional review before production.

Who is responsible: controller vs processor

Your practice decides why and how patient data is used, so the practice is the data controller. A messaging tool acting on your instructions is a data processor — and UK GDPR Article 28 requires a written Data Processing Agreement between you before any patient data flows. If a vendor will start texting your patients without signing one, that is the red flag, not a convenience.

Lawful basis — and the health-data layer

Following up a patient's own missed call is typically grounded in Article 6(1)(b) (steps the patient has requested) or 6(1)(f) (the practice's legitimate interest in returning enquiries — which needs a documented assessment). When the content turns clinical, Article 9 applies on top: health data needs a separate condition, usually 9(2)(h) — provision of health care. The practical consequence: a missed-call follow-up is defensible; using the same channel for promotions is a different activity with different rules (PECR), and a tool should not quietly blur the two.

STOP is law, not politeness

A patient who texts STOP (or STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT) must stop receiving automated messages — immediately, with at most a single confirmation. In our pipeline, opt-out keywords are honoured before every other rule, including the AI, and opting back in takes an explicit START. Whatever tool you evaluate, ask to see where in the pipeline opt-out sits. If it sits after the AI, it is in the wrong place.

The questions to ask any SMS tool

  • Where does patient data live at rest?EU/UK residency, and if any sub-processor is in the US (AI providers usually are), is the transfer covered by SCCs and limited to what's necessary?
  • Who are the sub-processors? A complete, named list belongs in the DPA, with notice before new ones are added.
  • Is patient data used to train AI models? The answer must be no, in writing.
  • What is the retention window — and can the practice negotiate a shorter one?
  • Can you serve a DSAR? Export and erasure for one patient, on request, within the 30-day statutory deadline.
  • Is there an audit trail?When the ICO or a patient asks what happened, “we think” is not an answer.
  • Is the practice's ICO registration current? A small annual fee, and the foundation for everything above.

How we answer the same questions

EU data residency (Supabase Frankfurt, Twilio Ireland), a named sub-processor list, no training on patient data, 24-month default retention that the DPA can shorten, DSAR export and erasure built in, an audit event on every state change, and STOP honoured first. The detail lives on our privacy page — and pilot onboarding starts with the DPA and a clinical safety review, not after them. If you want to pressure-test any of this, book a free demo and bring your most sceptical question.