PillarX Practice - Practitioner Data Processing Agreement

1. Scope, Parties and Roles

This agreement covers the clinical records a practitioner creates in PillarX Practice: client details, session records, appointments, and the notes attached to them.

It does not govern the PillarX wellness platform. Processing of an employer's staff data under a B2B subscription is covered by the separate PillarX Data Processing Agreement, and a clinical record about someone who also happens to be an employee is not covered by that agreement.

Read the B2B data processing agreement

PillarX Practice is not generally available. Access is by invitation only, and this agreement is published now so that it can be read before an invitation is accepted.

The intended model is that you, the practitioner, are the controller of your clients' records, because you decide which clients to record, what goes into each record and why. PillarX is the processor: it stores and protects those records on your instructions and does not read them for its own purposes.

Where you see a client through a company programme, the organisation running that programme is also involved in deciding why the processing happens. That is a separate arrangement with its own agreement.

PillarX is the processor named in this agreement. Our legal form, registered address, company registration number and VAT number are published on the imprint page rather than repeated here.

Company details

2. Subject Matter, Nature and Duration

The subject matter is the storage and protection of clinical records created by a practitioner in PillarX Practice.

The nature of the processing is storing what you enter, showing it back to you, and deleting it when you ask. PillarX does not analyse, profile, score or interpret clinical records, and does not use them to develop or train anything.

The purpose is to let a practitioner keep and find their own records. There is no secondary purpose.

Processing continues for as long as your access is open and records exist in the workspace.

3. Categories of Data Subjects and Personal Data

Categories of data subjects:

The clients a practitioner records in PillarX Practice, and the practitioner themselves as a user of the workspace.

Categories of personal data:

• •Client identity: full name and email address, both encrypted
• •Client demographics: date of birth, which is encrypted, plus year of birth and gender
• •Session records: the date, the start time and the length of the session, an encrypted free-text clinical note, and the issue areas, severity ratings and causes recorded against it
• •Appointments: date and time, duration, status, and an optional encrypted free-text note
• •Practice figures: an optional fee amount recorded against a session
• •Company-programme details, where a client is seen through one: the organisation, a department label, and whether the client is a member of that organisation
• •Consent attestation: the moment a practitioner confirmed they hold their client's consent to record sessions

Session records are data concerning health. Under Article 9 of the GDPR that is special category data, and it is treated as such throughout.

4. Processing Instructions

PillarX processes clinical records only on the practitioner's documented instructions, which for this workspace means the actions the software offers: creating, reading, correcting and erasing the records you enter.

PillarX does not read clinical records for its own purposes, does not disclose them except as described in this agreement, and does not use them to build features, produce statistics about your practice, or train any model.

PillarX Practice contains no artificial intelligence. No clinical record is sent to a language model, and no feature analyses, summarises or scores one. A source scan in our build pipeline fails the build if that ever stops being true.

If we believe an instruction would breach data protection law, we will say so rather than carry it out silently.

5. Confidentiality

Access to clinical records is restricted in the software, not merely by policy. A practitioner account reaches only its own caseload. The database tables holding clinical records grant nothing to ordinary logged-in accounts, so every request has to go through a server route that checks who is asking.

Opening a client record, a session note or an appointment note writes an entry to the audit log. The entry records which record was opened and by whom, never its contents.

6. Security Measures

The measures below are implemented today and are verifiable in the software:

• •Every client record has its own encryption key. Names, email addresses, dates of birth, session notes and appointment notes are encrypted with that key before they are stored.
• •Those keys are protected by a root key kept solely for clinical data, separate from the key protecting the rest of the PillarX platform. Nothing on the wellness side can decrypt a clinical record.
• •Each encrypted value is bound to the client, the table and the column it belongs to, so a value moved from one record to another stops being readable.
• •Erasing a client destroys that client's key. What remains is unreadable and cannot be restored, including from a backup.
• •The clinical part of the codebase is separated from the rest of the platform by an import boundary the build enforces. Code outside it cannot reach clinical data directly.
• •Appointment reminder emails carry no client information by construction: no name, no time, not even a count.
• •Access is scoped to the practitioner's own caseload, and opening a client record, a session note or an appointment note is written to the audit log.

7. Sub-processors

PillarX uses service providers to run the platform. Which of them are involved in handling clinical records, and on what terms, is being established.

The sub-processor list published in the PillarX Privacy Policy covers the wellness product. Do not read it as the list for clinical records, because it was drawn up for different processing.

8. International Transfers

This agreement makes no claim about where clinical records are stored or processed.

9. Assistance with Data Subject Rights

A request from a client goes to the practitioner first, because the practitioner holds the records and decides the answer. PillarX assists where the answer needs something done in the software.

Two things the software can do today. A client record can be erased from the workspace, which destroys its key irreversibly. And a practitioner can correct a session's clinical content for 24 hours after saving it, after which the record is fixed.

Clinical records are deliberately excluded from the data export a person can download from a PillarX wellness account, because that export returns the data PillarX is itself responsible for. A source scan in our build pipeline enforces the exclusion.

10. Personal Data Breach

If PillarX becomes aware of a breach affecting clinical records, we will tell the practitioner and provide the information needed to assess it.

11. Audit and Inspection

The workspace keeps its own audit log. Opening a client record, a session note or an appointment note writes an entry recording which record was opened and by whom, never its contents, and that log is the record a practitioner would want first if a question ever arose.

12. Return and Deletion on Termination

What the software does today: erasing a client destroys that client's key, and the record cannot be read back afterwards. There is no bulk export of a caseload in the workspace, so a practitioner who needs their records out contacts us and we arrange it.

Clinical records are not deleted automatically. Nothing expires them on a timer.

13. Annexes

A finished processor agreement carries two annexes: a description of the processing, and a statement of the technical and organisational measures. Sections 2 to 6 above hold the substance of both, written as prose.

14. Contact

For anything about this agreement, email pillarx@mypillarx.com.

PillarX is the processor named here. Our legal form, registered address, company registration number and VAT number are published on the imprint page rather than repeated in this agreement, so there is one place they are kept current.

Company details