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
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.