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.

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.

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.

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

User Models

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.

1. Listen for changes

• Subscribe to webhooks on user model updates.

Webhooks

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

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

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.