Data Protection Impact Assessment — the CAREFUL Platform

Document ID

[to be assigned in the ISO 27001 document register]

Version

2.0 · Draft · 24-Aug-2026

Supersedes

Privacy Impact Assessment v1.4, 27-Jan-2021

Owner

Data Protection Officer

Approver

Chief Executive Officer

Classification

Provided to adopting organisations

Next review

On approval, then annually or on material change

Template

ICO Sample DPIA template (following ICO DPIA guidance)

Standing note on roles. Careful Systems Limited (CSL) is the manufacturer of CAREFUL and, for patient and staff data processed in the platform, the processor. Each deploying healthcare organisation is the controller and is responsible for its own deployment DPIA (as recorded in our data sharing agreements); CSL provides this product DPIA and all reasonable assistance to support that assessment. This document assesses the processing CSL performs and designs, in both its processor capacity and its own controller capacities (staff, contacts, operational data), so that a controller can rely on it rather than reconstruct it.

Submitting details

Name of organisation

Careful Systems Limited (processor / manufacturer)

Data Protection Officer

Contactable at privacy@careful.online; the appointment is notified to the ICO

Contact

privacy@careful.online

Step 1: The need for a DPIA

CAREFUL is a clinical coordination platform processing patient-identifiable and special category (health) data at scale on behalf of NHS and other healthcare organisations. Processing of health data on a large scale is a type of processing the ICO identifies as likely high risk, so a DPIA is required. This assessment covers the platform as a product; it is reviewed on any material change to the platform, its data flows or its sub-processors (our Data Protection Policy requires screening before any new project, integration, sub-processor or purpose), and it supports — but does not replace — each controller's deployment DPIA.

Step 2: Description of the processing

Nature. Every deployment follows one pattern. Clinical and operational staff enter coordination data (tasks, handovers, referrals, patient status, team messages, basic notes) through native iOS/Android applications and a web interface. Where the controller enables it, patient demographics and ward-level location are populated automatically from the controller's Patient Administration System by HL7 ADT messaging, reducing transcription error. Data is stored on Microsoft Azure infrastructure in the UK (UK South), encrypted at rest (AES-256) and in transit (TLS 1.2+). No server-held data is stored on user devices; push notifications carry no patient-identifiable or clinical content. Every transaction is recorded in an attributable audit trail. Data is deleted or returned on the controller's instruction and at contract end (return in usable format and/or secure deletion within 30 days). The platform performs no automated decision-making or profiling.

Data flows. Staff device → TLS → Azure UK South (application, database, messaging services) ← HL7 ADT ← controller PAS. Outbound flows are limited to: pseudonymised error telemetry to Sentry and usage analytics to PostHog (EEA — see transfers), staff notifications by SMS/email via Twilio/SendGrid (EU residency; staff only, no patient communications), and push notification delivery via Azure Notification Hubs with the Apple and Google push services (transaction-nature only, no identifiable content). Architecture and data-flow diagrams accompany this document.

Scope. Patient data: name, address, date of birth, telephone number, NHS number, hospital number, ward and bed location, clinical summary including past medical history, clinical plans and actions, and responsible-clinician identity. This includes special category (health) data. Staff data: names, work email addresses, roles and grades, team membership, and platform activity (audit trail). No criminal offence data. Volume: all inpatients within the deployed services of each controller, processed continuously for the duration of each agreement; typical deployments range from single-pathway pilots to organisation-wide use. Records of deceased patients may be present in the ordinary course of care. Geography: patients resident or treated in the UK; all patient data stored in the UK only. Retention: for the duration of each agreement, then per the controller's instruction under the NHS Records Management Code of Practice.

Context. Data subjects are patients receiving care and the staff caring for them. Patients do not interact with the platform directly; their reasonable expectation is that information is shared among the team treating them, which is precisely the processing performed — Caldicott principle 7 (the duty to share for direct care) alongside principle 4 (need-to-know) shaped the design. Data subjects include children and vulnerable adults as ordinary patients of the deployed services; no child-specific or vulnerability-specific processing occurs. The processing replaces less controlled channels (consumer messaging, paper lists, pagers) and is therefore risk-reducing relative to current practice. The technology (team-scoped access, event-sourced audit) is established rather than novel. The Ambient Voice feature (speech capture for task and note creation) is novel in character, is disabled by default, and is out of scope of any deployment until the controller enables it, at which point the conditional assessment at Annex A applies and this DPIA is updated. CSL holds Cyber Essentials Plus, completes the DSPT annually (Standards Exceeded, 2025/26), and is ICO-registered (ZA249706).

