DPIA Public Summary

This summary explains the privacy risks assessed for Plinical, the safeguards required to address them, and the responsibilities of MTX STUDIO Ltd and its clinic customers. Health-data processing requires effective safeguards and appropriate supplier permissions. This publication does not itself authorise that processing.

1. Purpose and assessment scope

Plinical is a clinic-management service operated by MTX STUDIO Ltd, company number 15856187. It supports UK clinics and self-employed professionals, including those in Northern Ireland, with patients, appointments, clinical records, consent, referrals, invoicing, reports and communications.

The assessment covers the shared application, database, files, staff accounts, imports and exports, communications, suppliers, security, support, retention and data-rights assistance. It also covers MTX's separate business-contact, account-security and subscription-billing processing. Use is routine during the subscription and continues only for the applicable return, deletion or lawful retention period.

A DPIA is warranted because the platform is designed to hold confidential health records across multiple clinics, including records about children and other vulnerable people. Disclosure, alteration or unavailability can cause distress, discrimination, financial loss, loss of control or harm to care. Actual volumes, clinic workflows and patient populations affect the risk and must inform each deployment.

2. Who is responsible

Clinics are controllers of patient and clinical records: they decide why those records are used, who may access them, their clinical content and applicable retention. Each clinic must identify its Article 6 lawful basis and Article 9 condition for health data, provide privacy information and assess its own use of the service. Consent to treatment is not automatically data-protection consent.

MTX is a processor for hosted and automated functions carried out on clinic instructions under the Data Processing Agreement. MTX is separately a controller for its own enquiries, account administration, subscription billing, security and legal-compliance processing, described in the Privacy Notice.

Patients have no Plinical account, portal or self-booking facility in the assessed scope. Patients do not pay through Plinical; clinics record payments made elsewhere. Stripe supports clinic subscription billing.

Automated clinical decisions, biometric identification, sale of clinic data, advertising use of clinic records and general-purpose AI training are outside the permitted scope.

3. Information and processing lifecycle

InformationPurpose and limits Names, contact details, demographics and clinic identifiers support Patient identity and contactsidentification, scheduling and clinic communications. Clinics should collect only what their work requires.

Histories, medication, allergies, assessments, treatment plans, clinical notes, Health and care recordsreferrals and attachments support care documentation. These are special category data.

Forms, recorded choices and signature images document clinic processes.

Consent and signatures Signature images are not used for biometric identification.

Scheduling, services, invoices and records of payments made elsewhere support Appointments and invoicesclinic administration. Even without a diagnosis, context may reveal a health relationship.

Names, business emails, role assignments, authentication and security records Clinic staff and account data support authorised access and service administration.

Business identity, billing details, subscription status and minimised technical MTX subscription and records support MTX's own service, billing and security duties. Patient records operational data must not be sent to Stripe.

Collection and use. Authorised clinic users enter information, import CSV files and upload documents. The application processes these records within the clinic's workspace for scheduling, care documentation and administration. Imports must preserve the correct clinic, patient and source and be checked for errors and excessive information.

Storage and sharing. Structured records are stored in the database; files and generated documents use object storage. Authorised clinic users may view or export records. Clinic-selected recipients may receive communications, referrals or time-limited invoice links. Downloads create copies that the clinic must protect and manage.

Support and access. Under the stated operating model, MTX staff do not enter clinic workspaces or read patient records. Support is provided by ticket and reply with guidance. Clinics must use synthetic or fully redacted examples and must not send patient records, passwords or keys in support requests.

The automated service processes records to provide its functions. Encryption does not make this processing anonymous, and the assessment does not establish encryption controlled exclusively by the clinic. Key custody, automated decryption and supplier capabilities remain part of the security assessment.

4. Suppliers and international processing

The following map records the service architecture and owner-confirmed configuration. Optional services apply only when enabled. Locations identify the recorded main processing route; supplier access, metadata, backups and onward processing also require assessment.

