Incorporated as a schedule to the Tenant Licence Agreement signed in this onboarding pack and referenced by the clinician agreement signed alongside it. It is the Data-Processing Agreement the Master Terms (§11.1) incorporate: §6 sets the processor terms UK GDPR Article 28(3) requires. It also states, in one place, the Hard Constraints and why the data-protection surface is deliberately tiny. Provider: GGO Systems Limited (ICO registration ZC174006).
1. The core posture: no intentional patient-identifying data collection
As a matter of fixed design, the suite:
1. Does not intentionally collect patient-identifying health information. No patient name, email, date of birth, NHS number, MRN or other direct patient identifier is requested or stored by the patient-facing products.
2. Does not create patient accounts or profiles. No patient logins, no email capture, no behavioural profiling, no re-identifying analytics.
3. Never authenticates a patient. Patient-facing products (Polaris, The Compass) are anonymous. This principle is absolute.
4. Uses no advertising trackers, cross-site tracking, or behavioural profiling. Patient-facing apps use privacy-preserving, cookieless aggregate analytics (Plausible) only.
5. Contains no clinical decision logic. The suite presents information; it does not advise, triage, or recommend.
Technical telemetry, access-control tokens, IP addresses in infrastructure logs and procedure-specific links may create contextual privacy sensitivity even where they do not identify a patient by name. They must be minimised, retained only as needed for security/operations, and never used to identify patients.
2. The only credentialled surfaces
The "no authentication" rule is relaxed only for clinician / staff identity, and only on non-patient-facing surfaces:
- The Helm — authenticates clinician / staff identity only (never a patient). It persists an opaque clinician id; the registration number lives with the identity provider.
- Sanity Studio — content authoring, credentialled, non-patient-facing.
- This onboarding tool — processes the Tenant's / Author's business-contact and professional-registration data to form these agreements (not patient data).
The limited personal data processed is therefore clinician / staff / business-contact data — not patient data.
3. Data-protection analysis (summary)
- Patient-identifying data: not intentionally collected. The residual privacy surface is limited to technical telemetry, local device preferences, aggregate analytics and procedure-specific access context, which are minimised and assessed in the DPIA.
- Clinician / staff / contact data: limited account and contract data, processed under UK GDPR and the Data Protection Act 2018. Lawful basis: contract and/or legitimate interests.
- Sub-processors: Vercel (hosting), Sanity (CMS), Plausible (aggregate analytics, EU/Germany), Clerk (Clerk, Inc., USA — Helm auth). Notion (Notion Labs, Inc., USA) and the Provider's email provider process the onboarding records and signed packs.
4. The MVP gap — declared openly
Because there is no patient authentication and no patient identifier, the suite cannot prove an individual patient accessed a given asset. The litigation-defensibility narrative is population-level (Montgomery framing). This is a known, declared limitation, not a hidden defect, acknowledged by the Tenant at intake.
5. Audit trail (what is recorded)
Per content item: sourceDocumentType + sourceVersionReflected + lastSyncedAgainstSource; per pathway: approvalAuthority; Sanity edit history; and the immutable `clinicalSignoff` audit. This is clinician/staff governance metadata, not patient-identifying data. This Agreement itself is recorded with an electronic-signature audit (typed name, timestamp, document hash, IP, user-agent).
6. Processor terms (UK GDPR Article 28(3))
For the clinician and staff personal data described in §2, the Tenant is the controller and the Provider is the processor. This section is the written contract that UK GDPR Article 28(3) requires. It is signed with this pack as the Data-Processing Agreement the Master Terms incorporate; no separate data-processing agreement is needed.
6.1 Subject matter and duration. The processing of the Tenant's staff identity and business-contact data for the life of the licence (the Tenant Licence Agreement and any schedule that replaces or extends part of it), and thereafter only for the audit retention the Master Terms require.
6.2 Nature and purpose. Authenticating the Tenant's clinicians and staff in The Helm; operating the Deployment, including the clinical sign-off audit trail, support records and platform-security logs; and forming, storing and keeping these agreements.
6.3 Types of personal data and categories of data subject. Clinician and staff names, work email addresses, professional registration numbers, roles, and business-contact details, with the sign-in and audit metadata that accompanies them (timestamps, IP address, user agent). Data subjects: the Tenant's clinicians and staff — never patients.
6.4 The Provider's obligations as processor. The Provider will:
- (a) process the personal data only on the Tenant's documented instructions, which are these agreements, unless required to do otherwise by law, in which case it informs the Tenant before processing where the law allows;
- (b) ensure that every person it authorises to process the personal data is bound by a duty of confidentiality;
- (c) implement technical and organisational security measures appropriate to the risk; the Provider holds Cyber Essentials certification and maintains it while it processes the Tenant's data;
- (d) engage sub-processors only as listed in §3, give the Tenant notice of any intended addition or replacement, and allow the Tenant to object on reasonable data-protection grounds; the Provider imposes the same data-protection obligations on each sub-processor and remains liable to the Tenant for its performance;
- (e) taking into account the nature of the processing, assist the Tenant by appropriate technical and organisational measures in responding to requests from data subjects, and assist the Tenant in meeting its obligations under Articles 32 to 36 (security, breach notification, data-protection impact assessment and prior consultation) taking into account the information available to the Provider;
- (f) at the end of the licence, at the Tenant's choice, delete or return the personal data and delete existing copies, except to the extent that the audit retention the Master Terms require, or applicable law, requires the Provider to keep it;
- (g) make available to the Tenant all information necessary to demonstrate compliance with this section, and allow for and contribute to audits, including inspections, conducted by the Tenant or an auditor the Tenant mandates, on reasonable notice and no more than once in any twelve months unless a regulator requires otherwise or a personal-data breach has occurred;
- (h) inform the Tenant immediately if, in its opinion, an instruction infringes UK GDPR or other data-protection law;
- (i) notify the Tenant without undue delay after becoming aware of a personal-data breach affecting the Tenant's staff data.
6.5 International transfers. Clerk (Clerk, Inc.) and Notion (Notion Labs, Inc.) process data in the USA. The Provider relies on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses with those sub-processors and completes a transfer risk assessment for each. No patient data is transferred, because none is collected.
7. Tenant obligations
- Do not introduce patient identity, accounts, advertising trackers, cross-site tracking or behavioural profiling into any surface.
- Keep source documents current so source-declared content stays aligned.
- Operate the Tenant's own clinical governance over content.
This note states the position for the MVP. Any change to §1 is a written variation under the Master Terms (clause 12.3), not an operational tweak.