I'm about to send the prevention newsletter to the over-50 segment. Can you review it?
Patient communications reviewed before they go out.
Patient Communication Reviewer intercepts every patient communication before sending — newsletters, appointment reminders, clinical communications, post-visit follow-ups. Checks against GDPR Art. 9 privacy, medico-legal tone, healthcare regulatory references. Flags problematic phrasing, proposes compliant alternatives.
Patient Communication Reviewer at work.
Two areas for intervention. First: "as we know, your risk level requires attention" is too individual for a mass communication — implicitly reveals a clinical outcome. Proposed: "for those in this age cluster, monitoring is recommended". Second: treatment consent for prevention newsletters absent from the footer — mandatory for this facility.
I accept both. Go ahead with sending.
Changes applied, communication updated. Send authorised. The event is in the runtime audit registry for GDPR Art. 9 inspection by the DPO.
Why it exists.
Patient communication is the most sensitive point of contact between a healthcare facility and a patient. Every email touches sensitive data (special category under GDPR Art. 9) and requires phrasing consistent with the organisation's medico-legal register. An imprecise formulation can generate complaints, inappropriate reactions, regulatory exposure.
How it works before sending.
Patient Communication Reviewer activates before sending. For every patient communication about to leave the facility's system: checks for sensitive data (clinical data in clear text that should not appear), evaluates the medico-legal tone (phrasing consistent with the authorised register), verifies healthcare regulatory references (treatment consent, responsible physician, accessibility).
Three outcomes, never a diagnosis.
Silent pass (the communication goes out without interference), flag (the agent highlights a borderline phrase and proposes alternatives), block (the communication contains a formal violation, sending stops with escalation to the responsible physician or DPO). The agent does not substitute the physician in clinical communication, does not make diagnoses.
Who it serves and where it applies.
Communications manager
Reclaims the time of manual review of every outgoing patient communication. The flow moves from case-by-case approval to structured oversight. Most standard communications pass without interference; flags arrive where they are needed.
Responsible physician
Sees only the cases that require judgement. Appointment reminders, visit confirmations, prevention newsletters on general conditions pass the agent without interference. Attention focuses on clinical communications that require medical evaluation.
Facility DPO
Obtains an inspectable trace of GDPR Art. 9 compliance decisions for every patient communication. The risk of data breach in communication moves from a diffuse risk to an inspectable event via a standard SQL client.
A concrete example.
The system sends a prevention newsletter.
For a private healthcare facility sending 800 patient communications per week, the agent is integrated with the patient communication system via webhook. The system sends the agent a prevention newsletter that will be delivered to 340 patients in the age segment with glucose levels in the monitored range. The creative was prepared by the communications team.
The agent identifies two areas for intervention.
The agent runs the analysis. It identifies two areas for intervention: a phrase too individual in the newsletter body and the absence of the treatment consent reference in the footer. It produces the compliant alternatives. A flag with the two proposals to the communications manager on the Slack channel.
The manager accepts, sending is authorised.
The communications manager accepts the rephrasing, confirms the send. The event — revised newsletter, rules triggered, chosen alternatives, final decision — stays in the runtime audit registry, readable by the DPO via SQL client for GDPR Art. 9 audit.
Configuration and technical resources.
The Patient Communication Reviewer rules are declarative. The facility's compliance team and responsible physician define in a readable format the privacy rules (what constitutes sensitive data, what must be anonymised or aggregated), the authorised medico-legal register (phrasing consistent with the organisation's code of ethics), and the mandatory regulatory references (treatment consent, responsible physician, communication accessibility). The rules live in the customer's repository, versioned, validated at agent startup.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector, topic-guardrail, tool-param-validator
- Native channels
- Telegram, Slack, WhatsApp, OpenAI-compatible HTTP
- Patient communication system integration
- delivered during the project by the Exelab team
- Email and SMS for direct patient communications
- adapter delivered during the project
- MDR-SaMD scope
- the agent does not substitute the physician in clinical communication, does not make diagnoses, does not replace treatment consent
- Healthcare compliance rules
- declarative, versioned in Git, written by the compliance team and the responsible physician
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on the historical communications corpus
- Registry
- immutable, queryable with a standard SQL client (GDPR Art. 9 audit inspectable)
Frequently asked questions about the agent.
Treatment consent is a prerequisite of patient communication, managed by the facility's management system. The agent verifies that the communication is consistent with the recorded consent — a patient who has authorised prevention newsletters vs a patient who has authorised only appointment reminders. The consent-to-communication-type mapping rules are declarative in the customer's repository.
No. The agent verifies that the communication proposed by the facility's team is consistent with the configured compliance rules. The decision of what to communicate to the patient stays with the communications manager and the responsible physician, according to the facility's procedures.
Health data is treated as special category data under GDPR Art. 9. The runtime audit registry traces all agent decisions for inspection by the DPO or the regulator. The retention of patient data is configurable per instance according to the constraint applicable to the facility.
Integration with sending systems — the management system's patient communication module, healthcare-focused email marketing platforms, SMS gateways — is delivered during the project by the Exelab team. The typical pattern is a pre-send webhook: the communication system sends the content to the agent, the agent responds with the outcome (pass, flag, block).
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Patient Communication Reviewer would configure to the healthcare facility's case. Which patient communication system, which compliance rules, which approval flow.