DPA – The Body Navigator

Body Navigator — Data Processing Agreement

Last updated: 9 September 2026 Supersedes: version of 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.

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 by any means — including typed entry, document upload, and voice recording — together with content generated by the Platform in relation to that Patient and the Controller’s recorded interactions with it, 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

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, including where a Patient completes an outcome measure within the Platform;

(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;

(h) applying data minimisation to documents you upload and to voice recordings, recognising that clinical correspondence, scan reports and referral letters routinely contain direct identifiers and that a transcript carries whatever is said — and including only information that is clinically necessary.

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.

The single exception is set out at clause 6A (derived safety metrics), where we act as Controller in respect of aggregated, de-identified metrics.

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, speech-to-text transcription, document ingestion, 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

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. 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.

Assistance available to the Controller includes export of the case record, comprising case notes, the case notes timeline, uploaded document content, transcripts, generated outputs and the record of ruled-in and ruled-out considerations, in a structured, commonly used format.

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.

Deletion of a case deletes all Patient Data associated with it, including uploaded documents, transcripts, timeline entries, outcome measure responses, objective test results and the record of ruled-in and ruled-out considerations.

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.

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).

Case notes content is currently processed by OpenAI under “Global” residency, which may include the United States. The Processor is migrating this processing to OpenAI’s European region, after which case notes content will be processed within the EEA. The Processor uses the OpenAI Chat Completions API with the store parameter defaulting to false, so case notes content is not retained by OpenAI in a retrievable form; it is held only transiently for prompt caching and abuse-monitoring (up to 30 days). The Processor is applying for Zero Data Retention to remove this transient retention.

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

The Controller acknowledges that content uploaded as a document, and transcripts of audio recorded within the Platform, are transferred on the same basis as typed case notes content, that such content may contain direct Patient identifiers, and that the Controller’s data-minimisation obligation at clause 2.1(h) is material to limiting the identifiability of the data so transferred.

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) The administrator does not review the record of a Controller’s ruled-in and ruled-out considerations for the purpose of assessing, ranking or monitoring the professional performance of any individual Controller;

(d) 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;

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

(f) Administrative access is individually logged, providing a verifiable record of when access has occurred. [TO CONFIRM: confirm access logging is live, and align clause 6(f), Schedule 3, the Privacy Policy and the DPIA.]

6A. Derived safety metrics — Processor acting as Controller

As the manufacturer of a Class I medical device registered with the MHRA, the Processor has post-market surveillance obligations in respect of the Platform.

For that purpose the Processor may derive aggregated, de-identified metrics from Platform usage, including from the record of considerations Controllers rule in and rule out, in order to monitor the clinical safety and behaviour of the Platform and to detect changes in its performance over time.

In respect of those derived metrics the Processor acts as Controller, relying on Article 6(1)(f) legitimate interests, the legitimate interest being the safety monitoring of a registered medical device. The following apply:

(a) only aggregated, de-identified metrics are used for this purpose;

(b) aggregation is carried out such that no individual Controller or Patient is identifiable in the resulting metrics;

(d) the derived metrics are not Patient Data and are not subject to the deletion obligations at clause 4.8; and

(e) this purpose does not permit any access to Patient Data beyond that already provided for at clause 6.

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, whether by typed entry, document upload or voice recording;