Purposes. The purpose of the processing is the direct care of individual patients: safer, faster coordination of clinical work, with visibility and accountability of tasks and responsibility. Intended effects on individuals are fewer missed or delayed actions, safer handovers, and an attributable record of coordination. Benefits are evidenced in deployment evaluations (e.g. 30–60 minutes saved per clinician shift; 64% reporting safer end-of-shift handover). CSL gains no benefit from the data beyond providing the service and is contractually barred from further processing.

Step 3: Consultation

Patients are not consulted directly by CSL: CSL has no relationship with patients, and consultation on direct-care processing is the controller's channel through its privacy notice, patient information and engagement mechanisms — each controller confirms this in its deployment DPIA. Clinical users are consulted continuously: the product is clinician-designed, user acceptance testing runs at every release, and structured user feedback is collected in deployments. Internally, the DPO, Clinical Safety Officer, CTO and Cybersecurity Lead review this assessment; the clinical safety dimension is assessed in parallel under DCB0129 (Clinical Safety Case Report and Hazard Log, which this DPIA cross-references). Processor assistance: sub-processor DPAs and security documentation were reviewed. External security expertise: CREST-accredited penetration testing (most recently July 2026).

Step 4: Necessity and proportionality

Lawful basis. The controller's basis is Article 6(1)(e) UK GDPR (public task: provision of healthcare) with Article 9(2)(h) (provision of health care and treatment and management of health systems), the Article 9(3) safeguard being met because processing is by or under the responsibility of professionals owing a duty of confidentiality. The common law duty of confidentiality is met by implied consent to sharing for direct care. The National Data Opt-out does not apply (individual care only). CSL processes only on the controller's documented instructions under an Article 28 agreement and will challenge an instruction it believes unlawful. For CSL's own controller processing (staff, contacts, operations), bases are set out in the published privacy notice.

Does the processing achieve the purpose, and is there a less intrusive way? Coordination of inpatient care requires the treating team to share identifiable clinical information in near-real time; the alternative channels it replaces (consumer messaging, paper) process the same data with weaker minimisation, security and audit. Pseudonymisation is not compatible with direct care. The processing is therefore necessary and the least intrusive means available for the purpose.

Function creep. Prevented contractually (processing only on documented instructions; no other purpose; new sub-processors require prior written consent) and procedurally (DPO screening gate before any new purpose, feature, integration or sub-processor — the mechanism that also triggers review of this DPIA). Analytics are pseudonymous and operational only; the audit record is provided to controllers for their own governance, not used by CSL for other ends.

Data quality and minimisation. PAS integration makes the controller's PAS the source of truth for demographics, reducing transcription error; three identifiers are displayed on every patient screen; entries are correctable by users with a full audit trail, with a controlled retrospective-correction service for gross mis-transcription (senior-clinician request, logged as a data incident). Minimisation by design: the platform holds coordination data, not the full record; push notifications carry no identifiable content; no data on devices; telemetry is scrubbed on-device before transmission; team scoping limits each user's view to patients they care for.

Information to individuals and rights support. Controllers inform patients through their privacy notices (each commits in the data sharing agreement to cover CAREFUL); CSL publishes its own notice at careful.online/privacy and a sub-processor list. Rights are handled by the controller with CSL assistance within statutory timescales: provision of data held for subject access, rectification on instruction, erasure/restriction on instruction (noting the limited application of erasure to health records held under public task), exports to support portability accommodations. No automated decision-making rights arise.

Processor compliance and transfers. Sub-processor DPAs flow down equivalent obligations; the authorised list is fixed per controller with prior-written-consent for additions. All patient data remains in the UK. The only international element is pseudonymised operational telemetry processed in the EEA (Sentry — Google Cloud, Frankfurt; PostHog — AWS, Frankfurt) and EU data residency for Twilio staff communications; UK-to-EEA transfers rely on the UK adequacy regulations. Identifiable information (names, contact details, NHS numbers, request and clinical content) is removed on the device before transmission to Sentry/PostHog, and CSL commits contractually to maintain that configuration.

Step 5: Risk assessment

Source of risk and potential impact on individuals

Likelihood

Severity

Overall

External attacker gains access to patient data (infrastructure breach, credential compromise) → confidentiality loss, distress. Hazard log 6.1.

Remote

Severe

Medium

Authorised user accesses patients without need-to-know (over-broad team membership, admin browsing) → confidentiality loss. Hazard log 18.1, 8.1-lineage.

Possible

Significant

Medium

CSL insider or engineer accesses production data beyond support need → confidentiality loss. Hazard log 6.1.

Remote

Severe

Medium

Telemetry scrubbing fails or regresses so identifiable data reaches Sentry/PostHog in the EEA → unlawful transfer of identifiable data.

