Skip to main content
Contract Version: 1.0 Created: 2026-03-24 Owning Cores: CL (Clinical & EHR), PM (Practice Management) Status: Draft ADR Reference: ADR-004: CL-FW Event Patterns
Purpose: Define the event contracts for asynchronous communication between CL and PM cores, focusing on clinical documentation → charge capture, referral acceptance → care coordination, and financial program cost → outcomes reporting.

Event Contracts

Event 1: clinical_note_finalized

Summary: When a clinical progress note is signed/finalized in CL-04, PM-07 creates a charge capture suggestion. Payload Schema:
PM Consumer Action:
  1. Validate encounter_id exists in pm_encounters
  2. Check for duplicate event_id in processed events (idempotency)
  3. Create charge suggestion in pm_charge_suggestions with billing codes, modifiers, duration, and provider
  4. High-risk billing codes (compliance guard): Before auto-posting to pm_charges, evaluate CPT/HCPCS in event.payload.billing_codes against a curated high-risk list. Default list (same list MUST be used everywhere this guard is implemented; extend only via org config): 90839, 90840, 90785, H0038, H2035, H0004, T1017, 96127. Org customization: pm_module_settings.auto_post_high_risk_codes_list (text[] or JSON array of codes) replaces the default when set; empty array = use default. Definition — “high-risk”: codes that (a) require strong clinical documentation / medical necessity evidence, (b) draw payer or regulatory audit scrutiny, or (c) commonly require prior authorization — orgs SHOULD align overrides with their compliance policy.
    • Add boolean auto_post_high_risk_codes to pm_module_settings (default false).
    • Auto-post to pm_charges only when: orgSettings.auto_post_enabled === true AND (no high-risk code in payload OR orgSettings.auto_post_high_risk_codes === true).
    • Otherwise create or update pm_charge_suggestions for manual review (PF-10 notify billing as today).
  5. If auto-post rules pass, create pm_charges directly
  6. Send PF-10 notification to billing staff if manual review required
PHI Safety: No patient names, DOB, or narrative text. Only UUIDs and billing metadata.

Event 2: referral_accepted

Summary: When PM accepts an inbound referral, CL-12 creates a care coordination transition record. Payload Schema:
CL Consumer Action:
  1. Check if cl_patient_charts exists for patient; if not, flag for chart creation
  2. Create cl_care_transitions record with referral context
  3. Assign care coordinator via CL-12 assignment rules
  4. Send PF-10 notification to accepting provider and care coordinator

Event 3: clinical_program_cost_allocated

Summary: When FA allocates program costs, CL-10 outcomes can correlate clinical outcomes with financial investment. Payload Schema:
CL Consumer Action:
  1. Store cost data in CL-10 outcomes context for cost-effectiveness reporting
  2. Update CL-15 program quality dashboard with cost-per-outcome metrics
  3. No direct database writes to FA tables (read-only consumption)

Event 4: cl_crisis_episode_resolved

Summary: When a crisis episode is dispositioned with an assigned billing code (CL-13), PM-07 creates a crisis-specific charge suggestion and links it to the episode for audit. Payload Schema:
PM Consumer Action:
  1. Idempotency: same pattern as progress_note_signed using metadata.event_id in fw_domain_events
  2. Create crisis-specific pm_charge_suggestion with billing_code, service_date, rendering_provider_id
  3. For S9484 / H2011 and similar time-based codes, derive units from duration_minutes per org/payer rules in pm_module_settings (or PM-07 configuration)
  4. Link suggestion to cl_crisis_episodes via entity_id on suggestion metadata / extension table (implementation-specific) for audit
  5. Apply the same high-risk auto-post guard as Event 1 when codes overlap the high-risk list
Retry / idempotency: Treat event_id as the dedupe key; duplicates must not create a second suggestion.

Idempotency

All event handlers implement the following idempotency pattern:

Dead-Letter Queue

Failed events follow the DLQ pattern from ADR-004:
  1. On failure: write to fw_domain_events with status = 'failed', error message, retry count
  2. Cron edge function retries failed events (exponential backoff: 1s, 2s, 4s; max 3 retries)
  3. After final failure: PF-10 notification to system admin
  4. No retry on 4xx errors (except 429 rate limit)

E2E Test Plan