Draft · v0.1 · Not legal advice

HIPAA & Security Plan

Mariner Health handles information that, once real, is Protected Health Information (PHI). This document describes the app-level controls we build in, the operational controls that must exist around the app, and the shared responsibilities that make the whole system HIPAA-ready.

Pre-production notice. No real PHI may be entered into this project. Uploads must be synthetic or fully de-identified until every subprocessor has a signed Business Associate Agreement (BAA) and a HIPAA risk assessment has been completed and reviewed by qualified counsel.

1. Shared responsibility

Concern	App enforces	Requires ops / legal
Encryption in transit	HTTPS-only, HSTS	Managed by host
Encryption at rest	DB + Storage default encryption	Key management policy
Access control	RLS, roles, MFA, session timeout	Onboarding / offboarding process
Audit logging	Row-level app audit log	Retention + review cadence
BAAs	—	Hosting, DB, AI, email, storage, monitoring
Breach response	Alerting hooks	Written incident-response plan

2. App-level controls

Authentication: email + password, Google OAuth. MFA required for every account before first PHI-capable action.
Session: idle timeout, sign-out on the client clears cache and invalidates queries.
Authorization: RLS on every table. Roles live in a separate caregiver_roles table, never on profiles.
Least privilege: the server-role admin client is used only for verified operations, loaded dynamically inside handlers, never at module scope.
Minimum necessary: AI calls receive extracted excerpts, never full documents.
No PHI in logs: prompts and completions are hashed. Application logs strip identifiers.
Storage: private per-family buckets, signed URLs with short TTL, no public buckets.
Input validation: Zod schemas on every server function, client and server.

3. Consent management

Consent is modeled per (granter, subject child, grantee, data type). A caregiver can be granted access to a subset of a child's data (e.g., school records only). Revocation is immediate, logged, and cascades to any active sessions the grantee holds.

Every consent grant produces an audit_log row.
Every revocation produces an audit_log row and forces reauthentication on next request.
The consent center is a first-class screen, not buried in settings.

4. Audit logging

Reads and writes of child-scoped tables produce audit_log rows via a trigger. The owner of a family can view a filtered log for their children. Logs are append-only; there is no product surface to edit or delete them.

5. AI content handling

Every insight persists { conclusion, why, next_step, confidence, prompt_hash, model_id }.
The UI refuses to render an insight that is missing any of the three transparency fields.
Insights carry a persistent "Not medical advice" disclaimer.
Parents can flag or dismiss any insight; flagged insights are queued for review.
No AI-initiated actions. Every recommendation requires an explicit parent tap to act.

6. Incident response (outline)

Detection: alerting on auth anomalies, storage access spikes, and failed policy checks.
Containment: revoke sessions, rotate keys, freeze affected accounts.
Assessment: determine whether PHI was involved and how many individuals.
Notification: within legal deadlines, per HIPAA Breach Notification Rule.
Postmortem: written, retained, and reviewed with counsel.

7. Open items for review

Confirm BAA availability with each subprocessor (hosting, DB, AI provider, email, monitoring).
Retention schedule for audit logs and deleted records.
Data-export and right-to-delete workflows.
Pediatric consent nuances by jurisdiction (state-level minor consent laws).