PHI Isolation & Selective Sharing

Design patterns for PHI isolation and controlled cross-user data 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.

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.

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 sharing 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 of what moved, why, and when.

User Models

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

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.