Body Navigator — Data Processing Agreement

Last updated: 18 May 2026

This Data Processing Agreement (“DPA”) forms part of the Terms and Conditions (“Principal Agreement”) between Andrew Jackson Physiotherapy, the developer and operator of Body Navigator (“Processor”, “we”, “us”) and the User (“Controller”, “Clinician”, “you”) who uses the Body Navigator clinical reasoning support platform (the “Platform”).

The Principal Agreement is available at https://thebodynavigator.com/terms-and-conditions/. The Privacy Policy is available at https://thebodynavigator.com/privacy-policy/. This DPA is available at https://thebodynavigator.com/dpa/.

This DPA sets out the terms on which we process Patient data on your behalf, and reflects the requirements of Article 28 of the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

By using the Platform, you accept this DPA and agree to the terms set out below. This DPA takes effect on the date you first access the Platform and continues for as long as we process Patient data on your behalf.

1. Definitions

The following terms have the meanings set out below. Other terms used in this DPA have the meanings given to them in UK GDPR.

“Controller” means you, the Clinician or healthcare professional using the Platform, who determines the purposes and means of processing Patient data
“Processor” means Andrew Jackson, sole trader trading as Body Navigator
“Patient Data” means personal data relating to Patients that the Controller inputs into the Platform, including special category (health) data
“Sub-processor” means any third party engaged by the Processor to assist in providing the Platform, as listed in Schedule 2
“Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Patient Data
“Applicable Data Protection Law” means the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications Regulations (PECR), and any other applicable data protection legislation in force in the United Kingdom

2. Roles and responsibilities

2.1 The Controller

You are the Controller in respect of Patient Data. You are responsible for:

(a) determining the purposes and means of processing Patient Data;

(b) ensuring you have a lawful basis under UK GDPR Articles 6 and 9 for inputting Patient Data into the Platform — most commonly Article 9(2)(h) (provision of health or social care by a health professional subject to professional confidentiality obligations);

(c) ensuring that any consents required from Patients (under data protection law, professional standards, or organisational policy) have been obtained;

(d) ensuring your use of the Platform complies with your professional obligations (HCPC, CSP, GMC, or equivalent) and the data protection policies of any organisation under whose authority you act (such as an employing NHS Trust or private clinic);

(e) responding to data subject rights requests from your Patients;

(f) maintaining the accuracy of Patient Data you input;

(g) deciding what Patient Data is necessary, and minimising data that is not clinically necessary in line with the data minimisation principle.

2.2 The Processor

We are the Processor in respect of Patient Data. We process Patient Data only on your documented instructions, in accordance with this DPA, the Principal Agreement, and our Privacy Policy. We will not process Patient Data for any other purpose unless required by law, in which case we will inform you in advance unless legally prohibited from doing so.

3. Subject matter, duration, nature, and purpose of processing

The full details of processing are set out in Schedule 1 to this DPA. In summary:

Subject matter: processing of Patient Data input by the Controller into the Platform for the purpose of clinical reasoning support
Duration: for the duration of the Controller’s use of the Platform, plus any retention period set out in the Privacy Policy
Nature: automated processing, retrieval from a curated knowledge base, AI-supported organisation of clinical information
Purpose: to provide clinical reasoning support to the Controller in respect of the Controller’s patients
Types of personal data: as set out in Schedule 1
Categories of data subjects: Patients of the Controller

4. Processor obligations

We will:

4.1 Process only on documented instructions

Process Patient Data only on the documented instructions of the Controller, including with regard to transfers of Patient Data to a third country. The Controller’s instructions are set out in this DPA, the Principal Agreement, the Privacy Policy, and any other written instructions you give us in relation to your use of the Platform.

If we believe that an instruction infringes Applicable Data Protection Law, we will inform you, although we are not obliged to monitor the lawfulness of your instructions in general.

4.2 Confidentiality

Ensure that any person authorised by us to process Patient Data (including the administrator) is bound by confidentiality obligations equivalent to those that would apply if they were processing the data themselves.

4.3 Security

Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including those set out in Schedule 3. These include encryption in transit (TLS 1.2 / 1.3) and at rest (AES-256), authenticated access, server-side enforcement of access controls, and per-User data isolation.

4.4 Sub-processors

(a) The Controller authorises us to engage the Sub-processors listed in Schedule 2 for the processing of Patient Data.

(b) We will inform the Controller of any intended changes to Sub-processors, including the addition or replacement of Sub-processors, with reasonable advance notice (at least 30 days where practicable). The Controller may object to such changes within 30 days of notice on reasonable data protection grounds; if the parties cannot agree on a resolution, the Controller may terminate the Principal Agreement.

(c) We will impose written contractual obligations on each Sub-processor equivalent to the data protection obligations set out in this DPA, and remain liable to the Controller for the acts and omissions of the Sub-processor as if they were our own.

4.5 Assistance with data subject rights

