PHI Classification False Positives Before Masking
A health insurer has cataloged 6,200 columns. Automated classification flags 1,150 columns as PHI, including CUST_DT, PLAN_CD, and MEMBER_EFF_DT. The privacy office wants to apply a “Restricted” policy to every flagged asset before a masking project starts next week. A steward samples 200 flagged columns and finds 38% are false positives; only 210 columns are confirmed PHI by profiling and business review. There are three stewards and two working days before the policy must be set. CDGC propagates policy through lineage to downstream marts. If Restricted is applied to the false positives, roughly 400 reporting columns used by finance may be masked, breaking month-end reports. The privacy office is unwilling to delay the masking project.
1. How should the team tune classification and apply policy within the two-day constraint? Give the order of operations and the artifact you would use to separate confirmed from suspected PHI.
Read the worked answer
Do not apply Restricted to all 1,150 flags. Split the population into confirmed and suspected PHI and govern them differently.
Order of operations
- Stabilize the confirmed set. Use the 210 columns confirmed by profiling plus business review as the initial Restricted population. These have evidence beyond a name pattern.
- Create a separate classification or status for suspected PHI. The 940 remaining flags should be labeled Suspected PHI - review required, not Restricted. This preserves the privacy signal without triggering masking.
- Tune the rules that caused obvious false positives. Date and code columns such as CUST_DT, PLAN_CD, and MEMBER_EFF_DT should not be classified as PHI on name alone. Require data-pattern evidence or a business-term association.
- Triage by risk, not alphabetically. Review suspected columns that feed external or finance reports first, because misclassification there has the largest operational impact.
- Apply Restricted only to confirmed assets and record the review evidence, reviewer, and date.
Why this works It respects the privacy office’s deadline for real PHI while avoiding a mass masking event. The suspected bucket keeps the remaining flags visible and auditable. The trade-off is that some true PHI may sit in the suspected bucket for a short period; that residual risk should be explicitly accepted and time-boxed, not hidden.
2. How should the team prevent downstream over-masking while still protecting confirmed PHI?
Read the worked answer
Use lineage-aware policy scoping and explicit exceptions rather than a blanket propagation rule.
- Trace lineage from each confirmed PHI column to downstream assets. Apply Restricted to downstream assets that actually carry the PHI value or a derivative of it.
- For reporting columns that consume only non-PHI fields from the same table, do not inherit the policy merely because they share a table. Column-level lineage matters here.
- Where a downstream finance report legitimately needs a masked or aggregated value, define an approved exception with a compensating control (for example, aggregation or tokenization) rather than leaving it unmasked.
- Run a dry-run impact list before enabling masking: count affected columns by report and owner. The 400-column estimate should be validated against actual lineage, not assumed.
- Give finance report owners a 24-hour review window for the dry-run list, with the privacy office as final approver.
Reasoning Policy propagation is only as good as the lineage under it. Blanket propagation from a table-level flag will over-mask. Column-level scoping plus documented exceptions protects PHI without breaking month-end reporting. The privacy office should see the exception list and accept the residual risk explicitly.
3. What metrics should the team report to the privacy office after the two-day effort, and why not report “1,150 PHI columns protected”?
Read the worked answer
Report precision, coverage, and residual risk, not a single flag count.
Useful metrics:
- Confirmed PHI columns with Restricted applied: 210 of 210, with evidence.
- Suspected PHI columns awaiting review: 940, with an owner and review deadline.
- False-positive reduction: from 38% in the sample to the post-tuning rate on a re-sample.
- Downstream assets masked or exception-approved, split by report and business owner.
- Open exceptions and their compensating controls.
Why not “1,150 protected” That number conflates detection with protection. If 38% of the sample was false, the flag count overstates true PHI and understates the review burden. It also hides the 400 reporting columns that would be wrongly masked. A privacy office needs to know what is confirmed protected, what is still uncertain, and what risk has been accepted. Reporting a single inflated number would damage trust when the false positives surface later. The defensible statement is: “210 confirmed PHI columns are Restricted; 940 are queued for review; 12 exceptions are approved with controls.”