De-identification Specification — Stratum Platform

Purpose

• Case study or research publication
• Tier 3 marketplace sharing (cross-tenant precedent access)
• Partner data sharing under research BAAs
• Any export to a third party not covered by a signed BAA
Data accessed internally under a valid BAA by authorized users does NOT require de-identification prior to access. The PHI validation middleware (phi-validation.ts) handles input-time blocking; this spec governs output-time transformation.

---

Method Selection: Safe Harbor vs. Expert Determination

Selected method: Safe Harbor. Behavioral health denial precedents contain payer identifiers, clinical codes, and narrative text — not granular patient populations requiring statistical analysis. Safe Harbor's mechanical approach is sufficient, verifiable, and attorney-defensible without ongoing expert engagement. Expert Determination should be revisited if Stratum publishes research requiring date-level precision (e.g., exact admission/discharge timelines) or geographic granularity below state level.

---

The 18 Safe Harbor Identifiers — Treatment by Type

Stratum precedent objects do not contain most Safe Harbor identifiers by design (the PHI middleware blocks them at ingestion). The table below documents the complete 18 and their treatment in the de-identification transform. Note on Provider NPI: NPI is not one of the 18 Safe Harbor identifiers and is a public registry number. However, cross-referencing NPI + payer + denial type + year can re-identify a small practice. Apply consistent hashing to prevent linkage attacks.

---

Identifier Coverage: Existing Middleware vs. De-id Transform

The phi-validation.ts middleware currently covers 10 patterns (blocks at input): Gaps in middleware NOT yet covered (add to both middleware and de-id transform):

---

Technical Implementation

Location

src/middleware/deidentify.ts — new module, separate from phi-validation.ts The existing phi-validation.ts exports scanForPhi — the de-id transform reuses this scanner plus adds transformation logic.

Mode distinction

phi-validation.ts  →  REJECT mode  →  blocks request at ingestion (422)
deidentify.ts      →  TRANSFORM mode  →  strips/generalizes data at export

These are separate concerns. Never transform-in-place on the stored precedent record. De-identification only applies to export copies.

Core transform operations

1. Strip — Remove field value entirely, replace with null or placeholder token

"patient_name": "John Smith"  →  "patient_name": "[REDACTED]"

2. Generalize dates — Retain year, remove month/day

"service_date": "2024-03-15"  →  "service_date": "2024"
"service_date": "03/15/2024"  →  "service_date": "2024"

3. Generalize geography — Retain state, remove sub-state detail

"zip_code": "98101"  →  "zip_code": "[WA]"
"address": "123 Main St, Seattle, WA 98101"  →  "address": "[WA]"

4. Hash — Consistent pseudonym within export batch, not reversible

"provider_npi": "1234567890"  →  "provider_npi": "f3a9c1d2e4b6"

Salt is per-export, discarded after export. Do not reuse salt across exports. 5. Residual scan — After all transforms, run scanForPhi() on output. Any hits = export blocked. Log and alert.

Output format

De-identified records must include:

{
  "_deidentified": true,
  "_deidentification_method": "HIPAA Safe Harbor §164.514(b)(2)",
  "_deidentification_date": "2026-04-08",
  "_export_id": "uuid",
  "_salt_hash": "sha256(salt)[:8]"
}

The _salt_hash (not the salt itself) enables audit trail linking without enabling re-identification.

What is retained (safe to publish)

• Payer name (Anthem, Cigna, etc.) — not a patient identifier
• Denial type (Medical Necessity, Level of Care, etc.)
• Level of care (PHP, IOP, SUD Residential, etc.)
• Criteria source (MCG, InterQual, ASAM, LOCUS)
• Outcome (Won, Lost, Partial)
• Win reason
• Evidence score
• Service year (not full date)
• State (not sub-state geography)
• 42 CFR Part 2 flag (data_origin_type, sharing_restrictions)
• Narrative templates and policy references (already abstracted, no identifiers)

---

Use Case Requirements

Case Study / Research Publication

• Export via de-id transform
• Residual scan passes (zero hits)
• Attorney review of exported dataset before submission
• Publication outlet must be notified data is de-identified (not PHI)

Tier 3 Marketplace Sharing

