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.

Feature ID: CL-29
Status: ✅ Complete — 2026-02-25
Spec Reference: CL-29-discharge-aftercare-planning.md
Last Updated: 2026-02-24

Overview

CL-29 formalizes discharge planning and aftercare workflows: discharge assessment at admission, structured aftercare plans, warm handoff documentation, 7-day/30-day follow-up tracking (HEDIS FUH), readmission risk assessment, and family/caregiver and SDOH linkage. Integrations: CL-12 (transitions), CL-03 (treatment plan), CL-07 (safety), CL-10 (HEDIS FUH), CL-18 (SDOH), RH (housing coordination).

Quick Reference

  • Purpose: Discharge planning and aftercare workflows (assessment, aftercare plan, warm handoff, 7/30-day follow-up, readmission risk, RH housing coordination).
  • Scope: Four tables (cl_aftercare_plans, cl_follow_up_contacts, cl_readmission_risk_scores, cl_warm_handoffs); CL-12 transition_id link; CL-10 HEDIS FUH; RH event/API.
  • Key links: Spec, CL-12 Care Coordination & Transitions, CROSS_CORE_INTEGRATIONS.md.

Decision Tree

  1. Trigger: Discharge planned or aftercare plan finalized.
  2. Actor: Clinician / care coordinator (CL-29); RH for placement; reporting for FUH.
  3. Discharge assessment at admission → Create/update aftercare plan; link transition_id (CL-12).
  4. Aftercare plan finalized → Publish Discharge.AftercarePlan.Finalized (platform layer); RH and reporting subscribe.
  5. RH referral status change → RH.Referral.Status event (or API); CL-29 may consume for housing_plan sync.
  6. 7-day / 30-day follow-up → cl_follow_up_contacts; CL-10 HEDIS FUH consumes (query or event TBD).

Pattern Library

  • Discharge assessment: Form/workflow at admission; store in cl_aftercare_plans; link to cl_care_transitions via transition_id.
  • Warm handoff: Document caller, receiver, acceptance, time in cl_warm_handoffs; PHI; RLS via cl_has_org_access.
  • Follow-up tracking: cl_follow_up_contacts with contact_type 7_day | 30_day; feed HEDIS FUH per CL-10; use platform layer (message broker or REST) for reporting.

Common Mistakes

MistakeMitigation
Forgetting FORCE ROW LEVEL SECURITYAdd ALTER TABLE … FORCE ROW LEVEL SECURITY after ENABLE for all four tables
Missing cl_has_org_access pre-flightVerify function exists before running migrations (Phase 0 check)
Direct CL → RH table accessUse events or platform API only; CL documents, RH owns placement
Omitting WITH CHECK on UPDATEEvery UPDATE policy must include WITH CHECK (constitution §5.2.4)
Not seeding permission keysMigration seeds cl.aftercare-plans., cl.follow-up-contacts., etc. per PF-30

Pre-Flight Checklist

  • Phase 0: DB check that cl_has_org_access exists; fail deployment if missing.
  • Migration: four tables, indexes, updated_at triggers (pf_set_updated_at), RLS + FORCE RLS.
  • Permission keys seeded; roles assigned.
  • Event contracts (below) documented; CROSS_CORE_INTEGRATIONS.md updated.
  • RLS tests pass; cross-tenant isolation verified.

Integration Points (from Spec)

DependencyPatternPurpose
CL-12 (Care Transitions)Internal / DataLink aftercare plan to transition via transition_id; CL-29 extends with structured aftercare
CL-03 (Treatment Plan)Internal / DataGoals at discharge; treatment plan context for aftercare
CL-07 (Safety Planning)Internal / DataSafety planning at discharge
CL-10 (HEDIS FUH)Internal / Data7-day and 30-day follow-up contacts feed HEDIS FUH
CL-18 (SDOH)Internal / DataSDOH referrals at discharge; community resource linkage
RH (Recovery Housing)Cross-core / Event or APIHousing coordination at residential discharge; RH owns placement; CL-29 documents coordination and referral

API / Data Contracts

  • CL-12 transition link: cl_aftercare_plans.transition_id references cl_care_transitions(id); optional when transition record exists.
  • CL-10 HEDIS FUH: Follow-up contact records (cl_follow_up_contacts with contact_type 7_day/30_day) feed HEDIS FUH logic per CL-10; contract TBD (query or event).
  • RH housing: Coordination documented in aftercare plan (housing_plan); placement owned by RH; integration contract TBD (event or API for referral status).

Event Contracts

  • Planned: Discharge completed or aftercare plan finalized may publish events for RH or reporting. Explicit contract placeholders:
Discharge.AftercarePlan.Finalized (event)
AttributeValue
Channel / topicplatform.events.aftercare (or equivalent)
PublisherCL-29 service when aftercare plan is finalized
SubscribersRH (housing coordination), reporting (FUH / analytics)
Payload (minimal)organization_id, transition_id (cl_aftercare_plans.transition_id), aftercare_plan_id; optional: housing_plan (text), contact_type (cl_follow_up_contacts)
TransportPlatform message broker or REST gateway
Contract typeEvent
RH.Referral.Status (event or REST)
AttributeValue
Channel / topicplatform.events.referrals (or REST endpoint TBD)
PublisherRH when referral/placement status changes
SubscribersCL-29 (optional: update housing_plan or handoff state)
Payload (minimal)organization_id, referral_id, status; reference existing symbols as needed
TransportPlatform message broker or REST gateway
Contract typeEvent (preferred) or REST API (method/endpoint/request-response TBD)
These contracts are listed in CROSS_CORE_INTEGRATIONS.md; integration owners: CL team (CL-29), RH team (referral status).

Security and RLS

  • All CL-29 tables use organization_id (and site_id on cl_follow_up_contacts, cl_readmission_risk_scores). RLS via SECURITY DEFINER (e.g. cl_has_org_access); UPDATE policies include WITH CHECK (constitution §5.2.4). Plans, assessments, and handoffs are PHI; no RLS policy may query RLS-protected tables directly (§5.7).