# PHI / DEID Separation

Identified (PHI) and de-identified data live in two physically separate Snowflake databases with separate role grants. No role has implicit access to both; the only roles that hold both are the data-engineering and admin roles that build and operate the de-identification pipeline.

## Two separate databases

`CLINICOGENOMICS` holds identified data; `CLINICOGENOMICS_DEID` holds the de-identified mirror for external partners. Access to each is controlled by separate role families, verified live against `SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES`. A role holds database `USAGE` on exactly the database it is entitled to; the PHI and DEID chains are disjoint and never inherit each other.

## Role families

| Access class | Databases | Who / use case |
| --- | --- | --- |
| PHI only | `CLINICOGENOMICS` | Clinical operations, data ingest, internal review. No grant on the DEID database. |
| DEID only | `CLINICOGENOMICS_DEID` | Biopharma analytics, partner exports, BI on de-identified data. No grant on the PHI database. |
| Both (the only path) | Both databases | Data engineering and admin — they build and operate the de-identification pipeline that reads PHI and writes DEID. |

The two access chains are parallel hierarchies: VIEWER rolls into RESEARCHER rolls into ANALYST within each side, and the ANALYST of both sides rolls into `RWD_DATA_ENGINEER_ROLE`. A user mapped to a DEID role can never see PHI through that role, and vice versa.

## Picking the right role

> **Pick the role that matches the task**
>
> For users who hold both PHI and DEID roles: pick the role that matches the task, not the broadest one you hold. Use a `*_DEID_*` role for de-identified analytics, dashboards, and partner-facing work. Use a `*_PHI_*` role only when the task genuinely requires identified data. Reach for the DEID role first and fall back to PHI only when the work cannot be done on de-identified data.

## Expert determination

The DEID schema is covered by a HIPAA Expert Determination (Brad Malin, valid to Feb 2027). Any new DEID table, or any new field surfaced on the DEID side, goes back for expert-determination review before it is exposed. The determination certifies that the specific set of fields and transforms keeps re-identification risk very small; adding fields outside the certified set requires re-review.