EasyMed Clinician Terms and Data Processing Agreement

Version 2026-10-30 · effective 30 October 2026

This document has three parts:

Part 1: Clinician Terms of Service. The commercial terms for using EasyMed.
Part 2: Data Processing Agreement (DPA). Meets UK GDPR Article 28 for clinical data that EasyMed processes on the clinician's behalf.
Part 3: Sub-processor list.

"EasyMed" means Ziad Soliman, a sole trader in the United Kingdom, trading as EasyMed (email ziad@easymed.uk). "Clinician" means the psychiatrist, or the clinic or practice company, that signs up. Where a clinic signs up, the clinic is the Clinician and is responsible for its staff's use.

EasyMed is currently in a pilot with invited clinicians. During the pilot, payments run in Stripe test mode, so no real money is taken.

PART 1: CLINICIAN TERMS OF SERVICE

1. What EasyMed is

1.1 EasyMed is software for running a private psychiatry practice. It provides booking, rescheduling and follow-ups, payments, refunds and receipts, video consultation links, secure messaging with patients, pre-assessment questionnaires, clinical notes, medication and titration records, prescription tracking, GP letters, a record-access audit trail, calendar sync and feeds, data export, and AI drafting of reports.

1.2 EasyMed does not provide healthcare. The Clinician provides all clinical care, and is solely responsible for clinical decisions, prescribing, safeguarding, record content and their professional obligations.

2. Clinician eligibility and verification

2.1 The Clinician confirms that every doctor using EasyMed:

(a) holds full GMC registration with a licence to practise, and is on the Specialist Register or otherwise appropriately qualified for the care they offer;
(b) has adequate medical indemnity, as GMC rules require;
(c) is registered with the CQC, or practises under a CQC-registered provider, where their services are a regulated activity;
(d) holds their own ICO data protection registration as a controller.

2.2 Before a doctor can be booked, EasyMed checks:

(a) the GMC register: registration with a licence, a psychiatry specialty, no suspension or provisional-only registration, and a name match. The automatic check runs against EasyMed's own copy of GMC register data, which an EasyMed admin currently enters by hand; an EasyMed admin also confirms Specialist Register entry and the absence of conditions, undertakings and warnings on the GMC's online register;
(b) medical indemnity: an in-date certificate, with the provider, policy number and expiry date;
(c) identity: a short video call with an EasyMed admin, who sees the doctor's passport or driving licence and records a checklist.

EasyMed does not use face recognition or any other biometric check. Approved doctors are re-checked every month against EasyMed's copy of the register data, so the re-check only catches changes once that copy has been updated. EasyMed emails reminders 30 and 7 days before an indemnity certificate expires, and suspends the doctor automatically when it expires or when the register shows suspension, no licence or no registration. These checks support platform trust. They do not replace the Clinician's own regulatory responsibility.

2.3 The Clinician must tell EasyMed within 2 working days of any GMC sanction, condition, suspension, or loss of indemnity or CQC registration.

3. Fees, payments and payouts

3.1 EasyMed's fees, if any, are as agreed in writing between EasyMed and the Clinician.

3.2 Patient payments are taken by EasyMed through Stripe, using EasyMed's own Stripe account. During the pilot Stripe is in test mode.

3.3 Payouts to the Clinician are made as agreed in writing between EasyMed and the Clinician, net of fees, refunds and chargebacks.

4. Cancellation and refund settings

4.1 Each Clinician can set their own cancellation policy in EasyMed: a refund window (how long before the appointment a patient can cancel for a full refund, up to 30 days) and a late cancellation fee (a percentage of the fee kept when the patient cancels inside the window). The default is a 48-hour window and a 100% late fee, which means a full refund at 48 hours or more and no refund under 48 hours. If the Clinician cancels in EasyMed, the patient is refunded in full automatically. Refunds are worked out and sent to Stripe automatically. The Clinician can also issue a full or partial refund by hand from EasyMed.

4.2 The Clinician must make sure their policy is fair under the Consumer Rights Act 2015 and is shown to patients before they pay.

5. AI drafting tool

