Encore OS — Documentation

1. HIPAA (45 CFR 164.502, 164.312(b))

Controls

Control	Implementation	Evidence
PHI in transit	TLS enforced by Supabase platform (default)	Platform infrastructure
PHI in event payloads	IDs only — no names, DOB, SSN, or clinical data in `publishEvent` payloads	`src/cores/ce/hooks/useLeadMutations.ts` — payload contains `lead_id`, `contact_id`, `organization_id`, `correlation_id`, `converted_by` only
PHI in logs	No PHI in `logger.info/error` calls; structured IDs only	`supabase/functions/event-consumer/index.ts` — logs use `correlationId`, `patientId` (UUID), never names
PHI in toasts	Static toast messages (“Lead converted successfully”) with no dynamic PHI	`src/cores/ce/hooks/useLeadMutations.ts` — toast text is static
PHI in errors	`sanitizeErrorMessage(error)` used for all user-facing error display	CE hook error handlers
Audit trail	`ce_lead_conversions` table — INSERT-only, no UPDATE/DELETE policies	Migration + RLS policies
Retention	7-year minimum per HIPAA; enforced by org retention policy alignment (PF-46)	Documented in spec; table has no auto-deletion

Test Coverage

RLS tests: tests/rls/ce-lead-conversions.rls.test.ts — org isolation, immutability
Payload audit: Event payload verified IDs-only in code review

2. 42 CFR Part 2 (SUD Confidentiality)

Controls

Control	Implementation	Evidence
SUD data in payloads	Not transmitted — `substance_use_history` and `clinical_flags` are NOT included in event payloads	`useLeadMutations.ts` payload construction — only IDs
SUD data in audit	`data_mapping` JSONB field can store consent references if org configures SUD gating	Schema supports it; no SUD data stored by default
Consent verification	Chart-scoped per CL-11 (`cl_check_sud_consent(chart_id, ...)`) when SUD data is involved	Noted in spec Clarifications; consent gating required when CE-28 wires screening data into conversion flow
Re-disclosure prevention	No PHI/SUD data leaves CE core in events; PM subscriber fetches data server-side with service role	`event-consumer/index.ts` — server-side fetch

Notes

CE-29 events carry zero clinical content — they are ID-based pointers only
The PM subscriber (handleLeadConvertedToPatient) reads contact data server-side, never exposing it in event payloads
Full Part 2 consent enforcement is deferred to CL-11 integration per spec Clarifications

3. AHCCCS 320-O (Screening Documentation)

Controls

Control	Implementation	Evidence
Screening date in audit	`custom_fields` JSONB on `ce_lead_conversions` supports `screening_date` storage	Schema design
Screener identification	`converted_by` UUID identifies the user who triggered conversion	Column in `ce_lead_conversions`
Documentation trail	Immutable audit record links lead → conversion → patient/resident	`ce_lead_conversions` INSERT-only with `correlation_id`
CE-28 alignment	CE-28 screening disposition triggers CE-29 conversion; screening data flows via `data_mapping`	Spec integration pattern

Notes

AHCCCS 320-O requires 18 assessment elements documented in the clinical record
CE-29 captures the conversion decision point; full clinical documentation is CL-02/CL-04 responsibility
The data_mapping JSONB field provides extensibility for org-specific screening fields

4. Cross-Reference

Regulation	Spec Section	Task	Status
HIPAA 164.502	§5 Regulatory	T-COMP-1	✅ Complete
HIPAA 164.312(b)	§5 Regulatory	T-COMP-1	✅ Complete
42 CFR Part 2	§5 Regulatory	T-COMP-2	✅ Complete
AHCCCS 320-O	§5 Regulatory	T-COMP-3	✅ Complete

5. References

Spec: specs/ce/specs/CE-29-lead-to-patient-conversion-pipeline.md
Tasks: specs/ce/tasks/CE-29-TASKS.md
Compliance Tracker: docs/compliance/CE_COMMUNICATIONS_COMPLIANCE_TRACKING.md
Regulatory Tracker: docs/compliance/REGULATORY_COMPLIANCE_TRACKER.md
RLS Tests: tests/rls/ce-lead-conversions.rls.test.ts

HIPAA & 42 CFR Part 2 Compliance Evidence 42 CFR Part 2 Gating for Trauma Assessments — Compliance Evidence