Data processing agreement

Data processing agreement relating to Praxis, the associate pay and practice platform operated by Praxis Health Technologies Ltd. Version 1.16 - 30 September 2026. The Service was named "PraxisPay" until 19 September 2026, and "mzpay" before that; this agreement covers processing under each of those names.

This is the current version of this agreement, and it is the same text for every practice using the Service. The practice it binds is identified in the Parties section, and the sites it covers in Schedule 1, rather than either being written into this document, so that one agreement serves every practice without amendment.

Parties

(1) The Controller: the dental practice or group named below ("the Practice").

Full legal name of the company or partnership: as given by the Practice when it accepts this agreement in Praxis, together with the company number and registered office taken from the Companies House public register where the Practice is registered there.

The Practice confirms that it is the controller for every site covered by Schedule 1, and that the person accepting it is authorised to enter this agreement on its behalf.

(2) The Processor: Praxis Health Technologies Ltd, a company registered in England & Wales (company number 17294974), registered office 128 City Road, London, EC1V 2NX, ICO registration ZC180094 ("PHT").

Background

PHT provides the Practice with Praxis, a software service whose associate pay area, PraxisPay, administers associate pay: gathering income figures, allocating laboratory and other expenses to clinicians, supporting each clinician's approval of items charged to them, and producing monthly pay statements; together with a clinical documentation area, in which a clinician dictates or records a consultation to have clinical notes and patient letters drafted for them to check and copy into the Practice's own clinical system, a meeting recorder, in which the Practice's managers record internal meetings to have minutes drafted, and patient follow-up tools, in which the Practice's team and its clinicians work from the Practice's appointment diary to follow up patients who have not rebooked ("the Service"). In providing the Service, PHT processes personal data on the Practice's behalf. This agreement sets the terms of that processing as required by Article 28 UK GDPR. It forms part of, and is read with, the service agreement between the parties. In case of conflict concerning personal data, this agreement prevails.

Where the Practice entered into an earlier version of this agreement, whether signed on paper or accepted in the Service, this version replaces it in respect of every site covered by Schedule 1, from the date the Practice accepts this version. Processing already carried out under an earlier version remains governed by that version.

1. Definitions

"UK GDPR", "controller", "processor", "data subject", "personal data", "personal data breach" and "processing" have the meanings given in UK data protection law (the UK GDPR and the Data Protection Act 2018). "Sub-processor" means any third party engaged by PHT to process Practice personal data. The processing details - subject matter, duration, nature, purpose, categories of data and of data subjects - are set out in Schedule 1.

2. Roles and instructions

2.1 The Practice is the controller of all personal data processed in the Service, including patient-related billing data and workforce data. PHT is the processor.

2.2 PHT shall process Practice personal data only on the Practice's documented instructions, including as set out in this agreement, in Schedule 1 and in the Practice's configuration and use of the Service, unless required to do otherwise by law - in which case PHT will inform the Practice before processing unless the law prevents it.

2.3 PHT shall immediately inform the Practice if, in its opinion, an instruction infringes UK data protection law.

2.4 Specific instruction - patient names. The Practice specifically instructs PHT to process patient names, treatment descriptions, tooth references and amounts as they appear on the Practice's billing records (laboratory invoices, payment allocations, dental plan statements and case records), because correct attribution of laboratory work and expenses to clinicians and patients requires them. The Service is designed to hold no other patient identifiers, as Schedule 1 records, except the practice management system patient number used by the follow-up tools and anything a person types into a free text field (such as a follow-up note or the label of a potential lead), which is stored as written.

2.5 Specific instruction - the Praxis Assistant. The Service includes an assistant which answers questions about the Practice's own records in ordinary words, and prepares actions for an authorised person to confirm. The Practice specifically instructs PHT to send to the AI sub-processor named in Schedule 3, for that purpose only, the question asked and the records the person asking is already entitled to see - which may include the patient names and treatment descriptions described in clause 2.4, clinician names, and pay figures. The assistant is available to the Practice's managers, and to clinicians in respect of their own pay only. It is not available to reception staff. A clinician can obtain through the assistant only what they could already obtain in the Service; this is enforced by the same permission controls as the rest of the Service, and does not rely on instructions given to the AI model.

2.6 No solely automated decisions. The assistant does not decide anything. It cannot create, alter or delete any record by itself: every change it proposes is shown to an authorised person, with the values it would write, and takes effect only if that person confirms it. Where the change is to a pay statement, to a contract, or to a person's access, the confirming person must also record a reason, which is kept in the audit log with their name and the time. No processing in the Service produces a legal or similarly significant effect on a data subject by automated means alone within the meaning of Article 22 UK GDPR.

