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-19
Status: ✅ Implemented
Spec Reference: CL-19-peer-recovery-support-services.md
Last Updated: 2026-02-23

​
Overview

CL-19 adds peer specialist and recovery coach encounter documentation with HCPCS code support (e.g. H0038, H2017), supervision tracking, and integration with the patient chart (CL-01) and charge capture (PM-07). Integration is via Platform Foundation, internal CL dependencies, and event-based integration with PM.

​
Integration Points (from Spec)

DependencyPatternPurpose
PF-01 (Organizations & Sites)DirectMulti-tenant isolation
PF-02 (RBAC)DirectRole-based access
PF-70 (Medical Terminology)PlatformHCPCS H0038, H2017 and org-specific codes
CL-01 (Patient Chart)InternalPeer encounters visible on chart
CL-04 (Progress Notes)InternalDistinct document type; not progress notes
CL-11 (Part 2 Consent)Internalcl_check_sud_consent(chart_id, 'peer_encounter', auth.uid()) in RLS for peer encounters
PM-03 (Encounter)DataOptional encounter_id link from cl_peer_encounters to pm_encounters
PM-07 (Charge Capture)EventEncounter-to-billing event when peer encounter finalized; HCPCS from PF-70

​
API / Data Contracts

  • Peer encounters: cl_peer_encounters (chart_id, encounter_id, peer_provider_id, service_date, start_time, end_time, duration_minutes, service_type, hcpcs_code, focus_notes). service_type: Prefer PF-15 as the primary source: use its peer_encounter_type seeded values (e.g. Peer support, Recovery coaching, Crisis peer) for cross-org standardization and reporting. If an org does not use PF-15, implement an org-scoped table cl_peer_service_types and expose a config flag (e.g. use_pf15 = true/false) so implementations support both paths deterministically. Decision criteria: use PF-15 for cross-org standardization and reporting; use cl_peer_service_types for org-customized vocabularies. No public REST API; access via Supabase client and RLS.
  • Peer supervision: cl_peer_supervision (peer_provider_id, supervisor_id, supervision_date, modality, notes). SUD indicator deferred to Phase 2. For MVP, supervision records have no chart_id and no machine-readable SUD flag; application layer treats supervision as non-SUD unless org policy mandates otherwise. Phase 2 may add an optional notes_sud_flag BOOLEAN or chart_id column to enable cl_check_sud_consent enforcement on supervision records. Same access pattern as peer encounters (org-scoped RLS via cl_has_org_access).
  • Consent (CL-11): RLS for cl_peer_encounters MUST call cl_check_sud_consent(p_chart_id, p_record_type, p_requesting_user) with record_type = 'peer_encounter'. Signature and behavior defined in CL-11 spec Errata E-2 and CL-11 integration. Example: USING (cl_has_org_access(organization_id) AND cl_check_sud_consent(chart_id, 'peer_encounter', auth.uid())). For cl_peer_supervision in MVP, no chart_id exists, so CL-11 consent checks are deferred to Phase 2 when chart_id or notes_sud_flag is introduced; until then, supervision records remain org-scoped through cl_has_org_access.

​
Event Contracts

  • Published: peer_encounter_finalized (CL-19 → PM-07). Payload: peer_encounter_id, organization_id, chart_id, encounter_id (optional), peer_provider_id, service_date, hcpcs_code, duration_minutes. See EVENT_CONTRACTS.md.
  • Consumed: None for MVP.

​
Security and RLS

  • Tables: cl_peer_encounters, cl_peer_supervision — RLS enabled; org-scoped via SECURITY DEFINER helpers; UPDATE policies with WITH CHECK per constitution §5.2.4.
  • Part 2 (CL-11): Use helper cl_check_sud_consent(chart_id, 'peer_encounter', auth.uid()) in RLS for cl_peer_encounters; see CL-11 spec and integration doc.
  • PHI: Encounter and supervision data are PHI; no PHI in logs or external AI.