(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.

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.

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.

9.4 Contact

Andrew Jackson Physiotherapy, UNTIL, 1 Orchard Street, London W1H 6HJ. Email: andrew@thebodynavigator.com

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 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 or for the establishment, exercise, or defence of legal claims.

Deletion of an individual case deletes all Patient Data associated with that case.

[TO CONFIRM: retention of audio recordings — whether discarded immediately after transcription or retained, and if retained for how long. Add to this schedule and to Privacy Policy section 7.]

[TO CONFIRM: retention of Clinical Assistant chat exchanges — whether persisted against the case or session-only.]

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.

Processing also includes: speech-to-text transcription of audio recorded by the Controller within the Platform; ingestion of documents uploaded by the Controller, and processing of their textual content as case notes content; maintenance of a chronological case notes timeline, to which the Controller may add notes from subsequent sessions, and against which a working hypothesis may be re-evaluated; storage of outcome measure responses and objective test results recorded by or with the Controller; interactive processing of questions put by the Controller to the Clinical Assistant chat, together with the case context supplied to it; and recording of the Controller’s interaction with surfaced considerations — which were ruled in, which were ruled out, their prioritisation, and any added by the Controller.

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 take clinical decisions.

Types of personal data

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

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

Patient name
Patient age (date of birth is not collected)

Case notes and clinical content — processed by the AI sub-processors (OpenAI, and Pinecone for retrieval), currently under “Global” residency (which may include the United States), with migration to OpenAI’s European region in progress:

Clinical history and presenting complaint
Examination findings
Imaging or test results entered by the Controller
Working hypotheses, treatment plans, and other generated outputs
Textual content of documents uploaded by the Controller
Transcripts of audio recorded by the Controller
Notes added to the case notes timeline at subsequent sessions
Outcome measure responses and scores, including where entered by the Patient
Objective test results recorded against a working hypothesis
Questions put to the Clinical Assistant chat, and the case context supplied with them
The record of considerations ruled in and ruled out, their prioritisation, and considerations added by the Controller
Other clinical information relevant to the consultation, as entered by the Controller

In line with the data minimisation principle, the Controller should include only clinically necessary information in case notes content and avoid unnecessary identifiers where reasonably practicable. Direct identifiers entered in the dedicated Patient identifier field are stored separately in the EEA and are not transmitted to the AI sub-processors.

The Controller acknowledges that case notes content — including typed text, pasted text, uploaded documents and voice transcripts — may contain direct Patient identifiers (such as names, dates of birth or NHS numbers appearing in clinical correspondence), and that where present, such identifiers are transmitted to and processed by the AI sub-processors under the safeguards in clause 5 and Schedule 3. This applies with particular force to uploaded documents, which routinely carry direct identifiers in headers, footers or body text, and to voice recordings, where a transcript carries whatever is said.

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

Sub-processor	Role	Data processed	Location	Transfer safeguard
Google LLC (Firebase / Google Cloud — EU region)	Application database (Firestore) — storage of accounts, Patient identifier fields, case notes, uploaded document content, transcripts, timeline entries, outcome measure responses and activity records	User account information; Patient identifier fields; case notes content	European Economic Area (Belgium)	UK Adequacy Regulations (EEA)
Google LLC (Firebase Authentication)	User authentication	User email address only	United States	UK Addendum to EU SCCs
OpenAI, L.L.C.	LLM processing of case notes content, including uploaded document content, transcripts and Clinical Assistant chat exchanges	Case notes content, which may include patient identifiers present in the notes, uploaded documents, transcripts or chat. Patient identifier fields are not transmitted to OpenAI.	Currently “Global” (may include the United States); migration to European processing in progress	UK Addendum to EU SCCs
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 SCCs
[TRANSCRIPTION PROVIDER — TO CONFIRM]	Speech-to-text transcription of audio recorded within the Platform	Audio recordings and resulting transcripts	[TO CONFIRM]	[TO CONFIRM]
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 SCCs
Stripe Payments Europe Ltd / Stripe, Inc.	Payment processing	Billing information (no Patient Data)	EU (primary) / US	UK Addendum to EU SCCs
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 SCCs

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

[TO CONFIRM before publication: the transcription provider must be identified, its location of processing established, an appropriate transfer safeguard put in place, and a data processing agreement executed. If transcription is performed by an existing sub-processor already listed above, amend that entry rather than adding a new row. Whether audio is retained by the provider after transcription must also be established.]

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, and is governed by clause 6 of this DPA
Access logging providing a verifiable record of administrative access to Patient Data, at application level, with independent Google Cloud infrastructure-level logging. [TO CONFIRM: confirm access logging is live; align this Schedule with clause 6(f), the Privacy Policy and the DPIA before publication.]

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:

Migration of AI processing to European residency and adoption of Zero Data Retention (both in progress)
Secure secret-storage of service credentials and rotation of service API keys
Role-based access controls beyond the current single-administrator model
Controls on the size, format and content of uploaded documents
Additional certifications and attestations as appropriate to the Platform’s scale