• All precedents in marketplace clusters pass de-id transform at index time
• No raw PHI is ever included in marketplace payloads
• Cross-tenant access limited to de-identified records
• BAA governs relationship regardless — de-id is additive protection

Research BAA Partners

• BAA executed and stored before any data transfer
• Data transfer via de-id export only
• Partner must maintain their own HIPAA compliance program

---

Residual Risk: What Safe Harbor Does Not Eliminate

Safe Harbor does not guarantee zero re-identification risk. Known residual risks for Stratum: Suppression threshold: Any combination of (payer + LOC + denial type + year) with fewer than 3 distinct hashed-NPI values should be suppressed from published datasets.

---

Re-identification Attack Surface

Safe Harbor compliance is necessary but not sufficient against a determined re-identification attempt. This section addresses three attack classes not covered by the 18-identifier strip.

Attack 1: Linkage Attack (Cross-Dataset Re-identification)

What it is: A recipient (or adversary) cross-references the de-identified export against an external public dataset to re-identify records by matching combinations of retained fields. Relevant external datasets for behavioral health:
• CMS Medicare/Medicaid claims data (payer, LOC, service year, state — publicly queryable)
• SAMHSA TEDS-A/TEDS-D (Treatment Episode Data Set — payer type, LOC, state, diagnosis category)
• State all-payer claims databases (WA-APCD, NY SPARCS, etc.) — granular enough to narrow to facility
• SAMHSA Behavioral Health Barometer (state-level utilization, LOC breakdowns)
• NPI registry (provider name → NPI lookup — reverses hashing if salt is known)
Attack scenario: Exported record shows payer=Cigna, LOC=PHP, state=WA, year=2023, outcome=Won. Attacker queries SAMHSA TEDS to find WA facilities billing Cigna PHP in 2023. If only 2–3 facilities match, the record set is effectively identified even without any of the 18 identifiers. Mitigations:
• Quasi-identifier generalization — Before export, evaluate whether any combination of
retained fields (payer + LOC + state + year) yields a population of fewer than 11 distinct providers in the external reference datasets. If yes, suppress or further generalize (e.g., generalize state to region, or year to 2-year band).
• Disclosure-limited exports — For published research, cap the retained field granularity.
Example: publish payer category (commercial, Medicaid, MA) instead of named payer; publish LOC category (residential, outpatient) instead of specific LOC code.
• Recipient controls — For partner transfers (BAA), include a data use agreement (DUA)
prohibiting re-identification attempts and prohibiting linkage with external datasets.
• Pre-publication linkage check — Run a manual check against SAMHSA TEDS and CMS public
data before any research publication. Document the check in the export audit log. Attorney review item: Confirm whether a linkage analysis is required under the specific disclosure context, or whether Safe Harbor + suppression threshold is sufficient.

---

Attack 2: Salt Custody and Hash Reversal

What it is: The NPI hashing scheme uses a per-export salt to generate consistent pseudonyms. If the salt is retained — intentionally or by logging — the hash is fully reversible. Anyone with the salt can reconstruct the original NPI from the hashed value, then look up the provider in the public NPI registry to recover name, address, specialty, and practice size. Attack scenario: Export is shared with a research partner. A developer at that partner, or at Stratum, retains the salt from the export run. Six months later they cross-reference the hashed NPI back to the real NPI, then query the NPPES registry to recover provider identity. Mitigations:
• Salt never logged. The export process must explicitly prohibit writing the salt to any
log file, audit trail, database field, or environment variable. Salt exists only in memory during the export run.
• Salt destruction confirmation. The export process generates an attestation record:

{
     "export_id": "uuid",
     "salt_destroyed": true,
     "destruction_timestamp": "ISO-8601",
     "destruction_method": "in-memory only, no persistence"
   }

This record is written to the audit log. The salt itself is never written.
• Export isolation. Each export run generates a fresh random salt (Node.js crypto.randomBytes(32)).
Salts are never reused across exports. This prevents cross-export NPI correlation even if one export's salt were somehow recovered.
• Access controls on export function. The de-id export route must be restricted to admin
role only. Audit log must record user_id, timestamp, and export_id for every invocation.
• NPI omission option. For highest-sensitivity exports (public research publication),
consider omitting hashed NPI entirely rather than hashing it. Payer + LOC + outcome is sufficient for most research questions without provider pseudonymization.

