# PHI Isolation & Selective Sharing

Amigo users are designed to be fully isolated to support PHI and sensitive data. Cross-user personalization must be an explicit design choice: define what to share, when to share, and how to propagate changes - never rely on implicit or global sharing.

{% hint style="warning" %}
Privacy by design

* Each user’s model and context are isolated. Do not assume any default sharing.
* When collecting sensitive attributes (e.g., DOB for verbal auth), store them intentionally as part of the user model and treat them as PHI.
* Only share the minimum dimensions necessary; avoid free‑form dumps across users.
  {% endhint %}

{% hint style="warning" %}
Do not share accounts

* Do not expose a single Amigo user account to multiple real people (e.g., parents sharing a child’s login). This risks PHI contamination and audit ambiguity.
* Instead, create separate accounts for each person and explicitly transfer only the approved dimensions between users based on your Venn‑diagram design.
  {% endhint %}

## Isolation Model

* Per-user boundary: User models (knowledge, attributes) and `additional_context` are scoped to a single user.
* No implicit sharing: Parent/child, caregiver/patient, or team scenarios require an explicit sharing plan.
* Auditability: Sharing should be reproducible from a clear mapping (what moved, why, and when).

{% content-ref url="../../classic-api/core-api/users/user-models" %}
[user-models](https://docs.amigo.ai/developer-guide/classic-api/core-api/users/user-models)
{% endcontent-ref %}

## Selective Sharing via Dimensions

Use the “dimensions” concept to design a Venn diagram of shareable vs. private knowledge:

* Private dimensions: Remain with the source user only (e.g., PHI, sensitive identifiers).
* Shared dimensions: Well-defined subsets that can be copied/derived for another user.
* Neutral/derived dimensions: Summaries or non-sensitive attributes that may be safe to share.

We recommend marking shareable dimensions with consistent tags or stable names so automation can target them predictably.

## Multi‑Party Scenarios

Goal: Multiple real people need limited, explicit sharing (e.g., an authorized delegate or a care team member). We want isolation by default and carefully scoped sharing.

* Create separate accounts for each real person (isolation first).
* Represent relationships in each user’s `additional_context` (e.g., a list of linked user IDs and the role of each link).
* Define shareable dimensions (e.g., scheduling preferences, non‑sensitive summaries) and keep PHI (e.g., diagnoses, identifiers, DOB) private unless explicitly required.
* On updates to a source user model, selectively propagate only approved dimensions to linked users; on updates to linked users, push only designated context back.

This pattern avoids PHI contamination from shared credentials and keeps an auditable record of what moved between which users.

## How to Implement

1. Blueprint the model

* Enumerate dimensions and decide what is private vs. shareable (draw a Venn diagram for clarity).
* Assign stable identifiers via naming/tags. If the internal schema evolves, run a backfill to maintain referential stability.

2. Listen for changes

* Subscribe to webhooks on user model updates.

{% content-ref url="../../classic-api/webhooks" %}
[webhooks](https://docs.amigo.ai/developer-guide/classic-api/webhooks)
{% endcontent-ref %}

3. Transform and write

* When a source user model changes, read the model and copy only the approved dimensions into the target user’s `additional_context` or derived dimensions.
* Never transfer raw PHI unless business/legal requirements demand it; prefer derived or summarized attributes.

4. Review and audit

* Log what was transferred (source, target, dimensions) for traceability.
* Periodically re‑validate the blueprint to prevent drift or leakage.

## Sharing Plan - Visual

{% @mermaid/diagram content="%%{init: {"flowchart": {"useMaxWidth": true, "nodeSpacing": 20, "rankSpacing": 30}, "theme": "base", "themeVariables": {"primaryColor": "#D4E2E7", "primaryTextColor": "#100F0F", "primaryBorderColor": "#083241", "lineColor": "#575452", "textColor": "#100F0F", "clusterBkg": "#F1EAE7", "clusterBorder": "#D7D2D0"}}}%%
flowchart TB

classDef user fill:#F1EAE7,stroke:#D7D2D0,color:#100F0F
classDef share fill:#DDE3DB,stroke:#2c3827,color:#100F0F
classDef note fill:#E8E2EB,stroke:#C5BACE,color:#100F0F

A\[User A private dimensions]:::user
B\[User B private dimensions]:::user
S\[Shared dimensions<br/>explicitly allowed]:::share
N\[Only approved subsets flow.<br/>PHI stays within the source user unless required.]:::note

A --> S
B --> S
S --> A
S --> B
S --> N" %}

## Design Notes

* Least privilege: Share the minimum viable subset for the experience.
* Predictable targeting: Use stable dimension names/tags to avoid brittle selectors.
* Backfill on change: If you refine or re-map dimensions, run a backfill to keep shared data consistent.
* Verbal auth data: If capturing DOB or similar attributes for authentication, store them as explicit dimensions with appropriate controls; they are part of the user’s PHI model.