> ## Documentation Index
> Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
> Use this file to discover all available pages before exploring further.

# SUD Data Segmentation (42 CFR Part 2 / DS4P)

> How Encore OS segments substance-use and PHI fields on export — the enforced rule set, generated from code, plus the regulatory rationale.

Encore OS treats substance-use disorder (SUD) records as a privacy-segmented class under
**42 CFR Part 2** and DS4P. When data leaves the system through an export, the platform applies a
field-level treatment to PII/PHI before the row is written. This page documents both halves of that
control: the **enforced rule set** (generated from the code that runs it) and the **rationale** for
why each field is treated the way it is (hand-written, and the part an auditor reads).

<Note>
  This is a **hybrid page** (PF-113). The table below is generated from
  `DEFAULT_PII_FIELDS` in code and cannot drift from what actually runs; the surrounding rationale is
  authored by the compliance owner. The two are composed, not copied.
</Note>

## Enforced rule set

Exports run each row through [`applyPiiPhiFilter`](/api/platform#function-applypiiphifilter), which
applies a per-field treatment. With no tenant override, the platform falls back to the defaults
below — the literal, current contents of the enforcing constant:

{/* Source of truth: src/platform/export/utils/filterPiiPhi.ts → `DEFAULT_PII_FIELDS` (PF-44). Do not edit — run npm run docs:compliance:generate. */}

| Field             | Default treatment | Effect                     |
| ----------------- | ----------------- | -------------------------- |
| `date_of_birth`   | `redact`          | Replaced with `[REDACTED]` |
| `diagnosis`       | `remove`          | Field removed entirely     |
| `email`           | `redact`          | Replaced with `[REDACTED]` |
| `mobile_phone`    | `redact`          | Replaced with `[REDACTED]` |
| `mrn`             | `redact`          | Replaced with `[REDACTED]` |
| `phone`           | `redact`          | Replaced with `[REDACTED]` |
| `ssn`             | `remove`          | Field removed entirely     |
| `treatment_notes` | `remove`          | Field removed entirely     |

*8 fields are segmented by default; 3 are removed outright (`diagnosis`, `ssn`, `treatment_notes`) rather than masked.*

## Why removed vs. redacted

Two treatments appear above, and the distinction is deliberate:

* **`redact`** replaces a value with `[REDACTED]` but keeps the field present. This suits
  contact/identity fields (`email`, `phone`, `mrn`, `date_of_birth`) where an export consumer may
  need to know a value *existed* without seeing it.
* **`remove`** drops the field entirely so its presence is not even signalled. This is reserved for
  the most sensitive clinical content — `diagnosis` and `treatment_notes` — and for `ssn`. For SUD
  records, the diagnosis and clinical notes are exactly the data **42 CFR Part 2 §2.31** governs on
  re-disclosure; removing rather than masking them is defense-in-depth so a redacted-but-present
  field can never leak the existence of an SUD condition without a valid Part 2 consent and
  re-disclosure notice.

This control is one layer of the broader Part 2 posture (consent gating, disclosure logging,
emergency override under **§2.13**). For the authoritative regulatory mapping, owners, and status,
see the [42 CFR Part 2 entry in the Regulatory Compliance Tracker](/compliance/REGULATORY_COMPLIANCE_TRACKER#cl-11-42-cfr-part-2--implemented).

<Warning>
  The defaults are a floor, not the whole control. Per-entity export configuration can tighten (never
  loosen below) these treatments, and SUD re-disclosure additionally requires consent verification
  upstream of export. This page documents the default segmentation only.
</Warning>