2.7 Specific instruction - recordings, transcripts and minutes. The Practice specifically instructs PHT: (a) to send a clinician's dictation or consultation recording to the speech to text sub-processors named in Schedule 3, and the resulting transcript to the AI sub-processor named in Schedule 3, to draft clinical notes and patient letters for that clinician, together with, where the clinician asks for it when drafting a letter, a treatment plan or referral document the clinician uploads and the patient's appointment history read at that moment from the Practice's practice management system (the document and the history are not stored by PHT); (b) to store each consultation transcript for 30 days from the start of the recording and then delete it, or sooner where the clinician deletes it; (c) to send a recording of an internal meeting made by one of the Practice's managers to the speech to text sub-processor named in Schedule 3, to send the transcript to the AI sub-processor named in Schedule 3 to draft minutes, and to store the transcript and the minutes for the Practice until a person entitled to delete them does so; and (d) where the clinician asks for it, to send a stored consultation transcript to the AI sub-processor named in Schedule 3 to produce a review of the clinician's own consultation and case-acceptance skills (how they found out what the patient wanted, explained findings, presented options and costs, answered concerns and agreed next steps) for that clinician alone; the written review is stored with the transcript and deleted with it, and the review's scores, which contain no information about the patient, are kept for the clinician. A review is feedback for the clinician's own development: it makes no assessment of clinical care and is not shared with the Practice. No recording is stored by PHT at any point. A drafted note, letter or set of minutes is a draft for a person to check: the clinician remains responsible for what enters the clinical record, and nothing drafted is sent to a patient by the Service.

2.8 AI apps a user connects. A user may connect an AI app of their own choosing (for example Claude or ChatGPT) to their Praxis account, after signing in to Praxis and agreeing on a consent screen. The connection returns only what that user can already see in the Service under the same permission controls, and never returns patient names, patient references, tooth references or treatment notes, except as the next paragraph describes. If the user allows it on that consent screen, the AI app may also make a limited set of the changes that user could make in the Service themselves (such as approving or querying their own items, or adding their own costs, income or CPD); each change is shown to the user in the AI app and is made only after the user confirms it there, and the Service records it as made through an AI app. It can never finalise, submit or send back a pay statement. Where a user makes such a connection, the AI app acts for that user, under that user's own agreement with its provider; its provider is not a sub-processor of PHT and receives from PHT only the answers to that user's own requests. The user can end the connection at any time in the Service, and PHT ends it automatically when the user's account is frozen or signed out everywhere, or when the Practice stops using the Service; a connection returns nothing more about a practice once that practice no longer runs that user's pay in the Service.

If a clinician separately allows it on that consent screen, by a choice that is off unless they turn it on and that is offered only to clinicians, the AI app may also read that clinician's own patient follow-up list (each patient identified by their practice management system number, with the practice, visit dates, follow-up status, the follow-up note written by the practice team and the outstanding treatment value, but no patient name, date of birth or contact details, except anything the practice team typed into a note or tag, which is sent as written) and that clinician's own kept consultation transcripts that are linked to a patient, which may contain a patient's name and anything said in the appointment. This is a disclosure the clinician makes, as a controller or on the Practice's instruction, to an AI provider the clinician has chosen, for the clinician's own use such as drafting a letter to that patient; PHT sends it only in answer to that clinician's own requests and only while the connection lasts. The Practice is responsible for deciding whether its clinicians may use this and for any agreement it needs with that provider, and the clinician is responsible for using a service suitable for patient information that does not use it to train its models. Nothing read this way is changed in the Service, and any letter the AI app writes is neither sent nor stored by PHT.

2.9 Specific instruction - follow-up tools and other AI-assisted reading. The Practice specifically instructs PHT: (a) to read the Practice's appointment diary from its practice management system, on the Practice's own credentials, and to keep the records Schedule 1 describes, to give the Practice's team (according to their role) and each clinician (for their own patients) lists of patients to follow up and figures about new and lost patients; (b) to show a patient's name beside those lists while a page is open, fetched at that moment from the practice management system or taken from the names the Service already holds under clause 2.4, without storing it; (c) to send to the AI sub-processor named in Schedule 3, when a person asks for a brief for a recall telephone call, the patient's practice management system number, the date and booked reason of their last appointment, their recall date, the list's tags and the note the Practice's team wrote, and to keep the brief with that patient's follow-up record; and (d) to send to the AI sub-processor named in Schedule 3 a pay statement one of the Practice's managers uploads for a clinician, to read its figures for the manager to check before it is saved. A clinician's own uploads for their own records (pay statements from any practice they work at, and CPD certificates) are read by the same sub-processor for that clinician, as the privacy policy describes. Nothing read or drafted under this clause decides anything: a person checks it before relying on it.