Taking into account the nature of the processing, assist the Controller by appropriate technical and organisational measures, insofar as possible, in responding to requests from data subjects to exercise their rights under UK GDPR (rights of access, rectification, erasure, restriction, portability, and objection). Where we receive a request directly from a Patient or other data subject, we will forward it to the Controller without undue delay and will not respond to it directly except as instructed by the Controller or required by law.

4.6 Assistance with controller obligations

Assist the Controller in ensuring compliance with the Controller’s obligations under UK GDPR Articles 32 to 36 (security of processing, notification of personal data breaches, communication of personal data breaches to data subjects, data protection impact assessments, and prior consultation with the ICO), taking into account the nature of the processing and the information available to us.

4.7 Personal data breach notification

Notify the Controller without undue delay (and in any event within 72 hours) after becoming aware of a Personal Data Breach affecting Patient Data, and provide the Controller with all reasonable information necessary to enable the Controller to comply with its own breach notification obligations under UK GDPR Article 33.

4.8 Return or deletion of data

At the end of the provision of services relating to the processing, and at the Controller’s choice, delete or return all Patient Data to the Controller and delete existing copies, unless retention is required by law.

4.9 Availability of information

Make available to the Controller all information necessary to demonstrate compliance with this DPA, and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller. We may charge a reasonable fee for audit assistance beyond the provision of standard documentation.

5. International transfers

Patient Data may be transferred to and processed in countries outside the United Kingdom by the Sub-processors listed in Schedule 2. Such transfers are made under the following safeguards, as appropriate to the destination country:

UK Adequacy Regulations where the destination country is recognised as adequate by the UK government (e.g. the European Economic Area);
The UK International Data Transfer Agreement (IDTA) or the EU Standard Contractual Clauses with the UK Addendum, signed with each relevant Sub-processor;
For US transfers, where applicable, the recipient’s certification under the UK–US Data Bridge (an extension of the EU–US Data Privacy Framework).

We maintain a Transfer Risk Assessment documenting our assessment of each international transfer of Patient Data. A copy is available on request.

6. Administrative access

For the Platform to function, be supported, and be kept secure, the Body Navigator administrator has the technical ability to access Patient Data. The Controller acknowledges this and accepts that:

(a) Administrative access is undertaken only for legitimate operational purposes — specifically responding to a User support request, investigating a specific technical issue or security incident, or where required by law;

(b) The administrator does not access Patient Data for marketing, training of third-party AI models, general product browsing, or any purpose not necessary for operating the Platform;

(c) Other Users of the Platform have no ability to access the Controller’s Patient Data — each User can only access patients they themselves have entered;

(d) The administrator acts in the capacity of a Processor when accessing Patient Data, in accordance with the obligations set out in this DPA;

(e) The Processor will, as the Platform develops, introduce additional safeguards (such as access logging) to provide a verifiable record of when administrative access has occurred.

7. Liability and indemnity

The liability of each party under or in connection with this DPA is subject to the limits and exclusions of liability set out in the Principal Agreement, except as required by Applicable Data Protection Law.

To the extent permitted by law, the Controller agrees to indemnify and hold the Processor harmless against any losses, costs, expenses, damages, claims, demands, and liabilities arising from:

(a) the Controller’s input of Patient Data into the Platform without a lawful basis, or without obtaining any necessary consents;

(b) the Controller’s breach of its Controller obligations under this DPA or Applicable Data Protection Law; or

(c) any clinical act or omission by the Controller, including any claim made by a Patient relating to the Controller’s assessment, diagnosis, treatment, or use of any output of the Platform.

This is subject to and aligned with the indemnity provisions in the Principal Agreement.

8. Term and termination

This DPA takes effect on the date the Controller first accesses the Platform and continues for as long as the Processor processes Patient Data on the Controller’s behalf. On termination of the Principal Agreement, the Processor’s obligations under clause 4.8 (return or deletion of data) apply.

Termination of the Principal Agreement does not affect obligations under this DPA that by their nature should survive termination, including obligations relating to confidentiality, security, breach notification, return or deletion of data, and liability for prior breaches.

9. General

9.1 Order of precedence

In the event of conflict between this DPA and the Principal Agreement, this DPA prevails to the extent the conflict concerns data protection.

9.2 Changes to this DPA

The Processor may update this DPA from time to time to reflect changes in Applicable Data Protection Law, Sub-processors, or processing arrangements. Material changes will be notified to the Controller with reasonable advance notice. Continued use of the Platform after the effective date of a change constitutes acceptance of the updated DPA.

9.3 Governing law

This DPA is governed by the laws of England and Wales. The parties submit to the non-exclusive jurisdiction of the courts of England and Wales for the resolution of any dispute arising out of or in connection with this DPA.

9.4 Contact

For any questions or requests relating to this DPA, please contact:

Andrew Jackson Physiotherapy UNTIL, 1 Orchard Street London W1H 6HJ Email: [email protected]

Schedule 1 — Details of processing

Subject matter of processing

Processing of Patient Data input by the Controller into the Platform for the purpose of providing clinical reasoning support.

Duration of processing

