Let’s talk

Unified patient messaging

A prototype and full delivery proposal for a UK medical centre to bring WhatsApp, SMS, email and social messages into one compliant inbox.

Category
Healthcare, prototype and proposal
Status
Proposal
Period
Apr to May 2026
Role
Design, build, operate
Stack
React 18ViteTypeScriptTailwind CSSRechartsProposed: Next.js 15Proposed: Supabase (EU)Proposed: WhatsApp Cloud APIProposed: Anthropic ClaudeProposed: Vercel
Three-column messaging inbox with a conversation list, a patient thread mixing WhatsApp and SMS messages, an AI-drafted reply awaiting approval, and a patient panel with the next appointment. All names and content are fictional.

Context

A UK private medical centre had patient messages arriving on WhatsApp, Instagram, SMS and email, with reception copying details back and forth into the practice management system. Things slipped through. Health data is special-category data under UK GDPR, so any tool here is a data protection problem before it is a software problem.

What I built

In two days I built a clickable prototype so we could argue about something real instead of a wireframe: a three-column inbox with the patient record beside the thread, channel switching on the composer, and an AI-drafted reply the receptionist approves rather than writes. It ran on fictional data and the clinic signed it off.

The proposal that followed mattered more. I wrote a costed eight-week build plan on Next.js and an EU-hosted Supabase, with the Meta WhatsApp Cloud API used directly rather than through a reseller, and a compliance pack alongside it: a processor agreement drafted to Article 28, a DPIA template to be signed before pilot, all eight Caldicott principles mapped to features, a seven-year audit log, and a rule that a patient’s name, date of birth and NHS number never reach the language model.

Proposed patient messaging architecturePatients message through the Meta WhatsApp Cloud API in the EU region; an inbound webhook verifies signatures and deduplicates before Next.js server actions write to an EU Supabase Postgres database with row-level security. Reception works in a unified inbox fed by realtime and web push. Draft requests pass a data minimisation step before Claude, which never sends. The database feeds a seven-year audit log and encrypted EU backups.writesrequest draftPatientWhatsApp first; SMS, email laterWhatsApp Cloud APIMeta, EU regionInbound webhooksignature check · dedupeNext.js on Vercelserver actions, no API tierReceptiondesktop + mobile PWAUnified inboxthread · patient panel · draftsData minimisationstrip name, DOB, NHS no.Claude draftnever auto-sendsSupabase Postgres (EU)row-level security by orgRealtime + Web Pushno third-party pushAudit log7-year retentionEncrypted backups30 days · EU · RPO 24h
Proposed design. WhatsApp only in the first release; SMS, email and social channels follow one at a time.
  • Data store
  • Model or agent
  • Check or gate
  • Person
  • External service

I scoped the first release to WhatsApp only and kept the practice management integration out, so a slow third-party API could not sink the pilot.

Outcome

The prototype was approved. The build was not commissioned, and the honest lesson is that a good proposal is not a signature. What remains is a two-day prototype and roughly a hundred pages of delivery, compliance and pricing documentation I can reuse for the next clinic.

What I’d do differently

Build the prototype in the target framework instead of budgeting a week to migrate it. Use neutral placeholder content in demos from the start; realistic clinical text made the prototype compelling and unpublishable. And run Meta business verification in parallel with the sales conversation, since it costs nothing and was the top risk on the plan.

Recording

Prototype walkthrough on fictional data. Conversations, regenerating a draft, and the automations screen.

Screens