3. Confidentiality and personnel

3.1 PHT shall ensure that every person it authorises to process Practice personal data is subject to a binding duty of confidentiality and processes the data only for the purposes of the Service.

4. Security

4.1 Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, PHT shall implement and maintain appropriate technical and organisational measures to protect Practice personal data, including at minimum the measures in Schedule 2.

4.2 PHT shall not materially reduce the protection provided by those measures during the term of this agreement.

5. Sub-processors

5.1 The Practice gives general written authorisation for the sub-processors listed in Schedule 3.

5.2 PHT may add or replace a sub-processor with effect from the date PHT notifies the Practice of the change. Notice is given in the Service, where it is shown to the Practice's users when they next sign in, and Schedule 3 is updated on the same date. If the Practice reasonably objects to the change on data protection grounds, it may tell PHT at any time; the parties will discuss in good faith, and if no resolution is found, the Practice may terminate the affected part of the Service.

5.3 PHT shall impose on each sub-processor, by written contract, data protection obligations no less protective than those in this agreement, and remains fully liable to the Practice for each sub-processor's performance.

6. International transfers

6.1 Practice personal data is stored in the United Kingdom or the European Economic Area. Where a sub-processor processes personal data outside the UK/EEA (as identified in Schedule 3), PHT shall ensure the transfer is protected by a lawful transfer mechanism under UK GDPR (an adequacy decision, or the UK IDTA/Addendum to the EU Standard Contractual Clauses).

7. Assistance

7.1 PHT shall, taking into account the nature of the processing, assist the Practice by appropriate technical and organisational measures in fulfilling the Practice's obligation to respond to data subject requests (access, rectification, erasure, restriction, portability and objection). If PHT receives such a request directly, it will forward it to the Practice without undue delay and will not respond except on the Practice's instruction.

7.2 PHT shall assist the Practice with its obligations under Articles 32 to 36 UK GDPR (security, breach notification, data protection impact assessments and prior consultation), taking into account the nature of the processing and the information available to PHT.

8. Personal data breach

8.1 PHT shall notify the Practice without undue delay after becoming aware of a personal data breach affecting Practice personal data, and in any event within 48 hours, providing (as information becomes available) the nature of the breach, the categories and approximate numbers of data subjects and records affected, the likely consequences, and the measures taken or proposed to address it. PHT shall document all breaches and cooperate with the Practice's own notification obligations.

9. Audit

9.1 PHT shall make available to the Practice all information reasonably necessary to demonstrate compliance with Article 28 UK GDPR, and shall allow for and contribute to audits, including inspections, conducted by the Practice or its mandated auditor, on reasonable notice, no more than once per year unless a breach or supervisory authority requires otherwise, and in a manner that does not compromise the security of other customers' data.

10. Return and deletion

10.1 On termination or expiry of the Service, PHT shall, at the Practice's choice, return all Practice personal data in a commonly used electronic format and/or delete it, and shall delete remaining copies within 60 days, unless UK law requires storage of the personal data. The month-end export produced by the Service is the Practice's own record and is unaffected.

11. Term, liability and law

11.1 This agreement takes effect on the date the Practice accepts it in the Service, and continues for as long as PHT processes Practice personal data.

11.2 Each party's liability under this agreement is subject to the limitations and exclusions of the service agreement between the parties, save that nothing limits liability that cannot lawfully be limited.

11.3 This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.

How this agreement is entered into

This agreement is entered into electronically in Praxis. No signature is required, and neither party is asked to print, sign or return it.

PHT enters into it by publishing this version in the Service. The Practice enters into it when a person authorised to bind the Practice, signed in to their own Praxis account, confirms acceptance on screen. Acceptance is offered only to accounts holding the Administrator role, because this agreement binds the Practice and should be accepted by somebody able to bind it.

What is recorded. Praxis records the accepting person's name, role and account, the version accepted, the date and time, and a fingerprint of the exact text shown to them, so that what was agreed - and not merely that something was agreed - remains provable. The record is kept for as long as PHT processes Practice personal data, is never edited or deleted, and can be read by the Practice at any time in the Service under Settings.