Patient Data is retained for the duration of the Controller’s Account, regardless of whether the Controller’s subscription is currently active. A lapsed subscription does not trigger deletion — Patient Data remains intact during any period where the subscription is not active, so that it is available to the Controller on resubscription.

Patient Data is deleted without undue delay and in any event within one month of:

(a) active Account closure requested by the Controller; or

(b) receipt of a deletion request from the Controller under their right to erasure,

unless retention is required by applicable law (for example, billing records retained under HMRC requirements) or for the establishment, exercise, or defence of legal claims.

Nature and purpose of processing

Automated processing of Patient Data via a Retrieval-Augmented Generation (RAG) pipeline using large language models. The Platform retrieves clinical considerations, associations, relationships, and specialist links from a curated knowledge base in response to the Controller’s input, and optionally synthesises output based on the Controller’s own ruled-in considerations.

The purpose of processing is to provide clinical reasoning support to the Controller in respect of the Controller’s patients. The Platform does not provide a diagnosis, recommend specific treatments for specific patients, or function as a clinical decision support system.

Types of personal data

Patient Data is handled by the Platform in two distinct streams:

Patient identifier fields — stored in EU-based infrastructure and not transmitted to US-based AI sub-processors:

Patient name
Patient age

Case notes and clinical content — processed by AI sub-processors including OpenAI in the United States:

Clinical history and presenting complaint
Examination findings
Imaging or test results entered by the Controller
Working diagnoses, hypotheses, treatment plans
Other clinical information relevant to the consultation, as entered by the Controller

The Controller is instructed not to enter direct Patient identifiers (full names, dates of birth, NHS numbers, addresses, telephone numbers, email addresses, or other directly identifying information) into the case notes field, in order to minimise the international transfer of identifiable Patient Data. Direct identifiers should be kept in the Patient identifier field only.

The above is special category personal data within the meaning of UK GDPR Article 9(1).

Categories of data subjects

Patients of the Controller.

Schedule 2 — Authorised Sub-processors

The following Sub-processors are authorised to process Patient Data in connection with the provision of the Platform:

Sub-processor	Role	Data processed	Location of processing	Transfer safeguard
Google LLC (Firebase / Google Cloud — EU region)	Application database (Firestore) — storage of User accounts, Patient identifier fields, and case notes	User account information; Patient identifier fields; case notes	European Economic Area (Belgium)	UK Adequacy Regulations (EEA)
Google LLC (Firebase Authentication)	User authentication	User email address only	United States	UK Addendum to EU Standard Contractual Clauses
OpenAI, L.L.C.	Large language model processing of case notes content	Case notes content only	United States	UK Addendum to EU Standard Contractual Clauses
Pinecone Systems, Inc.	Vector database for retrieval of curated knowledge in response to case notes content	Vector embeddings derived from case notes content and from the curated knowledge base	United States (AWS us-east-1)	UK Addendum to EU Standard Contractual Clauses
Google LLC (Drive, Colab)	Document storage and processing pipeline for the curated clinical knowledge base — no Patient Data is processed in this pipeline	Curated knowledge base content only	EEA / Worldwide	UK Addendum to EU Standard Contractual Clauses
Stripe Payments Europe Ltd / Stripe, Inc.	Payment processing	Billing information (no Patient Data)	EU (primary) / US	UK Addendum to EU Standard Contractual Clauses
Microsoft 365 (Microsoft Ireland Operations Ltd)	Email and support communications	User correspondence (no Patient Data unless included by the Controller)	EU (primary) / Worldwide	UK Addendum to EU Standard Contractual Clauses

Changes to this list will be notified to the Controller in accordance with clause 4.4(b).

Schedule 3 — Technical and organisational security measures

The Processor implements the following technical and organisational measures to ensure a level of security appropriate to the risk of processing Patient Data:

Encryption

All Patient Data is encrypted in transit using TLS 1.2 / 1.3 between the Controller’s device and the Platform, and between the Platform and its Sub-processors
All Patient Data is encrypted at rest using AES-256

Access control

Authenticated access — all Users must sign in with a valid account before any data can be accessed
Server-side enforcement of access controls — every data request is validated at the server, so that even if the client interface were bypassed, no User can fetch records that do not belong to them
Per-User data isolation — each User account can only access patients they themselves have entered
Administrative access is restricted to the Platform’s sole administrator (the Data Controller named in section 2 of the Privacy Policy), and is governed by clause 6 of this DPA

Operational measures

Sub-processor due diligence and written data processing agreements with each authorised Sub-processor
Logging and monitoring of access to systems containing personal data
Backup and disaster recovery arrangements
A documented process for responding to suspected security incidents
Personal data breach notification procedures aligned with UK GDPR Articles 33 and 34

Future enhancements

As the Platform develops, the Processor will introduce additional safeguards including:

Access logging providing a verifiable record of administrative access to Patient Data
Role-based access controls beyond the current single-administrator model
Additional certifications and attestations as appropriate to the Platform’s scale