---

Attack 3: Narrative Re-identification (Case Fingerprinting)

What it is: Even with all 18 identifiers stripped and [PATIENT], [PROVIDER], [FACILITY] tokens substituted, appeal narrative text can re-identify a case by its clinical fingerprint — a unique combination of diagnosis details, treatment history, payer decision language, and clinical argument structure that effectively uniquely identifies the case. Attack scenario: A published case study describes "a 34-year-old with co-occurring PTSD and alcohol use disorder denied PHP at a Pacific Northwest facility, payer cited MCG criterion 7.D.2, appeal argued ASAM 3.1 criteria." A payer's internal staff, familiar with that specific denial from the original case, recognizes the clinical fingerprint even without any explicit identifier. This is a real concern for behavioral health specifically: the appeal population is small, the clinical scenarios are high-variability, and payers have their own denial records they can cross-reference. Mitigations:
• Narrative abstraction tier. Narrative fields (narrative_template, policy_reference,
evidence_kit) should be assessed for case-specificity before export. Apply a three-tier classification:
• Minimum narrative generalization. For any published dataset, narrative fields should be
reduced to structured attributes (criteria cited, evidence type, framing approach) rather than free text. Stratum's NarrativeTemplate type (framing, lead_with, avoid, example) should replace raw narrative text in all external exports.
• Rare-scenario suppression. Any precedent where the combination (payer + LOC + denial type
+ criteria source) appears only once in the export dataset should have its narrative field suppressed entirely, regardless of the 3-record threshold applied to quasi-identifiers.
• Human review gate for publication exports. Before any research publication, a person
(Patrick or designated reviewer) must read each exported narrative field and confirm it does not contain a recognizable clinical fingerprint. This review is documented in the export audit log as narrative_review_approved: true.
• Payer disclosure restriction. Consider restricting named payer in exports where narrative
is included. Publishing "Cigna denied PHP citing MCG 7.D.2 and the following argument pattern succeeded" is more re-identifiable than publishing the argument pattern without payer name. The DUA with research partners can restrict further payer-level attribution.

---

What Requires Attorney Review

Before first use of the de-id transform for any external disclosure:
• Confirm Safe Harbor method is sufficient for the specific disclosure context (publication vs. marketplace vs. partner transfer)
• Review the 18-identifier treatment table — confirm no gaps for behavioral health context
• Confirm suppression threshold (currently set at n < 3) is defensible
• Review the export metadata format (_deidentification_method field content)
• Confirm 42 CFR Part 2 SUD records require additional consent even after de-identification (likely yes — Part 2 has stricter standards than HIPAA Safe Harbor)
• Confirm whether a formal linkage analysis against external public datasets (SAMHSA TEDS, CMS) is required for research publication, or whether Safe Harbor + suppression threshold + DUA prohibition is sufficient
• Review the salt custody attestation procedure — confirm it satisfies audit trail requirements without creating a reversibility risk
• Confirm whether the DUA (data use agreement) prohibiting re-identification attempts is required for BAA partners, or whether the BAA itself is sufficient
Estimated legal review time: 2–4 hours. Cost: $500–$1,500.

---

42 CFR Part 2 Interaction

Substance use disorder records (data_origin_type: 'SUD') carry additional federal protections under 42 CFR Part 2. Safe Harbor de-identification does NOT automatically satisfy Part 2. Part 2 requires explicit patient consent for disclosure even of de-identified SUD data in many interpretations. Until attorney review confirms otherwise: SUD-origin records (data_origin_type: 'SUD') are excluded from all external exports regardless of de-identification status. Tag SUD exclusions in export logs.

---

Maintenance Triggers

This spec requires review when any of the following occur:

---

Sign-Off Required

