Intake Screening & Triage Workflow — Integration Documentation

​

Overview

​

Event Contracts

​

1. ce_screening_completed

{
  event_id: uuid;
  source: 'ce-28';
  timestamp: string; // ISO 8601
  correlation_id: uuid;
  organization_id: uuid;
  data: {
    screening_id: uuid;
    lead_id: uuid;
    disposition: 'proceed' | 'waitlist' | 'refer_out' | 'decline';
    clinical_flags: string[]; // Predefined flag codes only; no free-text PHI
    asam_score: number | null;
    recommended_level_of_care: string | null;
    needs_clinical_escalation: boolean;
    screener_id: uuid;
    screening_date: string; // ISO 8601
    program_type: 'residential' | 'iop' | 'php' | 'outpatient';
    sla_status: 'on_time' | 'missed';
  };
}

​

2. ce_lead_waitlisted

{
  event_id: uuid;
  source: 'ce-28';
  timestamp: string;
  correlation_id: uuid;
  organization_id: uuid;
  data: {
    lead_id: uuid;
    screening_id: uuid;
    program_type: string;
    reason: 'no_bed_available';
  };
}

​

Data Flow

CE-01 (Lead inquiry)
  ↓
CE-28 (Screening)
  ├── ce_screening_attempts (disposition recorded)
  ├── ce_screening_results (questionnaire responses, ASAM score)
  └── Events published:
      ├── ce_screening_completed → FW-16, PM-38, PM-39, CE-29
      └── ce_lead_waitlisted → PM-39 (conditional)
          ↓
CE-29 (Lead-to-Patient Conversion)
  ├── ce_lead_converted_to_patient → PM-01
  └── ce_lead_converted_to_resident → RH-01

​

Cross-Core Dependencies

​

Platform Integration Layers Used

• PF-10 (Notifications): @/platform/notifications — SLA miss alerts
• PF-30 (RBAC): Permission keys ce.screening.*
• FW-16 (Workflow): Event publishing via publishEvent() platform layer

​

Security Considerations

• All tables enforce RLS with organization_id tenant isolation
• PHI present in screening data (substance use, clinical flags) — encrypted at rest
• 42 CFR Part 2 consent gating (SUD-related screening): Before publishing any workflow/event payload that includes SUD-related screening data, implementations MUST verify on ce_screening_attempts that consent_obtained is true, consent_method is populated (per org policy / valid enum), and consent_recorded_at is set. These fields are the authoritative implementation mechanism for consent capture at the point of screening.
• Event metadata for audit: Published events that include SUD-related screening content MUST include consent_recorded_at (ISO-8601 timestamp) in event metadata (alongside correlation/event IDs) so downstream subscribers (PM-38, CE-29, analytics) can prove consent timing for audit and Part 2 tracking.
• Consent capture (consent_obtained, consent_method, consent_recorded_at) on ce_screening_attempts — all three are required for gated publish paths above

​

TODO

• Finalize ce_screening_completed event contract with PM-38 team — implemented in useCreateScreening.ts; payload matches schema above; consent-gated per 42 CFR Part 2
• Confirm RH-01 bed availability query mechanism (event vs API) — Phase 1: placeholder bedAvailable boolean in CreateScreeningInput; ce_lead_waitlisted published when proceed + no bed; RH-01 real-time query deferred to Phase 2
• Coordinate CE-29 conversion trigger from screening disposition — mapScreeningToPatient() in @/platform/ce/ maps screening fields to PM patient shape; CE-29 event-consumer already handles conversion

​

CE-28-ENHANCEMENTS — Crisis Alert Event (EN-01)

​

Trigger

• Phase 1 (no CE-37/CE-35): Keyword-only matcher on inbound SMS (CE-08) and web-form (CE-10) bodies.
• Phase 2: Adds CE-37 intent-classification model and CE-35 transcription stream analysis.

​

Payload (PHI-free)

​

Subscribers

​

Consent / 42 CFR Part 2

​

Ordering / Idempotency

• One event per ce_crisis_alerts insert. Re-classification updates do not re-publish; subscribers should treat alert_id as the idempotency key.
• Subscribers must tolerate at-least-once delivery.