UK optical records are Article 9 health data. Five checkpoints — GOC, PECR, DSPT for GOS practices, ICO Code — before WhatsApp automation goes live.
The free WhatsApp Business App and the WhatsApp Business Platform (the Cloud API accessed through a Meta-approved Business Solution Provider) are two different products with two different regulatory footprints. The app is designed for a single device, one operator at a time, and Meta's own terms restrict it to businesses that message a small number of contacts manually. It is unsuited to a practice managing hundreds of active patient records, both because of scale limits and because message content sent through the app is not covered by a Business Solution Provider's data processing agreement — the practice is effectively communicating consumer-to-consumer over Meta's infrastructure. The Cloud API, by contrast, provides a documented data processing agreement (see Meta's WhatsApp Business Terms of Service and the accompanying Business Solution Terms), audit-grade message logs held by the BSP, and per-template compliance under Meta's own approval workflow. For an optical practice handling health data, the API is not an upgrade tier — it is the only route that produces the evidence trail the ICO will ask for after a subject access request or a breach notification. Practices already using the free app for patient reminders should treat that as an interim arrangement, not a permanent solution.
The General Optical Council's Standards of Practice for Optometrists and Dispensing Opticians (in force since April 2016, with the current guidance last updated in 2024) sets Standard 14: Maintain confidentiality and respect your patients' privacy. The associated guidance is explicit that confidentiality applies to all forms of communication — spoken, written, and electronic — and that a registrant must take active steps to ensure that patient information is not disclosed to third parties without a lawful basis. Two practical consequences follow for WhatsApp automation. First, template content matters: a recall message that reads 'Your annual glaucoma review is due' discloses a clinical condition to whoever has physical access to the recipient's phone (family members, employers on shared devices), which is a broader disclosure than a neutral 'Your next appointment is due — please book online'. Templates should be drafted so the message body does not reveal clinical detail. Second, verification matters: a WhatsApp number in a patient record may have changed hands, may be shared with a partner, or may belong to a parent who booked on behalf of a child years earlier. The Standard 14 obligation to protect confidentiality means the practice should refresh consent-and-contact-preference at renewal appointments and keep a mechanism for patients to update or withdraw. GOC Standard 11 (record-keeping) further requires that the fact of a WhatsApp communication and its content are retained as part of the patient record, which in practice means the BSP export must land in the practice management system or a documented archive.
Optical patient data is health data. Under UK GDPR Article 9(1) it is special-category data and its processing is prohibited unless one of the ten Article 9(2) conditions applies — for a practice, typically 9(2)(h) (provision of health care) for clinical processing, or 9(2)(a) (explicit consent) for anything that goes beyond direct care. This is a separate and additional test to the Article 6 lawful-basis test, and both have to be satisfied. Where WhatsApp automation is used to send a message that is genuinely necessary to deliver care the patient has already contracted for — appointment confirmation, spectacle-ready notification, post-fitting comfort check — the ICO's 2021 Direct Marketing Code treats this as a service message rather than direct marketing, and PECR's opt-in requirements for electronic marketing do not apply. Where the message promotes something the patient has not asked for — a lens upgrade offer, a private paediatric optometry service, a two-for-one frame promotion — it is direct marketing under Regulation 22 of PECR and requires prior opt-in consent that is specific, informed, and freely given, with a clear withdrawal mechanism on every message. Practices commonly get this wrong by treating a general 'we may contact you about your care and offers' consent line as covering both. The ICO's guidance is that consent for marketing must be separately captured. A defensible workflow keeps clinical and marketing templates on separate categories in the BSP console, with different consent flags on the patient record driving which category the automation is permitted to send.
A practice that provides General Ophthalmic Services — NHS-funded sight tests under the GOS contract, including free sight tests for under-16s, over-60s, patients on qualifying benefits, and those with certain clinical conditions — sits inside the NHS data-handling regime. The Data Security and Protection Toolkit (DSPT), operated by NHS England, is the annual self-assessment that documents compliance with the 10 National Data Guardian standards. Practices submitting GOS claims through the Primary Care Support England (PCSE) portal are already inside this scope. If a WhatsApp workflow reaches into GOS-related records — for example, a recall reminder that pulls patient details from the practice management system that also holds GOS claim data — the workflow itself is a system in scope for the DSPT submission. Concretely, this means the BSP must be documented as a processor, a data flow diagram must reflect the WhatsApp path, and any breach must be reported through the DSPT incident tool as well as to the ICO within 72 hours. Practices that do only private work, and do not submit GOS claims, are not obligated to complete the DSPT, but the underlying UK GDPR obligations still apply — the DSPT simply formalises them for the NHS side. Practices commonly assume that because WhatsApp is 'end-to-end encrypted' it sidesteps DSPT scope. The DSPT applies to the practice's processing, not to WhatsApp's transport layer, so this is not correct.
The last checkpoint is procedural and is where most implementations quietly break. The consent to receive WhatsApp messages — and the separate consent to receive WhatsApp marketing — must be captured at a moment when the patient can actually read and understand what they are agreeing to, and the record of that consent must survive a subject access request in a defensible form. Three practical patterns work. First, an updated new-patient registration form (physical or digital) with two clearly separated tick boxes: one for service messages via WhatsApp (pre-ticked is not lawful — the boxes must start unchecked), one for marketing via WhatsApp, each with the phone number the consent applies to. Second, a re-consent flow for existing patients on their next visit — the front desk asks explicitly at check-in, and the practice management system records the operator, timestamp, and version of the consent language. Third, an in-message opt-out that actually works: every marketing template must carry a documented STOP-equivalent flow, and the BSP must be configured so an opt-out reply automatically flips the consent flag on the patient record and stops future marketing sends. Recall response rates typically improve when a practice moves recall from post to WhatsApp — the Association of Optometrists has covered this in its business-support materials — but the improvement is only defensible if the consent architecture underneath it is airtight. A well-run practice will keep an annual internal audit of consent records against actual messages sent, and will document the audit as part of its Record of Processing Activities under UK GDPR Article 30.
A UK optical practice that has cleared all five checkpoints ends up with a specific and defensible stack. On the messaging side: WhatsApp Business Platform (Cloud API) accessed through a BSP with a signed data processing agreement and evidence of processor DSPT alignment if the practice does GOS work. On the template side: neutral clinical templates that do not reveal condition detail, separate categories for service and marketing, and template approval status tracked in the BSP console. On the record side: WhatsApp inbound and outbound messages archived into the practice management system so they form part of the patient record for GOC Standard 11 purposes. On the consent side: dual tick-boxes at registration with re-consent at renewal, a working opt-out flow, and an annual internal audit reconciling sent messages against consent flags. On the escalation side: a documented route from a patient's inbound WhatsApp message into either a booking system (routine) or a clinical triage flow (urgent — sudden vision loss, painful red eye, foreign body — where the correct answer is 'please phone the practice now or attend a local eye casualty'). The last of these is the one automation cannot solve: a WhatsApp bot must never present itself as a triage service for potentially sight-threatening presentations, and both the GOC guidance on scope of practice and the AOP's clinical guidance are clear on the point.
Data + numbers referenced in this article are sourced from these public documents:
BossBot runs WhatsApp appointment and recall workflows through the Meta Cloud API with per-tenant data isolation and full audit-grade message logs — the record trail an ICO or DSPT reviewer will actually accept.
See BossBot for UK healthcare practicesNot ready to sign up yet? Try the free demo →