Pular para conteúdo

GDPR Data Protection Impact Assessment — EPPA

DPIA is mandatory for EPPA

Pursuant to GDPR Art. 35(3)(b), a DPIA is mandatory where processing involves "processing on a large scale of special categories of data referred to in Article 9(1)". EPPA processes photographic images of identifiable patients together with derived clinical metrics — this is data concerning health within the meaning of Art. 4(15) and a special category under Art. 9(1). The DPIA must be completed and signed off before the first non-research deployment, and revisited whenever processing changes materially (Art. 35(11)).

1. Document identity

Field Value
Document title EPPA Data Protection Impact Assessment
Document ID EPPA-DPIA-001
Version 0.1 (draft)
Status Draft — not yet submitted to DPO
Effective date n/a
Controller LABIS UCA — Universidad Católica Argentina (research-use phase)
Joint / sub-processors TBD per deployment (Cloudflare R2, hosting provider, SMTP relay)
DPO Pending appointment
Linked documents 00-overview.md, 01-intended-use-statement.md, 91-non-device-disclaimer.md

2. Description of the processing (Art. 35(7)(a))

2.1 Purpose

To assist a qualified clinician (see 01-intended-use-statement.md §3) in the photographic documentation and qualitative analysis of standing posture in adult patients, within an approved clinical research protocol.

2.2 Categories of personal data processed

Category Examples GDPR class Origin
Identifiers Patient pseudonym (UUID v4) Art. 4(1) personal data Generated client-side at intake
Identifiers (current state) Patient name in sessionStorage only Art. 4(1) personal data Entered by clinician at intake. Note: will move to server-side encrypted column when Lane L5 / Epic E3 lands.
Biometric — facial Faces appear in anterior + lateral photos Art. 9(1) special — biometric Captured by clinician
Health — postural Marker coordinates, derived angles, qualitative labels Art. 9(1) special — health Computed from images
Clinician identifiers (future) Email, hashed password, role Art. 4(1) personal data Account creation (Epic E3)
Technical Browser user-agent, IP for security logs Art. 4(1) personal data Web server access logs

2.3 Data subjects

  • Patients undergoing postural assessment in a LABIS-affiliated clinic or in a research site running an approved protocol.
  • Clinicians (kinesiologists, physiotherapists, physicians) using the tool.

2.4 Recipients

In the research-use phase, no recipient outside the controller other than:

  • The clinician operating EPPA at the point of care.
  • The hosting provider acting as a processor under an Art. 28 DPA (TBD).
  • The CSV / PDF report, exported to a research database controlled by the same LABIS UCA research group, under the same Art. 28 / institutional agreement.

2.5 Transfers outside the EEA

Flow Origin Destination Mechanism Status
App hosting (planned) EU clinic Cloudflare Workers / R2 (multi-region) Art. 46(2)(c) SCCs + Cloudflare DPA TBD
App hosting (Argentina) AR clinic LABIS UCA on-premise Adequacy decision: AR is recognised by EU Commission Decision 2003/490/EC OK
Image storage (current) Clinic Local browser / on-premise No transfer OK

Argentina adequacy

Commission Decision 2003/490/EC declares Argentina an "adequate" third country for the purposes of Art. 45. Data transferred from the EEA to LABIS UCA infrastructure in Argentina does not need SCCs.

