Skip to main content
Contract Version: 1.0 Created: 2026-03-24 Owning Cores: CL (Clinical & EHR), FW (Forms & Workflow) Status: Draft ADR Reference: ADR-004: CL-FW Event Patterns
Purpose: Define the event contracts for CL clinical events consumed by FW-16 (Event-Based Workflow Triggers) for automated task creation, notifications, and escalation workflows.

Automated event publishers (system actor)

Cron jobs and other non-human publishers must set metadata.user_id to a well-known platform system profile so audit trails stay consistent (no NULL actor, no arbitrary strings). All automated events MUST use this UUID for metadata.user_id unless a spec explicitly documents a different service principal.

Event Catalog

Event 1: cl_assessment_expired

Payload:
FW Automation Rule:
  • Template: reassessment_reminder
  • Task: “Complete overdue assessment”
  • Assignee: assigned_clinician_id
  • Priority: high if days_overdue > 7, medium otherwise
  • Due date: 3 business days from task creation

Event 2: cl_moud_monitoring_overdue

Payload:
FW Automation Rule:
  • Template: moud_care_team_alert
  • Alert: PF-10 notification to all care_team_ids
  • Task: “Complete for MOUD patient” assigned to assigned_clinician_id
  • Priority: high
  • Escalation: If not resolved in 48 hours, escalate to supervisor (Event 3)

Event 3: cl_moud_adherence_risk

Payload:
FW Automation Rule:
  • Template: moud_escalation
  • Alert: PF-10 critical notification to supervisor_id
  • Task: “Urgent MOUD adherence review” assigned to supervisor_id
  • Priority: critical
  • Due date: Same business day

Event 4: cl_care_gap_identified

Payload:
FW Automation Rule:
  • Template: care_gap_task
  • Task: “Close care gap: ” assigned to care_manager_id or unassigned pool
  • Priority: medium (elevated to high if due_date < 30 days)
  • Due date: 14 business days or due_date, whichever is earlier

Event 5: cl_crisis_episode_opened

Payload:
FW Automation Rule:
  • Template: crisis_supervisor_notification
  • Alert: PF-10 critical notification to supervisor_id and site clinical lead
  • No task created (crisis is actively managed by assigned clinician)
  • If crisis_type = 'observation_23hr', also create 6 interval assessment tasks (4-hour cadence)

Event 6: cl_restraint_event_initiated

Payload:
FW automation: Template name restraint_incident_creation — drives GR incident stub + PF-10 supervisor notification per org rules. GR / PF-10: GR-09 consumes the event for regulatory incident creation; PF-10 delivers the critical alert to supervisor_id (or site escalation path). Canonical event name: cl_restraint_event_initiated (physical start / initiation_time). Do not alias to cl_restraint_event_documented without updating EVENT_CONTRACTS.md, GR-09, and CL-GR-CLINICAL-INCIDENT-INTEGRATION.md — those documents MUST stay aligned with this contract.

FW-16 consumer spec: restraint_incident_creation automation template

FW-16 MUST register a workflow template named restraint_incident_creation (referenced by fw_workflow_events.auto_task_template for cl_restraint_event_initiated). Implementation MUST satisfy GR-09 incident auto-create and compliance testing. Seed note: The template restraint_incident_creation MUST be defined in the workflow templates seed (or equivalent FW-16 registry) with nodes implementing the table above: (1) validate payload, (2) call GR-09 incident upsert, (3) enqueue PF-10 supervisor alert. Until the template exists in seed, deployments SHOULD treat auto_task_template as a documentation contract and implement the template before enabling production automation for this event.

Event 7: cl_restraint_event_terminated

Payload (minimum):

Event 8: cl_care_gap_closed

Payload:

Event Registration Seed Data

All CL→FW events must be registered in fw_workflow_events for FW-16 to consume them:

Drift Prevention

To ensure event contracts don’t diverge between CL publishers and FW consumers: Add to CI pipeline: validate that every pg_notify('cl_events', ...) call in CL code matches a registered event in fw_workflow_events seed data.

Manual Audit (Current)

  • When adding a new CL event, update this contract and the seed SQL
  • Update EVENT_CONTRACTS.md with the new event entry
  • PR template includes checklist item: “Event contract updated if new events added”

Idempotency & DLQ

Summary aligns with ADR-004. Canonical handler pattern (copy-paste for FW/edge consumers):
DLQ / retry:
  • On failure, row in fw_domain_events uses status = 'failed', increment retry_count per retry attempt, populate error_message.
  • Cron retries with exponential backoff (e.g. 1s, 2s, 4s) up to 3 additional attempts; after max retries: retry_count = 3, processed_at remains NULL, PF-10 notifies system admin.
  • No retry on 4xx except 429 (rate limit).