When a new version is issued. The Practice is asked to accept it on next sign-in, and the previous acceptance stays on file as the record of what was agreed at the time. Until the current version is accepted, the Practice's Administrator cannot use the Service.

Where the Practice signed an earlier version of this agreement on paper, that signed copy remains the record for the processing carried out under it, and the Practice's acceptance record in the Service shows every version it has accepted since.

Schedule 1 - Details of processing

Sites covered

This agreement covers the Practice's processing at every site the Practice operates in the Service. The sites covered at any time are those recorded against the Practice in the Service, which the Practice can read at any time under Settings.

A site added to the Service later is covered from the date it is added, without a further agreement, provided it is operated by the Practice named above. A site the Practice ceases to operate stops being covered from the date it is removed, and processing already carried out for it remains governed by this agreement.

Subject matter and duration

Administration of associate pay for the sites covered above, for the duration of the service agreement.

Nature and purpose

Collection of income figures (entered by Practice staff or read from the Practice's practice management system on the Practice's own credentials); capture and AI-assisted reading of laboratory and supplier invoices; import of dental plan statements (Denplan, PracticePlan, Lloyd & White) to attribute plan income to clinicians; allocation of expenses to clinicians; clinician review and approval of items charged to them; calculation and production of monthly pay statements; duplicate-charge detection; monthly export of records for the Practice's bookkeeping; and an assistant which answers questions about those records in ordinary words and prepares actions for an authorised person to confirm (clauses 2.5 and 2.6).

Clinical documentation and meetings (clause 2.7): transcription of a clinician's dictation or consultation recording; AI-assisted drafting of clinical notes and patient letters from it, for the clinician to check and copy into the Practice's own clinical system; keeping each consultation transcript for 30 days, or until the clinician deletes it sooner; and transcription of internal meetings recorded by the Practice's managers, with AI-assisted drafting of minutes, the transcript and minutes being kept for the Practice; and, at the clinician's request, AI-assisted review of the clinician's own consultation and case-acceptance skills from a stored transcript (clause 2.7(d)).

Patient follow-up (clause 2.9): reading the Practice's appointment diary from its practice management system; building lists of patients to follow up, and of new, lost and all patients, with practice and clinician figures; recording the follow-up status, tags, notes, action requests and potential leads that the Practice's team and its clinicians enter; showing patient names beside those lists on request without storing them; finding a patient by name or number in the practice management system at the moment of the search; and AI-assisted drafting of call preparation briefs.

Categories of data subjects

• Patients of the Practice (billing and plan membership records, the appointment diary and follow-up records, and consultation transcripts, as described below);
• The Practice's workforce: owners, managers, reception staff, and dentists, hygienists and therapists, including practitioners named in the Practice's appointment diary;
• Anybody whose words are captured in a consultation recording (the patient and anybody accompanying them) or in a recorded internal meeting.

Categories of personal data