ServiceRecorded function and location Application and server functions in London. The service processes clinic data to Vercel application deliver the software.

Structured clinic records in London. Tenant separation, access and recovery Neon database controls apply.

Files, PDFs and signature images in Washington DC, United States. Private storage Vercel Blob and expiring delivery links are owner-confirmed.

Email dispatch in Ireland; metadata, logs, API and account records in the United Resend States. Message context may reveal health information.

Optional SMS delivery. The telecom route, location, retention and contractual The SMS Worksscope must be established before use. The owner confirms AI Optimiser and overrides are disabled.

Optional diagnostics with EU storage in Germany. The owner confirms clinical-data Sentry scrubbing; health payloads and session replay are excluded from the assessed use.

Optional technical counters in Ireland. The owner confirms region configuration.

Upstash Clinical payloads are excluded and retention must be limited to operational need.

Public-registration anti-abuse checks involving global browser and network signals.

Cloudflare TurnstileNo clinical or form contents are intended. MTX is controller; Cloudflare has processor and separate controller functions.

Clinic subscription billing, separate from patient invoicing and external patient Stripepayments. Provider payment operations may involve international processing. Its roles and transfers must be assessed for the actual service.

Auth.js is a self-hosted software library, rather than a separate hosting supplier. The assessed Fresha route is clinic-controlled CSV import, with no live API integration.

For restricted transfers, MTX must establish an applicable adequacy basis or valid contractual safeguards and complete the required transfer assessment or data protection test. A London application region does not make all processing UK-only. Supplier permission to handle health data is a separate requirement from transfer safeguards; section 9 explains the assessment finding.

5. Necessity and proportionality

Patient identity, care and scheduling information support the clinic's administration and recordkeeping.

Eliminating all health data would prevent the assessed clinical-record function. This does not justify unrestricted collection: clinics must limit fields, attachments, messages and access to the relevant purpose and keep records accurate.

The assessment identifies less intrusive choices: use minimal message text and neutral subject lines; omit diagnoses and clinical narratives from operational telemetry; keep patient data out of subscription billing; use private, expiring document delivery; and use synthetic data for demonstrations and testing. Patient portals, patient payment processing and automated clinical decisions are excluded and require reassessment before introduction.

Clinic access must follow least privilege, separating administrative and clinical roles and promptly disabling leavers. Exports require authorisation and secure handling. Technical evidence must establish tenant isolation, file and link access, logging, secret protection, vulnerability management and recovery. These controls must be tested against the version and configuration used in service.

6. Retention rights and incidents

Retention. During a subscription, clinics determine lawful patient-record retention requirements and issue instructions under the DPA. On termination, DPA version 2.0 provides 30 days for retrieval or a return request, followed by active deletion without undue delay as specified there. Protected backup copies must be deleted no later than 90 days after active deletion. Restoration must reapply deletion restrictions and must not restart that period. Legally required retention is limited to the applicable duty and protected from other use.

Deletion must cover structured data, documents, generated files and relevant downstream copies. MTX's own billing, security and legal records follow the separate purposes and retention criteria in its Privacy Notice. The platform's exit periods do not replace a clinic's professional or statutory record-retention duties.

Individual rights. Patients should contact their clinic for access, correction, restriction, deletion or other requests concerning clinic records. MTX must route requests and assist the clinic under the DPA, using identity and tenant checks. Export and assisted workflows must cover relevant records and attachments while protecting other people's information. Rights concerning MTX's own controller processing may be raised directly with MTX.

Incidents. Under DPA version 2.0, MTX must notify an affected clinic without undue delay and within 24 hours of becoming aware of a personal-data breach, providing available facts and further information as it becomes available. MTX must support the clinic's assessment and response. The clinic remains responsible for its controller notifications, including any applicable regulator and affected-person notifications.

