The 1.4% Match: Releasing a "De-identified" Hospital Dataset
A regional hospital network with 1.2 million patients wants to hand a research dataset to a university partner: 84,000 emergency-department encounters. The privacy office stripped names, medical record numbers, and street addresses, leaving 5-digit ZIP, full date of service, age in years, sex, and one diagnosis code drawn from 240 categories. Before release, an analyst matched the file against a commercial consumer database and found 1,180 records (1.4%) resolved to a single named individual. The university says collapsing dates to month and ZIP to three digits cuts the usable cohort to 12,000 and destroys the seasonal analysis the grant depends on. Grant renewal is in six weeks. The university will store the file on a shared departmental server and has offered its standard research agreement.
1. The privacy office calls the file "de-identified." Is that defensible, and what would you require before release?
Read the worked answer
No - as constructed, the file is not de-identified and cannot be defended.
The reasoning is not a checklist lookup but a claim about what the data can do in the recipient's hands:
- Full dates and 5-digit ZIPs are the two highest-yield join keys in existence. Combined with age and sex, they narrow a population of 1.2 million to single digits almost mechanically. The 1.4% is not a rounding error - 1,180 people are identifiable today, before any adversary tries.
- The failed-match count understates risk. An absence of matches against one commercial file says nothing about other files, voter rolls, or the university's own alumni and patient data. Re-identification testing measures the tester's data, not the world's.
- The diagnosis code is itself a quasi-identifier. For rare categories it may identify alone regardless of dates.
Requirements before any release: a written, risk-based determination that names the recipient, its motive and capability, what data it already holds, and the residual risk accepted with a signature; a data use agreement barring re-identification, onward transfer, and linkage to other datasets; security requirements for the shared server; and no release of the raw file until date and geography handling changes. Six weeks is enough time to do this properly - the deadline is not a reason to skip the determination, it is a reason to start it now.
2. The university refuses date generalization. What release designs would preserve the seasonal analysis while lowering re-identification risk?
Read the worked answer
Separate the analysis from the data. The university wants seasonal patterns; it does not need named individuals' exact admission dates to get them.
Options, roughly in order of preference:
- Analyze inside the boundary. The hospital computes the seasonal signal itself - counts by diagnosis category, week, and day-of-week - with small-cell suppression (e.g., suppress cells under 5 and secondary-suppress complements). Ship the tables, not the rows. This preserves the grant deliverable and eliminates the join key completely.
- Date-shift by a per-patient multiple of seven days. Each patient gets one random offset in {−28, −21, ... +28} applied to all their records. Day-of-week and weekday/weekend structure survive exactly; intra-patient intervals are preserved; exact-date matching against an external file breaks. Combine with 3-digit ZIP or geography suppression and age bands for small cells.
- Differentially private time series if the university needs interaction rather than a fixed table - publish the mechanism and the privacy parameter so the analysis is reproducible.
- Synthetic data only with published utility validation; it solves disclosure risk but creates a new risk: analysts drawing clinical conclusions from fake records.
Reject: releasing full dates "because the DUA covers it." A contract constrains a partner's behavior; it does not change what the data reveals to anyone who obtains it.
3. Who should decide the acceptable risk, and what makes that decision auditable?
Read the worked answer
The covered entity decides - the hospital, not the analyst, not the university. The hospital holds the duty of confidentiality and bears the consequences; the university bears almost none. Within the hospital, the decision belongs to a named accountability pair: the privacy officer for the disclosure determination, and the research governance or IRB function for the study itself. They may accept risk, but they cannot delegate it to whoever runs the matching script.
An auditable decision has four parts:
- A data inventory of everything in the release, element by element, with a justification for each element's presence. If a field has no stated analysis purpose, it comes out.
- The method and its results, including the match test, its data source, its failure modes, and the analyst's assumptions.
- Alternatives considered and rejected, with the reason. "Shifted dates would break the seasonal analysis" is a legitimate reason - but it must be written down before release, not reconstructed after an incident.
- A signature and a date on a specific residual risk statement, plus trigger conditions for re-review (new external datasets, change of recipient, change of scope).
Re-review matters because identifiability decays: the same file that is 1.4% re-identifiable this year may be far more so in three. Set a re-assessment interval in the agreement.