Patients: name as shown on billing or plan records; practice management system or plan provider patient reference; treatment description as billed (which may indicate the nature of dental treatment received, and is to that extent data concerning health, processed under the Practice's Article 9(2)(h) basis); tooth reference; plan fee category; amounts charged; scanned invoices which may show the above.

Appointment diary and follow-up records. For each patient in the diary read from the practice management system: the practice management system patient number, registration and recall dates, the outstanding treatment value, and each appointment's date and time, practitioner, status, appointment type and reason as booked (which may indicate the nature of treatment, and is to that extent data concerning health), and any cancellation reason. Added by people using the Service: the follow-up status, tags, notes and action requests for a patient, and the label, tags and note of a potential lead, which are free text and may contain a patient's name or what the patient said; and a call preparation brief drafted by the AI sub-processor from those facts (clause 2.9). The Service reads no patient name, date of birth or contact details into these records.

Expressly excluded by design: patient contact details (address, telephone, email), dates of birth, NHS numbers, medical histories, stored clinical notes and radiographs. The Service drafts clinical notes and letters for a clinician to copy into the Practice's own clinical system but does not store them, and it is not the Practice's clinical record.

Consultation transcripts. The words of a consultation, as transcribed, may include anything said in it, including health information about the patient (data concerning health, processed under the Practice's Article 9(2)(h) basis). Each transcript is stored encrypted when the recording finishes, linked where possible to the patient booked with the clinician at the time by their practice management system number, with that patient's own name replaced before it is stored. It is visible only to that clinician and deleted automatically 30 days after the recording started, or sooner if the clinician deletes it. The recording itself is never stored by PHT: it is held on the clinician's own device until it is transcribed, and removed from the device after 7 days if it is never sent.

Meeting transcripts and minutes. A recorded internal meeting's transcript and the minutes drafted from it are stored encrypted for the Practice, visible to the Practice's managers according to their role, until the person who recorded the meeting or an Administrator deletes them, or this agreement ends. They may contain anything said in the meeting, including workforce matters and, where a patient is mentioned, what was said about them. The recording itself is never stored by PHT.

Dates of birth in plan statements. A provider's statement file may contain a date of birth column. The Service does not read it, and does not store the file as received: an uploaded CSV is rebuilt without any date of birth column before it is filed, and a statement supplied as a PDF is not filed at all, the Service generating and keeping its own record of the import instead. No date of birth is written to storage at any point.

Assistant conversations. A question asked of the assistant, and the answer given, are stored so that the Practice can see what was asked and what was done on its behalf. A conversation may therefore contain any of the patient and workforce data listed above. Conversations are deleted 90 days after their last message. No conversation is used to train any AI model.

Workforce data

Name, work email address, role, GDC registration number (clinicians), authentication data (password hash, and where the person signs in with a work account, an identifier issued by Google or by Microsoft Entra ID identifying them to that provider), pay and contract terms, approval decisions and comments, acceptance of this agreement and of the Terms of Service and Privacy Policy, and an audit trail of actions in the Service, including the reason a person records when finalising a statement, changing a contract, or changing another person's access, and questions asked of the assistant and the answers given.

Schedule 2 - Technical and organisational measures

• All data hosted in the European Union (database and document storage: Supabase; application: Vercel), with encryption in transit (TLS) and at rest.
• Scanned invoices, plan statement records and other uploaded documents stored in a private storage bucket with no public access; served only through the authenticated application.
• Row level security enabled on every database table, and the hosting platform's public data API holds no access rights to any table: the database is reachable only by the application's own server-side credential.
• Role-based access control with eight permission tiers; every user sees only the sites and data their role allows; clinicians see only their own pay.
• Practice management system keys, the Practice's and those a clinician supplies, are encrypted at rest (AES-256-GCM) with a key held only in the application's server configuration, and are never shown back in the Service once saved.
• Assistant requests are authorised on the server against the same permission rules as the rest of the Service, on every request. A clinician's assistant has no operation that accepts another person's identity, so it cannot return another clinician's data whatever it is asked.
• The assistant cannot compose database queries. It chooses from a fixed set of read operations, and it cannot write to any record: every change is written by the Service's existing controls, after an authorised person confirms it (clause 2.6).
• Assistant use is rate limited for each user, and assistant conversations are deleted 90 days after their last message.
• Passwords stored as bcrypt hashes (cost 12); sign-in and registration links are single-use, expiring tokens stored only as SHA-256 hashes.
• An append-only audit log of material actions (who, what, when, before and after values).
• Finalised pay statements are immutable snapshots; subsequent data changes cannot silently alter what a clinician was paid.
• Segregation of environments; production secrets held in the hosting platform's encrypted configuration, never in code. Demonstration sign-in cannot be enabled on the production service.
• Sub-processors bound by data processing agreements; the AI provider is contractually barred from training on customer data, and plan statement files are never sent to it.
• Recordings are never stored by PHT. A consultation transcript, and a meeting's transcript and minutes, are encrypted at rest with a key held only in the application's server configuration, so a copy of the database shows no readable text; they are never written to logs, never placed in a web address, and are not indexed or searchable. A consultation transcript is deleted automatically 30 days after the recording started.
• Breach response procedure with defined containment, assessment and notification steps (clause 8).

Schedule 3 - Authorised sub-processors

The Practice's own practice management system (for example Dentally) is not a sub-processor: the Service reads from it using credentials the Practice supplies, at the Practice's instruction.

Sign-in providers are not sub-processors either, and are listed here so the position is disclosed rather than assumed. Where the Practice enables staff sign-in with a Google or a Microsoft work account, the member of staff authenticates directly with that provider against their own account. No Practice or patient data is sent to the provider, and the provider processes nothing on PHT's instructions: it confirms to the Service who has signed in. Google's APIs Terms of Service provide for controller-to-controller terms between the parties rather than processor terms, and where a Microsoft work account is used the provider is already the Practice's own supplier for that account. Google sign-in is enabled today; Microsoft is not.