2.6 Data flow diagram (current state)

   ┌───────────────┐   ┌────────────────────┐   ┌─────────────────────┐
   │  Clinician    │   │  Patient           │   │  Camera             │
   │  (browser)    │◄──┤  (in clinic)       │──►│  (photo capture)    │
   └───────┬───────┘   └────────────────────┘   └──────────┬──────────┘
           │                                               │
           │                          image (JPG/PNG)      │
           │ ◄─────────────────────────────────────────────┘
           │
           ▼
   ┌──────────────────────────────────────────┐
   │  EPPA Next.js client (localhost:9002)    │
   │  ─ patient ID + name in sessionStorage   │
   │  ─ markers placed in-browser             │
   │  ─ POST image + markers to API           │
   └──────────────────┬───────────────────────┘
                      │  HTTP (loopback in research-use phase)
                      ▼
   ┌──────────────────────────────────────────┐
   │  EPPA FastAPI server (localhost:8100)    │
   │  ─ stateless computation                  │
   │  ─ returns analysis JSON                  │
   │  ─ no persistence in current build        │
   └──────────────────┬───────────────────────┘
                      │
                      ▼
   ┌──────────────────────────────────────────┐
   │  CSV / PDF export (clinician's disk)     │
   │  ─ MUST carry non-device disclaimer       │
   │  ─ MUST carry pseudonymised patient ID    │
   └──────────────────────────────────────────┘

When Epic E3 (server-side persistence) lands, the data flow changes materially: this DPIA must be re-issued at that point.

3. Necessity and proportionality (Art. 35(7)(b))

3.1 Lawful basis under Art. 6

Two lawful bases are available depending on the deployment context:

  • Art. 6(1)(a) — consent. In a private-clinic research-use deployment, consent is obtained at intake under a written information sheet. This is the default basis. It requires that consent be specific, informed, freely given and revocable (Art. 7).
  • Art. 6(1)(e) — task carried out in the public interest / official authority. In a hospital-research deployment where the institution is designated by national law to carry out clinical research, this basis may apply in addition to or in place of consent. Choice between (a) and (e) must be documented per deployment.

Why not Art. 6(1)(b) — contract?

A patient does not enter a contract with EPPA, and the processing is not necessary for the performance of a clinician–patient treatment contract (EPPA is research-use, not part of care). Art. 6(1)(b) is therefore not available.

3.2 Special-category basis under Art. 9

The default basis is Art. 9(2)(j) — scientific research with appropriate safeguards (Recital 159, Art. 89(1)).

Required Art. 89(1) safeguards in place for EPPA:

  • Data minimisation — only the photographic frames of the patient required for the four standard views are captured; no continuous video; no audio.
  • Pseudonymisation — patient identifier in exports is a UUID; the mapping to identity is held in a controlled register (in the current state, in the clinician's local sessionStorage; in Epic E3, in an encrypted Postgres column with pgcrypto and a KMS-managed key).
  • Technical and organisational measures under Art. 32 — see section 5.
  • Purpose limitation — research-use only, no profiling, no decisions with legal effect under Art. 22.

Alternative bases that may apply in specific deployments:

  • Art. 9(2)(a) — explicit consent. Used when (j) is not available, e.g. when the research element is not formalised.
  • Art. 9(2)(h) — health and social care with Art. 9(3) safeguards (processing under the responsibility of a professional bound by professional secrecy). Applicable in a clinical-care context — outside the current intended use.

3.3 Proportionality

Question Answer
Is there a less-intrusive alternative? A non-photographic posture-assessment workflow (palpation + goniometer notes) exists. EPPA is justified by reproducibility, longitudinal comparison and inter-rater reliability.
Is the data adequate, relevant and not excessive (Art. 5(1)(c))? The captured image is the minimum needed to compute postural metrics. Captures are deleted from the device after upload to the research repository under the retention schedule below.
Are decisions taken solely on the basis of automated processing (Art. 22)? No. All EPPA outputs are advisory; the clinician's judgement is in the loop. Art. 22 does not apply.

4. Risk identification (Art. 35(7)(c))

The following risk register is the seed for the ISO 14971 risk file (planned in 12-iso-14971-risk.md). Likelihood, impact and risk levels are on a 1–5 scale.

# Risk Likelihood Impact Risk Mitigation
R1 Re-identification from facial features in anterior/lateral images even when the patient ID is pseudonymised 4 5 High Implement a face-blur preprocessing step for any image leaving the controller's perimeter (research dataset export, analytics, ML training); store original images encrypted at rest; require explicit consent for un-blurred storage.
R2 Unauthorised access to patient images via mis-configured object storage (S3 / R2 / MinIO bucket public) 3 5 High Bucket policy default-deny; signed pre-signed URLs with TTL ≤ 15 min; IAM scoped per-clinician; quarterly access review; CSPM scan in CI.
R3 Transfer of personal data to a non-EU / non-adequate jurisdiction without SCCs (e.g. a US-only CDN edge serving EU clinic traffic) 3 4 High Region-locked deployment for EU clinics; Cloudflare R2 with EU jurisdiction setting; SCCs in the DPA; transfer impact assessment (TIA) per deployment.
R4 Loss of CSV / PDF export containing patient data via clinician's lost laptop 3 4 High Full-disk encryption mandatory on every clinical workstation; export contains pseudonymised ID only; mapping register kept on a separate device; non-device disclaimer header in every export.
R5 Stale sessionStorage patient ID leaks across clinical sessions if the browser tab is reused with a different patient 3 3 Medium Hard-clear sessionStorage on logout (Epic E3); patient context indicator in the header; idle timeout of 10 minutes.
R6 Insider threat — a credentialed clinician browses patient images outside their case load 2 4 Medium Per-action audit log (immutable append-only — Epic E3 AuditLog model); access proportional to role; quarterly access-anomaly review.
R7 Backup leakage — Postgres backup including images stored unencrypted 2 5 Medium Backups encrypted with KMS-rotated keys; backup retention 90 days; quarterly restore drill; access to backups MFA-gated.
R8 Subject Access Request (Art. 15) not deliverable within one month (Art. 12(3)) because data is spread across the clinic device + sessionStorage + research repository with no single index 3 3 Medium DSAR runbook with named owner; single-pane patient index in Epic E3; documented procedure for the research-use phase.
R9 Right to erasure (Art. 17) not honourable for analyses retained for scientific research under Art. 89(1) 3 3 Medium Document the Art. 17(3)(d) exemption (necessity for scientific research) in the privacy notice; offer irreversible pseudonymisation in lieu of erasure where consistent with the research purpose.
R10 Cross-tenant data leak in a future multi-clinic deployment due to missing organisation scoping 2 5 Medium Mandatory organization_id column on every query (enforced at ORM level); per-tenant integration tests; tenancy fuzz test.

5. Technical and organisational measures (Art. 32)

Domain Measure Status
Pseudonymisation (Art. 32(1)(a)) Patient UUID in exports Partially in place (current build)
Encryption (Art. 32(1)(a)) TLS 1.3 in transit; AES-256 at rest in object storage; pgcrypto for Patient.full_name Planned (Epic E3)
Confidentiality (Art. 32(1)(b)) RBAC: admin, clinician, viewer; clinic-scoped queries Planned (Epic E3)
Integrity (Art. 32(1)(b)) Append-only AuditLog; image hash recorded at upload Planned (Epic E3)
Availability (Art. 32(1)(b)) Daily backup, 90-day retention, quarterly restore drill Planned (Epic E3)
Resilience (Art. 32(1)(b)) Multi-AZ Postgres; CDN failover Planned (Epic E3)
Restoration (Art. 32(1)(c)) Documented restore procedure; RTO 4h, RPO 24h Planned (Epic E3)
Testing (Art. 32(1)(d)) Quarterly tabletop; annual penetration test Planned

A pragmatic security checklist mapped to OWASP ASVS L2 + IEC 82304-1 §6 is maintained at 50-secdev-checklist.md (planned).

6. Data subject rights — operational procedures

Right Article Owner SLA Procedure
Information (privacy notice) Art. 13/14 Clinic intake clerk At collection Hand the patient the EPPA privacy notice in the patient's language before image capture; obtain consent signature.
Access Art. 15 DPO (delegated to controller's records manager) 1 month, extendable by 2 months Patient writes to privacy@labis-uca.com.ar ; records manager retrieves all images, derived data and audit-log entries via patient UUID; delivers in machine-readable format.
Rectification Art. 16 Treating clinician 1 month If marker coordinates are demonstrably wrong, the clinician re-runs and supersedes the prior analysis. The prior record is not deleted (audit purpose) but is flagged superseded.
Erasure Art. 17 DPO 1 month If the request falls within Art. 17(3)(d) exception (scientific research with Art. 89(1) safeguards), the controller offers irreversible pseudonymisation: face-blur of images, deletion of the UUID-to-identity mapping. Otherwise, full deletion.
Restriction Art. 18 DPO 1 month Records are flagged restricted=true in the database; excluded from analytics and research exports until resolved.
Portability Art. 20 DPO 1 month Export in CSV + JSON of all marker sets, analysis runs and image hashes attributable to the data subject. Images themselves are also portable as a ZIP.
Objection Art. 21 DPO Immediate Halt processing pending balancing test against the public-interest research basis (Art. 6(1)(e) / Art. 9(2)(j)).
Withdrawal of consent Art. 7(3) DPO Immediate Where consent (Art. 6(1)(a)) is the basis, withdrawal halts further processing; data already processed remains lawful but is subject to erasure on request.

7. Retention schedule

Data class Retention Trigger to start Action at end
Raw clinical images (research-use) 10 years Date of capture Irreversible pseudonymisation (face blur) OR deletion, per consent.
Marker sets and analysis runs 10 years Date of capture Same.
CSV / PDF exports held by clinician 10 years Date of export Same; clinician is co-controller for exported copies.
Audit log (AuditLog) 10 years Event date Deletion.
Consent records (ConsentRecord) 10 years from end of processing Withdrawal or end of retention of corresponding data Deletion.
Clinician account data (email, hash) Duration of employment + 6 months Onboarding Deletion after offboarding.
Web server access logs (Art. 32 security) 90 days Date of request Deletion.

The 10-year figure is anchored to the Argentinian Ley 26.529 Art. 18 minimum record-retention period for clinical records (10 years from the last contact with the patient), and is consistent with EU national rules ranging from 10 to 30 years depending on jurisdiction. The retention schedule must be re-confirmed per deployment market.

8. ROPA — Record of Processing Activities (Art. 30) — skeleton

Field Value
Controller name LABIS UCA — Universidad Católica Argentina
Controller address TBD
Controller contact TBD (privacy@… email pending)
DPO contact TBD
Joint controllers None (research-use); may include affiliated research site in collaborative protocol
Processors (Art. 28) TBD per deployment: hosting (Cloudflare or equivalent), SMTP relay, backup storage
Processing purpose Research-use postural assessment (see §2.1)
Categories of data subjects Adult patients in clinical research; clinicians
Categories of personal data See §2.2
Categories of recipients See §2.4
Transfers to third countries See §2.5
Retention See §7
Security measures See §5
Lawful bases Art. 6(1)(a) or 6(1)(e); Art. 9(2)(j) by default
ROPA last reviewed 2026-05-21
Next review 2027-05-21 or on material change

9. Consultation with the DPO and supervisory authority

Pursuant to Art. 35(2), the DPO has been consulted on this draft (status: pending appointment — open question).

Pursuant to Art. 36, prior consultation of the supervisory authority is required where the DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. After applying the measures in §5, all residual risks in §4 are Medium or lower. Prior consultation is therefore not currently required but must be revisited after each material change (e.g. addition of automated decision-making, addition of a US-based processor without SCCs, change of target population to include paediatric patients).

10. Sign-off

Role Name Decision Date
Controller (LABIS UCA) TBD TBD TBD
DPO TBD TBD TBD
Head of Clinical TBD TBD TBD
Head of Quality TBD TBD TBD

This DPIA is a living document. It must be reviewed annually or upon any material change to the processing, the data categories, the recipients, the transfers, the retention, or the security posture.

References