Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

Spec: specs/ce/specs/CE-29-lead-to-patient-conversion-pipeline.md
Status: ✅ Evidence Documented
Last Updated: 2026-03-28

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

Controls

ControlImplementationEvidence
PHI in transitTLS enforced by Supabase platform (default)Platform infrastructure
PHI in event payloadsIDs only — no names, DOB, SSN, or clinical data in publishEvent payloadssrc/cores/ce/hooks/useLeadMutations.ts — payload contains lead_id, contact_id, organization_id, correlation_id, converted_by only
PHI in logsNo PHI in logger.info/error calls; structured IDs onlysupabase/functions/event-consumer/index.ts — logs use correlationId, patientId (UUID), never names
PHI in toastsStatic toast messages (“Lead converted successfully”) with no dynamic PHIsrc/cores/ce/hooks/useLeadMutations.ts — toast text is static
PHI in errorssanitizeErrorMessage(error) used for all user-facing error displayCE hook error handlers
Audit trailce_lead_conversions table — INSERT-only, no UPDATE/DELETE policiesMigration + RLS policies
Retention7-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

ControlImplementationEvidence
SUD data in payloadsNot transmitted — substance_use_history and clinical_flags are NOT included in event payloadsuseLeadMutations.ts payload construction — only IDs
SUD data in auditdata_mapping JSONB field can store consent references if org configures SUD gatingSchema supports it; no SUD data stored by default
Consent verificationChart-scoped per CL-11 (cl_check_sud_consent(chart_id, ...)) when SUD data is involvedNoted in spec Clarifications; consent gating required when CE-28 wires screening data into conversion flow
Re-disclosure preventionNo PHI/SUD data leaves CE core in events; PM subscriber fetches data server-side with service roleevent-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

ControlImplementationEvidence
Screening date in auditcustom_fields JSONB on ce_lead_conversions supports screening_date storageSchema design
Screener identificationconverted_by UUID identifies the user who triggered conversionColumn in ce_lead_conversions
Documentation trailImmutable audit record links lead → conversion → patient/residentce_lead_conversions INSERT-only with correlation_id
CE-28 alignmentCE-28 screening disposition triggers CE-29 conversion; screening data flows via data_mappingSpec 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

RegulationSpec SectionTaskStatus
HIPAA 164.502§5 RegulatoryT-COMP-1✅ Complete
HIPAA 164.312(b)§5 RegulatoryT-COMP-1✅ Complete
42 CFR Part 2§5 RegulatoryT-COMP-2✅ Complete
AHCCCS 320-O§5 RegulatoryT-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