Data Protection Impact Assessment¶

Facilitator Referral Attribution System¶

1. Description of Processing¶

What: When a patient arrives via a facilitator referral link, the system records facilitator_id on the patient and case records so commission can accrue correctly and so the facilitator can access shared case data after the patient grants consent.

Why: Facilitators are external licensed agents who bear patient acquisition costs and provide coordination services (appointment scheduling, translation, pre-travel logistics). Commission attribution is the contractual mechanism by which their services are funded. Without accurate attribution, the facilitator-mediated coordination model collapses and patients lose access to facilitator support. The legitimate interest is threefold: (a) contractual performance with facilitators, (b) accurate financial audit records, (c) enabling the consent-gated coordination workflow.

Scope: This DPIA covers the referral attribution sub-flow only — from link creation to commission accrual. It does not re-assess the broader patient data lifecycle (covered by Curaway's main privacy notice and data processing agreements).

Legal basis: Legitimate interests (GDPR Art. 6(1)(f)) for cookie placement and attribution recording. Processing is necessary for the performance of the facilitator service agreement and does not override patient privacy interests given the minimal data involved (only facilitator_id — not health data).

Who is affected: Patients who arrive via referral link. Facilitators (as data subjects whose ID is processed). No minors are anticipated; facilitators sign a commercial agreement and are institutional or professional actors.

2. Necessity and Proportionality¶

Why a cookie?

UTM parameters embedded in the URL persist only for the browser tab session and are lost on redirect or if the patient bookmarks the link and returns later. The referral funnel for cross-border medical travel typically spans days to weeks (patient researches, discusses with family, then registers). A persistent cookie is proportionate to that timeline.

Why not server-side IP-based attribution?

IP-based attribution would require logging patient IP addresses against facilitator IDs, creating a biometric-adjacent linkage without consent. This is more invasive than a cookie containing only facilitator_id.

Why not an explicit "I have a referral code" input?

Explicit code entry creates friction for patients who are not tech-fluent (a significant portion of cross-border medical travel patients). It also creates a failure mode where patients arrive via a link but abandon registration when prompted for a code they don't understand.

Why HMAC-signed rather than encrypted?

The cookie payload contains only facilitator_id (a non-personal, internal UUID) and a 16-hex-character HMAC truncated signature — format: {facilitator_id}.{HMAC-SHA256[:16]} (verified at app/services/referral_link_service.py:89-101). No timestamp is embedded in the cookie payload. There is no PII in the payload; encryption would add complexity without adding privacy benefit. HMAC signature provides tamper-detection sufficient to prevent slug-forging attacks without requiring symmetric key management for decryption.

TTL of 1 year: Proportionate to the referral funnel duration. The cookie is consumed one-shot at registration (apps/patient-app/src/lib/referralCookie.ts:66-80 in curaway-health-navigator), so it does not persist beyond the point of use on any patient who completes registration.

Minimisation audit:

3. Data Flow¶

Each step identifies what data moves, across what boundary, and what lawful ground applies.

Key data-minimisation note for Step 2: The slug-resolution endpoint (app/routers/public_referral.py:134-270) sets cookies only when has_consent=True (public_referral.py:244-268). Two cookies are set on consent: curaway_ref (HMAC-signed facilitator_id, no timestamp) and curaway_ref_slug (raw slug identifier, low PII materiality — slugs are random strings, not user-identifying). When consent is absent, the endpoint records a counter increment only — no cookies, no events row, no ip_hash or ua_hash stored. This consent-gated design strengthens the privacy posture: the cookie itself is consent-dependent, not pre-consent. When consent is given, the events row stores ip_hash and ua_hash (SHA-256 hashes — not raw values). Counsel should confirm whether hashed IP/UA constitutes PII under applicable supervisory authority guidance (ICO / CNIL).

Pre-consent UTM telemetry (Step 2a — FF-gated addition): When feature flag referral_preconsent_utm_enabled is ON, a second, slimmer event row (referral_link.click_preconsent) is emitted if has_consent=False AND any utm_* parameter is present in the redirect request. This row contains ONLY: slug, facilitator_id, utm_source, utm_medium, utm_campaign, utm_content, utm_term, landing_path. It does NOT contain ip_hash, ua_hash, region, or any patient identifier. Justification: UTM strings are business/analytics metadata describing which campaign or channel drove the visit — they are not user identifiers and are classified as non-PII business metadata under this DPIA. Consent-gated logging would miss dominant first-visit traffic (pre-consent arrivals), making campaign attribution structurally impossible. The flag is defaulted OFF so counsel can review before activation (see §9 item 6). Implementation: app/services/referral_link_service.py (record_click, pre-consent branch) and app/models/event.py (EventType.REFERRAL_LINK_CLICK_PRECONSENT).

Cross-border: EU patient browser → app.curaway.ai (Cloudflare edge, EU PoP) → backend on Railway (ap-south-1). Transfer is covered by Curaway's standard SCCs (see Section 8).

4. Recipients¶

DP-4 constraint (attribution-only cases): A facilitator whose referral did not result in a consent grant can see that a commission is pending attribution to their account but cannot see any case details. The data isolation is structural — the commissions table holds only attribution + amount fields and the /commissions endpoint does not join to case content. UI distinction (showing the row in a muted/badged style) is FE work tracked under plan PR #651 Task 5.5.

5. Retention¶

Erasure note: Patient-initiated erasure under GDPR Art. 17 triggers the existing cascade erasure handler. referred_by_facilitator_id on both patients and cases becomes NULL via FK constraint. Commission accrual records that have already settled are retained in anonymized form under the Art. 17(3)(b) legal obligation defence (financial audit, tax records). Unsettled commissions at time of erasure are voided.

6. Risks and Mitigations¶

Overall risk level: Low. No special-category data is processed in this flow. The cookie payload contains no health data, no racial or ethnic origin, no biometric data. The predominant risk is commission misattribution, which is a financial rather than privacy risk. The consent-gated cookie design and hashed-only telemetry strengthen the privacy posture relative to many comparable attribution implementations.

7. Data Subject Rights¶

Consent and attribution independence: Attribution (Step 4) is distinct from access consent (Step 5). A patient can be attributed to a facilitator without ever granting that facilitator access to their case. The facilitator earns a referral commission but sees no case data. This separation is architecturally enforced.

8. Cross-Border Considerations¶

EU patients are registered under tenant-curaway-patients with data residency in ap-south-1 (Mumbai, India). Facilitators may be located in any jurisdiction; the facilitator_id field is an internal UUID — it does not constitute personal data of the facilitator in isolation without the facilitator directory, which is held separately.

Transfer mechanism: EU patient data flowing to Railway backend (ap-south-1) is covered by Curaway's existing Standard Contractual Clauses (SCCs) under GDPR Art. 46(2)(c). This DPIA does not change the cross-border transfer posture established in the main DPA.

Special-category data: facilitator_id is not special-category data under GDPR Art. 9. It is not health data, racial or ethnic origin, political opinion, religious belief, biometric data, or data concerning sexual orientation. The referral attribution flow does not make the cross-border transfer of special-category data more complex than what is already covered by the main DPA.

Provider jurisdiction: Providers are in destination countries (India, Turkey, Thailand, Spain). Provider-facing data views do not include facilitator attribution data (see Section 4).

9. Consultation and Sign-Off¶

No high-risk processing requiring supervisory authority consultation has been identified. Risk level is Low (see Section 6). This DPIA is sufficient under GDPR Art. 35(7) without prior consultation under Art. 36.

Sections requiring legal review before finalisation:

1. Art. 17(3)(b) defence for retaining anonymized commission accruals post-erasure — confirm with counsel that financial audit obligation is established under applicable jurisdiction law (India Companies Act 2013 / UK Companies Act 2006 as applicable to facilitator contracts).
2. Legitimate interest basis (Art. 6(1)(f)) — confirm that the Legitimate Interests Assessment (LIA) is documented separately and that the balancing test has been completed. LIA is at docs/compliance/lia-facilitator-referral-attribution.md.
3. Facilitator T&Cs — confirm that last-cookie-wins attribution policy and rectification exclusion are explicitly disclosed.
4. ip_hash / ua_hash classification — confirm with counsel whether SHA-256 hashed IP address and User-Agent string constitute personal data under applicable supervisory authority guidance (ICO, CNIL). See §6 risk row and §2 minimisation audit.
5. curaway_ref_slug cookie — confirm slug values are never configured to contain personally identifying strings (e.g., facilitator names). Currently a process control, not a technical enforcement (see §6 risk row).
6. Pre-consent UTM telemetry — counsel must confirm UTM strings are not classified as PII or special-category data under their applicable guidance. Currently classified as business metadata (campaign source, medium, name, content, term). The referral_preconsent_utm_enabled feature flag is defaulted OFF so this flag can be disabled if counsel objects. No ip_hash, ua_hash, region, or patient identifier is stored in the pre-consent event row. Activation requires counsel sign-off on this item. See §3 (Step 2a) and §6 (UTM risk row).

DPO sign-off:
Name:  Srikanth Donthi
Title: CPO/CTO (acting DPO under Curaway MVP governance)
Date:  2026-05-05
Signature: ____________________

10. Review Schedule¶

This document was produced as part of PR #651 Phase 2 Task 2.2 and updated under issue #666. Source references: app/routers/public_referral.py:134-270, app/services/referral_link_service.py:54-67, app/services/referral_link_service.py:89-101, app/services/referral_link_service.py:557-583, app/routers/patients.py:58-68, app/services/case_service.py:19-50, curaway-health-navigator/apps/patient-app/src/lib/referralCookie.ts:66-80.