# PHI Isolation & Selective Sharing

Amigo users are designed to be fully isolated so the platform can safely handle PHI and sensitive data. Cross-user personalization has to be an explicit design choice. Define what to share, when to share it, 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. Don't assume any default sharing.
* When collecting sensitive attributes (for example, 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" %}
Don't share accounts

* Do not expose a single Amigo user account to multiple real people (for example, 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 of what moved, why, and when.

{% content-ref url="/pages/vX6z4zD2a8fjLjPeW9FZ" %}
[User Models](/developer-guide/classic-api/core-api/users/user-models.md)
{% endcontent-ref %}

## Selective Sharing via Dimensions

Use the "dimensions" concept to design a Venn diagram of shareable versus private knowledge:

* **Private dimensions**: stay with the source user only (PHI, sensitive identifiers).
* **Shared dimensions**: well-defined subsets that can be copied or derived for another user.
* **Neutral or 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 (for example, an authorized delegate or a care team member). The aim is isolation by default, with carefully scoped sharing on top.

* Create separate accounts for each real person (isolation first).
* Represent relationships in each user's `additional_context` (a list of linked user IDs and the role of each link).
* Define shareable dimensions (scheduling preferences, non-sensitive summaries) and keep PHI (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 versus shareable (draw a Venn diagram for clarity).
* Assign stable identifiers via naming and 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="/pages/oEO21lDVNYQHFywcW8sh" %}
[Webhooks](/developer-guide/classic-api/webhooks.md)
{% 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 or 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 and 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 you capture DOB or similar attributes for authentication, store them as explicit dimensions with appropriate controls. They are part of the user's PHI model.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.amigo.ai/developer-guide/operations/devops/phi-isolation-and-selective-sharing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.