Method	Standard	Cost	Flexibility
Safe Harbor (§164.514(b)(2))	Remove all 18 enumerated identifiers	Low — implementable in code	Lower — mechanical
Expert Determination (§164.514(b)(1))	Statistical re-identification risk < "very small"	High — requires qualified statistician	Higher — retains more granularity
#	Identifier	Present in Precedent Objects?	Treatment
1	Names (patient, relative, employer, provider)	Possibly in narrative/appeal text	Strip — remove or replace with [PATIENT], [PROVIDER], [EMPLOYER] tokens
2	Geographic subdivisions smaller than state (zip codes, street addresses)	Possible in provider address fields	Generalize — retain state only; strip zip, street, city
3	Dates more specific than year (birthdate, admission, discharge, service, death)	Likely in service_dates or narrative	Generalize — retain year only (e.g., "2024" not "03/15/2024")
4	Phone numbers	Blocked at input	Confirm absent via scan; strip if found
5	Fax numbers	Blocked at input	Confirm absent via scan; strip if found
6	Email addresses	Blocked at input	Confirm absent via scan; strip if found
7	Social Security Numbers	Blocked at input	Confirm absent via scan; strip if found
8	Medical record numbers	Blocked at input	Confirm absent via scan; strip if found
9	Health plan beneficiary numbers	Possible in policy_reference	Strip — remove member/subscriber/policy IDs
10	Account numbers	Blocked at input	Confirm absent via scan; strip if found
11	Certificate/license numbers	Unlikely	Confirm absent via scan
12	Vehicle identifiers/license plates	Not applicable	N/A
13	Device identifiers/serial numbers	Not applicable	N/A
14	URLs containing patient info	Blocked at input	Confirm absent via scan; strip if found
15	IP addresses	Not stored in precedent objects	Confirm absent
16	Biometric identifiers	Not applicable	N/A
17	Full-face photos/comparable images	Not applicable	N/A
18	Any other unique identifying number or code	Provider NPI (quasi-identifier)	Hash — replace with sha256(NPI + salt)[:12]; consistent within export but not reversible
Pattern	Middleware Covers	De-id Transform Also Needed
SSN	Yes	Yes — as residual scan
Phone	Yes	Yes — as residual scan
Email	Yes	Yes — as residual scan
MRN	Yes	Yes — as residual scan
Full dates (MM/DD/YYYY)	Yes	Yes — generalize to year
Full dates (Month DD, YYYY)	Yes	Yes — generalize to year
Account numbers	Yes	Yes — as residual scan
Health plan IDs	Yes	Yes — as residual scan
IP addresses	Yes	Yes — as residual scan
URL with patient info	Yes	Yes — as residual scan
Pattern	Description	Safe Harbor #
Names	Patient/provider names in free text	1
Fax numbers	Similar format to phone	5
Geographic (zip codes)	5-digit or 9-digit zip	2
Geographic (street addresses)	Free-text address fields	2
Certificate/license numbers	State license formats	11
NPI numbers	10-digit provider ID	18 (quasi)
Risk	Likelihood	Mitigation
Small-practice provider re-identification via payer + LOC + year	Low-medium	NPI hashing; avoid publishing single-provider datasets
Rare diagnosis + rare payer combination	Low	Suppress records where combination appears fewer than 3 times in dataset
Narrative text containing implicit identifiers (facility names, city references)	Medium	Manual review of narrative fields before publication; add [FACILITY] tokenization
Tier	Definition	Treatment
Generic	Applicable to any case of this type; no case-specific detail	Include as-is
Semi-specific	References specific criteria or framing but no patient detail	Include with review
Case-specific	Describes a unique clinical scenario, rare combination, or specific event	Suppress or abstract before export
Trigger	Action
New identifier fields added to PrecedentObject schema	Update identifier coverage table; confirm de-id transform handles new fields
New use case (new disclosure type)	Confirm Safe Harbor is sufficient for that context; update Use Case Requirements section
HHS updates Safe Harbor identifier list	Update identifier table; re-validate transform
42 CFR Part 2 regulatory update	Review SUD exclusion policy with counsel
Dataset scale crosses 10,000 records	Consider Expert Determination assessment — Safe Harbor sufficiency assumptions may shift
Any attorney identifies gaps during review	Update immediately before proceeding
Role	Name	Date	Status
Platform Engineer	—	—	Pending
Business Owner	Patrick	—	Pending
HIPAA Counsel (external)	—	—	Required before first use

---

Related files:
• /Users/patricklord/REPOS/Stratum Collective/stratum-platform/docs/HIPAA_AUDIT_READINESS.md
• /Users/patricklord/REPOS/Stratum Collective/stratum-platform/src/middleware/phi-validation.ts
• /Users/patricklord/REPOS/Stratum Collective/stratum-platform/src/db/schema.sql