5.1 The AI tool produces drafts for the Clinician's review only. It is designed and instructed not to suggest diagnoses, treatments or risk levels. Its intended purpose, shown with every report, is: "Drafting aid that organises information supplied by the patient and clinician for clinician review. It does not provide diagnoses, treatment recommendations or risk predictions. The clinician is responsible for all clinical content."

5.2 The Clinician must read, correct and approve every draft before it is finalised, shared or relied on. EasyMed leaves the diagnosis and plan sections empty, and a report cannot be finalised until the Clinician has written them. The Clinician is responsible for the final content.

5.3 The Clinician must not use the tool to generate diagnostic or treatment recommendations, and must report any output that appears to do so to ziad@easymed.uk. EasyMed treats such reports as clinical safety incidents.

5.4 The Clinician must give patients the AI information in the patient privacy notice, and respect a patient's request not to use the tool.

6. Clinician responsibilities

The Clinician must:

(a) keep login details secure and turn on multi-factor authentication when it is available (EasyMed does not offer it to clinicians yet);
(b) give only staff who need it access, and remove leavers promptly;
(c) give patients a privacy notice (EasyMed provides a template);
(d) set retention periods for their clinical records (EasyMed's defaults follow the NHS Records Management Code);
(e) not use EasyMed for emergencies or crisis care, and have their own out-of-hours and risk procedures;
(f) complete a deployment-side clinical risk assessment (DCB0160-style) for their use of EasyMed;
(g) secure messaging is switched on by default for every Clinician. Unless they turn it off, they must set a realistic expected reply time and auto-reply, check urgent-attention alerts promptly, and turn messaging off when they cannot monitor it. Messages are not monitored by EasyMed. The crisis keyword check is a safety net and can miss messages;
(h) send GP letters themselves. EasyMed prepares the letter but does not send or store it;
(i) choose and control the video service used for their appointments (Google Meet through their own Google account, or another service whose link they give).

7. Availability and support

During the pilot EasyMed runs on a single server with nightly backups. EasyMed is not designed as a sole store of record, so the Clinician should keep their own records of anything essential, for example by using EasyMed's data export.

8. Liability

8.1 Neither party limits liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot legally be limited.

8.2 EasyMed is not liable for clinical decisions, for the content of approved records or reports, or for the Clinician's breach of professional duties.

9. Term and termination

9.1 Monthly rolling; either party may end with 30 days' notice.

9.2 EasyMed may suspend access immediately for GMC suspension, loss of indemnity, a security risk, or serious breach.

9.3 On termination, Part 2 clause 11 (return and deletion of data) applies.

10. General

English law; courts of England and Wales.

1. Roles

1.1 For Clinical Data (defined in Annex A), the Clinician is the controller and EasyMed is the processor.

1.2 For Platform Data (clinician and patient accounts, login and security logs, billing, payments and refunds, the marketplace, doctor search and ratings, doctor verification (GMC checks, indemnity certificates and the identity call), fraud prevention and EasyMed marketing), EasyMed is an independent controller. This DPA does not apply to Platform Data.

1.3 Where a clinic is the Clinician, individual doctors working for it act under the clinic's authority.

2. Processing only on documented instructions

2.1 EasyMed processes Clinical Data only on the Clinician's documented instructions. These Terms, the settings the Clinician chooses in EasyMed, and written instructions from the Clinician count as instructions. This includes transfers outside the UK (Article 28(3)(a)).

2.2 If EasyMed is legally required to process Clinical Data in another way, it will tell the Clinician first unless the law forbids it.

2.3 EasyMed will tell the Clinician immediately if it thinks an instruction breaks data protection law.

2.4 EasyMed will not use Clinical Data for its own purposes. That includes product analytics on identifiable data, AI model training and marketing. Exception: aggregated, anonymised statistics where no person can be identified.

3. Confidentiality

EasyMed ensures everyone authorised to process Clinical Data is bound by confidentiality (Article 28(3)(b)) and has access only as needed. EasyMed's admin screens do not show clinical notes, questionnaires, reports, medication or prescription records, or messages; admins can see basic appointment details (patient name, phone number, doctor and time) and can cancel or change an appointment. Views and changes of clinical notes, questionnaires, reports, medication and titration records, prescription records, messages, GP details and letters, the patient record view and reschedules made through the application are logged in an audit trail that the Clinician can see. Care status notes, and direct database or server access by the people who run EasyMed, are not logged in that audit trail.

4. Security (Article 32)

4.1 EasyMed will put in place and maintain the measures in Annex B.

4.2 Disclosure: internal security reviews found serious issues. A review on 30 October 2026 confirmed that the critical and high items found in the code are closed. Still open: rotation of credentials that were once stored in the code repository, encryption of messages and clinical notes in the database, completing server hardening, and an independent penetration test. EasyMed commits to closing these before processing any real patient's Clinical Data, and to confirming this to the Clinician in writing.

5. Sub-processors

5.1 The Clinician gives general written authorisation for the sub-processors listed in Part 3.

5.2 EasyMed will give at least 30 days' notice of any new or replacement sub-processor by email and by updating Part 3 on easymed.uk/clinician-terms. The Clinician can object on reasonable data protection grounds. If the objection cannot be resolved, the Clinician may end the agreement without penalty and receive a refund of prepaid fees.

5.3 EasyMed will put a written contract in place with each sub-processor with data protection obligations at least as strict as this DPA. EasyMed remains liable to the Clinician for its sub-processors' performance (Article 28(4)).

6. Help with data subject rights

EasyMed will:

(a) pass on any request it receives from a patient about Clinical Data within 2 working days, without answering it unless instructed;
(b) provide tools (export, correction, restriction) or help so the Clinician can respond within the one-month legal deadline.

7. Help with security, breaches, DPIAs and consultations

7.1 Breach notification. EasyMed will notify the Clinician without undue delay and in any event within 24 hours of becoming aware of a personal data breach affecting Clinical Data. This leaves the Clinician time to meet its own 72-hour duty to report to the ICO under Article 33. The notice will include, as far as known: what happened, categories and approximate numbers of people and records, likely consequences, measures taken or proposed, and a contact point. EasyMed will update the Clinician as more is learned.

7.2 EasyMed will help the Clinician with breach notifications to the ICO and patients, its own DPIAs (EasyMed provides its DPIA), and any prior consultation with the ICO.

8. International transfers

EasyMed's application, database and backups are hosted in Germany (EEA). EasyMed transfers Clinical Data outside the UK and EEA only to the destinations and under the safeguards in Part 3. These are: UK adequacy regulations (EEA); the UK Extension to the EU–US Data Privacy Framework for certified US recipients; or the ICO IDTA or UK Addendum to the EU SCCs, with a transfer risk assessment. EasyMed will keep a record of each safeguard and provide a copy on request.

9. Audits and information

9.1 EasyMed will make available all information needed to show compliance with Article 28, and allow audits and inspections (Article 28(3)(h)).

9.2 Audits: on 30 days' notice, once a year (or after a breach), during business hours, under confidentiality. EasyMed may first offer reasonable evidence instead, such as certifications, security test summaries or documentation.

10. Records

EasyMed keeps a record of processing activities as a processor (Article 30(2)).

11. Return and deletion at the end of the service

11.1 At the end of the agreement the Clinician can export all Clinical Data in a common, machine-readable format (a structured JSON export, plus PDFs of reports and message attachments) for 60 days.

11.2 After that, EasyMed will delete Clinical Data, including from its sub-processors, within 90 days. Backups are overwritten within 35 days of that. EasyMed will confirm deletion in writing. This does not apply where UK law requires EasyMed to keep data.

11.3 Because medical records must be kept for long periods (for example 20 years for mental health records under the NHS Records Management Code), the Clinician is responsible for making sure that exported records are kept for the required period after leaving EasyMed.

12. Liability

Each party's liability under this DPA is subject to Part 1 clause 8. Neither party limits liability to data subjects under Article 82.

13. Order of precedence

If this DPA conflicts with Part 1, this DPA wins on data protection matters.

Annex A: Details of processing (Article 28(3))

Item	Detail
Subject matter	Providing EasyMed practice management software to the Clinician
Duration	The term of the agreement plus the return and deletion period
Nature	Collection, storage, organisation, retrieval, display, transmission, automatic crisis-keyword checks, AI-assisted drafting, export, deletion
Purpose	Allowing the Clinician to assess, treat, monitor and communicate with patients and their GPs
Data subjects	Patients (adults, and young people if the Clinician sees them); patients' GPs; the Clinician's staff; patients' representatives
Personal data	Identity and contact details; home visit address and postcode; appointment, reschedule and follow-up details; GP details; nominated pharmacy
Special category data	Health data: PHQ-9, GAD-7 and ASRS questionnaires and ratings, psychiatric, medication, family and social history, booking reasons, clinical notes and addenda, diagnoses and risk levels entered by the Clinician, medication and titration records, BP, pulse and weight, prescription records, secure messages and attachments, care status notes, GP letters, psychiatric reports and AI drafts. Possibly data revealing sex life, sexual orientation, religion or ethnicity where recorded clinically. Possibly criminal offence information, where recorded clinically.

Annex B: Technical and organisational measures

Status at the version date. Items marked "Not yet in place" are open.

Encryption in transit. HTTPS for all app and browser traffic, through a Caddy reverse proxy with Let's Encrypt certificates. The API redirects HTTP to HTTPS and sends HSTS for one year. The mobile app's release builds refuse a non-HTTPS server address, and Android release builds block unencrypted traffic. Email is sent over SMTP with SSL. Not yet in place: certificate pinning in the app.
Encryption at rest. Google Calendar tokens, the Google Calendar connection (OAuth) state and patient details sent to Stripe are encrypted with ASP.NET Data Protection. Amazon S3 encrypts stored files by default. Not yet in place: encryption of the message and clinical note columns in the database.
Access control. Every request that names a record is checked against the signed-in patient's or doctor's own id, and doctor access to a patient also needs a doctor–patient relationship. Only approved doctors can use clinical features. Admin endpoints re-check admin status in the database, and admins sign in with a second factor; no admin screen shows clinical notes, questionnaires, reports, prescriptions or messages, though admins can see and cancel appointments. The database has no network port open to the outside. Not yet in place: multi-factor authentication for clinicians and patients.
Secrets. No secrets in configuration files in the repository; production refuses to start if a required secret is missing; server secrets are in a file readable only by its owner. Not yet in place: rotation of every credential that was ever stored in the repository.
Authentication. 15-minute access tokens with required expiry; 30-day refresh tokens stored only as hashes, rotated on every use (each new token gets a fresh 30 days, so a session ends after 30 days without use), with reuse detection; all sessions revoked on password change, password reset, email change or deactivation, and push device tokens switched off at the same time; lockout after 5 failed logins; rate limits on login, signup, token refresh, one-time codes, messaging, GMC checks and lookups; one-time codes expire after 15 minutes, allow 5 attempts and are capped at 10 a day. Minimum password length is 8 characters.
Logging and monitoring. Audit trail of views and changes of clinical notes, questionnaires, reports, medication and titration records, prescription records, messages and GP details, visible to the Clinician. Application logs record ids, route templates and a request id only, never names, contact details, clinical content, messages, tokens or secrets. Logs kept up to 30 days (errors up to 90). Not yet in place: audit of care status notes; alerts on unusual access.
Secure development. Code review, automated security tests in the test suite, dependency scanning. Not yet in place: an independent penetration test.
Data minimisation. Calendar feeds show patient initials and no booking reason or home address; reviewer names hidden; message notifications contain no text; push and SMS appointment notifications do not name the doctor; emails to clinicians do not name the patient; AI prompts leave out the patient's name and date of birth, and identifiers found in free text are removed before sending; one-time codes sent by email, not SMS. The unedited AI draft is kept with the report after finalisation.
AI safeguards. Patient and clinician text is placed in delimited, escaped data sections; the system prompt forbids following instructions inside them and forbids diagnosis, treatment and risk content; the output is sanitised (diagnosis, opinion, plan and treatment sections and diagnostic codes are removed; other wording in the narrative is not caught automatically); finalisation is blocked until the Clinician writes the diagnosis and plan; no model training on customer data (Anthropic commercial terms).
Backups and recovery. Nightly database dump and key-ring backup, kept for 14 days on the server.
Server. API, worker and database run in Docker containers on a dedicated virtual machine.
People. Not yet in place: written confidentiality agreements, annual data protection and security training, and a leaver process.
Incident response. 24-hour notification to controllers (Part 2 clause 7.1). Not yet in place: a written breach response plan and an incident log.
Certification. Not yet in place: Cyber Essentials and a DSPT submission.
Data location. Application, database, logs and backups on the server: Germany (EEA). File storage: AWS London (United Kingdom). Text messages: AWS us-east-1 (United States).

PART 3: SUB-PROCESSOR LIST

Provider	Purpose	Data involved	Location	Transfer mechanism
WorldPosta	Hosting: a CloudEdge virtual machine running the API, background worker, PostgreSQL database, log files and nightly backups	All data	Germany (EEA)	UK adequacy (EEA)
WorldPosta	Transactional email over SMTP with SSL, from no-reply@easymed.uk	Recipient email address and name; email content (appointment details, the clinician's name in patient emails, video links, one-time codes, prescription status). Emails to clinicians do not name the patient. Never message text or clinical notes.	As for hosting	As for hosting
Amazon Web Services	S3 file storage	Indemnity certificates (current and archived), doctor profile photos, message attachments	United Kingdom (London)	Not needed (UK)
Amazon Web Services	SNS: SMS text messages	Mobile number; text of appointment, reschedule and prescription status messages (these do not name the clinician or the medicine); messages sent by admins	United States (us-east-1)	UK Extension to the Data Privacy Framework where the provider is certified; otherwise the IDTA or UK Addendum
Stripe (Stripe Payments Europe Ltd, Ireland; Stripe, Inc., US)	Card payments and refunds	Amount, currency, appointment time and internal ids in readable form; patient name, phone, location, clinician name, booking reason and emergency flag encrypted by EasyMed; card details entered by the patient directly into Stripe. Stripe is also an independent controller for some fraud and regulatory purposes.	Ireland (EEA) and US	UK adequacy for the EEA; for the US, the UK Extension to the Data Privacy Framework where the provider is certified, otherwise the IDTA or UK Addendum
Google LLC (Firebase Cloud Messaging; Apple's push service for iPhones)	Push notifications	Device token; notification title and text (message alerts are content-free; appointment alerts give the time and do not name the clinician; prescription status updates)	US	As for Stripe (US)
Google LLC (Google Calendar API, with Google Meet)	Read-only free/busy lookup of the clinician's own calendar, and creating Google Meet video meetings in it if the Clinician turns this on	Clinician's busy times, OAuth tokens (encrypted); meeting events titled "EasyMed appointment" with the appointment time. No patient data is sent by EasyMed.	US	As for Stripe (US)
Anthropic, PBC	AI drafting of psychiatric reports (Claude API)	Patient age, clinician name, clinic location ("Home visit" for home visits), appointment date, pre-assessment answers, scores and ratings, consultation notes (health data). Patient name and date of birth are not sent; identifiers found in free text are removed first.	US	As for Stripe (US)
Geoapify	Address autocomplete	Only the address text a user types, sent from EasyMed's server with no name or account details	EU data centres (EEA)	UK adequacy (EEA)
postcodes.io (Ideal Postcodes)	Postcode validation and coordinates (doctor search, practice addresses, home-visit distance)	Only a postcode, sent from EasyMed's server with no name or account details	Not stated by the provider	None used: the postcode is sent without any name or account details

Not sub-processors: the video service the Clinician chooses (Google Meet in the Clinician's own Google account, or another service such as Zoom or Microsoft Teams, which the Clinician contracts for and controls); Cloudflare (DNS only, in "DNS only" mode, so it does not proxy or see traffic); Let's Encrypt (issues HTTPS certificates; receives no user data); GMC register data (public data EasyMed uses as controller); Caddy, PostgreSQL, Docker and Ical.Net (software run on EasyMed's own server, not third parties).