Remote

Significant

Low

Information recorded against the wrong patient → inaccurate record, wrong-care consequences. Hazard log 10.1/11.1.

Possible

Significant

Medium

Data retained beyond need, or not returned/deleted at contract end → unlawful retention.

Remote

Significant

Low

Shared or personal device exposes another user's session or data → confidentiality loss. Hazard log 28.1.

Possible

Minimal

Low

Staff data (activity/audit records) repurposed for performance monitoring beyond the stated purpose → unfair processing of staff.

Possible

Significant

Medium

Sub-processor breach (Azure, Sentry, PostHog, Twilio) → confidentiality loss at scale.

Remote

Severe

Medium

R10

Ambient Voice, if enabled: capture of bystander speech, transcription errors entering the record, audio processed by a speech-to-text provider → confidentiality and accuracy risks. Hazards 42.1–47.1.

— (feature disabled by default; assessed at Annex A on enablement)

—

Conditional

Step 6: Measures to reduce risk

Risk

Measures

Effect

Residual

Approved

Defence in depth: WAF/DDoS at edge, private pod networking, least-privilege and IP-restricted production access, MFA on privileged accounts, Key Vault secrets with rotation, encryption at rest and in transit, annual CREST penetration testing (July 2026; findings remediated), Cyber Essentials Plus, 24-hour breach notification to controllers.

Reduced

Low

(DPO)

Team-scoped visibility (no team in common → no clinical record access); three-tier RBAC; membership visible to the whole team; attributable audit of every access-relevant transaction; transferred controls to the controller (administrator governance, leaver/rotation process, periodic access review — hazard log checklist item 3).

Reduced

Low

Production access limited to named, vetted engineers; development against synthetic data; all access via audited APIs; same-day revocation on leaving; confidentiality and annual DP training for all staff.

Reduced

Low

Client-side scrubbing configured and contractually committed; configuration covered by release regression testing; sub-processor DPAs; DPO screening before any telemetry change.

Reduced

Low

Three identifiers on every patient screen; PAS as source of truth where integrated; search-before-add; correction within the platform with audit; controlled retrospective-correction service logged as a data incident; transferred patient-identification controls (checklist item 4/6).

Reduced

Low

Contractual retention per controller instruction; return and/or secure deletion within 30 days of termination; deletion obligations flowed to sub-processors.

Reduced

Low

No data on devices; PID-free notifications; session expiry (7-min web client / 30-min server / 12-h mobile / 30-day absolute); login resets view and push routing; one-click account disable; transferred device-policy controls (checklist item 6).

Reduced

Low

Purpose limitation in the Article 28 agreement; audit and BI data provided to the controller for governance and incident investigation; controller's own staff-privacy obligations apply; CSL performs no staff analytics beyond service operation. Controllers are advised to address staff-monitoring transparency in their deployment DPIA.

Reduced

Low

Sub-processor due diligence and DPAs; certifications (Azure ISO 27001/SOC 2); minimisation so that Sentry/PostHog hold nothing identifiable; prior-written-consent gate on additions; breach notification obligations flowed down.

Reduced

Low

R10

Feature disabled by default; enablement gated on the controller's DPIA and data sharing agreement update naming the speech-to-text provider; Ambient AI Constraints Policy (recorder only — no clinical reasoning); mandatory review of generated content before saving; hazards 42.1–47.1 controls. Annex A to be completed with the controller before enablement.

Conditional gate

—

No residual risk is assessed as high; ICO consultation is not required.

Step 7: Sign-off and outcomes

Item

Name/position/date

Notes

Measures approved by

(CEO — date)

Actions integrated into the development commitment register and ISO 27001 programme

Residual risks approved by

(CEO — date)

No high residual risk; ICO consultation not required

DPO advice provided

(Data Protection Officer — signature and date)

Summary of DPO advice

(to complete)

DPO advice accepted or overruled by

(CEO — date)

If overruled, reasons must be recorded

Consultation responses reviewed by

(DPO — date)

User-consultation evidence: UAT records, deployment surveys

This DPIA will be kept under review by

Data Protection Officer

Reviewed annually and on material change to the platform, its data flows or its sub-processors; re-issued alongside any DCB0129 change assessment

Annex A (conditional): Ambient Voice enablement — to be completed with a controller before the feature is switched on

Scope of capture and locations of use; the named speech-to-text provider, its processing location and transfer basis; addition of the provider to the controller's data sharing agreement and this DPIA; patient information/notice updates; training on identity confirmation, review-before-save and capture termination; device and acceptable-use policy for open captures. Cross-reference: hazard log 42.1–47.1 and the Ambient AI Constraints Policy v1.0.