Consent That Outlived Its Scope
A telehealth app collected consent in 2022 for "sharing your health intake data with partner clinics to coordinate your care." The consent screen listed three named clinics. In 2024, the company signed a data-sharing agreement with a national analytics vendor and began sending de-identified intake summaries - age band, condition category, ZIP3 - to that vendor for "population health insights." The company's position is that the data is de-identified, so consent is not required. A privacy engineer notes that ZIP3 plus age band plus a rare condition category (e.g., a specific cancer subtype) can re-identify a meaningful fraction of users in rural ZIPs, where a ZIP3 may cover only a few thousand people. About 8% of the user base lives in ZIP3 areas with populations under 20,000. The vendor contract permits the vendor to "create derivative datasets" and to "combine with third-party data."
1. Evaluate the de-identification claim. Is the data de-identified for the purposes of the consent question, and what does the vendor contract do to that conclusion?
Read the worked answer
The de-identification claim is not safe to rely on, and the contract makes it worse.
De-identification is a property of re-identification risk in context, not a checkbox on a field list. The combination of ZIP3 + age band + rare condition is a quasi-identifier set. In dense urban ZIP3s the risk may be low; in rural ZIP3s (8% of users, areas under 20k) the cell sizes are small enough that a specific cancer subtype plus age band could point to a handful of people - potentially one. That is re-identifiable by a motivated party, and the standard for "de-identified" is generally that re-identification is not reasonably likely by anyone, not just by the company.
The contract compounds it:
- "Create derivative datasets" means the vendor can enrich and re-link.
- "Combine with third-party data" is the single most common path from pseudonymous to identified. Once combined, the data is no longer de-identified in the vendor's hands.
So the correct conclusion: for the rural cohort, treat the data as pseudonymized, not anonymized, and therefore in scope of consent. For the rest, you still cannot rely on the original consent - it named three clinics for care coordination, not a national analytics vendor for population insights. That is a different purpose and a different recipient.
2. The company wants to keep the analytics program. Lay out the lawful paths and the trade-offs of each.
Read the worked answer
Path 1 - Fresh consent for the analytics purpose. Disclose recipient category, purpose, data fields, and the combination/derivative use. Trade-off: honest and durable, but you must re-consent the base, expect a low response rate, and you cannot use non-responders' data. You also must not bundle it with care delivery.
Path 2 - Genuine anonymization before sharing. Strip ZIP3 to state or region, collapse rare conditions into broader categories, suppress small cells, and prohibit combination/re-linking contractually. Trade-off: preserves the program without consent, but the utility drops - rare-condition signal is exactly what the analytics wanted. And you must actually enforce the small-cell suppression, not just write it in the contract.
Path 3 - Rely on an existing legal basis other than consent (e.g., a public-interest or research basis, depending on jurisdiction). Trade-off: jurisdiction-specific, usually requires a DPIA and safeguards, and is hard to defend for a commercial vendor relationship.
Path 4 - Stop the program. Sometimes correct, rarely chosen.
Recommendation: Path 2 for the aggregate program (state-level, small-cell suppression, no combination clause), plus Path 1 if the company genuinely needs the rural/rare-condition granularity. Do not keep the current arrangement - it rests on a de-identification claim the contract itself undermines.
3. Draft the three contract changes you would insist on before any further data flows, and explain what each protects against.
Read the worked answer
Delete the "combine with third-party data" permission, or restrict it to aggregated, non-individual-level use. Protects against: the vendor re-identifying your users by linking to external datasets - the most common de-anonymization route. Without this, your de-identification analysis is void the moment the vendor enriches.
Prohibit re-identification and derivative datasets at the individual level; require small-cell suppression (e.g., no cell under a defined threshold) and no sharing of ZIP3-level data. Protects against: the rural re-identification risk specifically, and against the vendor building a person-level asset from your health data.
Add audit, deletion-on-termination, and breach-notification-within-a-defined-window obligations, plus a right to audit the vendor's combination practices. Protects against: finding out after the fact that the data was misused, and against data surviving the relationship.
Optional fourth: a purpose limitation clause naming "population health insights" and barring resale. Each clause maps to a specific failure mode identified in the risk assessment - that mapping is what makes the contract defensible if challenged.