Legitimate Interests Assessment¶

Facilitator Referral Attribution — Cookie + Attribution Recording¶

1. Purpose Test¶

What is the legitimate interest?

Commission attribution to facilitators who refer patients to the Curaway platform.

Is this interest valid and genuine?

Facilitators are external licensed agents (translation, appointment coordination, pre-travel logistics) who bear patient acquisition costs and provide coordination services. Their contracts structure compensation as commission on converted referrals. Without accurate attribution of which facilitator introduced each patient:

• Facilitators cannot be compensated for services rendered — the commercial model collapses.
• Patients lose access to facilitator-mediated coordination support, which many explicitly sought when responding to facilitator outreach.
• Curaway cannot fulfil its contractual obligations to facilitator partners.

This is a recognized, established commercial purpose — commission tracking is structurally identical to affiliate attribution used across e-commerce and professional services. The ICO's LIA guidance cites "commercial interests" as a valid category of legitimate interest provided the balancing test is satisfied (ICO, Legitimate interests, 2020, pp. 8-10).

Is the interest specific?

Yes. The processing is scoped exclusively to: (a) recording which facilitator introduced which patient, and (b) enabling commission accrual. It does not extend to behavioural profiling, targeting, or any secondary use.

Conclusion (Purpose Test): PASS. The interest is genuine, specific, and recognized in commercial law and data protection guidance.

2. Necessity Test¶

Is the processing necessary to achieve the purpose, or could the same outcome be achieved with less data?

The following alternatives were evaluated:

Why a cookie specifically?

The cookie holds only facilitator_id and an HMAC truncated signature ({facilitator_id}.{HMAC-SHA256(facilitator_id, secret)[:16]}). Cookie composition verified at app/services/referral_link_service.py:89-101. No PII, no IP, no timestamp, no device fingerprint is embedded in the cookie payload.

Data elements evaluated:

A second cookie (curaway_ref_slug) carries the raw slug value for analytics purposes. The slug is a non-personal URL-safe identifier — it identifies the link, not the patient or the facilitator's identity directly.

Pre-consent constraint (verified): Cookies are set only when has_consent is True (app/routers/public_referral.py:245). When consent has not been given, the redirect endpoint records a counter increment only — no events row, no ip_hash or ua_hash stored. This is structurally enforced in app/services/referral_link_service.py:551-556.

One-shot consumption: The curaway_ref cookie is read once by the patient-app at registration (curaway-health-navigator/apps/patient-app/src/lib/referralCookie.ts:66-80) and submitted as referred_by_facilitator_id in POST /api/v1/patients/register. The frontend clears the cookie after extraction; it does not persist beyond registration.

Conclusion (Necessity Test): PASS. The cookie approach is the minimum-data, minimum-friction approach that achieves the purpose. No less-invasive alternative preserves attribution across the full funnel.

3. Balancing Test¶

3a. Reasonable Expectations¶

The patient's journey prior to the cookie being set:

1. Patient receives a referral link from a named facilitator (via WhatsApp, email, or in-person briefing). The facilitator has explicitly positioned themselves as the patient's coordinator ("click this link and I'll be your coordinator on Curaway").
2. Patient clicks the link. The URL is https://app.curaway.ai/r/{slug} — visibly a Curaway link via the facilitator's referral.
3. Cookie is set only if the patient has already given cookie consent; the banner/consent is presented before or alongside the redirect.

In this context, a reasonable data subject would expect: - That clicking a referral link routes them via that facilitator. - That the facilitator receives credit for the referral. - That the cookie enables this credit, not ongoing tracking.

The cookie does not enable surveillance across sessions or sites. It is a single-purpose, one-shot attribution marker.

3b. Data Minimisation and Harm Potential¶

3c. Override Assessment — Data Subject Interests and Rights¶

Who is affected: Patients seeking cross-border medical care. This population includes vulnerable individuals (medical need, distance from provider). The processing is not special-category data (GDPR Art. 9 does not apply to a business UUID cookie). The fact of platform use is not contained in the cookie.

Override factors:

Balance conclusion: The vulnerable population flag raises scrutiny but does not tip the balance. The processing is: - Consent-gated (cookie only after consent). - Minimal (no PII, no health data in the cookie). - Time-limited and one-shot in practice. - Matched to reasonable expectations (patient clicked a labeled referral link). - Subject to full erasure and objection rights downstream.

The controller's interest in accurate commission attribution (which also serves the patient's interest in receiving facilitator coordination) is not overridden by data subject interests, rights, and freedoms.

Conclusion (Balancing Test): BALANCE FAVORS CONTROLLER, conditional on: 1. Privacy notice disclosing attribution immutability and the one-shot cookie mechanism. 2. Facilitator T&Cs disclosing last-cookie-wins attribution policy and rectification exclusion. 3. Consent mechanism being genuinely presented before cookie set (currently enforced in code; must remain a hard constraint on any future change to the consent flow).

4. Decision¶

Article 6(1)(f) — legitimate interests — is appropriate for the processing of facilitator_id via HMAC-signed cookie and the recording of referred_by_facilitator_id on patient and case records.

All three parts of the LIA balancing test are satisfied:

This conclusion backs the legal basis stated in DPIA-2026-001 §1.

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

5. Sections Requiring Legal Review¶

6. Review Schedule¶

7. Cross-References¶

Appendix: Factual Discrepancies Noted vs. DPIA-2026-001¶

The following discrepancies were identified during code review for this LIA. The DPIA should be updated in a separate PR.

This LIA was produced under issue #656 to back the Art. 6(1)(f) basis stated in DPIA-2026-001. Source references verified against code at commit HEAD on 2026-05-05.