Supplier changes. DPA version 2.0 requires at least 15 calendar days' advance notice of a new or replacement Sub-processor and an opportunity to object. Supplier notice periods and technical switching arrangements must allow MTX to meet that obligation before the affected processing changes.

7. Risks and required safeguards

The register assesses harm to individuals. Likelihood and impact are each rated from 1 to 5 and multiplied:

Low 1-4, Moderate 5-9, High 10-14 and Very High 15-25. A control may lower likelihood while leaving the severity of a possible disclosure or care failure unchanged.

The rows below preserve risks R1-R24 from the original assessment and add R25-R26. They summarise the measures needed to address each risk. They do not state that every measure has been independently verified. Original forecast scores are not presented as measured or accepted residual scores.

RiskPotential harmRequired safeguards Enforce clinic scope in queries, APIs, files and exports; R1 Tenant One clinic receives another clinic's perform negative access tests and independent separationrecords. checks.

Least privilege, strong authentication and session Stolen credentials or excessive R2 User accountscontrols, rate limiting, access reviews and rapid permissions expose records. leaver removal.

Validate records, preserve provenance and audit R3 Record Wrong, missing or altered data trails, support correction, test concurrent changes integrityaffects care. and recovery.

Downloaded records reach Restrict and log exports, minimise scope and provide R4 Exports unauthorised people.secure-download and local-retention guidance.

R5 Wrong recipients or excess detail Verify recipients, minimise content, use safe Communicationsexpose confidential care.templates and check referral and retry workflows.

R6 Document A shared, guessed or persistent link Private storage, strong link tokens, enforced expiry, linksexposes documents.authorisation, revocation and access testing.

Logs or support tickets disclose Allowlist or scrub diagnostic fields; exclude clinical R7 Diagnostics clinical data or secrets.content, credentials and replay; test actual payloads.

R8 Technical Cached content or region changes Use short-lived technical counters, exclude health cachewiden exposure.data and verify regions, expiry and failover.

Wrong-patient, wrong-clinic or Validate files and schema, bind imports to the clinic, R9 Importsexcessive records affect privacy or preview content and support duplicate checks and care.rollback.

Images are reused, over-retained or Limit purpose, access and retention; prohibit R10 Signatures used for identification.biometric matching in the assessed service.

Test backups and restoration, define recovery Outage or failed recovery interrupts R11 Availabilityobjectives and provide clinic downtime and access to care records. reconciliation procedures.

Apply clinic instructions, verified active deletion, Records remain beyond the R12 Retentionbackup expiry and narrowly controlled legal-retention permitted purpose or period. exceptions.

Verify identity and clinic, route requests promptly and Requests fail or disclose another R13 Rightstest complete, controlled export and correction person's records. workflows.

7. Risks and required safeguards continued

RiskPotential harmRequired safeguards Maintain the no-staff-access support model; establish R14 Operational Misuse of infrastructure, credentials actual key and service capabilities; restrict and accessor keys bypasses access boundaries. monitor operational privileges.

Use synthetic or irreversibly anonymised material; Real patient data appears in R15 Test materialseparate environments and inspect public and test demonstrations or screenshots. assets.

Enforce contractual and technical purpose limits, R16 Secondary Records are reused for advertising, disable conflicting vendor features and assess any usesale or AI training. proposed new use.

Monitor incidents, maintain escalation contacts, R17 Breach Delayed detection or notice prevents preserve evidence and test the 24-hour notification responsetimely protection. process.

Use accessible notices, clinic-led representative R18 Vulnerable Disclosure or confusing access harms checks, minimal communications and appropriate peoplechildren or vulnerable patients. access controls.

International processing lacks Establish the actual route, supplier health-data R19 Transferseffective protection or lawful permission, transfer basis, assessment and necessary coverage.supplementary controls.

Maintain the supplier inventory, monitor changes, R20 Supplier New locations, features or recipients reassess risk and make the 15-day clinic notice changesalter protection. process workable.

Limit Turnstile to necessary signals, exclude form R21 Bot Registration checks collect excessive contents, assess global processing and explain the protectioninformation. roles and purposes.

Minimise content and metadata, restrict retention R22 Email Logs and delivery records reveal and access, and match supplier contracts to the metadatapatient relationships. actual data.

Review code and dependencies, scan for secrets, R23 Security Vulnerabilities or leaked secrets patch promptly, rotate credentials and test the flawsenable unauthorised access. deployed service.

Users rely on incomplete records or Explain the service boundary, support data-quality R24 Clinical software instead of professional checks and train users in downtime and reconciliation reliance judgement.procedures.

Keep patient data out of Stripe, restrict billing roles, R25 Subscription Billing errors or excess metadata verify subscription linkage and assess paymentbillingexpose identity or financial details. provider processing.

Separate operational decisions from independent R26 Privacy Conflicting duties weaken challenge, DPO advice; document duties, implementation, governancerisk decisions or rights handling. advice and accountable decisions.

Risk acceptance must rely on actual configurations, contracts, tests and operating evidence. A forecast cannot establish that risk has fallen. Severe potential harm must remain in the impact assessment unless a specific, supported reason demonstrates that the harm itself has been reduced.

8. Accountability and consultation

MTX management is responsible for operational decisions, implementation and lawful risk acceptance.

The role of the Data Protection Officer, Theodoros Mentis, is to advise and monitor independently. The company has selected a role allocation placing product, hosting, security and supplier decisions with Christos Mentis, CEO and Director. Its operation in practice and the independence of advice must be evidenced separately from adoption of the allocation.

Clinic, clinician, reception and patient or representative perspectives should inform the assessment where appropriate. Consultation should address access, confidentiality, messages, rights, accessibility and continuity of care. Actual feedback and resulting decisions must be recorded; a decision not to consult a group needs a specific reason. This publication does not report completed stakeholder consultation or independent DPO advice.

9. Assessment findings and processing conditions

The assessment identifies a credible need for the service and material risks requiring effective safeguards.

Owner confirmations cover private files and expiring links, EU diagnostics and scrubbing, Ireland cache configuration, disabled SMS AI features and the contractual notification and deletion capabilities. These confirmations are part of the evidence; they are distinct from current production test results and accountspecific contractual records.

Health-data permission remains a material issue. Vercel's published DPA restricts sensitive or special category customer data, while Resend's published DPA describes sensitive-data transfers as not applicable. Account-specific permission or a verified alternative processing route must resolve the actual health-data use. Encryption, generic supplier terms and the availability of transfer clauses do not by themselves resolve that issue.

The assessment record does not establish a completed, evidence-backed residual-risk acceptance for live clinical processing. Supplier health-data coverage, the applicable transfer arrangements, control effectiveness and independent privacy advice must support that decision. Affected live health-data processing must not begin until the mandatory prerequisites are satisfied. Publishing this summary does not record a management signature or regulatory approval.

Where a required DPIA identifies high risk remaining despite mitigation, the relevant controller must consult the ICO before the processing proceeds. MTX must assist clinic controllers and fulfil that obligation for its own controller processing where applicable. An internal acceptance decision cannot waive prior consultation. See ICO guidance on concluding a DPIA.

10. Maintenance and contact

This public summary accompanies the original assessment dated 19 August 2026 and subsequent updates.

It replaces the public information at this page on publication; the underlying assessment and decision history remain retained. Reassessment is required before material changes to features, data, scale, suppliers or locations, following significant incidents, and no later than 19 August 2027.

Privacy, security and assessment enquiries:support@mtxstudio.com. DPO:th.mentis@mtxstudio.com.

Clinics may request supporting information through the DPA information and audit process. Patients should direct clinic-record requests to their clinic and may raise privacy concerns with the ICO.

Registered office: MTX STUDIO Ltd, Princess House The Square, 3rd Floor, Shrewsbury, Shropshire, England, SY1 1JZ.