Skip to main content
Version: 2.4.0
Last Updated: 2026-05-28
Change Note: Added CL↔PM↔GR care-quality measures & grant-reporting events (clinical.outcome_assessment.recorded, clinical.care_gap.identified, cl_cocm_registry_status_changed, pm_care_management_charge_posted) and the cl_quality_measure_period_calculated consumer extension (PM-25-EN-01, PM-77, GR-28, GR-31); CL-51 engine registers CL-12-EN-68/CL-22-EN-01/CL-29-EN-66/CL-51-EN-01/CL-51-EN-02 measure definitions. PHI-free payloads; SUD rows DS4P-labeled + Part 2 consent-gated. See CL-PM-GR-CARE-QUALITY-GRANT-INTEGRATION.md. Prior: Added HR-44/FA-43 Proliant (ReadyPay) embedded payroll-run events (hr_payroll_run_started, hr_payroll_run_preprocessed, hr_payroll_run_verified, hr_payroll_run_approved, hr_payroll_run_submitted, fa_payroll_je_generated) with PHI-safe payloads; see HR-44-PROLIANT-READYPAY-INTEGRATION.md. Prior: Added HR-44 Proliant HCM integration events (hr_proliant_sync_completed, hr_proliant_conflict_detected) with PHI-safe payload guidance. Prior: six BHRF (A.A.C. R9-10-701..722) lifecycle event contracts (CL-68/GR-27/PM-74) with coded hold_reason and R7 idempotency. Constitution Reference: Section 1.3 (Integration Patterns - Pattern 2)
Event-based integration enables loose coupling between cores via domain events. Events are published using PostgreSQL pg_notify and consumed via database triggers or edge functions.

Event Schema Standard

All events MUST follow this structure:

RH lifecycle events: canonical names & persistence (FW-16)

Canonical names match KnownEventName in src/platform/events/types.ts and rows in fw_workflow_events / inserts into fw_domain_events: Realtime: Consumers should read fw_domain_events (and FW-16 automation) as the source of truth. A dedicated pg_notify channel (e.g. rh_events) is optional and must not diverge from persisted domain events.

Status Legend

  • Implemented - Fully implemented and tested
  • 📝 Planned - Specified but not yet implemented
  • 🟡 In Progress - Partially implemented

Canonical Event Channels

Use these channels when documenting or implementing events. New events must use the channel for their owning core. Reference this table from specs/_templates/INTEGRATION_CONTRACT_TEMPLATE.md when defining event contracts. Event naming: For new events, use the canonical format {core}_{entity}_{action} (e.g. hr_employee_hired, cl_assessment_completed). Existing events may use the legacy dotted pattern (e.g. hr.benefit_enrollment.created). PM-51 RPA naming exception: The PM-51 RPA events (pm.rpa.execution_completed, pm.rpa.consecutive_failures) use dotted naming as approved for this feature. This is an explicit exception to the standard underscore convention for backward compatibility with the RPA automation system. New PM events outside of PM-51 should follow the standard pm_{entity}_{action} format. See INTEGRATION_CONTRACT_TEMPLATE.md § Event Naming Conventions.

Event Delivery Mechanism

Canonical guide: EVENT_DELIVERY.md — how to choose table-driven vs HTTP consumer vs realtime vs external webhooks. Current Implementation (✅ Complete):
  • Events published via PostgreSQL pg_notify to dedicated channels:
    • domain_events - HR lifecycle events (credentials, onboarding, offboarding)
    • automation_trigger - FW form submission/update events
    • fa_events - FA financial events (journal posting, payments, budgets, consolidations)
    • it_events - IT module events (ticket created, contract/license expiring, asset assigned, purchase request submitted/approved)
    • lo_events - LO leadership events (rocks, todos, meetings, issues)
    • cl_pm_events - Active channel for CL/PM cross-core events (CL-01 break-glass, PM eligibility, appointment check-in to CL-04, CL-09 lab orders/results) — ✅ Active for CL-01, PM, and CL-09 integration events
    • cl_events - CL clinical events (note finalized, assessment completed, group session completed) — 📝 Reserved for CL-02+ internal events; not yet in use
    • pm_events - PM practice management events (eligibility verified) — 📝 Planned; channel reserved for PM-02+
  • Subscribers consume via edge functions that listen to pg_notify
  • Events include full organization context for multi-tenant isolation
  • All events logged to pf_audit_logs for permanent audit trail
  • Event consumer edge function: supabase/functions/event-consumer/index.ts
  • Automation executor edge function: supabase/functions/automation-executor/index.ts
Event Flow:
Security:
  • All events include organization_id for tenant isolation
  • Edge functions run with service role (no JWT verification)
  • Event payloads logged for security audit
  • No sensitive data (passwords, SSNs) in event payloads
Idempotency and Retry (R7):
  • Idempotency keys: All event payloads MUST include a unique event_id (uuid); workflow executions MUST use execution_id as the idempotency key. Handlers in event-consumer and automation-executor MUST record processed keys and skip duplicates (e.g. check fw_workflow_executions or a processed-events table before performing side effects).
  • Retry/backoff: On transient failure (5xx, timeout), retry with exponential backoff (e.g. 1s, 2s, 4s, max 3 retries). Do not retry on 4xx (except 429).
  • Duplicate detection: When invoked more than once (retry, at-least-once delivery), handlers MUST detect already-processed event_id or execution_id and return success without re-executing; never create duplicate charges, notifications, or workflow steps.

PHI-Safe Payload Guidance

For PF-10/PF-11 workflows and PM-16-style billing communications, payloads must be identifier-only:
  • Allowed: system-generated UUIDs (organization_id, patient_id, statement_id, etc.)
  • Disallowed: patient names, MRNs, DOBs, account numbers, or narrative PHI fields
  • Resolve display details only through authorized API/UI lookups after permission/RLS validation
  • Use PM-16 integration guidance as the reference implementation pattern
Future Enhancements:
  • Event bus for higher throughput (Redis, RabbitMQ, Kafka)
  • Event replay for debugging and recovery
  • Event versioning for schema evolution
  • Circuit breaker for failing event handlers
  • Dead letter queue for failed events
  • Event aggregation and analytics

Supabase Realtime channel contracts

Channel contracts for Supabase Realtime (broadcast/presence) are documented here when they define cross-cutting semantics or multi-tenant rules. Implementations must enforce authorization at channel subscription time and align with RLS on application tables.

PF-73: Swim Lane Diagram collaborative realtime channel \

Owner: PF-73 (Workflow Builder with Swim Lane Visualization)
Status: ✅ Implemented (Phase 2.2)
Spec: PF-73-workflow-builder-swim-lane-visualization.md
Implemented: 2026-03-14
Hooks:
  • useDiagramPresence(orgId, diagramId) — wraps useRealtimePresence from @/platform/realtime
  • useDiagramBroadcast(orgId, diagramId) — wraps useRealtimeBroadcast; event diagram_updated
Broadcast payload:
Channel schema: org:{orgId}:diagram:{diagramId} — composite key; never use diagram id alone (prevents cross-tenant leakage). Semantics: subscribe, broadcast, and presence (track) are allowed only after channel-level authorization. Authorization MUST be performed at channel subscription time (before allowing subscribe(), broadcast(), or track()/presence), not solely via RLS on application tables. Multi-tenant verification rules:
  • Org-scoped auth: Verify the requester belongs to orgId (e.g. via pf_has_org_access(organization_id, auth.uid())) before allowing join, broadcast, or presence on that channel.
  • RLS: Diagram and version tables remain org-scoped; require RLS policies on realtime.messages (where applicable) plus an explicit server/edge check that verifies the requester belongs to orgId.
  • Documentation: Channel-level checks and required RLS/auth checks are documented in CROSS_CORE_INTEGRATIONS.md and PF-73-workflow-builder-swim-lane-INTEGRATION.md.

Implemented Events

FW-03: Form Submission Events

Event: automation_trigger (form_submitted / form_updated)
Publisher: FW (Forms & Workflow)
Subscribers: FW-03 Automation Engine
Status: ✅ Complete
Implemented: 2025-11-25
Payload Schema:
Implementation:
Consumer: supabase/functions/automation-executor/index.ts
  • Listens to automation_trigger channel via pg_notify
  • Fetches matching automation rules
  • Evaluates conditions
  • Executes actions (email, notification, webhook, record update)
  • Logs execution to fw_automation_logs
Testing: ✅ Complete - All test cases passed

HR-02: Credential Management Events

Event 1: hr_credential_expired (canonical)
Legacy alias (deprecated): credential_expired — maintained for backward compatibility but should migrate to canonical name
Publisher: HR (Workforce)
Subscribers: Event Consumer (audit logging), HR-04 (Scheduling)
Status: ✅ Complete
Implemented: 2025-11-25
Payload Schema:
Implementation:
Event 2: hr_credential_verified (canonical)
Legacy alias (deprecated): credential_verified — maintained for backward compatibility but should migrate to canonical name
Payload Schema:
Implementation:
Consumer: supabase/functions/event-consumer/index.ts
  • Logs all events to pf_audit_logs
  • Future handlers ready for notifications and alerts
HR-04 Integration (Credential Blocking):
  • HR-04 Scheduling subscribes to hr_credential_expired events (canonical; legacy credential_expired alias supported for backward compatibility)
  • When credential expires, employee is automatically blocked from shift assignment
  • Blocking prevents scheduling until credential is renewed and verified
  • Integration documented in HR-04 spec (Scheduling & Capacity)
Implementation in HR-04:
Testing: ✅ Complete - Events fire correctly on status changes

HR-03: Onboarding & Offboarding Events

Status: ✅ Complete (base events), 📝 Planned (IT trigger events)
Implemented: 2025-11-25 (base), 2026-01-02 (IT triggers spec)

Completion Events (✅ Implemented)

Event 1: hr_onboarding_completed (canonical name; legacy alias onboarding_completed)
Publisher: HR (Workforce)
Subscribers: Event Consumer (audit logging)
Payload Schema:
Event 2: offboarding_completed
Payload Schema:

IT Trigger Events (📝 Planned - IT-08 Integration)

These events trigger IT-08 IT Onboarding/Offboarding workflows. Event 3: hr_onboarding_started
Publisher: HR (Workforce)
Subscribers: IT-08 (IT Provisioning)
Trigger: INSERT on hr_onboarding_instances
Payload Schema:
Event 4: hr_onboarding_task_created
Publisher: HR (Workforce)
Subscribers: IT-08 (IT Task Instance)
Trigger: INSERT on hr_onboarding_task_instances WHERE category = ‘it_setup’
Payload Schema:
Event 5: hr_offboarding_started
Publisher: HR (Workforce)
Subscribers: IT-08 (IT Offboarding)
Trigger: INSERT on hr_offboarding_instances
Payload Schema:
Event 6: hr_offboarding_task_created
Publisher: HR (Workforce)
Subscribers: IT-08 (IT Access Revocation)
Trigger: INSERT on hr_offboarding_checklist_items WHERE category = ‘access_revocation’
Payload Schema:
Consumer: supabase/functions/event-consumer/index.ts
  • Logs all events to pf_audit_logs
  • IT-08 handlers create corresponding IT provisioning/offboarding instances
Testing: ✅ Complete (base events) - Events published on workflow completion

HR-31: Policy Acknowledgment Events — ⛔ ARCHIVED

⛔ DEPRECATED (2026-03-26): HR-31 has been consolidated into GR-01. The HR-31 tables (hr_policies, hr_policy_distributions, hr_policy_acknowledgments) were dropped in migration 20260326034722. These event contracts are retained for historical reference only.
Status: ⛔ Archived — consolidated into GR-01
Spec: HR-31 (deprecated)
Integration: HR-31 Integration (archived)

Event 1: hr_policy_acknowledgment_completed (archived)

Publisher: HR-31 (dropped)
Subscribers: None (historical only — no active subscribers)
Payload Schema (historical):
Idempotency: (organization_id, acknowledgment_id)

Event 2: hr_policy_distribution_created (archived)

Publisher: HR-31 (dropped)
Subscribers: None (historical only — no active subscribers)
Payload Schema (historical):
Idempotency: (organization_id, distribution_id)

Consumer: hr_onboarding_completed → HR-31 (archived)

Archived: HR-31 previously consumed hr_onboarding_completed (HR-03) to create new-hire policy packet distributions. This consumer was removed when HR-31 was consolidated into GR-01. GR-01 now handles policy acknowledgment workflows directly.

HR-05: Time & Attendance Exception Events

Status: ✅ Implemented
Implemented: 2026-03-09

Event 1: hr_timesheet_exception_created

Publisher: HR (DB trigger on hr_time_exceptions)
Subscribers: time-exception-notify edge function → PF-10 (in-app notification)
Channel: hr_events
Trigger: INSERT on hr_time_exceptions
Payload Schema:
Consumer: supabase/functions/time-exception-notify/index.ts
  • Resolves manager via hr_employees.manager_id
  • Creates in-app notification via createNotificationIfNew() (dedup by reference)
  • Notification type: timesheet_exception
  • Auth gate: validates Authorization header before processing

HR-10: Performance Management Events

Status: ✅ Implemented
Implemented: 2026-01-13 (Event 1), 2026-01-12 (Event 3)

Event 1: performance_review_completed

Publisher: HR (Workforce)
Subscribers: LO-03 (Goals), HR-15 (Compensation), HR-16 (Succession Planning)
Status: ✅ Implemented (2026-01-13)
Payload Schema:
Purpose: Notify other systems of completed reviews for goal alignment, compensation planning, succession planning Implementation:

Event 2: performance_goal_completed

Publisher: HR (Workforce)
Subscribers: LO-03 (Goals)
Status: 📝 Planned
Payload Schema:
Purpose: Update organizational goal progress when employee goals complete

Event 3: hr_pip_terminated

Publisher: HR (Workforce)
Subscribers: HR-03 (Offboarding), HR-14 (Employee Relations)
Status: ✅ Implemented (2026-01-12)
Payload Schema:
Purpose: Trigger employee relations case and potential offboarding when PIP fails Implementation:
  • Hook: src/cores/hr/hooks/performance/usePIPTerminationIntegration.ts
  • Event registered in: fw_workflow_events table
  • Triggered by: usePIPMutation.completePIP() when outcome is ‘unsuccessful’
  • Creates: hr_disciplinary_actions record with action_type: 'termination'
  • UI Warning: PIPCompleteDialog.tsx shows warning for unsuccessful outcome
Consumer Actions:
  1. Creates disciplinary action record in HR-14
  2. Publishes hr_pip_terminated event for workflow automation
  3. Future: Triggers HR-03 offboarding workflow via automation rules

HR-11 / HR-PAY-02: Benefit Enrollment Events (Payroll Deductions)

Status: 📝 Planned (Event payloads documented; publisher and HR-PAY-02 subscriber to be implemented) Spec Reference: HR-PAY-02 (Payroll Deductions), HR-11 (Benefits Administration). When implemented, HR-PAY-02 will subscribe to auto-create deduction on enrollment and end-date deduction on termination. See src/cores/hr/lib/reconcileEnrollmentDeductions.ts for enrollment-deduction sync pattern.
⚠️ BREAKING CHANGE (v2.2.0): The payloads for hr.benefit_enrollment.created and hr.benefit_enrollment.terminated were restructured:
  • Removed: enrollment_id, benefit_plan_id, enrollment_date, coverage_tier
  • Added: benefit_enrollment_id, amount, pre_tax
  • Structure: Event-specific fields moved into payload object per Event Schema Standard Implementers consuming these events must update their handlers.

Event 1: hr.benefit_enrollment.created

Publisher: HR (Workforce) — HR-11 Benefits
Subscribers: HR-PAY-02 (Payroll Deductions)
Payload Schema:
Purpose: Notify payroll deductions (HR-PAY-02) of new benefit enrollment so a deduction can be auto-created.

Event 2: hr.benefit_enrollment.terminated

Publisher: HR (Workforce) — HR-11 Benefits
Subscribers: HR-PAY-02 (Payroll Deductions)
Payload Schema:
Purpose: Notify payroll deductions (HR-PAY-02) of benefit enrollment termination so the deduction can be end-dated.

HR-PAY-04: Employer Tax Liability Events (Tax Forms Compliance)

Status: 📝 Planned (Publisher implemented; FA consumer not yet implemented) Publisher: HR (Workforce) — HR-PAY-04 — ✅ Implemented in src/cores/hr/services/employer-taxes/publish-tax-event.ts (publishes to hr_events). Subscribers: FA (Finance) — for GL posting and liability tracking. Consumer: Not yet implemented; until FA consumes this event, GL posting may be manual. See FA_FINANCIAL_COMPLIANCE_TRACKING.md. Spec Reference: HR-PAY-04 (Tax Forms Compliance)

Event: hr.employer_tax_liability.calculated

Publisher: HR (Workforce) — HR-PAY-04
Subscribers: FA (Finance) — for GL posting and liability tracking
Payload Schema (Event Schema Standard):
Purpose: Notify FA when employer-side tax liability has been calculated so FA can post to GL (or queue for manual posting until FA automation is ready). Contingency: Until FA is ready to consume this event, GL posting may be manual; document acceptance and link confirmation in HR-PAY-04 plan.

HR-34: Contractor & Contingent Workforce Events

Status: 📝 Planned (Event stubs defined; publishers to be implemented in Phase 4) Publisher: HR (Workforce) — HR-34 Subscribers: PF-10 (Notifications), FW-16 (Workflow automation — optional) Spec Reference: HR-34 Contractor & Contingent Workforce Management Channel: hr_events

Event 1: hr_contractor_created

Publisher: HR (Workforce) — HR-34 Subscribers: PF-10 (Notifications), FW-16 (optional automation triggers) Status: 📝 Planned Payload Schema:
Purpose: Notify downstream systems when a new contractor is onboarded. No tax IDs in payload.

Event 2: hr_contractor_contract_renewal_due

Publisher: HR (Workforce) — HR-34 Subscribers: PF-10 (Notifications — renewal alerts to HR managers) Status: 📝 Planned Payload Schema:
Purpose: Alert HR managers when a contractor contract is approaching its end date. Fired by batch cron or on contract create/update. No tax IDs in payload.

Event 3: hr_contractor_credential_expiring

Publisher: HR (Workforce) — HR-34 Subscribers: PF-10 (Notifications — expiration alerts) Status: 📝 Planned Payload Schema:
Purpose: Alert when a contractor credential is approaching expiration (30/60/90 day thresholds). Aligns with HR-02 credential expiration patterns. No tax IDs in payload.

FA-12: Expense Management Events

Status: ✅ Implemented (Events 1-4 published in code)
Spec Reference: specs/fa/specs/FA-12-expense-management-reimbursements.md

Event 1: fa_expense_report_submitted (canonical)

Publisher: FA (Finance)
Subscribers: FW-03 (Approval Workflow), PF-10 (Notifications)
Status: ✅ Implemented
Payload Schema:
SLA: Delivery < 500ms p95, Processing < 2s p95, 3 retries with exponential backoff Purpose: Trigger approval workflow for expense report
Note: Canonical event name is fa_expense_report_submitted. This is the canonical schema for the event. Previous versions using event_type and simplified fields have been consolidated into this format. Consumers should migrate to use ExpenseReportSubmittedEvent interface fields.

Event 2: fa_expense_report_approved (canonical)

Publisher: FA (Finance)
Subscribers: FA-05 (Payment Processing), PF-10 (Notifications)
Status: ✅ Implemented
Payload Schema:
Purpose: Trigger reimbursement processing
Note: Consumers (FA-05, PF-10) MUST use event_id for deduplication and retry handling. The event_version field enables schema evolution tracking.

Event 3: fa_expense_report_rejected (canonical)

Publisher: FA (Finance)
Subscribers: PF-10 (Notifications)
Status: ✅ Implemented
Payload Schema:
Purpose: Notify employee of rejection
Note: Consumers (PF-10) MUST use event_id for deduplication and retry handling. The event_version field enables schema evolution tracking.

Event 4: fa_reimbursement_processed (canonical)

Publisher: FA (Finance)
Subscribers: FA-02 (GL), PF-10 (Notifications)
Status: ✅ Implemented
Payload Schema:
Purpose: Notify reimbursement completion and trigger GL posting
Note: Consumers (FA-02, PF-10) MUST use event_id for deduplication and retry handling. The event_version field enables schema evolution tracking.

HR-14: Employee Relations Events

Status: ✅ Complete
Implemented: 2026-01-09

Event 1: disciplinary_action_termination

Publisher: HR (Workforce)
Subscribers: HR-03 (Offboarding), PF-10 (Notifications)
Payload Schema:
Purpose: Trigger HR-03 offboarding workflow when disciplinary action results in termination

Event 2: incident_reported

Publisher: HR (Workforce)
Subscribers: GR-06 (Incident Management), PF-10 (Notifications for critical/serious)
Payload Schema:
Purpose: Notify GR-06 incident management system of workplace incidents

Event 3: grievance_filed

Publisher: HR (Workforce)
Subscribers: GR-03 (Compliance)
Payload Schema:
Purpose: Notify compliance team of employee grievances for tracking and resolution

HR-26: E-Verify Integration Events

Status: ✅ Implemented
Publisher: HR-26 (E-Verify orchestrator edge function)
Subscribers: PF-10 (notifications), audit log
Event 1: hr_everify_case_created
Trigger: Successful USCIS case creation via hr-everify-orchestrator
Payload:
Event 2: hr_everify_status_changed
Trigger: Status transition on poll or manual update
Payload:
Event 3: hr_everify_tnc_opened
Trigger: Case enters TNC state
Payload:

Status: ✅ Complete
Implemented: 2026-01-13

Event 1: merit_increase_approved

Publisher: HR (Workforce)
Subscribers: HR-07 (Payroll), FA (Budget tracking), PF-10 (Notifications)
Trigger: hr_merit_increases.status'approved'
Payload Schema:
Purpose: Notify payroll and finance of approved salary changes

Event 2: compensation_analysis_completed

Publisher: HR (Workforce)
Subscribers: FA (Analytics), PF-10 (Notifications)
Trigger: hr_compensation_analyses.status'approved'
Payload Schema:
Purpose: Notify finance of equity analysis results for budgeting decisions

Event 3: compensation_cost_allocated

Publisher: HR (Workforce)
Subscribers: FA (Budget adjustments), FA (Cost forecasting)
Trigger: hr_merit_increases.status'approved'
Payload Schema:
Consumer Actions:
  1. FA creates budget alert for significant cost increases
  2. FA updates departmental expense forecasts
  3. FA may trigger budget amendment workflow if over threshold
Testing: Verify event fires on merit increase approval with correct payload

HR-16: Succession Planning Events

Status: 📝 Planned
Implemented: TBD

Event 1: successor_identified

Publisher: HR (Workforce)
Subscribers: PF-10 (Notifications)
Payload Schema:
Purpose: Notify managers of successor readiness

Event 2: talent_promoted

Publisher: HR (Workforce)
Subscribers: HR-16 (Succession Planning)
Payload Schema:
Purpose: Update succession plans when talent is promoted

HR-17: Employee Engagement Events

Status: 📝 Planned
Implemented: TBD

Event 1: survey_completed

Publisher: HR (Workforce)
Subscribers: PF-10 (Notifications)
Payload Schema:
Purpose: Notify managers of survey completion for tracking participation

Event 2: exit_interview_completed

Publisher: HR (Workforce)
Subscribers: HR-03 (Offboarding)
Payload Schema:
Purpose: Update offboarding workflow when exit interview completed

HR-44: Proliant HCM Integration Events

Status: 📝 Planned
Implemented: TBD
Spec Reference: HR-44 Proliant HCM Integration

Event 1: hr_proliant_sync_completed

Publisher: HR-44 (Proliant HCM Integration)
Subscribers: PF-10 (Notifications), HR-18 (Workforce Analytics refresh)
Channel: hr_events
Payload Schema:
Purpose: Notify downstream systems of sync completion for refresh/alerting. Admins receive PF-10 notification when status is partial or failed, or when conflicts_detected > 2.

Event 2: hr_proliant_conflict_detected

Publisher: HR-44 (Proliant HCM Integration)
Subscribers: PF-10 (admin notification)
Channel: hr_events
Payload Schema:
PHI Safety: No raw field values in the event payload. Consumers fetch conflict detail via authorized UI/RPC lookup (hr_proliant_conflict_logs row, subject to RLS and hr.proliant-integration.resolve-conflicts permission). Purpose: Alert admins when manual conflict resolution is needed. One event per conflict; batching is handled by the consumer edge function.

HR-44 / FA-43: Proliant (ReadyPay) Embedded Payroll-Run Events

Status: 📝 Planned
Implemented: TBD
Spec References: HR-44 Proliant HCM Integration · FA-43 Payroll Journal Entry Auto-Generation
Integration Contract: HR-44-PROLIANT-READYPAY-INTEGRATION.md
Payroll-run-lifecycle events published while Encore drives a Proliant/ReadyPay run (start → preprocess → verify → approve → submit) plus the FA GL handoff after JournalEntry is pulled. These complement the existing hr_proliant_sync_completed / hr_proliant_conflict_detected events (which cover generic sync/conflict). PHI/PII rule (all events below): carry IDs + non-identifying status/aggregates only. No SSN, no per-employee wage detail in payloads — consumers fetch detail via RLS-protected lookups.

Event 1: hr_payroll_run_started

Publisher: HR-44 · Subscribers: PF-10 (notifications), HR payroll-run wizard · Channel: hr_events
Purpose: A run was opened via POST /Payroll/{cal}/start. Drives wizard progress + audit.

Event 2: hr_payroll_run_preprocessed

Publisher: HR-44 · Subscribers: HR payroll-run wizard · Channel: hr_events
Purpose: preprocess produced a preview/pre-calc; wizard renders the preview. Aggregates only.

Event 3: hr_payroll_run_verified

Publisher: HR-44 · Subscribers: HR payroll-run wizard, PF-10 · Channel: hr_events
Purpose: Proliant verify tests (+ Encore-side reconciliation) completed. PF-10 alerts on failure.

Event 4: hr_payroll_run_approved

Publisher: HR-44 · Subscribers: HR payroll-run wizard, PF-10 · Channel: hr_events
Purpose: A batch was approved via approve/{batch}. Audit + wizard advance.

Event 5: hr_payroll_run_submitted

Publisher: HR-44 · Subscribers: FA-43 (GL pull trigger), PF-10, HR-18 (analytics refresh) · Channel: hr_events
Purpose: Emitted by proliant-run-poller once the Proliant JournalEntry is available, fully mapped to Encore fa_account ids, and the run is balanced (debits === credits). PHI-safe: IDs and GL amounts only — no SSN, name, or other PII. FA-43 consumes this event to write the draft fa_journal_entries + fa_journal_entry_lines rows (GL handoff).

Event 6: fa_payroll_je_generated

Publisher: FA-43 · Subscribers: FA-02 (GL posting), FA-13/FA-35 (grant cost allocation), PF-10 · Channel: fa_events
Purpose: Draft GL entries were generated from pulled Proliant JournalEntry (gl1..gl6
  • CostCenter1-5). FA-02 posts them; FA-13/FA-35 consume for grant cost allocation.

FA-02: Vendor Bill Approved Events

Event: vendor_bill_approved
Publisher: FA (Finance & Accounting)
Subscribers: FW-03 (Workflow completion), PF-10 (Notifications), FA-03 (Payment queue)
Status: ✅ Complete
Implemented: 2025-11-26
Payload Schema:
Consumer:
  • supabase/functions/event-consumer/index.ts - Logs to audit trail
  • FW-03 Automation Engine - Completes approval workflow steps
  • PF-10 Notifications - Notifies vendors and accounting team
  • FA-03 Payment Processing - Queues bill for payment
Testing: ✅ Complete - Event fires on bill approval

FA-03: Payment Processed Events

Event: payment_processed
Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL posting), PF-10 (Vendor notification), FA-06 (Bank reconciliation)
Status: ✅ Complete
Implemented: 2025-11-26
Payload Schema:
Consumer:
  • FA-02 Chart of Accounts - Creates GL journal entry for payment
  • PF-10 Notifications - Sends payment confirmation to vendor
  • FA-06 Bank Reconciliation - Marks expected transaction for reconciliation
Testing: ✅ Complete - Event fires on payment creation with bill applications

FA-03: Vendor Activated (domain event)

Registry ID: FA-E-06 (vendor_activated)
Event name: fa.vendor.activated
Version: 1.0.0
Publisher: FA (Finance & Accounting) — vendor master activation (e.g. FA-UX-11 Vendor onboarding wizard)
Status: 📝 Planned
Spec reference (single source of truth): FA-03 Accounts Payable — Event Contracts — FA-E-06 (naming, versioning, payload)
Publish call pattern:
Payload schema (payload object):
Purpose: Notify async consumers (indexing, search, cross-core integrations) after a vendor is activated, without exposing sensitive vendor credentials in the event stream.

FA-22: Accounts Payable Automation Events

Spec Reference: specs/fa/specs/FA-22-accounts-payable-automation.md
Publisher: FA (Finance & Accounting)
Subscribers: FW-16 (Workflow Events – workflow triggers). Subscribers must subscribe to event_type values fa_bill_scan_completed and fa_bill_duplicate_flagged.
Status: 📝 Planned
Channel: fa_events (or equivalent)

fa_bill_scan_completed

Event type: fa_bill_scan_completed
When: After fa-scan-invoice edge function completes and inserts into fa_invoice_scans.
Payload Schema:

fa_bill_duplicate_flagged

Event type: fa_bill_duplicate_flagged
When: After fa-detect-duplicates creates a fa_duplicate_detection_log entry (on bill insert or cron).
Payload Schema:
Integration: FW-16 Event Registry – register event_type values fa_bill_scan_completed and fa_bill_duplicate_flagged so workflow designers can trigger automations (e.g., notify approver when duplicate flagged).

FA-04: Purchase Order Events

Status: ✅ Complete
Implemented: 2026-01-27
Spec Reference: specs/fa/specs/FA-04-purchase-orders.md

FA-E-04: purchase_order_approved

Event: purchase_order_approved
Publisher: FA (Finance & Accounting)
Subscribers: Event Consumer (audit logging), PF-10 (Notifications), FA-11 (Fixed Assets - asset creation from PO)
Status: ✅ Complete
Channel: fa_events
Payload Schema:
Consumer:
  • supabase/functions/event-consumer/index.ts - Logs to audit trail
  • PF-10 Notifications - Notifies purchaser and receiving staff
  • FA-11 Fixed Assets - Creates asset records from PO (when implemented)
Trigger: Database trigger fa_publish_po_approved() fires when PO status changes to ‘approved’ Testing: ✅ Complete - Event fires on PO approval

FA-E-05: goods_received

Event: goods_received
Publisher: FA (Finance & Accounting)
Subscribers: Event Consumer (audit logging), PF-10 (Notifications), FA-11 (Fixed Assets - asset receipt)
Status: ✅ Complete
Channel: fa_events
Payload Schema:
Consumer:
  • supabase/functions/event-consumer/index.ts - Logs to audit trail
  • PF-10 Notifications - Notifies AP staff for bill matching
  • FA-11 Fixed Assets - Updates asset status to “received” (when implemented)
Trigger: Database trigger fa_publish_goods_received() fires on receipt creation Testing: ✅ Complete - Event fires on receipt creation

FA-02: Journal Entry Posted Events

Event: journal_entry_posted
Publisher: FA (Finance & Accounting)
Subscribers: Event Consumer (audit logging), FA-07 (Balance refresh), PF-10 (Notifications)
Status: ✅ Complete
Implemented: 2025-11-26
Payload Schema:
Consumer:
  • Event Consumer - Logs all posted journal entries to audit trail
  • FA-07 Financial Reporting - Refreshes account balances and financial statements
  • PF-10 Notifications - Alerts accounting team of significant postings
Testing: ✅ Complete - Event fires on journal entry posting with all line details

FA-08: Budget Approved Events

Event: budget_approved
Publisher: FA (Finance & Accounting)
Subscribers: FW-03 (Workflow completion), PF-10 (Notifications), FA-07 (Reporting)
Status: ✅ Complete
Implemented: 2025-11-26
Payload Schema:
Consumer:
  • FW-03 Automation Engine - Completes approval workflow
  • PF-10 Notifications - Notifies budget owners and finance team
  • FA-07 Financial Reporting - Enables budget vs. actual reporting
Testing: ✅ Complete - Event fires on budget approval

FA-08: Budget Exceeded Events

Event: budget_exceeded
Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications to budget owners), FA-08 (Alert log)
Status: ✅ Complete
Implemented: 2025-11-26
Payload Schema:
Consumer:
  • PF-10 Notifications - Sends alerts to budget owners and finance managers
  • FA-08 Budget Management - Logs alert and tracks budget compliance
Testing: ✅ Complete - Event fires when budget threshold exceeded

FA-09: Consolidation Completed Events

Event: consolidation_completed
Publisher: FA (Finance & Accounting)
Subscribers: FA-07 (Consolidated reports), PF-10 (Notifications), Event Consumer (audit)
Status: ✅ Complete
Implemented: 2025-11-26
Payload Schema:
Consumer:
  • FA-07 Financial Reporting - Generates consolidated financial statements
  • PF-10 Notifications - Alerts management of completed consolidation
  • Event Consumer - Logs consolidation completion to audit trail
Testing: ✅ Complete - Event fires on consolidation run completion

PM-05: Provider Time-Off Events

Owning Core: PM (Practice Management)
Spec: PM-05 Provider Schedule & Availability
Integration: PM-05-provider-schedule-availability-INTEGRATION.md
Status: ✅ Implemented (2026-02-20) — declared in INTEGRATION doc; canonical schemas registered here on 2026-05-04 during PM-05 pre-verification.
All three events use canonical naming pm_{entity}_{action} and carry IDs only — no PHI. Subscribers must dereference IDs through PM RLS-protected reads.

pm_time_off_requested

Publisher: PM-05 (on insert into pm_provider_time_off with status = 'pending')
Subscribers: PF-10 Notifications (notify approver), FW (workflow triggers), Event Consumer (audit)
Schema version: 1

pm_time_off_approved

Publisher: PM-05 (on update to pm_provider_time_off.status = 'approved')
Subscribers: PM-03 (refresh availability), PM-04 (refresh facilitator availability), PF-10 (notify provider + coverage), HR-04 (display only — no shared tables), Event Consumer (audit)
Schema version: 1

pm_time_off_denied

Publisher: PM-05 (on update to pm_provider_time_off.status = 'denied')
Subscribers: PF-10 (notify requester), Event Consumer (audit)
Schema version: 1
PHI safety: None of the three payloads contain patient data. time_off_type is workforce metadata, not clinical PHI.
Idempotency: Subscribers SHOULD treat time_off_id as the idempotency key.
Registration TODO: Verify these three events are seeded in fw_workflow_events (producer=pm). If absent, add a follow-up migration; if the shipped PM-05 hooks do not currently call publishEvent, this section documents the contract for the upcoming wiring.

CL-57: Clinical Content Marketplace Events

cl_marketplace_bundle_imported

Publisher: CL-57 (cl-marketplace-import Edge Function on successful import) Subscribers: Event Consumer (audit), future content-distribution analytics Status: ✅ Implemented Schema version: 1
PHI safety: Marketplace content is platform-curated reference data (no patient identifiers). All payload fields are tenant + bundle metadata only. Publishing semantics: Event publishes only after the import transaction has been materialized for the tenant (cl_marketplace_imports marked completed and import outputs persisted). Publisher authorization for curator actions is gated by cl_can_curate_marketplace() per CL-57. Idempotency: event_id is the canonical deduplication key for cross-retry processing (Event Schema Standard). import_id remains the domain-specific idempotency key for marketplace import workflows and subscriber reconciliation. Retry semantics: Fire-and-forget from the import flow. A publish failure does NOT roll back the import (the per-org rows are already materialized and survive event-bus outages). Versioning/consumers: Consumers should branch on schema_version; current consumers are audit/event-observability pipelines, with downstream analytics consumers planned. Spec reference: CL-57 Clinical Content Marketplace

CL-31: Co-Occurring Disorder Integrated Documentation — No Events Published

Status: ⚪ Not Applicable (intentional) Publisher: None (CL-31 is an intra-CL extension) Subscribers: None CL-31 (Co-Occurring Disorder Integrated Documentation) extends CL-02 (assessments), CL-03 (treatment plans), and CL-04 (progress notes) in-place and does not publish any domain events in Phase 1 or Phase 2. Rationale:
  • 42 CFR Part 2 SUD redaction is enforced at request time via cl_check_sud_consent() and redactSUDFields() in @/platform/clinical, not via async event consumers.
  • All COD integration with downstream cores (PM billing, CL-15 quality measures) flows through existing CL-02/CL-03/CL-04 events; no new event surface is introduced.
  • ASAM COD level is informational only; no PM service-authorization event coupling (Clarification #12).
If a future phase introduces a domain event (e.g., cl_cod_assessment_completed for CL-15 quality reporting), it MUST be added here with full schema, PHI-safety review, and a CONTEXT.md decision record. Spec reference: CL-31 Co-Occurring Disorder Integrated Documentation

Planned Events (LO-14/15 Action Dependencies & Status)

LO-14: Action Unblocked Event

Event: action_unblocked
Publisher: LO (Leadership Operating System)
Subscribers: PF-10 (Notifications), Event Consumer (audit logging)
Status: 📝 Planned
Spec Reference: LO-14 Action Dependencies
Purpose: Notify when a dependency action completes, enabling dependent actions to proceed. Payload Schema:
Consumer Actions:
  • Event Consumer: Log to pf_audit_logs for audit trail
  • PF-10 Notifications (Future): Send notification to action assignee
Implementation (Planned):

LO-15: Action Status Changed Event

Event: action_status_changed
Publisher: LO (Leadership Operating System)
Subscribers: PF-10 (Notifications), Event Consumer (audit logging)
Status: 📝 Planned
Spec Reference: LO-15 Enhanced Action Status
Purpose: Notify when an action’s status changes, enabling audit logging and status-based notifications. Payload Schema:
Consumer Actions:
  • Event Consumer: Log to pf_audit_logs for audit trail
  • PF-10 Notifications (Future): Send notifications based on status:
    • needs_review → Notify reviewer/goal owner
    • blocked → Notify assignee and goal owner
    • complete → Notify goal owner
Implementation (Planned):

Planned Events (FW-22 Execution Monitoring)

FW-22: Workflow Execution Failed Event

Event: execution_failed
Publisher: FW (Forms & Workflow)
Subscribers: PF-10 (Notifications), FW-22 (Monitoring Dashboard)
Status: 📝 Planned (FW-22 Implementation)
Spec Reference: FW-22 Workflow Execution Monitoring & Debugging
Purpose: Notify when a workflow execution fails, enabling alerts and monitoring dashboard updates. Payload Schema:
Consumer Actions:
  • PF-10 Notifications: Send alert to workflow owner and org admins
  • FW-22 Dashboard: Update failed execution count, trigger refresh
Implementation (Planned):

Planned Events (FW-32 External Form Portal)

FW-16-P2: Event Schema Updated

Event: fw_event_schema_updated
Publisher: FW (Forms & Workflow)
Subscribers: FW (Event Registry UI), Monitoring
Status: ✅ Implemented (FW-16-P2)
Channel: fw_events

FW-16-P2: Event Deprecated

Event: fw_event_deprecated
Publisher: FW (Forms & Workflow)
Subscribers: FW (Event Registry UI), Monitoring
Status: ✅ Implemented (FW-16-P2)
Channel: fw_events

FW-32: External Form Submission Event

Event: fw_external_form_submitted
Publisher: FW (Forms & Workflow)
Subscribers: PF-10 (Notifications), FW-03 (Automation Engine)
Status: ✅ Implemented (FW-32 — published by portal-form-submit edge function via pg_notify)
Spec Reference: FW-32 External Form Portal
Purpose: Notify when a form is submitted via the external portal, trigger notifications and workflow automations. Payload Schema:
Consumer Actions:
  • PF-10 Notifications: Send confirmation email to submitter
  • FW-03 Automation Engine: Trigger any workflow automations configured for external form submissions
Implementation (Planned):

Planned Events (FW-34 Approval Workflows)

FW-34: Approval Request Submitted Event

Event: fw_approval_submitted
Publisher: FW (Forms & Workflow)
Subscribers: PF-10 (Notifications), FW-03 (Automation Engine)
Status: 📝 Planned (FW-34 Implementation)
Spec Reference: FW-34 Approval Workflows
Purpose: Notify when a new approval request is submitted, trigger notifications to approvers. Payload Schema:
Consumer Actions:
  • PF-10 Notifications: Send notification to assigned approvers
  • FW-03 Automation Engine: Trigger any related automations
Implementation (Planned):

FW-34: Approval Request Completed Event

Event: fw_approval_completed
Publisher: FW (Forms & Workflow)
Subscribers: FW-03 (Automation Engine), PF-10 (Notifications)
Status: 📝 Planned (FW-34 Implementation)
Spec Reference: FW-34 Approval Workflows
Purpose: Notify when an approval request is completed (approved or rejected). Payload Schema:
Consumer Actions:
  • FW-03 Automation Engine: Trigger post-approval automations (e.g., update entity status)
  • PF-10 Notifications: Notify submitter of decision
Implementation (Planned):

FW-34: Approval Escalated Event

Event: fw_approval_escalated
Publisher: FW (Forms & Workflow)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned (FW-34 Implementation)
Spec Reference: FW-34 Approval Workflows
Purpose: Notify when an approval is escalated due to timeout. Payload Schema:
Consumer Actions:
  • PF-10 Notifications: Notify escalation target and original approver

Planned Events (FW-33 Form Signature Capture)

FW-33: Form Signature Captured Event

Event: fw_form_signature_captured
Publisher: FW (Forms & Workflow)
Subscribers: FW-03 (Automation Engine), PF-10 (Notifications)
Status: 📝 Planned (FW-33 Implementation)
Spec Reference: FW-33 Form Signature Capture
Purpose: Notify when a signature is captured on a form field, trigger automations and notifications. Payload Schema:
Consumer Actions:
  • FW-03 Automation Engine: Trigger signature-based workflow automations
  • PF-10 Notifications: Send confirmation to signer

FW-33: Signed Document Generated Event

Event: fw_signed_document_generated
Publisher: FW (Forms & Workflow)
Subscribers: PF-11 (Documents)
Status: 📝 Planned (FW-33 Implementation)
Spec Reference: FW-33 Form Signature Capture
Purpose: Notify when a signed PDF document is generated from a form submission. Payload Schema:
Consumer Actions:
  • PF-11 Documents: Link document to submission, update document metadata

Planned Events (FW-16 Event Registry)

The following events are planned for registration in fw_workflow_events as part of FW-16 (Event-Based Workflow Triggers):

HR Core Events (Planned)

HR-01 canonical events (confirmed 2026-04-28): hr_employee_created, hr_employee_assigned_to_site, and hr_employee_terminated are published by HR-01 — see HR-01 Integration §Events for full payload schemas. hr_employee_hired is treated as a synonym/legacy alias of hr_employee_created for downstream consumers (FW-16 registry retains both names during transition; new subscribers SHOULD prefer hr_employee_created). Subscribers include PF-101 (Google Workspace provisioning/offboarding), HR-30 (final paycheck on termination), and FW-16 workflow triggers.

PF-101: Google Workspace Integration (planned detail)

Spec: PF-101 Integration: PF-101 Integration Consumes:
  • hr_employee_created (HR-01) — provision or link a Google Workspace user when tenant policy enables provisioning. Payload: organization_id, employee_id, profile_id, department_id, position_id, hire_date, correlation_id, timestamp.
  • hr_employee_assigned_to_site (HR-01) — reconcile site-based group, OU, Drive, Calendar resource, or Chat mappings. Payload: organization_id, employee_id, site_id, assignment_date, role, correlation_id, timestamp.
  • hr_employee_terminated (HR-01) — suspend/offboard linked Workspace user, revoke licenses, remove groups, queue Drive transfer review. Payload: organization_id, employee_id, termination_date, termination_reason, correlation_id, timestamp.
Publishes:
  • pf_google_workspace_user_provisioned — subscribers PF-10, HR status consumers; payload: organization_id, employee_id, profile_id, google_user_id, correlation_id, timestamp. Signals successful Workspace user provisioning without exposing secrets or PHI. Subscribers requiring email must perform scoped lookups using google_user_id or profile_id.
  • pf_google_workspace_connector_degraded — subscribers PF-10, PF-36; payload: organization_id, connection_id, capability (directory|gmail|calendar|drive|chat|licensing|reports), reason_code (sanitized machine code), correlation_id, timestamp. Alerts admins when credential, scope, quota, BAA gate, or sync health degrades.
See PF-101 Integration §Event Contracts for full payload schemas, BAA/PHI-gating rules, and idempotency semantics (events keyed by event_id as the canonical deduplication key; correlation_id is used only for trace/linkage).

HR-28: Fingerprint Clearance Card Management (planned detail)

Spec: HR-28
Publishes:
  • hr_fingerprint_clearance_status_changed — notify HR-02, HR-03 gates when clearance moves between blocking/non-blocking states; payload: organization_id, employee_id, clearance_id, previous_status, new_status, effective_at.
  • hr_fingerprint_clearance_expiration_warning — scheduled worker fires at 90/60/30-day thresholds; subscriber PF-10; payload: organization_id, employee_id, clearance_id, days_until_expiration, expiration_date.
See HR-28 Integration for full payload schemas.

HR-29: FLSA Classification & Compliance Engine (planned detail)

Spec: HR-29 Publishes:
  • hr_flsa_classification_changed — subscribers HR-07 (Payroll), HR-01 (Employee Directory); payload: classification_id, position_id, employee_id, previous_classification, new_classification, effective_date, retroactive_start_date, retroactive_pay_request_id, organization_id.
  • hr_flsa_reclassification_approved — subscribers HR-07 (Payroll); payload: reclassification_id, employee_id, new_classification, effective_date, retroactive_start_date, retroactive_pay_request_id, organization_id.
See HR-29 Integration for full payload schemas and data flow.

HR-30: Final paycheck (planned detail)

Spec: HR-30
Consumes: hr_employee_terminated (HR-03) — create hr_final_paycheck_requests.
May publish: hr_final_paycheck_status_changed — subscribers PF-10, HR-07 (Phase 2); payload stub in HR-30 Integration.

RH Core Events (Planned)

FA Core Events (Planned)

Implementation: See FW-16 Event-Based Workflow Triggers for full specification.

FA-10: Tax Reporting Events

Status: 📝 Planned
Spec Reference: FA-10 (Tax Reporting & Compliance)

Event 1: tax_1099_generated

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

Event 2: tax_w2_generated

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), HR-07
Payload Schema:

Event 3: tax_year_closed

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-07
Payload Schema:

FA-11: Fixed Assets Events

Status: 📝 Planned
Spec Reference: FA-11 (Fixed Assets & Depreciation)

Event 1: asset_created

Publisher: FA (Finance & Accounting)
Subscribers: FM-05 (Facilities), PF-10 (Notifications)
Payload Schema:

Event 2: asset_disposed

Publisher: FA (Finance & Accounting)
Subscribers: FM-05 (Facilities), PF-10 (Notifications), FA-02 (GL)
Payload Schema:

Event 3: depreciation_posted

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), FA-07 (Financial Reporting)
Payload Schema:

FA-12: Expense Management Events

Status: 📝 Planned
Spec Reference: FA-12 (Expense Management & Reimbursements)
Note: The canonical schema for FA-12 events is defined in the FA-12 section above (lines 484-582). This duplicate section has been removed. Please refer to the ExpenseReportSubmittedEvent interface and other event definitions in that section for the authoritative payload formats.

FA-13: Project Accounting Events

Status: 📝 Planned
Spec Reference: FA-13 (Project Accounting & Grant Tracking)

Event 1: project_created

Publisher: FA (Finance & Accounting)
Subscribers: FA-08 (Budgeting), PF-10 (Notifications)
Payload Schema:

Event 2: project_budget_exceeded

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-08 (Budgeting)
Payload Schema:

Event 3: grant_drawdown_received

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), PF-10 (Notifications)
Payload Schema:

FA-14: Cash Management Events

Status: 📝 Planned
Spec Reference: FA-14 (Cash Management & Treasury)

Event 1: cash_position_updated

Publisher: FA (Finance & Accounting)
Subscribers: FA-07 (Financial Reporting), PF-10 (Notifications)
Payload Schema:

Event 2: investment_maturity_approaching

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

Event 3: credit_limit_approaching

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

FA-15: Cost Allocation Events

Status: 📝 Planned
Spec Reference: FA-15 (Cost Allocation & Indirect Cost Rates)

Event 1: idc_rate_calculated

Publisher: FA (Finance & Accounting)
Subscribers: FA-13 (Project Accounting), PF-10 (Notifications)
Payload Schema:

Event 2: idc_allocated

Publisher: FA (Finance & Accounting)
Subscribers: FA-13 (Project Accounting), FA-02 (GL)
Payload Schema:

FA-16: Financial Analytics Events

Status: 📝 Planned
Spec Reference: FA-16 (Financial Analytics & Dashboards)

Event 1: kpi_threshold_exceeded

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

FA-17: Intercompany Events

Status: 📝 Planned
Spec Reference: FA-17 (Intercompany Transactions)

Event 1: intercompany_transaction_created

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), FA-09 (Consolidation)
Payload Schema:

Event 2: intercompany_elimination_generated

Publisher: FA (Finance & Accounting)
Subscribers: FA-09 (Consolidation), FA-02 (GL)
Payload Schema:

FA-19: Financial Close Events

Status: 📝 Planned
Spec Reference: FA-19 (Financial Close Management)

Event 1: close_period_started

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-02 (GL)
Payload Schema:

Event 2: close_period_completed

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-07 (Financial Reporting)
Payload Schema:

Event 3: close_task_assigned

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

FA-10: Tax Reporting Events

Status: 📝 Planned
Spec Reference: FA-10 (Tax Reporting & Compliance)

Event 1: tax_1099_generated

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

Event 2: tax_w2_generated

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), HR-07
Payload Schema:

Event 3: tax_year_closed

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-07
Payload Schema:

FA-11: Fixed Assets Events

Status: 📝 Planned
Spec Reference: FA-11 (Fixed Assets & Depreciation)

Event 1: asset_created

Publisher: FA (Finance & Accounting)
Subscribers: FM-05 (Facilities), PF-10 (Notifications)
Payload Schema:

Event 2: asset_disposed

Publisher: FA (Finance & Accounting)
Subscribers: FM-05 (Facilities), PF-10 (Notifications), FA-02 (GL)
Payload Schema:

Event 3: depreciation_posted

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), FA-07 (Financial Reporting)
Payload Schema:

FA-12: Expense Management Events

Status: 📝 Planned
Spec Reference: FA-12 (Expense Management & Reimbursements)
Note: The canonical schema for FA-12 events is defined in the FA-12 section above (lines 484-582). This duplicate section has been removed. Please refer to the ExpenseReportSubmittedEvent interface and other event definitions in that section for the authoritative payload formats.

FA-13: Project Accounting Events

Status: 📝 Planned
Spec Reference: FA-13 (Project Accounting & Grant Tracking)

Event 1: project_created

Publisher: FA (Finance & Accounting)
Subscribers: FA-08 (Budgeting), PF-10 (Notifications)
Payload Schema:

Event 2: project_budget_exceeded

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-08 (Budgeting)
Payload Schema:

Event 3: grant_drawdown_received

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), PF-10 (Notifications)
Payload Schema:

FA-14: Cash Management Events

Status: 📝 Planned
Spec Reference: FA-14 (Cash Management & Treasury)

Event 1: cash_position_updated

Publisher: FA (Finance & Accounting)
Subscribers: FA-07 (Financial Reporting), PF-10 (Notifications)
Payload Schema:

Event 2: investment_maturity_approaching

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

Event 3: credit_limit_approaching

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

FA-15: Cost Allocation Events

Status: 📝 Planned
Spec Reference: FA-15 (Cost Allocation & Indirect Cost Rates)

Event 1: idc_rate_calculated

Publisher: FA (Finance & Accounting)
Subscribers: FA-13 (Project Accounting), PF-10 (Notifications)
Payload Schema:

Event 2: idc_allocated

Publisher: FA (Finance & Accounting)
Subscribers: FA-13 (Project Accounting), FA-02 (GL)
Payload Schema:

FA-16: Financial Analytics Events

Status: 📝 Planned
Spec Reference: FA-16 (Financial Analytics & Dashboards)

Event 1: kpi_threshold_exceeded

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

FA-17: Intercompany Events

Status: 📝 Planned
Spec Reference: FA-17 (Intercompany Transactions)

Event 1: intercompany_transaction_created

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), FA-09 (Consolidation)
Payload Schema:

Event 2: intercompany_elimination_generated

Publisher: FA (Finance & Accounting)
Subscribers: FA-09 (Consolidation), FA-02 (GL)
Payload Schema:

FA-18: Revenue Recognition Events

Status: ✅ Implemented (FA-18 Phase 2 WS3, 2026-04-25)
Spec Reference: FA-18 (Revenue Recognition Advanced)

Event 1: fa_revenue_recognized

Publisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL), FA-05 (AR), FA-13 (Projects)
Payload Schema:
Notes: Published atomically with the fa_revenue_recognitions insert by fa_process_revenue_recognition (writes to fw_domain_events). journal_entry_* populated only when both revenue & deferred accounts resolve (schedule → contract → module defaults). auto_posted reflects fa_module_settings.auto_post_revenue_recognition. Canonical narrative: FA-18-revenue-recognition-advanced-INTEGRATION.md.

Event 2: fa_revenue_schedule_completed

Publisher: FA (Finance & Accounting)
Subscribers: FA-05 (AR), FA-13 (Projects), LO (Leadership OS metrics)
Payload Schema:
Notes: Emitted in the same transaction as the recognition that drives the schedule’s running total to within tolerance of total_revenue_amount. Tolerance comes from fa_module_settings.revenue_recognition_sum_tolerance (default 0.01).

FA-19: Financial Close Events

Status: 📝 Planned
Spec Reference: FA-19 (Financial Close Management)

Event 1: close_period_started

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-02 (GL)
Payload Schema:

Event 2: close_period_completed

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications), FA-07 (Financial Reporting)
Payload Schema:

Event 3: close_task_assigned

Publisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications)
Payload Schema:

LO Core: Leadership Operating System Events

LO-01: Vision & Strategic Planning Events

Event: rock_completed Publisher: LO (Leadership Operating System) Subscribers: FA (Finance - financial goals), PF-10 (Notifications), PF-04 (Audit) Status: ✅ Complete
Implemented: 2025-12-03
Payload Schema:
Purpose: Notify when Rock is completed (may trigger financial goals)

LO-04: To-Dos & Task Management Events

Event 1: todo_created
Publisher: LO (Leadership Operating System)
Subscribers: PF-10 (Notifications)
Status: ✅ Complete
Implemented: 2025-12-03
Payload Schema:
Event 2: todo_completed
Status: ✅ Complete
Implemented: 2025-12-03
Payload Schema:
Event 3: todo_overdue
Status: ✅ Complete
Implemented: 2025-12-03
Payload Schema:

LO-05: Scorecards & KPI Tracking Events

Event 1: scorecard_updated
Status: ✅ Complete
Implemented: 2025-12-03
Event 2: metric_threshold_breached
Status: ✅ Complete
Implemented: 2025-12-03

LO-06: Structured Meetings Events

Event 1: meeting_scheduled
Status: ✅ Complete
Implemented: 2025-12-03
Event 2: meeting_completed
Status: ✅ Complete
Implemented: 2025-12-03
Event 3: action_item_created
Status: ✅ Complete
Implemented: 2025-12-03

LO-07: Issues & Problem Solving Events

Event 1: issue_identified
Status: ✅ Complete
Event 2: issue_resolved
Status: ✅ Complete

LO-09: Assessments & Surveys Events

Event 1: assessment_distributed
Status: ✅ Complete
Implemented: 2025-12-03
Event 2: assessment_completed
Status: ✅ Complete
Implemented: 2025-12-03

Planned Events

RH-01: Resident Admission Events

Event (canonical): rh_resident_admitted
Deprecated alias: resident_admitted (do not use in new code) Publisher: RH (Recovery Housing) Subscribers: FA (Finance & Revenue), PM (POS derivation for charge capture) Persistence: fw_domain_events (SECURITY DEFINER trigger on rh_episodes) Status: 🟡 Implemented (DB persistence); FA/PM batch consumers 📋 Planned Spec Reference: RH-01 Census, Beds & Episodes · RH-01.1 Bed Board & Facility Types Integration Doc: RH-01-bed-board-census-INTEGRATION.md
Payload Schema:
Purpose: FA Core creates billing account and sets up recurring invoice schedule. PM uses facility_type to derive POS for charge capture (PM-07). user_id captures the staff member who performed the admission for audit and accountability. Consumer implementation note: FA should follow the fa-consume-pm-payment-events batch pattern (read fw_domain_events, idempotency log per event id) — dedicated fa-consume-rh-episode-events function 📋 Planned until FA episode AR schema is finalized.

RH-01: Resident Discharge Events

Event (canonical): rh_resident_discharged
Deprecated alias: resident_discharged Publisher: RH (Recovery Housing) Subscribers: FA (Finance & Revenue), PM (census/bed-day billing finalization) Persistence: fw_domain_events (trigger on rh_episodes) Status: 🟡 Implemented (DB persistence); FA/PM batch consumers 📋 Planned Spec Reference: RH-01 Census, Beds & Episodes · RH-01.1 Bed Board & Facility Types Integration Doc: RH-01-bed-board-census-INTEGRATION.md
Payload Schema:
Purpose: FA Core finalizes billing and closes billing account. PM uses facility_type and actual_length_of_stay_days for bed-day billing reconciliation. user_id captures the staff member who performed the discharge for audit and accountability.

RH-01: Bed Assignment Events

Event (target canonical): rh_bed_assigned
Deprecated alias: bed_assigned
Publisher: RH (Recovery Housing) Subscribers: HR (workload/census update) Persistence: ✅ Now in KnownEventName — trigger when HR consumer is scheduled Status: 📝 Planned (RH-01.1 Implementation) Spec Reference: RH-01.1 Bed Board & Facility Types Integration Doc: RH-01-bed-board-census-INTEGRATION.md
Payload Schema:
Purpose: HR updates workload/staffing census when a bed is assigned. user_id captures the staff member who performed the assignment for audit and accountability.

RH-01: Bed Released Events

Event (target canonical): rh_bed_released
Deprecated alias: bed_released Publisher: RH (Recovery Housing) Subscribers: HR (workload/census update) Persistence: ✅ Now in KnownEventName Status: 📝 Planned (RH-01.1 Implementation) Spec Reference: RH-01.1 Bed Board & Facility Types Integration Doc: RH-01-bed-board-census-INTEGRATION.md
Payload Schema:
Purpose: HR updates workload/staffing census when a bed is released after discharge. user_id captures the staff member who performed the release for audit and accountability.

RH-01: Invoice Creation Requested Events

Event (canonical): rh_invoice_creation_requested
Legacy alias (deprecated): invoice_creation_requested — maintained for backward compatibility but should migrate to canonical name
Publisher: RH (Recovery Housing) Subscribers: FA (Finance & Revenue) Channel: rh_events Status: 📝 Planned (RH-01 Implementation) Spec Reference: RH-01 Census, Beds & Episodes Integration Doc: RH-01-bed-board-census-INTEGRATION.md
Payload Schema:
Purpose: FA creates the first invoice based on the resident agreement payment terms. facility_type helps FA tag invoices by service line for financial reporting. user_id is present when a staff member manually triggers invoice creation; omitted when auto-generated by the billing schedule.

RH-03: Critical Incident Events

Event 1 (canonical): rh_critical_significant_event_reported
Legacy alias (deprecated): critical_significant_event_reported
Publisher: RH (RH-03 Safety Events & Compliance)
Subscribers: PF-10 (notifications)
Channel: rh_events
Status: 📝 Planned
Spec Reference: RH-03 Safety Events & Compliance
Integration Doc: RH-03-safety-events-compliance-INTEGRATION.md
Payload Schema:
Event 2 (canonical): rh_significant_event_investigation_completed
Legacy alias (deprecated): significant_event_investigation_completed
Publisher: RH (RH-03 Safety Events & Compliance)
Subscribers: PF-10, RH compliance/reporting consumers
Channel: rh_events
Status: 📝 Planned
Spec Reference: RH-03 Safety Events & Compliance
Integration Doc: RH-03-safety-events-compliance-INTEGRATION.md
Payload Schema:
Event 3 (canonical): rh_uds_test_positive
Legacy alias (deprecated): uds_test_positive
Publisher: RH (RH-03 Safety Events & Compliance)
Subscribers: RH-03 relapse/event workflows, PF-10 notifications
Channel: rh_events
Status: 📝 Planned
Spec Reference: RH-03 Safety Events & Compliance
Integration Doc: RH-03-safety-events-compliance-INTEGRATION.md
Payload Schema (consent-safe identifier-only):
Part 2 / consent handling: Subscribers MUST NOT expect substances or narrative test detail in this payload. Consumers must perform an RH-controlled, consent-gated read (RH-04 EN-4) before retrieving UDS result details.

RH-04: Resident Billing Events

Event: resident_charge_created
Publisher: RH (Recovery Housing)
Subscribers: FA-05 (Accounts Receivable)
Status: 📝 Planned (RH-04 Implementation)
Spec Reference: FA-05: Accounts Receivable & Revenue Recognition
Payload Schema:
Purpose: FA-05 auto-generates invoices from resident charges. When RH-04 publishes this event, FA-05 creates an invoice for the resident’s linked customer record, posts it to GL, and links the invoice to the source charge for traceability. Consumer Actions:
  1. FA-05 looks up resident → customer mapping
  2. Creates invoice with charge as line item
  3. Sets invoice status to “sent” and auto-posts to GL (DR AR, CR Revenue)
  4. Links invoice to source charge via fa_invoices.source_charge_id
  5. Sends notification to billing coordinator (PF-10)
Implementation Notes:
  • Event contract defined in FA-05 spec (Section 9: Integration Points)
  • Database schema ready: fa_invoices.source_charge_id column exists
  • Event consumer implementation pending RH-04 completion
  • Batch processing support for 100+ charges/day
  • CRITICAL: The database trigger that emits this event MUST capture the creating user’s ID from the session/context (e.g., using auth.uid() or current_setting('request.jwt.claims', true)::json->>'sub') and populate the user_id field in the emitted event payload. This ensures the audit trail is preserved and traceable to the specific user who created the charge.

RH-06: Compliance Events

Event 1: compliance_deadline_approaching
Publisher: RH (Recovery Housing)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Spec Reference: RH-06 (Compliance Tracking & Staff Operations)
Payload Schema:
Purpose: Send compliance deadline reminders 7 days before due date Event 2: non_compliance_detected
Publisher: RH (Recovery Housing)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Payload Schema:
Purpose: Alert management to non-compliance issues

FA-01: Payment Received Events

Event: payment_received
Publisher: FA (Finance & Revenue)
Subscribers: RH (Recovery Housing)
Status: 📝 Planned (FA-01 Implementation)
Payload Schema:
Purpose: RH Core updates cached payment status based on received payments

HR-01: Employee Assignment Events

Event: employee_assigned_to_site Publisher: HR (Workforce) Subscribers: RH (Recovery Housing) Channel: hr_events Status: 📝 Planned (RH-06 Implementation, Q2 2026) Payload Schema:
Purpose: RH Core receives notifications when staff are assigned to recovery housing sites

HR-01: Employee Created Events

Event: employee_created Publisher: HR (Workforce) Subscribers: GR (Governance & Risk) Channel: hr_events Status: 📝 Planned (Q2 2026) Payload Schema:
Purpose: GR Core assigns default policies and training requirements to new employees

LO-01: Vision & Strategic Planning Events (Planned)

Event: vision_updated
Status: 📝 Planned (LO-01 Implementation)
Event: strategic_goal_created
Status: 📝 Planned (LO-01 Implementation)
Event: rock_created
Status: 📝 Planned (LO-01 Implementation)

LO-02: Accountability Chart Events (Planned)

Event: role_assigned
Status: 📝 Planned (LO-02 Implementation)
Event: accountability_chart_updated
Status: 📝 Planned (LO-02 Implementation)

LO-08: Feedback & 1-on-1s Events (Planned)

Event: one_on_one_scheduled
Status: 📝 Planned (LO-08 Implementation)
Event: feedback_submitted
Status: 📝 Planned (LO-08 Implementation)

LO-10: Knowledge Portal Events (Planned)

Event: knowledge_article_created
Status: 📝 Planned (LO-10 Implementation)
Event: process_updated
Status: 📝 Planned (LO-10 Implementation)

LO-16: Goals & Actions Event Integration (Planned)

Event: goal_created
Publisher: LO (Leadership Operating System)
Subscribers: FA (budget planning), GR (compliance), FW (workflow linking)
Status: 📝 Planned (LO-16 Implementation)
Payload Schema:
Event: goal_completed
Publisher: LO
Subscribers: RH (program metrics), FA (financial tracking), GR (compliance tracking)
Status: 📝 Planned (LO-16 Implementation)
Payload Schema:
Event: action_assigned
Publisher: LO
Subscribers: HR (employee development), PF-10 (notifications)
Status: 📝 Planned (LO-16 Implementation)
Payload Schema:
Event: action_completed
Publisher: LO
Subscribers: LO-14 (unblock dependencies), PF-10 (notifications)
Status: 📝 Planned (LO-16 Implementation)
Payload Schema:
Implementation:
  • Events published via lo_events channel (pg_notify)
  • Database triggers on lo_quarterly_rocks and lo_rock_milestones
  • Events logged to pf_audit_logs for audit trail
  • Consumer examples provided for RH, FA, GR, FW modules
Related Spec: specs/lo/LO-16-goals-event-integration.md

Planned Events (GR Core)

GR-01: Policy Management Events

Event 1: policy_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-02 (Training assignments), GR-03 (Compliance evidence)
Status: 📝 Planned (GR-01 Implementation)
Spec Reference: GR-01 Policy Management
Payload Schema:
Event 2: policy_acknowledged
Publisher: GR (Governance & Compliance)
Subscribers: GR-02 (Training compliance), GR-03 (Compliance tracking)
Status: 📝 Planned (GR-01 Implementation)
Payload Schema:

GR-02: Training & CEU Tracking Events

Event: training_completed Publisher: GR (Governance & Compliance) Subscribers: GR-03 (Compliance evidence), HR-02 (Credentialing) Status: ✅ Implemented (GR-02-EN-01, 2026-05-01) Spec Reference: GR-02 Training & CEU Tracking Channel / Transport: gr_events (pg_notify) + direct HTTP fan-out via pg_net (see “Delivery bridge” below) Trigger: gr_on_training_completed (AFTER INSERT on gr_training_completions) → public.gr_publish_training_completed() (SECURITY DEFINER) Consumers (HTTP):
  • hr-training-credential-refresh — recomputes ce_hours_completed on employee credentials
  • gr-evidence-from-training — inserts deduplicated gr_compliance_evidence rows for linked requirements
Delivery bridge (2026-05-01): After publishing to pg_notify('gr_events', ...) the trigger calls public.gr_dispatch_training_event('training_completed', payload) (SECURITY DEFINER, service_role-only EXECUTE). The dispatcher reads project_url and service_role_key from vault.decrypted_secrets and issues two net.http_post calls — one to /functions/v1/gr-evidence-from-training and one to /functions/v1/hr-training-credential-refresh — with X-Correlation-Id propagated from the publisher’s correlation ID. Each HTTP call is wrapped in its own BEGIN…EXCEPTION block and any failure is logged with RAISE WARNING so dispatcher errors never block the originating INSERT. The pg_notify channel is preserved for back-compat and unit-test contracts. Migration: supabase/migrations/20260501114741_*.sql. Idempotency: Consumers rely on partial unique index gr_compliance_evidence_org_req_src_uq on (organization_id, requirement_id, source_reference) so retried deliveries are safe. PHI/PII: Payload contains identifiers and aggregate CEU credit only — no patient data, no employee names, no certificate content. Payload Schema:

Event: enrollment_overdue Publisher: GR (Governance & Compliance) Subscribers: GR-03 (Compliance evidence / status), HR-02 (Credentialing risk), PF notifications Status: ✅ Implemented (GR-02-EN-01, 2026-05-01) Spec Reference: GR-02-EN-01 Training Events Channel / Transport: gr_events (pg_notify) + HTTP dispatcher placeholder via pg_net Trigger: gr_on_enrollment_overdue (BEFORE UPDATE on gr_training_enrollments) → public.gr_publish_enrollment_overdue() (SECURITY DEFINER) Delivery bridge (2026-05-01): Trigger also calls public.gr_dispatch_training_event('enrollment_overdue', payload). No HTTP consumer is wired yet — the dispatcher currently emits a RAISE NOTICE placeholder. Follow-up work will fan out to a notification / supervisor-escalation edge function. Idempotency: The trigger fires only on transitions where NEW.status = 'overdue' AND OLD.status IS DISTINCT FROM 'overdue' AND overdue_event_published_at IS NULL. The trigger sets overdue_event_published_at = now() in the same row update, guaranteeing at most one publication per enrollment per overdue cycle. PHI/PII: Identifiers and due-date metadata only — no employee name or course content. Payload Schema:
Audit: Both publishers best-effort insert into pf_audit_logs with a generated correlation ID (failures swallowed so trigger does not block the originating write).

GR-02-EN-04 (PF-96 → CE requirement library)

Event Name: Consumes pf_jurisdiction_profile_changed from PF-96; no new emitted event Publisher: PF-96 (Jurisdiction Profiles) Subscribers: GR-02 training requirement catalog service Status: 📝 Planned Spec Reference: GR-02-EN-04 Purpose: GR-02 training requirement catalogs consume PF-96 jurisdiction profile metadata to align with CE-facing requirement libraries. No new cross-core event is emitted; GR-02 subscribes to the existing pf_jurisdiction_profile_changed event. Payload Schema (consumed from PF-96):
Implementation Location: GR-02 training requirement catalog service (event subscriber logic)

GR-03: Compliance Tracking Events

Event 1: requirement_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-04 (Audit checklists), GR-06 (AI assistance)
Status: 📝 Planned (GR-03 Implementation)
Spec Reference: GR-03 Compliance Tracking
Event 2: compliance_status_changed
Publisher: GR (Governance & Compliance)
Subscribers: GR-04 (Audit readiness), GR-05 (Risk assessment), GR-06 (AI monitoring)
Status: 📝 Planned (GR-03 Implementation)
Payload Schema:

GR-04: Audit Management Events

Event 1: audit_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-06 (AI assistance)
Status: 📝 Planned (GR-04 Implementation)
Spec Reference: GR-04 Audit Management
Event 2: audit_finding_created Publisher: GR (Governance & Compliance) — gr_publish_audit_finding_created trigger (AFTER INSERT ON gr_audit_findings) Subscribers: GR-08 (Accreditation CAP automation), GR-05 (Risk assessment), GR-06 (AI monitoring) Status: ✅ Complete (GR-04-EN-01 Implementation) Spec Reference: GR-04-EN-01 CAP Automation from Audit Findings Payload Schema:
Purpose: When an audit finding of severity critical/high is recorded against a requirement linked to an active accreditation, auto-create a Corrective Action Plan (CAP) so accreditation remediation is tracked without manual re-entry. Consumer Actions: Idempotency / skips: keyed on source_event_id = fw_domain_events.id; re-delivery → 23505 no-op. severity not in (critical,high) → INFO-skip (low_severity); requirement_id NULL → INFO-skip (no_requirement); no active accreditation resolved → skip. Testing Requirements:
  • gr_publish_audit_finding_created fires on gr_audit_findings INSERT with a PHI-free payload (no description/remediation_plan)
  • critical/high finding on an active-accreditation requirement creates a gr_accreditation_caps row
  • medium/low finding → no CAP
  • NULL requirement_id → no CAP
  • Re-delivery of the same event_id creates no duplicate
  • Tenant isolation verified

GR-05: Risk Assessment Events

Event 1: risk_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-06 (AI assistance)
Status: 📝 Planned (GR-05 Implementation)
Spec Reference: GR-05 Risk Assessment
Event 2: risk_assessed
Publisher: GR (Governance & Compliance)
Subscribers: GR-06 (AI monitoring)
Status: 📝 Planned (GR-05 Implementation)
Payload Schema:

GR-11: Procedures Management Events

Event 1: procedure_approved
Publisher: GR (Governance & Compliance)
Subscribers: GR-02 (Training), GR-03 (Compliance)
Status: ✅ Complete (GR-11 Implementation)
Spec Reference: GR-11 Procedures Management
Payload Schema:
Purpose: Notify when procedure is approved for use, enabling training assignments and compliance tracking Consumer Actions: Testing Requirements:
  • Event fires when procedure status changes to ‘approved’
  • Payload includes all required fields including site_id
  • Event logged to pf_audit_logs
  • Tenant isolation verified (org_id matches)

Event 2: procedure_execution_completed
Publisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance evidence)
Status: ✅ Complete (GR-11 Implementation)
Payload Schema:
Purpose: Provide compliance evidence of procedure execution Consumer Actions: Testing Requirements:
  • Event fires when execution status changes to ‘completed’
  • Payload includes procedure and execution context
  • Event logged to pf_audit_logs
  • Related entity (context_type/context_id) included when available

Implementation:
  • Events published via gr_events channel (pg_notify)
  • Database triggers on gr_procedures (status change to ‘approved’) and gr_procedure_executions (status change to ‘completed’)
  • Events logged to pf_audit_logs for audit trail with user_id and correlation_id fields populated
  • Consumer examples provided for GR-02, GR-03 modules
Trigger Function Requirements:
  • All trigger functions that publish events to the gr_events channel MUST be created WITH SECURITY DEFINER
  • Coding Guideline: SQL trigger code for events must include SECURITY DEFINER clause
  • The trigger function owner and privileges must be set appropriately so the function can emit notifications even when invoked by less-privileged roles to remain compliant
  • Trigger functions must populate user_id from the current session context (e.g., auth.uid()) in addition to any role-specific fields like approved_by or executed_by
  • When events may chain (e.g., procedure approval triggers training assignment), trigger functions should generate and propagate correlation_id to enable event traceability

GR-06-EN-01: AI-Powered State Compliance Checking Events

Event: gr_state_gap_analysis_completed
Publisher: GR-06-EN-01 (Governance & Compliance)
Subscribers: PF-91 (compliance dashboard), PF-10 (notifications — critical gap alerts)
Channel / Transport: gr_events (pg_notify) — planned (align with other GR event publications); Kafka topic TBD if/when event bus externalizes
Status: 📝 Planned (Phase 4 — emit when state gap analysis completes)
Contract version: 1.0 (draft)
Spec / integration: GR-06-EN-01 · Integration
Payload schema (JSON fields):
Consumer actions:

GR-12: Procedure Templates Library Events

Event 1: gr_template_instantiated
Publisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance tracking), PF-10 (optional notification)
Status: 📝 Planned (GR-12 Implementation)
Spec Reference: GR-12 Procedure Templates Library
Payload Schema:
Purpose: Notify when a template is instantiated as a new procedure, enabling compliance tracking updates. Consumer Actions:
Event 2: gr_template_contributed
Publisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance tracking)
Status: 📝 Planned (GR-12 Implementation)
Payload Schema:
Purpose: Notify when an approved procedure is contributed as an org-private template.

GR-07: Quality Improvement Events

Event: qi_project_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance tracking), GR-04 (Audit management)
Status: 📝 Planned (GR-07 Implementation)
Spec Reference: GR-07 Quality Improvement

GR-08: Accreditation Management Events

Event: accreditation_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance tracking), GR-04 (Audit management)
Status: 📝 Planned (GR-08 Implementation)
Spec Reference: GR-08 Accreditation Management

GR-15: Nonprofit Governance Controls Events

Status: ✅ Implemented
Implemented: 2026-03-12 (PR #1002 remediation)
Spec Reference: GR-15 Nonprofit Governance Controls

Event 1: gr_coi_cycle_launched

Publisher: GR (Governance & Compliance)
Subscribers: PF-10 (Notifications — reminder emails to attestation participants), GR-03 (Compliance tracking — annual COI completion)
Channel: gr_events
Status: ✅ Implemented
Payload Schema:

Event 2: gr_whistleblower_report_submitted

Publisher: GR (Edge function: gr-whistleblower-submit)
Subscribers: PF-10 (Notifications — alert compliance officers), GR-03 (Compliance tracking)
Channel: gr_events
Status: ✅ Implemented
Payload Schema:

CL-07-EN-01: Zero Suicide Framework Events

Event 1: cl_safety_plan_shared
Channel: cl_events
Publisher: CL (CL-07-EN-01 Zero Suicide Framework)
Subscribers: PF-10 (Notifications — notify shared contacts), workflow listeners
Status: 📝 Planned
PHI Restrictions: UUIDs only (safety_plan_id, patient_id). No patient names, DOB, SSN, or clinical detail.
Payload Schema:

Event 2: cl_zero_suicide_followup_scheduled
Channel: cl_events
Publisher: CL (CL-07-EN-01 Zero Suicide Framework)
Subscribers: PM scheduling views, PF-10 (reminders)
Status: 📝 Planned
PHI Restrictions: UUIDs only (patient_id, encounter_id). No patient names, DOB, SSN, or clinical detail.
Payload Schema:

CL–GR Bridge Events (Incident Bridge)

Contract Source: Full event contract, payload schema, security requirements, and testing requirements are in CL-GR-CLINICAL-INCIDENT-INTEGRATION.md.
Regulatory driver: AHCCCS AMPM 1620-O; ARS 46-454; 42 CFR 482.13; CARF; Joint Commission EC.04.01.01.
Event 1: cl_safety_plan_activated
Channel: cl_events
Publisher: CL (CL-07 Suicide Risk Screening & Safety Planning)
Subscribers: GR (GR-08/GR-09 Incident Reporting — creates draft incident)
Status: 📝 Planned
PHI Restrictions: UUIDs only (chart_id, safety_plan_id, encounter_id). No patient names, DOB, SSN, or clinical detail.
Payload Schema:

Event 2: cl_restraint_event_documented
Channel: cl_events
Publisher: CL (CL-13 Crisis Intervention Documentation, when implemented)
Subscribers: GR (GR-08/GR-09 — creates draft incident per 42 CFR 482.13)
Status: 📝 Planned
PHI Restrictions: UUIDs only. No patient names, DOB, SSN, or clinical detail.
Payload Schema:

Event 3: gr_incident_created
Channel: gr_events
Publisher: GR (GR-08/GR-09 Incident Reporting)
Subscribers: CL (chart flag — open documentation requirement indicator)
Status: ✅ Implemented
PHI Restrictions: UUIDs only (chart_id when patient-related). No patient names, DOB, SSN, or clinical detail.
Payload Schema:
Security and Resilience (all three bridge events): Tenant Validation Requirements:
  1. User-initiated flows: Must validate organization_id against JWT claims (current_setting('jwt.claims.organization_id')) before any writes. Client-side checks are insufficient; server-side validation is mandatory.
  2. Service-initiated/pg_notify flows: Use a trusted organization context and MUST call a server-side SECURITY DEFINER stored procedure that:
    • Enforces strict organization_id checks against the trusted context
    • Includes auditable assertions (log mismatches to pf_audit_logs)
    • Rejects mismatches with explicit errors
    • Service-role callers must be limited to least-privilege roles
    • Includes audit logging for all event consumptions
    • Uses exponential backoff retries with dead-letter queue handling for max-retry failures
  • All emissions and consumptions MUST be logged to pf_audit_logs with user_id, organization_id, timestamp, correlation_id.

GR-09: Incident Reporting Events

Event 1: incident_created
Publisher: GR (Governance & Compliance)
Subscribers: GR-05 (Risk assessment), GR-06 (AI monitoring)
Status: 📝 Planned (GR-09 Implementation)
Spec Reference: GR-09 Incident Reporting
Event 2: incident_resolved
Publisher: GR (Governance & Compliance)
Subscribers: GR-05 (Risk update), GR-06 (AI monitoring)
Status: 📝 Planned (GR-09 Implementation)
Payload Schema:

GR-10 / GR-UX-10: Contract management & contract creation wizard

See GR-10-contract-creation-INTEGRATION.md for contract management and contract creation wizard integration details. Event Contract Template (GR-10):
Status: No events published in v1. Contract creation wizard (GR-UX-10) is local to GR core. Future integration candidates include FA (billing setup triggers) and workflow notifications. Spec Reference: GR-10 Contract Management, GR-UX-10 Contract Creation Wizard

GR-13: Procedure Analytics Events

Event 1: procedure_gap_identified
Channel: gr_events
Publisher: GR (GR-13 Procedure Analytics)
Subscribers: GR-07 (QI project candidate creation)
Status: 📝 Planned
Spec Reference: GR-13 Procedure Analytics
Payload Schema:
Purpose: Notifies GR-07 that a procedure compliance gap was identified via analytics and a QI project should be considered. Implementation note (2026-04-19): Publisher writes to fw_domain_events via publishEvent() (src/platform/events/publishEvent.ts). fw_workflow_events is the registry of event definitions, not the event log — the consumer subscribes to fw_domain_events rows where event_name = 'procedure_gap_identified'. The current payload does not include gap_kind / metric / threshold_breached (these were proposed in earlier drafts but never shipped); the consumer composes its initial problem statement from procedure_title, completion_rate_pct, and overdue_count.

GR-14: Regulatory Incident Reporting Events

Event 1: regulatory_report_submitted Publisher: GR (Governance & Compliance) — GR-14 frontend hook useIncidentRegulatoryReports.ts Subscribers: GR-03 (Compliance evidence), GR-08 (Accreditation evidence), PF-10 (Notifications) Status: ✅ Complete (GR-14-EN-01 Implementation) Spec Reference: GR-14-EN-01 GR-03 / GR-08 Consumers (Regulatory Report) Payload Schema:
Consumer field resolution: the live publisher payload carries only {regulatory_report_id, incident_id, submitted_by}. Consumers JOIN gr_incident_regulatory_reports on regulatory_report_id to read regulation_citation, regulatory_body, and submitted_at (the spec’s regulation_code / submitted_to / submitted_at payload fields do not exist on the wire — see GR-14-EN-01 spec errata §3.6).
Purpose: When a regulatory report is submitted for an incident, auto-capture it as durable compliance evidence (GR-03) and, when a survey is active, as survey-prep accreditation evidence (GR-08), so audit/accreditation trails are populated without manual re-entry. Consumer Actions: Idempotency: All consumers key on source_event_id = fw_domain_events.id via the partial unique indexes above (WHERE source_event_id IS NOT NULL); a re-delivered {event_id} hits a 23505 and no-ops. GR-03 resolves requirement_id by cascade: org gr_regulation_to_requirement_map → platform-default map row (organization_id IS NULL) → gr_module_settings.default_evidence_requirement_id → else WARN-skip (no_requirement_mapping). GR-08 maps regulation_citation → accreditation_body via gr_regulation_to_accreditation_map; no active survey → INFO-skip (no_active_survey). Testing Requirements:
  • Event fires from useIncidentRegulatoryReports on report submission
  • GR-03 consumer inserts compliance evidence with source_event_id set
  • GR-08 consumer inserts one accreditation-evidence row per active survey
  • Re-delivery of the same event_id creates no duplicate (23505 no-op)
  • Feature flag gr_module_settings.enable_auto_evidence_consumers=false short-circuits both consumers
  • Tenant isolation verified (org_id matches across mapping + evidence rows)
Idempotency Indexes (GR-14-EN-01 + GR-04-EN-01): All event consumers store the originating fw_domain_events.id in a source_event_id UUID NULL column and dedupe via a partial unique index (WHERE source_event_id IS NOT NULL): A consumer re-reading a redelivered {event_id} hits 23505 on its index and returns action: 'duplicate' without writing.

Event Infrastructure

Generic Event Publisher:
Event Consumer Edge Function:
  • Location: supabase/functions/event-consumer/index.ts
  • Listens to domain_events channel
  • Logs all events to pf_audit_logs with:
    • module = ‘hr’ (or relevant core)
    • action = ‘domain_event’
    • table_name = source table
    • new_values = event payload
  • Future-ready for event handlers (commented code included)
Testing: ✅ Complete - All events logged correctly

Planned Events (IT Module)

The IT (Information Technology) module defines 18 planned events for asset management, support ticketing, vendor management, software licensing, security compliance, and procurement. Full IT event documentation: IT Integration Contracts

IT-01: Asset Management Events

Event 1: it_asset_purchased
Publisher: IT (IT-01 Asset Management)
Subscribers: FA (Finance - asset capitalization)
Status: ✅ Implemented
Last Verified: 2026-02-15
Spec Reference: IT-01 IT Asset Management
Payload Schema:
Implementation:
Event 2: it_asset_assigned
Publisher: IT (IT-01 Asset Management)
Subscribers: PF-10 (Notifications), HR
Status: ✅ Implemented
Event 3: it_asset_maintenance_required
Publisher: IT (IT-01 Asset Management)
Subscribers: FM (Facilities), PF-10 (Notifications)
Status: 📝 Planned
Event 4: it_asset_disposed
Publisher: IT (IT-01 Asset Management)
Subscribers: FA (Finance), GR (Governance)
Status: ✅ Implemented
Last Verified: 2026-02-15
Implementation:

IT-02: Support Ticketing Events

Event 1: it_ticket_created
Publisher: IT (IT-02 Support Ticketing)
Subscribers: PF-10 (Notifications)
Status: ✅ Implemented
Spec Reference: IT-02 IT Support & Ticketing
Payload Schema:
Event 2: it_ticket_status_changed
Publisher: IT (IT-02)
Subscribers: PF-10 (Notifications)
Status: ✅ Implemented
Last Verified: 2026-02-15
Implementation:
Event 3: it_ticket_sla_breached
Publisher: IT (IT-02)
Subscribers: PF-10 (Notifications), IT-02 Dashboard
Status: ✅ Implemented
Implemented: 2026-01-05
Payload Schema:
Implementation:

IT-03: Vendor Management Events

Event: it_contract_expiring
Publisher: IT (IT-03 Vendor Management)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Spec Reference: IT-03 IT Vendor Management
Payload Schema:

IT-04: Software License Events

Event 1: it_license_created
Publisher: IT (IT-04 Software License Management)
Subscribers: FA (Finance)
Status: 📝 Planned
Spec Reference: IT-04 Software License Management
Event 2: it_license_expiring
Publisher: IT (IT-04)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Event 3: it_license_renewed
Publisher: IT (IT-04)
Subscribers: FA (Finance)
Status: ✅ Implemented
Last Verified: 2026-02-15
Implementation:
Event 4: it_license_compliance_alert
Publisher: IT (IT-04)
Subscribers: PF-10 (Notifications), FA (cost tracking)
Status: ✅ Implemented
Implemented: 2026-01-05
Payload Schema:
Implementation:

IT-05: Security & Compliance Events

Event 1: it_security_incident_created
Publisher: IT (IT-05 Security & Compliance)
Subscribers: GR (Governance & Risk), PF-10 (Notifications)
Status: ✅ Implemented
Implemented: 2026-01-05
Spec Reference: IT-05 IT Security & Compliance
Payload Schema:
Implementation:
Event 2: it_vulnerability_detected
Publisher: IT (IT-05)
Subscribers: GR (Governance), PF-10 (Notifications)
Status: ✅ Implemented
Implemented: 2026-01-05
Payload Schema:
Implementation:
Event 3: it_patch_deployed
Publisher: IT (IT-05)
Subscribers: Event Consumer (audit logging), Asset tracking
Status: ✅ Implemented
Implemented: 2026-01-05
Payload Schema:
Implementation:
Event 4: it_patch_deployment_overdue
Publisher: IT (IT-05)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned

IT-06: Procurement Events

Event 1: it_purchase_request_submitted
Publisher: IT (IT-06 Procurement)
Subscribers: FW-34 (Approval Workflows), PF-10 (Notifications)
Status: ✅ Implemented
Spec Reference: IT-06 IT Procurement
Event 2: it_purchase_request_approved
Publisher: IT (IT-06)
Subscribers: FA-04 (Purchase Orders), PF-10 (Notifications)
Status: ✅ Implemented
Payload Schema:
Event 3: it_purchase_request_received
Publisher: IT (IT-06)
Subscribers: IT-01 (Asset creation), PF-10 (Notifications)
Status: 📝 Planned

Implemented Events (FA Core)

FA-19: Financial Close Management Events

Status: ✅ Complete
Implemented: 2026-01-19
Financial Close Management events are published to the fa_events channel for close period lifecycle tracking and task management integration.

Event 1: close_period_started

Publisher: FA (Finance)
Subscribers: PF-10 (Notifications), Audit Log
Trigger: UPDATE on fa_close_periods when status changes from ‘not_started’ to ‘in_progress’
Payload Schema:
Implementation:

Event 2: close_period_completed

Publisher: FA (Finance)
Subscribers: FA-02 (Fiscal Periods), PF-10 (Notifications)
Trigger: UPDATE on fa_close_periods when status changes to ‘completed’
Payload Schema:
Purpose: Notify FA-02 General Ledger to update fiscal period status, trigger period-end reporting

Event 3: close_period_approved

Publisher: FA (Finance)
Subscribers: FA-07 (Financial Reporting), PF-10 (Notifications)
Trigger: UPDATE on fa_close_periods when status changes to ‘approved’
Payload Schema:
Purpose: Enable final report generation for approved close periods

Event 4: close_task_assigned

Publisher: FA (Finance)
Subscribers: PF-10 (Notifications)
Trigger: UPDATE on fa_close_tasks when assigned_to changes
Payload Schema:
Purpose: Notify assigned user of new close task assignment

Event 5: close_task_completed

Publisher: FA (Finance)
Subscribers: PF-10 (Notifications), FA-19 (Progress tracking)
Trigger: UPDATE on fa_close_tasks when status changes to ‘completed’
Payload Schema:
Purpose: Track close progress, update dashboard metrics, notify stakeholders Consumer: supabase/functions/event-consumer/index.ts
  • Logs all events to pf_audit_logs
  • Handlers for notification delivery pending PF-10 integration
Testing: ✅ Events fire correctly on status changes

PF-11 / PF-60: Document Lifecycle Events (RAG)

Status: ✅ Implemented (triggers and migration)
Implemented: Migration 20260226140000_pf_rag_document_knowledge_events.sql
Spec Reference: specs/pf/specs/PF-11-document-management.md, docs/architecture/integrations/PF-60-rag-infrastructure-INTEGRATION.md
For PF-11 and PF-60, events use the DomainEvent envelope (see Event Schema Standard above): on the wire, the message has top-level event_type, payload, and metadata. The interfaces below describe the payload only (the inner object inside payload). Handlers receive the full envelope and use payload (and optionally metadata); they must not expect event_type inside the payload.

Events: document_published, document_updated, document_deleted

Channel: domain_events
Publisher: PF (PF-11)
Subscribers: PF-60 (RAG Infrastructure), Event Consumer
Trigger: INSERT / UPDATE / DELETE on pf_documents (see migration for trigger definitions)
Payload-only schemas (inside envelope.payload)
Note: Event payload contains only IDs and non-PHI metadata. RAG consumers (PF-60) must fetch document content (e.g. extracted_content, title) from pf_documents using document_id under RLS.
Consumer actions

PF-61: Knowledge Base System Events

Status: 📝 Planned
Implemented: TBD
Spec Reference: specs/pf/specs/PF-61-knowledge-base-system.md

Event: knowledge_article_published

Event: knowledge_article_published
Channel: domain_events
Publisher: PF (PF-61)
Subscribers: PF-60 (RAG Infrastructure)
Status: 📝 Planned
Purpose
Notifies RAG infrastructure that a knowledge article has been published and is ready for embedding generation.
Trigger Conditions
  • Article status changes from draft or in_review to published via UPDATE
  • Note: Event only fires on UPDATE operations when status changes to published. Consumers must fetch article details (title, tags, category) under RLS using article_id.
Payload Schema
Note: Event payload contains only IDs and non-PII metadata. Consumers must fetch article details (title, tags, category) from pf_knowledge_base table using article_id under RLS policies.
Implementation
Consumer Actions
Testing Requirements
  • Event payload structure validation
  • Event fires on publish
  • Correct organization_id included
  • PF-60 handles event correctly

Event: knowledge_article_unpublished

Event: knowledge_article_unpublished
Channel: domain_events
Publisher: PF (PF-61)
Subscribers: PF-60 (RAG Infrastructure)
Status: 📝 Planned
Purpose
Notifies RAG infrastructure to remove embeddings for an unpublished article.
Trigger Conditions
  • Article status changes from published to draft, in_review, or archived
  • Article is deleted
Payload Schema
Implementation
Consumer Actions
Testing Requirements
  • Event payload structure validation
  • Event fires on unpublish
  • Correct organization_id included
  • PF-60 handles event correctly

Planned Events (CL/PM EHR & Practice Management)

Source: EHR_PM_PLANNING_BUNDLE.md
Status: 📝 Planned (stubs); payload schemas to be defined in respective CL/PM specs.

CL/PM Event Summary

PM events as automation triggers: When the cl_pm_events channel is implemented, FW-03 Automation Engine can subscribe and use PM events as automation triggers (trigger type pm_event or event with source PM). Billing admins can create rules that run when specific events occur (e.g. claim status = denied, charge approved, payment posted), with optional payload filters (event_type, new_status, payer_id). See PM-19: PM-Triggered Business Rule Automation and PM-19 Integration. CL-23 In-Basket event consumption: CL-23 (Clinical In-Basket) consumes the following planned events to create or update cl_inbasket_items (item types: cosign_request, lab_review, refill_request, chart_message, referral_response, cds_alert). Event names and payload schemas are defined in the rows above; when implemented, CL-23 subscribes and maps to in-basket item_type and payload. Key events: progress_note_signed (cosign), cds_alert_triggered (cds_alert), cl_lab_result_received / cl_lab_result_reviewed (lab_review). Planned stubs for referral and chart_message below. See CL-23 Clinical In-Basket Integration. CL-23 planned event stubs (referral_response, chart_message):
⚠️ Naming compliance note: When these events are implemented, names MUST follow the established {domain}_{entity}_{action} convention (e.g., cl_referral_response_received, cl_chart_message_sent). The placeholder names below are for planning only.
Consumers can align on channel, publisher, subscriber, and payload placeholders early; payload schemas will be defined in respective PM/CL specs. PM-19 automation trigger payload schemas (canonical): All PM events consumed by FW-03 for automation MUST include organization_id in payload or metadata for tenant isolation. Filterable fields used by PM-19 rules: IDs-only rule for PM automation payloads: All example payloads in this subsection use UUIDs/IDs only (no PII/PHI). Human-readable identifiers (e.g. claim numbers, account numbers) must not be included in event payloads; use system-generated UUIDs only, or if needed store only irreversible hashes. Consumers resolve display data via authorized APIs. Example payload (claim_status_changed):
Example payload (charge_approved / charge_status_changed):
Example payload (payment_posted):
All example payloads above use IDs only (no PII/PHI). Automation actions resolve display data via authorized APIs. Acceptance criteria for transition to full specs: (1) Payload schema documented with required/optional fields and types; (2) Channel cl_pm_events created and wired; (3) Publisher/subscriber contracts and error handling agreed; (4) Owner and target date (sprint/quarter) assigned per row above.

CL/PM Full Payload Schemas (Canonical)

Payloads use IDs only (no PII/PHI). All events include event_id (uuid) as the primary idempotency key and metadata: { organization_id, user_id?, timestamp, correlation_id? }. Idempotency note: event_id is the canonical deduplication key per the Event Schema Standard. Some older event contracts reference correlation_id for idempotency — these should be treated as supplementary domain-specific keys; event_id takes precedence.

clinical_note_finalized (CL-04 → PM-07)

Event: clinical_note_finalized (alias: progress_note_signed)
Publisher: CL
Subscribers: PM-07 (charge capture), PF-10
Contract: CL-PM-ENCOUNTER-TO-BILLING
Idempotency: Consumer (PM-07) MUST use event_id to avoid duplicate charges. Error handling: Retry with exponential backoff; dead-letter queue after N failures. No PII/PHI in payload.

peer_encounter_finalized (CL-19 → PM-07)

Event: peer_encounter_finalized
Publisher: CL
Subscribers: PM-07 (charge capture)
Contract: CL-19 Peer Recovery Support
Idempotency: Consumer (PM-07) MUST use event_id to avoid duplicate charges. No PII/PHI in payload. payload.user_id is set only when the event is user-initiated; otherwise omit.

assessment_completed (CL-02)

treatment_plan_signed (CL-03)

cl_sdoh_screening_completed (CL-18)

Consumers MUST resolve patient identity from chart_id (e.g. cl_sdoh_screenings.chart_idcl_patient_charts). patient_id is not in the payload to avoid denormalization and sync/merge issues.

patient_registered (PM-01)

appointment_scheduled (PM-03)

encounter_completed (PM-03 / CL-04)

cl_assessment_completed (CL-02-EN-59)

Event: cl_assessment_completed
Channel: cl_events
Publisher: CL-02
Subscribers: PM-07 (charge capture for assessment billing)
Status: ✅ Active (2026-04-04)
Payload includes instrument_code to allow subscribers to differentiate cognitive screening instruments (moca, slums, mmse) from other assessments. No PHI in payload — consumers must fetch clinical data server-side.

claim_submitted / claim_status_changed (PM-08)

prior_auth_required / prior_auth_received (PM-10)

eligibility_verified (PM-02)

charge_approved / charge_status_changed (PM-07 → FW-03)

Event: charge_approved or charge_status_changed
Publisher: PM (PM-07)
Subscribers: FW-03 (automation triggers), PF-10
Spec Reference: PM-19 PM-Triggered Business Rule Automation

claim_created (PM-08)

Event: claim_created
Publisher: PM (PM-08)
Subscribers: FW-03 (optional)
Spec Reference: PM-19

denial_received (PM-08 / PM-09)

Event: denial_received
Publisher: PM (PM-08/PM-09 when denial_codes updated, e.g. from ERA)
Subscribers: FW-03, PF-10
Spec Reference: PM-19

payment_posted (PM-09 → FA)

Event: payment_posted
Channel: cl_pm_events
Publisher: PM (PM-09)
Subscribers: FA (revenue/AR posting to GL)
Status: Implemented (FA consumer: fa-consume-pm-payment-events)
Spec Reference: PM-09 Payment Posting & ERA Processing
Integration Doc: PM-09 Integration
Purpose: Notify FA when an insurance or patient payment has been posted so FA can post revenue/AR to the general ledger. Loose coupling: PM publishes after posting; FA consumes asynchronously. Trigger: After pm_payments row is created/updated with status ‘posted’ or ‘partially_posted’ and at least one pm_payment_applications exists (or after ERA batch posting completes). Payload Schema:
Idempotency: FA MUST use event_id to avoid duplicate GL entries. No PII/PHI in payload (IDs only).

write_off_approved (PM-09 / PF-10 → FA)

Event: write_off_approved
Channel: cl_pm_events
Publisher: PM (PM-09) or PF-10 (approval workflow completion)
Subscribers: FA (write-off/bad debt GL entry)
Status: Implemented (FA consumer: fa-consume-pm-payment-events)
Spec Reference: PM-09 Payment Posting & ERA Processing
Integration Doc: PM-09 Integration
Purpose: Notify FA when a write-off or bad debt has been approved (PF-10/FW-34) so FA can post the write-off to the general ledger. Trigger: When platform approval (PF-10/FW-34) completes for a write-off request tied to PM-09 (e.g. payment or application write-off). Payload Schema:
Idempotency: FA MUST use event_id to avoid duplicate write-off GL entries. No PII/PHI in payload (IDs only).

capitation_payment_received (PM-33 → FA)

Event: capitation_payment_received
Channel: cl_pm_events
Publisher: PM (PM-33 — useCreateReconciliationMutation in src/cores/pm/hooks/useCapitationReconciliations.ts)
Subscribers: FA (capitation revenue GL posting — fa-consume-pm-payment-events)
Status: Implemented (FA-49 Phase 4 — publisher: PM-33 reconciliation hook; consumer: fa-consume-pm-payment-events processCapitationReceived)
Spec Reference: FA-49 PM-to-FA Revenue Posting Activation
Purpose: Notify FA when a capitation (PMPM) payment is recorded as received against a PM-33 reconciliation period so FA can post capitation revenue to the GL (DR Cash / CR Capitation Revenue). Trigger: After a pm_capitation_reconciliations row is inserted (reconciliation recorded as received in PM-33 UI). Payload Schema:
Idempotency: FA MUST use event_id to avoid duplicate capitation revenue GL entries (fa_pm_event_log dedup). No PII/PHI in payload (IDs + amounts only).

Planned Events (FA Cross-Core — when CE/GR/CL ready)

clinical_program_cost_allocated — Payload Schema

Channel: cl_events Publisher: CL (Clinical core) Publisher Artifact: TBD — CL edge function or trigger (pending CL module maturity) Subscriber: FA-35 (fa-consume-cl-program-cost edge function) Subscriber Artifact: supabase/functions/fa-consume-cl-program-cost/index.ts (FA-35) Idempotency Key: event_id (UUID); consumer deduplicates on fa_cl_allocation_activity.source_event_id.
Implementation Location:
  • Publisher: TBD — CL edge function or database trigger (pending CL module implementation)
  • Subscriber: supabase/functions/fa-consume-cl-program-cost/index.ts (FA-35 Phase 1)
Contract References: No PHI/PII: Only program UUIDs and integer counts. No patient names, diagnoses, or clinical details.

encounter_cost_calculated — Payload Schema

Channel: fa_events (or cl_pm_events — to be confirmed) Publisher: PM-35 (Practice Management / Encounter Cost Accounting) Subscriber: FA-35 (fa-consume-encounter-cost edge function) Idempotency Key: event_id (UUID); consumer deduplicates on event_id (or source_event_id if included in payload). Status: 📝 Planned — schema pending FA-35 + PM-35 joint session (see PENDING_CONTRACTS.md) Payload Schema (draft):
Implementation Location:
  • Publisher: TBD — PM-35 edge function or trigger (pending PM-35 Phase 2)
  • Subscriber: supabase/functions/fa-consume-encounter-cost/index.ts (FA-35 Phase 2)
Contract References: No PHI/PII: Only UUIDs and cost amounts. No patient names, clinical details, or diagnoses.

CL/PM Event Error Handling and Idempotency

  • Idempotency: Every event MUST include a unique event_id. Consumers MUST record processed event_ids and MUST NOT create duplicate side effects (e.g. duplicate charges) when the same event is delivered more than once.
  • Retry policy: Consumers SHOULD retry transient failures with exponential backoff (e.g. 1s, 2s, 4s, max 3 retries).
  • Dead-letter queue (DLQ): After max retries, event SHOULD be written to a DLQ or logged for manual resolution; alert operators.
  • No PII/PHI in payload: Only UUIDs and non-identifying codes. See constitution and EVENT_CONTRACTS security guidance.

Example Stub: assessment_completed

Event: assessment_completed
Channel: cl_pm_events
Publisher: CL (Clinical & EHR)
Subscribers: PM (optional billing), FW, PF-10
Status: 📝 Planned
Spec Reference: CL-02 – Comprehensive Assessments
Definition Timeline: Q2 2026; payload schema finalized in CL-02 spec.
Owner: CL team; tracking: CL-02 spec.
Purpose: Notify when a comprehensive assessment is completed so downstream workflows (billing, automation, notifications) can react. Trigger Conditions: Assessment record finalized/signed (e.g. INSERT/UPDATE on assessment table with status = completed). Payload Schema (mandatory fields per EVENT_CONTRACTS guidelines): GUIDANCE: Event payload must not contain PII/PHI; use IDs only (e.g. assessment_id, patient_id). No names, emails, or other sensitive data. See EVENT_CONTRACTS payload guidelines. Implementation: Not yet implemented. Channel cl_pm_events to be created when CL/PM event pipeline is implemented.

CL-03: treatment_plan_review_scheduled

Event: treatment_plan_review_scheduled
Channel: cl_pm_events
Publisher: CL (Clinical & EHR)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Spec Reference: CL-03 – Treatment Planning
Integration Doc: CL-03-treatment-planning-INTEGRATION.md
Owner: CL team.
Purpose: Notify when a treatment plan is due for review (e.g. 30 days before annual review_due_date) so PF-10 can send alerts to the assigned clinician/care coordinator. Trigger Conditions: Scheduled or cron evaluation: plans where review_due_date is within the notification window (e.g. 30 days); or on plan create/update when review_due_date is set. Payload Schema: Implementation: Not yet implemented.

CL-03: treatment_plan_event_triggered

Event: treatment_plan_event_triggered
Channel: cl_pm_events
Publisher: CL (Clinical & EHR)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Spec Reference: CL-03 – Treatment Planning
Integration Doc: CL-03-treatment-planning-INTEGRATION.md
Owner: CL team.
Purpose: Notify when a life event is recorded that triggers a treatment plan update (hospitalization, move, LOC change, incarceration). Success metric: alert/queue within 48 hours of event recorded. Phase 1: manual event entry only. For auditability, user_id must be present when the trigger is user-initiated. Trigger Conditions: User records a qualifying life event for a chart (e.g. “Life event” form or chart event); optional future ADT integration. Payload Schema: Implementation: Not yet implemented.

PM-02: Insurance & Eligibility Verification Events

Status: 📝 Planned
Spec Reference: PM-02-insurance-eligibility-verification.md

Event: pm_eligibility_verified

Channel: pm_events
Publisher: PM (Practice Management) — PM-02
Subscribers: CL-01 (Patient Chart — coverage info update), PM-08 (Claims — eligibility gate)
Trigger: After an eligibility check record is created and eligible field is set
Status: 📝 Planned
Payload Schema:
PHI Logging Guidelines:
  • Allowed: check_id, patient_id (UUID only — no name/DOB), check_type, eligible, organization_id
  • Prohibited: benefit_details contents, policy_number, subscriber_dob, subscriber_name
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Consumer Actions:
  1. CL-01: Update patient chart coverage status display (coverage info widget)
  2. PM-08: Allow/block claim submission based on eligibility status (eligibility gate)
  3. FW automations: Trigger workflows on eligibility change (e.g., notify staff of inactive coverage)
Implementation Note:
  • Register in fw_workflow_events table via seed migration (Phase 0, T0 task)
  • Channel pm_events must be added to the Event Delivery Mechanism channel list
  • Published via publishEvent() from @/platform/events after eligibility check record creation

Event: pm_benefits_parsed

Channel: pm_events Publisher: PM (Practice Management) — PM-02-EN-02 (pm-parse-271-benefits edge function) Subscribers: PM-48 (Patient Cost Estimation & Financial Clearance), PM-07 (Charge Capture — copay/deductible defaults) Trigger: After successful X12 271 EB-loop parsing and persistence of pm_benefit_details rows for an eligibility check Status: 📝 Planned (PM-02-EN-02) Spec Reference: PM-02-EN-02-eligibility-benefit-detail-parsing.md §FR-3.3 Payload Schema:
PHI Logging Guidelines:
  • Allowed: eligibility_check_id, patient_id (UUID only — no name/DOB), parsing_confidence, service_types_parsed, organization_id
  • Prohibited: copay/coinsurance/deductible amounts, OOP max values, raw EB segments, subscriber identifiers
  • Retention: Event logged via publishEvent(); no benefit dollar amounts in application logs or edge function stdout (createLogger sanitization required)
Consumer Actions:
  1. PM-48 (Patient Cost Estimation): Trigger refresh of patient responsibility estimates for affected appointments
  2. PM-07 (Charge Capture): Refresh copay/deductible defaults shown in charge entry form for the patient
Implementation Note:
  • Published via publishEvent() from @/platform/events after pm-parse-271-benefits edge function completes successful parsing
  • Channel pm_events (already declared for pm_eligibility_verified)
  • Service-role edge function MUST scope all DB writes by organization_id before publishing (defense-in-depth per PM-02-EN-02 FR-3.1)

PM-01-EN-01: Patient Merge Events

Status: 📋 Specification — implementation pending Spec Reference: PM-01-EN-01-patient-merge-workflow.md Integration Reference: PM-01-EN-01-patient-merge-workflow-INTEGRATION.md

Event: pm_patient_merged

Channel: pm_events Publisher: PM (Practice Management) — pm_merge_patients() SECURITY DEFINER function (PM-01-EN-01) Subscribers: CL (chart cache invalidation), PM-08 (claims grouping cache), CE-29 (lead↔patient mapping), PF-71 (patient identity boundary) Trigger: Successful commit of pm_merge_patients() after all PM/CL FK re-points and audit row write. Status: 📋 Specification Schema Version: 1 Payload Schema:
PHI Logging Guidelines:
  • Allowed: all payload fields above (UUIDs and timestamp only)
  • Prohibited: merge_reason body, demographics, MRN, any chart data
  • Retention: Event row retained in fw_workflow_events; PF-44 audit row retained per HIPAA §164.312(b)
Delivery Semantics:
  • Idempotency key: merge_log_id
  • Delivery: at-least-once
  • Ordering: per survivor_patient_id
  • Undo: v1 publishes no pm_patient_merge_undone event. Consumers MUST reconcile from pm_patient_merge_log (filter rolled_back_at IS NOT NULL) when maintaining long-lived projections.
Consumer Actions:
  1. CL: Invalidate chart-by-patient caches keyed on merged_patient_id; subsequent reads will resolve to the survivor via the re-pointed cl_patient_charts.patient_id.
  2. PM-08 (Claims): Drop in-memory groupings keyed on merged_patient_id.
  3. CE-29 (Lead Conversion): Re-point lead↔patient mapping rows where applicable.
  4. PF-71 (Patient Identity Boundary): Refresh identity caches.
Implementation Notes:
  • Registered in fw_workflow_events via the PM-01-EN-01 migration (one row, schema_version = 1, owning_core = pm).
  • Channel pm_events is already declared (PM-02 events).
  • Published from inside the SECURITY DEFINER function; if the fw_workflow_events insert fails, the entire merge transaction aborts (no partial state).

PM-50: AI Denial Prediction Events

Status: 📝 Planned Spec Reference: PM-50-ai-denial-prediction-prevention.md

Event 1: pm.denial_prediction.created

Channel: pm_events Publisher: PM (Practice Management) — PM-50 / AI Denial Prediction service Subscribers: None (available for future GR dashboards or analytics) Trigger: After a denial risk prediction is generated and saved to pm_denial_predictions Status: 📝 Planned Payload Schema:
Storage:
  • Event table: fw_domain_events (via publishEvent() from @/platform/events)
  • Retention: Standard event retention policy (see EVENT_DELIVERY.md)
PHI Logging Guidelines:
  • Allowed: prediction_id, claim_id (UUID only), risk_score, risk_level, model_version, organization_id
  • Prohibited: No PHI; claim-level features are categorical/aggregate only
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Purpose: Notify when a new denial prediction is created. Available for future integration with GR dashboards or analytics tracking. Implementation Note:
  • Register in fw_workflow_events table via seed migration
  • Published via publishEvent() from @/platform/events after prediction record creation in predict-denial-risk edge function

Event 2: pm.denial_prediction.outcome_recorded

Channel: pm_events Publisher: PM (Practice Management) — PM-50 / PM-29 Denial Management (via feedback loop) Subscribers: PM-50 (retraining pipeline for model feedback) Trigger: When actual_outcome field is updated on pm_denial_predictions (claim adjudication result recorded) Status: 📝 Planned Payload Schema:
Storage:
  • Event table: fw_domain_events (via publishEvent() from @/platform/events)
  • Retention: Standard event retention policy (see EVENT_DELIVERY.md)
PHI Logging Guidelines:
  • Allowed: prediction_id, claim_id (UUID only), actual_outcome, actual_denial_reason (code only), organization_id
  • Prohibited: No PHI; denial reason is code-level only (no narrative)
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Purpose: Notify when actual claim outcome is recorded for model feedback. PM-50 retraining pipeline consumes this to improve prediction accuracy. Consumer Actions:
  1. PM-50 Retraining: Add outcome to training dataset for monthly model retraining
  2. Analytics: Track prediction accuracy over time (precision/recall metrics)
Implementation Note:
  • Register in fw_workflow_events table via seed migration
  • Published via database trigger on pm_denial_predictions UPDATE when actual_outcome changes from NULL to non-NULL
  • Alternative: Published via publishEvent() from PM-29 when denial outcome is recorded

CL-09: cl_lab_order_created

Event: cl_lab_order_created
Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-09
Subscribers: PF-10 (Notifications), FW (Workflow Automation)
Status: 📝 Planned
Spec Reference: CL-09 – Lab & Diagnostic Orders & Results
Integration Doc: CL-09-lab-diagnostic-orders-results-INTEGRATION.md
Owner: CL team.
Purpose: Notify when a lab order transitions from draft to ordered so downstream systems can track pending orders and trigger workflow automations. Trigger Conditions: UPDATE on cl_orders WHERE NEW.status = 'ordered' AND OLD.status = 'draft'. Payload Schema: PHI Logging Guidelines:
  • Allowed: order_id, chart_id, ordering_provider_id, loinc_code, priority, lab_id, organization_id
  • Prohibited: Patient names, DOB, SSN, result values, diagnosis information
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Implementation: Not yet implemented. Published via publishEvent() from @/platform/events.

CL-09: cl_lab_result_received

Event: cl_lab_result_received
Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-09 / External Lab Interface
Subscribers: CL-08 (Clinical Decision Support — abnormal result alert via evaluateCdsRules()), PF-10 (Notifications)
Status: 📝 Planned
Spec Reference: CL-09 – Lab & Diagnostic Orders & Results
Integration Doc: CL-09-lab-diagnostic-orders-results-INTEGRATION.md
Owner: CL team.
Purpose: Notify when a lab result is ingested (via HL7v2/FHIR interface or manual entry) so CL-08 CDS can evaluate for abnormal result alerts and notifications can be sent to the ordering provider. Trigger Conditions: INSERT on cl_order_results (result ingested from external interface or manually entered); order status transitions to resulted. Payload Schema: PHI Logging Guidelines:
  • Allowed: order_id, result_id, chart_id, loinc_code, abnormal_flag, source, organization_id
  • Prohibited: Patient names, DOB, SSN, actual result values (result_value, result_value_numeric), reference ranges
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Consumer Actions: Implementation: Not yet implemented. Published via publishEvent() from @/platform/events or from the cl-lab-result-ingestion edge function for interface-ingested results.

CL-09: cl_lab_result_reviewed

Event: cl_lab_result_reviewed
Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-09
Subscribers: PF-10 (Notifications), PF-04 (Audit)
Status: 📝 Planned
Spec Reference: CL-09 – Lab & Diagnostic Orders & Results
Integration Doc: CL-09-lab-diagnostic-orders-results-INTEGRATION.md
Owner: CL team.
Purpose: Notify when a clinician signs off on (reviews) a lab result, completing the result review workflow. This creates an audit trail and can trigger downstream notifications. Trigger Conditions: UPDATE on cl_order_results WHERE NEW.reviewed_by IS NOT NULL AND OLD.reviewed_by IS NULL; order status transitions to reviewed. Payload Schema: PHI Logging Guidelines:
  • Allowed: order_id, result_id, chart_id, reviewed_by, organization_id
  • Prohibited: Patient names, DOB, SSN, actual result values, clinical notes
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Implementation: Not yet implemented. Published via publishEvent() from @/platform/events.

PF-63: Teams Channel Notification Dispatch

Event: teams_channel_notification_dispatched
Publisher: PF (Platform Foundation) — event-consumer edge function
Subscribers: entra-teams-notify edge function
Status: ✅ Complete
Implemented: 2026-02-21
Description: When any domain event is consumed by event-consumer, it checks pf_teams_notification_config for matching rules. If active rules exist for the event type and organization, it dispatches messages to the configured Teams channels via entra-teams-notify. Routing Mechanism:
  • Table: pf_teams_notification_config
  • Match criteria: organization_id + event_name + is_active = true
  • Each matching rule triggers a separate call to entra-teams-notify
Payload Schema:
Dispatch Payload (to entra-teams-notify):
Supported Event Types (built-in message templates):
  • hr_employee_hired — New hire announcement
  • credential_expiring — Credential expiry warning
  • form_submitted — Form submission notification
  • leave_approved — Leave approval notification
  • rh_resident_admitted — New resident admission (canonical; replaces resident_admitted)
Security:
  • Service-role authentication for dispatch calls
  • HTML escaping on all interpolated template values
  • Organization access verified via verifyOrgAccess()

CL-12: Care Coordination & Transitions Events

Event: referral_accepted

Channel: cl_pm_events
Publisher: PM (Practice Management) — PM-06
Subscribers: CL-12 (Care Coordination)
Status: ✅ Implemented (Consumer in event-consumer edge function) Spec Reference: CL-12, CL-PM-REFERRALS
Purpose: When a referral is accepted (PM-06 status → admitted), CL-12 creates a cl_transitions record (type = referral), links referral_id, and triggers discharge checklist / medication reconciliation as applicable. Trigger Conditions: UPDATE on pm_referrals WHERE NEW.status = 'admitted' AND OLD.status != 'admitted'. Payload Schema: PHI Logging Guidelines:
  • Allowed: referral_id, patient_id, organization_id, urgency, referral_direction
  • Prohibited: Patient names, DOB, SSN, clinical notes, diagnosis codes
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Consumer Actions (CL-12):
  1. Create cl_transitions record with transition_type = 'referral' and referral_id
  2. If outbound: trigger discharge checklist creation
  3. Trigger medication reconciliation (CL-05)
  4. Generate C-CDA transition summary (CL-16, when available)

Event: transition_completed

Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-12
Subscribers: PM-06 (Referral Management)
Status: ✅ Implemented (Published by useCompleteChecklist hook) Spec Reference: CL-12, CL-PM-REFERRALS
Purpose: Published when a discharge checklist is completed for a transition that has a linked referral_id. PM-06 consumes this to update the referral status to completed. Trigger Conditions: UPDATE on cl_discharge_checklists WHERE NEW.overall_status = 'completed' AND OLD.overall_status != 'completed' AND parent cl_transitions.referral_id IS NOT NULL. Payload Schema: PHI Logging Guidelines:
  • Allowed: transition_id, chart_id, referral_id, checklist_id, organization_id, transition_type
  • Prohibited: Patient names, DOB, SSN, checklist item notes, clinical details
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Consumer Actions (PM-06):
  1. Update pm_referrals status to completed where id = referral_id

CL-15: Clinical Reporting & Quality Measures Events

Event: cl_incident_reported

Channel: cl_events
Publisher: CL (Clinical & EHR) — CL-15
Subscribers: GR-03 (Compliance Tracking), GR-04 (Audit Management), GR-08 (Accreditation Management), PF-10 (Notifications)
Status: ✅ Implemented
Spec Reference: CL-15, CL-15 Integration
Purpose: Published when a clinical incident is formally reported to the state, indicating a regulatory reporting action. GR consumes this for compliance tracking, audit workflows, and accreditation evidence. PF-10 notifies compliance officers and administrators. Trigger Conditions: UPDATE on cl_incidents WHERE NEW.reported_to_state_at IS NOT NULL AND OLD.reported_to_state_at IS NULL. Payload Schema:
Consumer Actions: PHI/PII Logging Guidelines:
  • Safe to log: incident_id, organization_id, incident_type, severity, reported_by
  • Log as flag only: chart_id → log has_chart_id: true/false
  • Prohibited: patient names, chart content, clinical details
  • custom_fields must be sanitized to remove any PII/PHI before logging
Idempotency: Handled by FW-16 workflow engine via event_name + payload_hash.

CL-16-EN-01: TEFCA/QHIN Connectivity Events (Planned) \

Publisher: CL (Clinical & EHR) — CL-16-EN-01
Status: 📝 Planned
Spec Reference: CL-16-EN-01
Integration Doc: CL-16-EN-01-tefca-qhin-connectivity-INTEGRATION.md
Ownership: CL-16-EN-01 owns event production and payload versioning.
Payload constraints (all TEFCA events):
  • Required identifiers: event_id (UUID), organization_id, patient_id (nullable when unresolved), correlation_id, status.
  • Identifier-only payloads; no PHI payload bodies.
  • event_id is required for idempotency and retry deduplication across at-least-once delivery.

Event: cl_tefca_query_submitted \

Channel: cl_pm_events
Publisher: CL-16-EN-01
Consumers: PF-04 audit, operations analytics
Status: 📝 Planned
Purpose: Record submission of a TEFCA/QHIN patient query with traceable correlation. Payload minimums: event_id, organization_id, patient_id, correlation_id, status = 'submitted', requester context. event_id MUST be a UUID string and is required for idempotency/retry semantics.

Event: cl_tefca_exchange_completed \

Channel: cl_pm_events
Publisher: CL-16-EN-01
Consumers: PF-04 audit, CL-12 downstream exchange consumers
Status: 📝 Planned
Purpose: Record successful TEFCA/QHIN exchange completion for downstream retrieval/processing. Payload minimums: event_id, organization_id, patient_id, correlation_id, status = 'completed', exchange log reference. event_id MUST be a UUID string and is required for idempotency/retry semantics.

Event: cl_tefca_exchange_blocked \

Channel: cl_pm_events
Publisher: CL-16-EN-01
Consumers: PF-04 audit, compliance workflows
Status: 📝 Planned
Purpose: Record policy/consent-blocked TEFCA exchange attempts (fail-closed path). Payload minimums: event_id, organization_id, patient_id, correlation_id, status = 'blocked', policy/consent block reason code. event_id MUST be a UUID string and is required for idempotency/retry semantics.

CL-16: FHIR Interoperability & Data Exchange Events

Event: cl_fhir_bundle_exported

Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-16
Subscribers: PF-04 (Audit), PF-10 (Notifications)
Status: 🟡 In Progress (Phase 1)
Spec Reference: CL-16
Purpose: Published when a FHIR $patient-everything bundle or bulk export is completed. Triggers audit logging and optional notifications to compliance staff. Trigger Conditions: Successful completion of patient-everything action in the fhir-r4 edge function. Payload Schema: PHI Logging Guidelines:
  • Allowed: chart_id, exchange_log_id, organization_id, user_id, exchange_type, resource_types, record_count, has_part2_consent
  • Prohibited: Patient names, DOB, SSN, diagnosis codes, medication names, clinical content
  • Retention: Event logged to pf_audit_logs; no PHI in application logs or edge function stdout
Consumer Actions:
  1. PF-04 (Audit): Log export event to pf_audit_logs with exchange details
  2. PF-10 (Notifications): Optionally notify compliance officer for bulk/patient-access exports
Idempotency: Unique on (correlation_id, event_type). Consumers should deduplicate by exchange_log_id.

Event: cl_ccda_document_sent

Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-16
Subscribers: PF-04 (Audit), GR (Governance & Compliance)
Status: 📝 Planned (Phase 2)
Spec Reference: CL-16
Purpose: Published when a C-CDA 2.1 document is sent to an external partner (e.g., Arizona Contexture HIE, DirectTrust recipient). Triggers audit logging and compliance tracking. Trigger Conditions: Successful transmission of C-CDA document to external recipient. Payload Schema: PHI Logging Guidelines:
  • Allowed: chart_id, exchange_log_id, organization_id, user_id, document_type, partner_id, partner_name, has_part2_consent, redisclosure_notice_included
  • Prohibited: Patient names, DOB, SSN, clinical content, diagnosis codes
  • Retention: Event logged to pf_audit_logs; no PHI in application logs
Consumer Actions:
  1. PF-04 (Audit): Log send event with partner details and document type
  2. GR (Compliance): Track C-CDA exchanges for regulatory reporting; verify redisclosure notice compliance
Idempotency: Unique on (correlation_id, event_type). Consumers deduplicate by exchange_log_id.

Event: cl_ccda_document_received

Channel: cl_pm_events
Publisher: CL (Clinical & EHR) — CL-16
Subscribers: CL-01 (Patient Chart), PF-10 (Notifications)
Status: 📝 Planned (Phase 2)
Spec Reference: CL-16
Purpose: Published when a C-CDA 2.1 document is received from an external partner (e.g., HIE, DirectTrust sender). Triggers chart update and notifications to the assigned clinician. Trigger Conditions: Successful ingestion and parsing of inbound C-CDA document. Payload Schema: PHI Logging Guidelines:
  • Allowed: chart_id, exchange_log_id, organization_id, document_type, partner_id, partner_name, resource_types_extracted, record_count, reconciliation_needed
  • Prohibited: Patient names, DOB, SSN, extracted clinical content, diagnosis codes, medication names
  • Retention: Event logged to pf_audit_logs; no PHI in application logs
Consumer Actions:
  1. CL-01 (Chart): Flag chart for reconciliation review if reconciliation_needed = true; store document reference in cl_patient_chart_documents
  2. PF-10 (Notifications): Notify assigned clinician that new external data is available for review
Idempotency: Unique on (correlation_id, event_type). Consumers deduplicate by exchange_log_id.

PM-13: Telehealth Integration Events

Event: telehealth_session_started

Channel: cl_pm_events
Publisher: PM-13 (Telehealth Integration)
Status: ✅ Implemented
Last Verified: 2026-02-23
Purpose: Published when a telehealth session transitions to active status. Provides encounter context for modifier selection and clinical documentation. Trigger Conditions: pm_telehealth_sessions.session_status updated from scheduled or waiting to active. Payload Schema: PHI Logging Guidelines:
  • Allowed: session_id, appointment_id, encounter_id, organization_id, telehealth_modality, platform, user_id
  • Prohibited: Patient names, DOB, SSN, session URLs, join links, recording URLs
  • Retention: Event logged to pf_audit_logs; no PHI in application logs
Consumer Actions:
  1. FW-16 (Workflow): Trigger automation rules on session start (e.g., notify care team)
  2. PF-10 (Notifications): Send session-started notification to relevant staff
Idempotency: Unique on (correlation_id, event_type). Consumers deduplicate by session_id.

Event: telehealth_session_completed

Channel: cl_pm_events
Publisher: PM-13 (Telehealth Integration)
Status: ✅ Implemented
Last Verified: 2026-02-23
Purpose: Published when a telehealth session transitions to completed status. Provides session metadata for PM-07 auto-modifier/POS assignment and CL-04 clinical documentation pre-fill. Trigger Conditions: pm_telehealth_sessions.session_status updated to completed. Payload Schema: PHI Logging Guidelines:
  • Allowed: session_id, appointment_id, encounter_id, organization_id, telehealth_modality, duration_minutes, user_id
  • Prohibited: Patient names, DOB, SSN, session URLs, recording URLs, patient_location (may reveal home address)
  • Masking: patient_location logged as presence flag (has_patient_location: true/false), not raw value
  • Retention: Event logged to pf_audit_logs; no PHI in application logs
Consumer Actions:
  1. PM-07 (Charge Capture): Apply telehealth modifiers (95/FQ/GQ) and POS (02/10) based on telehealth_modality and patient_location when clinical_note_finalized fires
  2. FW-16 (Workflow): Trigger post-session automation (e.g., satisfaction survey, follow-up scheduling)
  3. CL-04 (Progress Notes): Pre-fill telehealth fields (is_telehealth, telehealth_modality, patient_location, provider_location) on the clinical note
Idempotency: Unique on (correlation_id, event_type). Consumers deduplicate by session_id.
Next Review: 2026-03-03 (Quarterly)

PM-15: Clearinghouse Integration Events

Status: 📝 Planned Implemented: TBD Spec Reference: PM-15 (Clearinghouse Integration)

Event 1: clearinghouse_batch_submitted

Publisher: PM (Practice Management) — PM-15 Clearinghouse Subscribers: PM-08 (Claims), PF-10 (Notifications), PM-11 (RCM Dashboard) Payload Schema:
Purpose: Notify downstream systems that a batch has been successfully transmitted to the clearinghouse. PHI Logging Guidelines:
  • Allowed: batch_id, clearinghouse_id, transaction_type, record_count, organization_id, user_id
  • Prohibited: file_name (if it contains patient names/MRNs)
  • Masking: Log file_name only if guaranteed safe (e.g., BATCH_20260223_001.x12); otherwise hash or redact
  • Retention: Logged to pf_audit_logs
Consumer Actions:
  1. PM-08 (Claims): Update claim status to submitted for all claims in the batch
  2. PM-11 (RCM Dashboard): Increment submission metrics
  3. PF-10 (Notifications): Notify billing admin of successful submission

Event 2: clearinghouse_batch_error

Publisher: PM (Practice Management) — PM-15 Clearinghouse Subscribers: PM-08 (Claims), PF-10 (Notifications) Payload Schema:
Purpose: Notify that a batch submission failed (e.g., connectivity error, 999 rejection). PHI Logging Guidelines:
  • Allowed: batch_id, clearinghouse_id, transaction_type, error_code, organization_id
  • Prohibited: error_message (if it contains patient identifiers from a rejection)
  • Masking: Sanitize error_message to remove potential PHI before logging
  • Retention: Logged to pf_audit_logs
Consumer Actions:
  1. PM-08 (Claims): Update claim status to error / draft (returned for correction)
  2. PF-10 (Notifications): Alert billing admin of submission failure

Event 3: clearinghouse_era_received

Publisher: PM (Practice Management) — PM-15-P2 Clearinghouse Transport (Phase 2b) Subscribers: PM-09 (Payment Posting & ERA), PM-29 (Denial Management) Channel: pm_events Status: 📝 Planned Payload Schema:
Purpose: Notify downstream systems that an 835 ERA file has been retrieved from the clearinghouse and parsed. PM-09 uses this to trigger the payment posting pipeline; PM-29 uses CARC/RARC data from the parsed ERA for denial routing. PHI Logging Guidelines:
  • Allowed: event_id, correlation_id, era_file_id, batch_id, claim_count, total_paid, organization_id
  • Prohibited: Storage object paths and individual CLP/SVC claim-level data
  • Masking: If internal diagnostics require a storage lookup, log only the opaque era_file_id
  • Retention: Logged to pf_audit_logs
Consumer Actions:
  1. PM-09 (Payment Posting & ERA): Resolve storage location from era_file_id, then run payment posting pipeline — create pm_payments and pm_payment_applications from CLP/SVC data; persist CARC/RARC into pm_transaction_log.error_codes
  2. PM-29 (Denial Management): Route CARC/RARC codes for denial intake and appeal workflow

Event 4: clearinghouse_health_changed

Publisher: PM (Practice Management) — PM-15-P2 Health Monitoring (Phase 2c) Subscribers: PF-10 (Notifications) Channel: pm_events Status: 📝 Planned Payload Schema:
Purpose: Notify when clearinghouse connection health status changes. PF-10 fires alerts on transitions to down or degraded; recovery notifications are throttled (require 2 consecutive healthy checks before alerting on healthy transition). PHI Logging Guidelines:
  • Allowed: All fields (no PHI in health status events)
  • Prohibited: None (event contains no patient data)
  • Retention: Logged to pf_audit_logs
Consumer Actions:
  1. PF-10 (Notifications): Alert billing admin on down or degraded; send recovery notification on healthy (throttled: 2 consecutive healthy checks required)

PM-47: Managed Care Auth Tracking

Status: 📝 Planned Spec Reference: PM-47-managed-care-authorization-tracking.md Integration Doc: PM-47-managed-care-authorization-tracking-INTEGRATION.md

Event: pm_auth_expiring

Channel: pm_events Publisher: PM (Practice Management) — PM-47 Subscribers: PM (dashboard refresh), CL (clinical review preparation) Trigger: Daily cron edge function checks authorizations approaching expiration thresholds Status: 📝 Planned Payload Schema:
PHI Logging Guidelines:
  • Allowed (PHI-safe identifiers): event_id, correlation_id, authorization_id, patient_id (UUID only), payer_id, expiration_date, days_remaining, service_type, organization_id
  • Prohibited: Patient name, DOB, auth details beyond what’s in schema
  • Retention: Event logged to pf_audit_logs
  • Logging Guidance: Log only event_id, correlation_id, and non-PHI identifiers (e.g., organization_id, authorization_id, payer_id) in application logs; omit patient-identifiable data
Consumer Actions:
  1. PM (dashboard): Refresh auth expiration dashboard counts
  2. CL (clinical review): Pre-populate concurrent review task with auth context

Event: pm_auth_validation_failed

Channel: pm_events Publisher: PM (Practice Management) — PM-47 Subscribers: PM-08 (claim submission gate) Trigger: Pre-submission auth-to-claim validation detects authorization coverage gaps Status: 📝 Planned Payload Schema:
Validation Failure Reason Codes:
  • no_active_auth — No active authorization found for the service date and service type
  • units_exceeded — Claim line units exceed remaining authorized units
  • date_outside_auth — Service date falls outside the authorization’s valid date range
PHI Logging Guidelines:
  • Allowed (PHI-safe identifiers): event_id, correlation_id, claim_id, line_number, reason_code, organization_id
  • Prohibited: Claim line service details, patient identifiers
  • Retention: Event logged to pf_audit_logs
  • Logging Guidance: Log only event_id, correlation_id, and non-PHI identifiers (e.g., organization_id, claim_id, reason_code) in application logs; omit patient-identifiable data and the optional message field
Consumer Actions:
  1. PM-08 (claim submission): Block claim submission; display validation failure details to user

CL-21: MAT/MOUD Tracking Events

cl_moud_monitoring_overdue

Publisher: CL-21 (MAT/MOUD Tracking)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Channel: cl_events
Description: Fired when a monitoring event (UDS, hepatic panel, etc.) passes its due_by timestamp without a completed_at value. Payload Schema:
PHI Logging Guidelines:
  • Allowed: monitoring_event_id, enrollment_id, monitoring_type, due_by, days_overdue, organization_id
  • Prohibited: chart_id should be logged as has_chart_id: true/false, not as raw UUID
  • Retention: Logged to pf_audit_logs
Consumer Actions:
  1. PF-10 (Notifications): Alert clinical staff and supervisors of overdue monitoring

cl_moud_adherence_risk

Publisher: CL-21 (MAT/MOUD Tracking)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Channel: cl_events
Description: Fired when a patient’s medication adherence status indicates risk (e.g., consecutive missed doses or declining adherence pattern). Payload Schema:
PHI Logging Guidelines:
  • Allowed: enrollment_id, adherence_status, consecutive_missed_count, organization_id
  • Prohibited: chart_id should be logged as has_chart_id: true/false, not as raw UUID
  • Retention: Logged to pf_audit_logs
Consumer Actions:
  1. PF-10 (Notifications): Alert prescriber and care team of adherence risk

PF-48: Security Event Detected

Status: ✅ Implemented
Event: security_event_detected
Channel: Database Webhook on pf_security_events INSERT
Publisher: PF-48 (Security Event Monitoring)
Subscribers: PF-04 (Audit), PF-10 (Notifications), PF-36 (Health Dashboard)
Delivery Mechanism: Supabase Database Webhook triggers security-event-alert-delivery Edge Function on INSERT to pf_security_events. Payload (webhook record):
Handler Requirements:
  1. Refetch full row from pf_security_events by event_id before processing
  2. Verify organization_id matches webhook payload (TOCTOU protection)
  3. Match against pf_security_alert_configs for active alert rules
  4. Deliver via PF-10 with retry (3 attempts, exponential backoff)
  5. Write to pf_security_alert_delivery_failures (DLQ) on permanent failure
PHI: No PHI in payload. Event metadata only (IDs, types, severity). Consumer Actions:
  1. PF-10 (Notifications): Deliver security alerts to configured recipients
  2. PF-04 (Audit): Log security event processing
  3. PF-36 (Health Dashboard): Display security event metrics

PF-43: Quota Violated

Status: 📝 Planned
Event: pf_quota_violated
Publisher: PF-43 (Quota enforcement framework)
Subscribers: PF-10 (Notifications), PF-48 (Security Event Monitoring — future)
Purpose: Notify platform and organization admins when a quota soft or hard limit is exceeded. Payload (canonical): All payload keys use snake_case. Envelope fields are required for idempotency and routing per Event Schema Standard (§ Idempotency and Retry). Integration Doc: PF-43-tenant-resource-quotas-INTEGRATION.md — see pf_quota_violated schema and envelope. Consumer Actions:
  • PF-10: Send notification to platform/org admins per alert threshold and mute settings
  • PF-48: Ingest security event for monitoring/analytics

PF-36 Phase 2: SLA Violation Events

pf.sla.violation.detected

Publisher: PF-36 (System Health Dashboard — SLA Violation Detection)
Subscribers: PF-10 (Notifications)
Trigger: pf-detect-sla-violations edge function detects metric value breaching SLA threshold.
SLA: Processing < 1s p95 Consumer Actions:
  1. PF-10 (Notifications): Deliver SLA violation alerts to configured recipients (in-app + email)

pf.sla.violation.resolved

Publisher: PF-36 (System Health Dashboard — SLA Violation Detection)
Subscribers: PF-10 (Notifications)
Trigger: pf-detect-sla-violations detects metric returned to within SLA threshold.
Consumer Actions:
  1. PF-10 (Notifications): Deliver resolution notification to original alert recipients

PF-68: Website Chatbot — Lead Captured

pf_chatbot_lead_captured

Status: ✅ Implemented
Publisher: chatbot-lead-capture edge function
Channel: domain_events
Subscribers: Payload:
Consumer Actions:
  1. CE-01: Link lead to chatbot session source, set source_type = 'chatbot'
  2. PF-35: Forward lead data to configured webhook endpoints

CE: Community Engagement Events

ce.suppression.created

Status: 📝 Planned (CE-16) Publisher: CE-16 (Communications Compliance & Suppression) Channel: domain_events Spec Reference: CE-16 spec Subscribers: Payload (IDs only — no PII/PHI):
Idempotency: suppression_id — subscribers MUST deduplicate. PII Handling: No phone numbers, emails, or names in the payload. Consumers needing contact details MUST resolve via authorized read of ce_contacts.

ce_lead_converted

Status: ✅ Implemented (⚠️ Deprecated — CE-29: use ce_lead_converted_to_patient or ce_lead_converted_to_resident instead) Publisher: CE-01 (Contacts & Lead Management)
Channel: domain_events
Spec Reference: CE-17 CE–RH Admission Handoff Contract
Subscribers: Payload:
Consumer Actions:
  1. RH-01:
    • Resolve contact PII by reading ce_contacts via contact_id with authorized access (RLS-enforced)
    • Create resident admission record with mapped fields from resolved contact data
    • Check idempotency via lead_id + organization_id (or fallback to event_id from audit table)
PII Handling: This event does NOT include PII (names, emails, phones, addresses, DOB) in the payload. Consumers MUST resolve PII by reading from ce_contacts using the provided contact_id with proper authorization checks. This ensures PII is only accessed by authorized consumers and maintains audit trails. Idempotency: RH consumer MUST check for existing admission using lead_id + organization_id before creating resident record. If lead_id is not available, fallback to event_id lookup in audit tables.

ce_lead_converted_to_patient

Status: 🔜 In Progress
Publisher: CE-29 (Lead-to-Patient Conversion Pipeline)
Channel: domain_events
Spec Reference: CE-29 Integration
Subscribers: Payload: IDs only (no PII/PHI). See CE-29 integration doc for full schema.
Idempotency: correlation_id — subscribers MUST deduplicate.

ce_lead_converted_to_resident

Status: 🔜 In Progress
Publisher: CE-29 (Lead-to-Patient Conversion Pipeline)
Channel: domain_events
Spec Reference: CE-29 Integration
Subscribers: Payload: IDs only (no PII/PHI). See CE-29 integration doc for full schema.
Idempotency: correlation_id — subscribers MUST deduplicate.

donation_received

Status: 📝 Planned
Publisher: CE-18 (Fundraising & Donation Events)
Channel: domain_events
Spec Reference: CE-18 Fundraising & Donation Events, FA-31 CE-FA Donation Revenue Integration
Subscribers: Payload:
Consumer Actions:
  1. FA-31: Create GL journal entry (debit cash/AR, credit revenue) with fund allocation; check idempotency via event_id
Idempotency: FA consumer MUST track processed event_ids and MUST NOT create duplicate GL entries.

fundraising_campaign_completed

Status: 📝 Planned
Publisher: CE-18 (Fundraising & Donation Events)
Channel: domain_events
Spec Reference: CE-18 Fundraising & Donation Events, FA-31 CE-FA Donation Revenue Integration
Subscribers: Payload:
Consumer Actions:
  1. FA-07: Update campaign revenue reports with completion summary
  2. FA-31 (Optional): Generate campaign summary journal entry or report flag
Idempotency: FA consumer MUST track processed event_ids or use campaign_id + organization_id + completion_date composite key.

ce_web_form_submitted

Status: 📝 Planned
Publisher: CE-10 (Web-to-Lead Capture)
Channel: domain_events
Spec Reference: CE-10 Web-to-Lead Capture
Subscribers: Payload:
Consumer Actions:
  1. CE-01: Lead already created; event enables workflow automation triggers
  2. CE-05: Update pipeline analytics (web form submission metrics)
  3. PF-10: Send notification to assigned staff member
Note: Full submission data is stored in ce_web_form_submissions table (accessible via submission_id). Event payload contains only summary metadata (no PII).

FW-49: Execution Timeout & Watchdog Events

Integration: FW-49-execution-timeout-watchdog-INTEGRATION.md
See also: EVENT_DELIVERY.md — when these fire relative to the table-driven automation path.

workflow.execution.timed_out

Status: ✅ Implemented
Publisher: FW (via workflow-timeout-checker Edge Function; pg_cron–scheduled)
Channel: fw_events
Consumers: FW-47 (DLQ), FW-25 (compensation), FW-22 (monitoring)

workflow.execution.deadline_extended

Status: ✅ Implemented
Publisher: FW (via extend-execution-deadline Edge Function)
Channel: fw_events
Consumers: Audit trail, FW-22 (monitoring)

FW-47: Dead Letter Queue Alert Events

Integration: FW-47-dead-letter-queue-INTEGRATION.md
Publisher: FW DLQ threshold monitoring (scheduled job / worker path per integration doc)
Channel: In-app / PF-10 notifications (operational alerts; not necessarily pg_notify channels)

fw_dlq_threshold_exceeded

Status: ✅ Implemented (operational alert via PF-10)
Consumers: Automation admins, org admins (notification); optional future subscribers for dashboards
Payload (logical):
Note: event_id MUST be a UUID. Timestamps remain ISO-8601, consistent with the document’s idempotency/retry guidance.

fw_dlq_new_permanent_failure

Status: ✅ Implemented (operational alert via PF-10)
Consumers: Automation admins; links to DLQ entry review UI
Payload (logical):
Note: event_id MUST be a UUID. Timestamps remain ISO-8601, consistent with the document’s idempotency/retry guidance.
Note: Exact notification payload shapes may mirror PF-10 notification templates; align with fw_dead_letter_queue and DLQ settings in FW module.

Planned Events (PF-82 Business Process Registry)

process_health_changed

Status: 📝 Planned
Publisher: PF (via pf_refresh_process_health scheduled function)
Channel: domain_events
Consumers: PF-36 (System Health Dashboard), PF-10 (Notifications)

process_discovered

Status: 📝 Planned
Publisher: PF (via auto-discovery cron)
Channel: domain_events
Consumers: PF-04 (Audit Logging)

PF-83: SLA Management Events

pf_sla_warning_triggered

Status: 📝 Planned
Publisher: PF (via pf-sla-checker edge function)
Channel: domain_events
Consumers: PF-10 (Notifications)

pf_sla_breached

Status: 📝 Planned
Publisher: PF (via pf-sla-checker edge function)
Channel: domain_events
Consumers: PF-10 (Notifications), FW-03 (Workflow Automation, optional)

pf_sla_completed

Status: 📝 Planned
Publisher: PF (via event-driven instance resolution)
Channel: domain_events
Consumers: PF-04 (Audit Logging)

PF-91: Compliance Automation & Regulatory Dashboard

Spec / integration: PF-91 spec, PF-91 integration

pf_compliance_drift_detected

Status: 📝 Planned Publisher: PF (via compliance-run-checks Edge Function) Channel: domain_events Consumers: PF-10 (Notifications), PF-04 (Audit Logging)

pf_compliance_evidence_ready

Status: 📝 Planned Publisher: PF (via generate-compliance-evidence Edge Function) Channel: domain_events Consumers: PF-10 (Notifications, optional)

PF-96: Medicaid State Compliance Configuration

Spec / integration: PF-96 spec, PF-96 integration

pf_jurisdiction_profile_changed

Status: 📝 Planned Publisher: PF-96 (on org/site jurisdiction config change) Channel: domain_events Subscribers: CL-02, CL-04, CL-11, CL-40, PM-07, PM-08, PM-10, PM-18, PM-41, PF-91 Version: 1.0 Purpose: Notifies consumers when an organization or site changes its jurisdiction profile assignment, enabling cache invalidation and rule refresh across clinical and billing modules. Payload Schema:
Deduplication: Use event_id for idempotency. Ordering: Consumers should process events by timestamp ascending within each (organization_id, site_id) partition. Consumer Actions:
  • CL-02, CL-04, CL-11, CL-40: Invalidate cached clinical rules; refetch useClinicalRules() for assessment/note/consent validation
  • PM-07, PM-08, PM-10, PM-18, PM-41: Invalidate cached billing rules; refetch useBillingRules() for charge capture/claims/scrub
  • PF-91: Refresh compliance dashboard to reflect new jurisdiction requirements
Error Handling: Consumers must handle profile resolution failures gracefully; fallback to federal baseline if new profile unavailable.

ce_screening_completed

Status: ✅ Implemented
Publisher: CE-28 (Intake Screening & Triage Workflow)
Channel: domain_events
Spec Reference: CE-28 Integration
Implementation: src/cores/ce/hooks/useCreateScreening.ts (client-side, consent-gated per 42 CFR Part 2)
Subscribers: Payload:
Consent Gate (CRITICAL): This event is only published when consent_obtained = true on the screening attempt. No PHI is included in the payload — only IDs and clinical disposition metadata. This complies with 42 CFR Part 2 requirements for SUD data. Idempotency: correlation_id (screening attempt ID) — subscribers MUST deduplicate.

ce_lead_waitlisted

Status: ✅ Implemented
Publisher: CE-28 (conditional — emitted when disposition = 'proceed' but bed unavailable)
Channel: domain_events
Spec Reference: CE-28 Integration
Implementation: src/cores/ce/hooks/useCreateScreening.ts
Subscribers: Payload:
Consent Gate: Only published when consent_obtained = true. Idempotency: correlation_id — subscribers MUST deduplicate.

ce_crisis_alert_created

Status: 📝 Planned — CE-28-ENHANCEMENTS EN-01 Publisher: CE-28-ENHANCEMENTS EN-01 (Crisis-Keyword AI Alerting) Channel: domain_events Spec Reference: CE-28-ENHANCEMENTS §EN-01; CONTEXT D-10 Subscribers: Payload:
PHI Gate (CRITICAL): Payload contains IDs and tier metadata only — NO patient narrative, NO detected keywords, NO evidence excerpts. Subscribers needing alert detail MUST query the CE API with alert_id (RLS-enforced). Idempotency: correlation_id (alert ID) — subscribers MUST deduplicate.

CE-75: HubSpot Inbound Sync Events

Registered with CE-75 (HubSpot Connection & Inbound Contact Sync). All four payloads are PHI-free by contract — connection/run ids, HubSpot record ids, event types, and bucket counts only; never contact field values, never token material (spec §Integration Points; the sync pipeline itself reaches consumers through ce_hubspot_sync_log + CE-60 audit rows, not events). Publisher wiring lands with the first cross-core consumer; the UI surfaces (sync health, re-auth banner, backfill report) currently read the tables directly.

ce_hubspot_connected

Status: 📝 Planned (registered) — CE-75 Publisher: ce-hubspot-oauth (callback leg, after the connection upsert) Channel: domain_events Spec Reference: CE-75 Integration Payload:

ce_hubspot_connection_needs_reauth

Status: 📝 Planned (registered) — CE-75 Publisher: ce-hubspot-sync-worker (refresh-failure flip; mirrors the PF-10 notification of AC-11) Channel: domain_events Spec Reference: CE-75 AC-11 Payload:

ce_hubspot_sync_dead_letter

Status: 📝 Planned (registered) — CE-75 Publisher: ce-hubspot-sync-worker (retry-exhaustion archive; AC-10) Channel: domain_events Spec Reference: CE-75 AC-10 Payload:

ce_hubspot_backfill_completed

Status: 📝 Planned (registered) — CE-75 Publisher: ce-hubspot-backfill (terminal completed checkpoint; AC-12/14) Channel: domain_events Spec Reference: CE-75 AC-12 Payload:
PHI Gate (ALL four): ids, counts, enum strings, and timestamps only — no contact field values, no HubSpot property payloads, no token material, no error text (sanitized errors live in ce_hubspot_sync_log). Idempotency: correlation_id per event as noted — subscribers MUST deduplicate.

CL-14-EN-01: Group Encounter Generation Events

cl_group_encounters_approved

Contract ID: EVT-CL-14-EN-01-001
Publisher: CL-14-EN-01
Subscribers: PM-07
Channel: cl_events
Version: 1.0
Purpose: Notify PM-07 that a reviewed set of generated group encounters has been approved and is ready for charge creation.
Trigger: Batch approval action in CL-14-EN-01 review UI (single or bulk approve).
Payload Schema:
PHI: Payload contains identifiers only; no direct PHI content. Idempotency: event_id — PM-07 consumer must deduplicate and process at-most-once per event_id.

CL-40: Clinical Intake & SDOH Assessment Events \

cl_intake_finalized

Publisher: CL-40 (on intake assessment finalization) Subscribers: PM-07 (charge creation), CL-18 (SDOH referral follow-up) Version: 1.0 Payload Schema:
PHI: Payload contains IDs only — no PHI per 42 CFR Part 2 / HIPAA. Idempotency: event_id — subscribers MUST deduplicate.

cl_sdoh_referral_created

Publisher: CL-40 (on SDOH screening positive → auto-referral) Subscribers: CL-18 (social referral tracking) Version: 1.0 Payload Schema:
PHI: Payload contains IDs only — no PHI. Idempotency: event_id — subscribers MUST deduplicate.

cl_peer_encounter_documented

Publisher: CL-40 (on peer encounter creation/signature) Subscribers: PM-07 (CPT charge creation) Version: 1.0 Payload Schema:
PHI: Payload contains IDs only — no PHI. Idempotency: event_id — subscribers MUST deduplicate.

PF-98: AI Staff Headshot Generator

pf_headshot_job_completed

Publisher: PF-98 (Edge Function pf-headshot-webhook) Subscribers: PF-10 (user notification), PF-43 (quota decrement) Version: 1.0 Status: 📝 Planned Payload Schema:
PHI: Payload contains IDs only — no PHI or biometric data. Idempotency: event_id — subscribers MUST deduplicate.

pf_headshot_campaign_completed

Publisher: PF-98 (Edge Function pf-headshot-webhook or pf-headshot-status-poll) Subscribers: PF-10 (admin notification) Version: 1.0 Status: 📝 Planned Payload Schema:
PHI: Payload contains IDs and counts only — no PHI or biometric data. Idempotency: event_id — subscribers MUST deduplicate.

cl_referral_status_updated

Publisher: CL-12-EN-67 (Bi-Directional Referral — status history insert trigger) Subscribers: PF-10 (notifications, audit logging) Channel: cl_events Version: 1.0 Status: 📝 Planned Trigger Conditions:
  • INSERT on cl_referral_status_history — fires after a new status entry is recorded for a referral.
Payload Schema:
PHI: Payload contains IDs and status only — no PHI, patient names, or narrative content. Idempotency: event_id — subscribers MUST deduplicate.

PF-100: Platform Ambient Transcription Events

Status: 📋 Planned Spec: PF-100 Integration: PF-100 Integration Channel: pf_transcription_events Common metadata: every payload includes { session_id: uuid, organization_id: uuid, timestamp: ISO-8601, correlation_id: uuid }. PHI-safe: payloads carry IDs only — never transcript text, names, or clinical narrative. All subscribers MUST deduplicate by event_id.

Published events

Consumed events

PHI / privacy: No event payload may contain transcript text, draft content, patient/employee/resident names, or any free-text clinical narrative. Numeric metrics (latency, diff %, counts) and IDs only. Subscribers needing content MUST query the appropriate pf_transcription_* table directly (subject to RLS). Idempotency: All events carry event_id (UUID). Subscribers MUST deduplicate. Per-event triggers are SECURITY DEFINER and emit at-least-once.

Planned Events (PM-64 AI Coding Assistant)

Spec: PM-64 AI Coding Assistant — 📋 Specification Pattern: Event + Platform Integration Layer. PM-64 consumes a CL-04 event to trigger redaction → RAG → LLM → suggestion, then publishes its own events when suggestions are created and when coders accept / edit / reject. NO PHI in any payload (constitution §4.3, GR-06-EN-01).

CL-04: Note Finalized (consumed by PM-64)

Event: cl_note_finalized Publisher: CL (Clinical) — CL-04 Subscribers: PM-64 (AI coding suggestion trigger), PM-07 (charge capture eligibility), PF-10 (notifications) Status: 📋 Planned (PM-64 will be the first formal consumer) Channel: cl_clinical_events PHI: Payload carries IDs only — never note text. PM-64 reads the note via @/platform/clinical and runs PHI redaction (fail-closed) before any LLM call.

PM-64: AI Coding Suggestion Created

Event: pm.ai_coding_suggestion_created Publisher: PM (PM-64 pm-ai-coding-suggest edge function) Subscribers: PM (Coder UI sidecar — CodingSuggestionSidecar), GR (compliance audit), PM-50-EN-01 (fairness drift monitor) Status: 📋 Planned (PM-64) Channel: pm_events PHI: None. IDs and model metadata only.

PM-64: AI Coding Decision Recorded

Event: pm.ai_coding_decision_recorded Publisher: PM (PM-64 pm-ai-coding-record-decision edge function) Subscribers: PM-07 (charge capture — only on accepted / edited), PM-50 (denial-risk model retraining feed), GR (compliance audit queue), PM-50-EN-01 (fairness drift monitor) Status: 📋 Planned (PM-64) Channel: pm_events PHI: None. Decision metadata + IDs only; rejection_reason is structured (enum) — no free-text narrative.
Naming exception: PM-64 events use the dotted pm.ai_coding_* form to align with the existing PM-51 RPA naming exception and to namespace the AI coding subsystem cleanly. New non-AI PM events should still follow the pm_{entity}_{action} underscore convention.

CL-43: Concurrent Review & Utilization Management Events

Status: 📋 Planned (CL-43). Payloads are PHI-free — IDs and structured metadata only (no clinical narrative, no patient demographics). Channel: cl_clinical_events Integration doc: CL-43-concurrent-review-utilization-management-INTEGRATION.md

CL-43: Review Overdue

Event: cl_review_overdue Publisher: CL (CL-43 — cl-review-overdue-scan cron / trigger on cl_concurrent_reviews) Subscribers: PF-10 (notifications — UM coordinator + supervisor escalation), CL-08 (CDS alert surface) Status: 📋 Planned (CL-43) Channel: cl_clinical_events PHI: None. IDs only — consumers must read the review record via @/platform/clinical if narrative context is needed.
Idempotency: Consumers MUST dedupe on (review_id, escalation_tier) — the scan re-emits at most once per tier per review.

CL-43: Review Determination Recorded

Event: cl_review_determination_recorded Publisher: CL (CL-43 — useRecordDetermination mutation, post-commit trigger on cl_concurrent_reviews) Subscribers: PM-11 (revenue cycle analytics — auth utilization + denial impact) Status: 📋 Planned (CL-43) Channel: cl_clinical_events PHI: None. Determination metadata + IDs + payer reference only. denial_reason_code is a structured payer reason code (no free-text narrative).
Idempotency: Consumers MUST dedupe on review_id — re-emission only occurs if a prior determination is overturned via appeal (CL-43 publishes a new event with updated determination).

PM-55: ONC HTI-1 / USCDI v3 Patient Access API Events

Status: 📋 Planned (PM-55). Payloads are PHI-free — IDs only. Full schemas to be finalized when PM-55 Phase 1 implements the publishers. Naming exception: PM-55 uses the dotted pm.fhir_* form to namespace the FHIR/SMART subsystem (consistent with PM-51 RPA and PM-64 AI Coding exceptions).

pm.fhir_app_authorized

Publisher: PM (PM-55 useGrantAppConsent mutation / pm-fhir-token edge function) Subscribers: PF-04 (audit), GR (compliance metrics) Channel: pm_events PHI: None — IDs only.

pm.fhir_app_revoked

Publisher: PM (PM-55 useRevokeAppAccess) Subscribers: PF-04 (audit), GR Channel: pm_events PHI: None.

pm.fhir_information_blocking_logged

Publisher: PM (PM-55 pm-fhir-router) Subscribers: GR-08 (incident reporting — escalates when disposition = info_blocking) Channel: pm_events PHI: None — denial_narrative is NOT included in event payload (stored only on pm_information_blocking_log row, retrieved server-side).

pm.fhir_access_logged

Publisher: PM (PM-55 pm-fhir-router — emitted on every FHIR request, success or denial) Subscribers: PF-04 (HIPAA audit stream) Channel: pm_events PHI: None — IDs + status only; no request body, no resource contents. Volume note: High-cardinality. Subscribers should batch.
Consumed events from CL-11: cl.part2_consent_granted and cl.part2_consent_revoked are required by PM-55. TBD by CL-11 owner — tracked in PENDING_CONTRACTS.md until CL-11 publishes them. If CL-11 cannot publish, PM-55 will fall back to polling cl_consents.updated_at per a separate decision log entry.

CL-42: Clinical Pathways & Protocol-Driven Care

Owning core: CL · Channel: cl_events · Spec: specs/cl/specs/CL-42-clinical-pathways-protocol-driven-care.md CL-42 publishes 3 canonical snake_case events. Payloads carry IDs only — no PHI/PII. Consumers join to their own data using the IDs.

cl_pathway_milestone_completed

Publisher: CL (useMilestoneMutations.useCompleteMilestone) Consumers: CL-10 (outcomes trigger), CL-08 (CDS rule re-evaluation), CL-23 (in-basket task closure)
Idempotency: keyed on (milestone_id) — milestone status transitions to completed exactly once. Retry: at-least-once delivery; consumers must dedupe on milestone_id.

cl_pathway_variance_created

Publisher: CL (useDocumentVariance) Consumers: CL-08 (CDS rule trigger), GR (variance reporting), CL-15 (quality measures)
Idempotency: keyed on (variance_id). PHI: rationale field is NEVER included in the event payload — only the reason_code reference.

cl_pathway_milestone_overdue

Publisher: CL edge function cl-pathway-overdue-check (hourly pg_cron) Consumers: CL-08 (CDS alert generation), CL-23 (in-basket task creation), GR (compliance tracking)
Idempotency: keyed on (milestone_id) — published once per milestone status transition pending|in_progressoverdue. The cron updates status to overdue in the same transaction; subsequent runs skip already-overdue milestones. Batching: processed in batches of 100 milestones per invocation.

CL-46: Problem List Management Events

cl_problem_list_updated

Publisher: CL (useProblemMutation — add / update / inactivate) Consumers: CL-08 (CDS rule re-evaluation on diagnosis change), PM-07 (encounter/charge problem context)
Idempotency: at-least-once delivery; consumers dedupe on (problem_id, action). PHI: IDs + ICD-10 code only — no clinical narrative in the payload.

CL-35: Population Health & Quality Measure Events

cl_quality_measure_period_calculated

Publisher: CL edge function cl-hedis-calculator (pg_cron) → pf_domain_events (source_module: cl, target_module: fa) Consumers: FA VBP / quality-data pipeline (measure-period rollups)
Idempotency: keyed on (measure_id, period_start, period_end) — one row per measure period per cron run. PHI: aggregate counts + measure codes only — no patient-level data.

CL-56: Centralized Clinical Notification & Critical Result Alerting Events

cl_notification_dispatched

Publisher: CL edge function cl-clinical-notify Consumers: CL-25 (audit dashboard SLA metrics)
PHI: No PHI. IDs and severity only — patient name, diagnosis, lab values, and narrative are explicitly prohibited (DB CHECK constraint chk_cl_notification_no_phi on cl_notification_events.payload). Idempotency: keyed on (event_id). Dedup is enforced upstream by cl-clinical-notify (key: signal_type + chart_id + severity [+ source_record_id] within dedup_window_seconds); only the surviving (non-deduped) event publishes this event.

cl_notification_sla_breached

Publisher: CL cron edge function cl-notification-sla-evaluator (every 60s) Consumers: GR-09 (incident reporting — auto-creates safety incident for unacknowledged criticals), CL-25 (audit dashboard)
PHI: No PHI — IDs and severity only. Idempotency: keyed on (event_id). The evaluator sets sla_breached_at in the same transaction it publishes; subsequent runs skip events with non-null sla_breached_at.

CL-68 / PM-74 / GR-27: BHRF Clinical Residential Episode Lifecycle Events

Full contract: CL-GR-PM-BHRF-EPISODE-LIFECYCLE.md. BHRF = A.A.C. R9-10-701–722 (adult), a licensed clinical residential level of care — distinct from RH recovery housing. CL is downstream: GR-27/PM-74 consume CL-68 events but do not depend on CL. No cross-core imports or FKs; residence_ref/chart_ref are id values from payloads. SUD-identifying context gated by CL-11 (42 CFR Part 2) before emission. Idempotency & retry standard (applies to all BHRF events below): every payload carries a unique event_id (UUID) which is the canonical cross-system dedupe key. Consumers MUST record processed event_ids and treat duplicates as success (idempotent). The per-event domain tuple listed under Idempotency is a secondary guard for replay/race safety. Delivery is at-least-once: on transient consumer errors (5xx, timeout) retry with exponential backoff per the canonical R7 policy (1s, 2s, 4s; max 3 retries; do not retry 4xx except 429); fatal errors (schema/validation, consent-denied) are not retried and are dead-lettered for review. Canonical RH event / alias: rh_psychiatric_residential_admission is a logical alias for the canonical RH-01.1 rh_resident_admitted event filtered to facility_type = 'psychiatric_residential' (and likewise rh_resident_discharged). No new RH event is introduced — RH-01.1 canonical names remain authoritative; consumers subscribe to the canonical events and filter by facility_type.

rh_resident_admitted (BHRF-filtered view: facility_type='psychiatric_residential')

Channel: rh_events Publisher: RH (RH-01.1 — canonical rh_resident_admitted) Consumers: CL-68 (open clinical episode), PM-74 (per-diem + 5-day exemption), GR-27 (licensure/staffing applicability) Status: 📝 Planned
PHI: IDs only; no clinical narrative. Idempotency: canonical key event_id; secondary domain guard (organization_id, chart_id, residence_id, admitted_at).

cl_bhrf_loc_determined

Channel: cl_events (single canonical channel) Cross-core handoff: PM-74/GR-27 subscribe to cl_events for this contract; do not dual-publish to alternate channels. Publisher: CL (CL-68) Consumers: PM-74 (authorization context), GR-27 (compliance counters) Status: 📝 Planned
PHI: Coded LOC only; SUD-implying LOC gated by CL-11 before emission. Idempotency: canonical key event_id; secondary domain guard (organization_id, episode_id, determined_at).

cl_bhrf_clinical_assessment_completed

Channel: cl_events Publisher: CL (CL-68) Consumers: GR-27 (15-day timeliness compliance), PM-74 (optional) Status: 📝 Planned
PHI: IDs/timestamps only. Idempotency: canonical key event_id; secondary domain guard (organization_id, episode_id, completed_at).

pm_bhrf_continued_stay_review_required

Channel: cl_pm_events Publisher: PM (PM-74) Consumers: CL-43 (Concurrent Review / UM) — PM-74 publishes; it does not import CL-43. Status: 📝 Planned
PHI: No clinical/SUD context on the authorization handoff. Idempotency: canonical key event_id; secondary domain guard (organization_id, authorization_id, expires_on) — use a stable time boundary (expires_on, or timestamp if expires_on is null). Do not dedupe on remaining_days (mutable across valid successive reviews — would suppress legitimate continued-stay events).

gr_bhrf_compliance_finding_raised

Channel: gr_events Publisher: GR (GR-27) Consumers: PF notifications/dashboards Status: 📝 Planned
PHI: None — facility/regulatory metadata only. Idempotency: canonical key event_id; secondary domain guard (organization_id, residence_ref, finding_type, COALESCE(due_at, timestamp))due_at is optional, so fall back to the event timestamp to avoid falsely deduping distinct findings that both have due_at = null.

pm_residential_charge_held

Channel: pm_events Publisher: PM (PM-74) Consumers: PF dashboards / notifications (operational held-charge worklist) Status: 📝 Planned
PHI: None — billing/operational ids and a coded hold reason only; no clinical/SUD context. Idempotency: canonical key event_id; secondary domain guard (organization_id, residence_ref, chart_ref, service_date, hold_reason) (one hold per per-diem day per reason). At-least-once delivery; retry per the canonical R7 policy as stated in the BHRF idempotency & retry standard above.

CE-24: Partner Contract Renewal Notification

Type: PF-10 notification (not a domain event). Notification type key: contract_renewal_reminder Owner: CE-24 (Partner Document & Contract Management) Producer: ce-contract-renewal-check edge function (daily cron, 08:00 UTC) Consumer: PF-10 (pf_notifications) — delivered to in-app inbox per user notification preferences. Payload (PF-10 notification metadata):
Recipients:
  • Contract created_by user
  • All org users holding permission ce.contracts.manage (resolved via ce_users_with_permission(p_org_id, 'ce.contracts.manage') SECURITY DEFINER helper)
Idempotency: Deduplicated per (contract_id, notification_window) via ce_contract_renewal_log rows with action = 'notification_sent'. Each successful send writes a log row before exiting the per-contract handler. PHI: No PHI — partner and contract metadata only.

PF-110: Clinical Bed Board Read Model (Consumer Only)

PF-110 does not publish any new domain events. It is a read-model/composer that consumes existing events from RH, CL, and PM to invalidate its 30s in-memory cache. No event payload changes are introduced. Consumed events (invalidation triggers): Publishes: None. Future event pf_bed_board_snapshot_refreshed is deferred (see PF-110 spec § Open Questions). Spec Reference: PF-110 Clinical Bed Board Read Model Integration Doc: PF-110-clinical-bed-board-read-model-INTEGRATION.md PHI: Elevated fields (acuity, primary diagnosis, recent assessment) gated by pf.bed_board.view_clinical_details; SUD-related fields redacted unless caller holds cl.sud.view (42 CFR Part 2).

HR-35: Internal Mobility & Talent Marketplace

HR-35 publishes three domain events for internal employee applications and transfer execution. Payloads are PII-minimized — sensitive fields (cover_note, disposition_notes, reason, compensation snapshots) are excluded from events; subscribers must query HR-35 APIs with appropriate authorization for those fields.

hr_internal_application_submitted

Publisher: HR-35 (useSubmitInternalApplication) Subscribers: HR-09 (optional unified applicant panel), HR-16 (succession pipeline) Retention: Per internal_mobility_record_retention_years (default 2 years). PHI: None. Employee identifier only; no clinical or demographic data.

hr_internal_application_advanced

Publisher: HR-35 (useAdvanceApplicationStatus via transitionStatus) Subscribers: HR-16 (succession pipeline updates) Retention: Per internal_mobility_record_retention_years. PHI: None. disposition_notes excluded from payload.

hr_employee_transferred

Publisher: HR-35 (useExecuteTransfer) Subscribers: HR-23 (position assignments — when shipped), HR-15 (compensation reconciliation), HR-18 (workforce analytics) Retention: Per internal_mobility_record_retention_years. PHI: None. Compensation snapshots and reason excluded; subscribers requiring those must hold hr.compensation.view and query HR-35 / HR-15 APIs. Spec: HR-35 Internal Mobility & Talent Marketplace Integration Doc: HR-35-internal-mobility-INTEGRATION.md

HR-09-P5: ATS Advanced Features Events

Status: 📝 Planned (publishers wired during HR-09-P5 execution) Spec: specs/hr/specs/HR-09-ATS-PHASE5-advanced-features.md §Event Contracts All HR-09-P5 events follow the PHI-Safe Payload Guidance (IDs only; no candidate name/email/phone/SSN/report contents).

Event 1: hr_reference_completed

Publisher: HR-09-P5 (hr-reference-submit edge function) · Subscribers: FW (workflow triggers — advance candidate stage when all references complete)

Event 2: hr_background_check_completed

Publisher: HR-09-P5 (checkr-webhook on terminal state) · Subscribers: HR-09 (offer gating), FW (automation)

Event 3: hr_background_check_flagged

Publisher: HR-09-P5 (checkr-webhook when result = flagged) · Subscribers: HR-09 (block hire), FW (FCRA adverse action workflow), PF-10 (notify hiring manager)
PHI/PII note: No report contents or criminal-record detail in payload — those live behind RLS in hr_background_checks and PF-11 documents.

Event 4: hr_job_board_application_received

Publisher: HR-09-P5 (hr-job-board-import) · Subscribers: HR-09 (application + candidate creation)
PHI/PII note: No raw email/phone/resume text in payload; subscribers fetch the candidate row via RLS-protected lookup.

CL-51 / CL-54-EN-01 / CL-69 / PM-75: Care-Quality Measures & Grant-Reporting Events

Anchor: CL-PM-GR-CARE-QUALITY-GRANT-INTEGRATION.md. Boundary: CL computes/captures, PM bills/submits, GR reports. All payloads are PHI-free (aggregates, ids, and coded values only); SUD-derived data is DS4P-labeled (CL-63) and Part 2 consent-gated (CL-11) before any payer/grantor-facing redisclosure.

cl_quality_measure_period_calculated (consumer extension)

The canonical CL measure-publication event (full schema above / in CL-FA-VBP-QUALITY-DATA-PIPELINE.md) is the single surface for all CL quality measures. The CL-51 eCQM engine registers the new measure definitions from CL-12-EN-68 (HEDIS TRC), CL-22-EN-01 (cardiometabolic SSD/SMD/SMC/SAA/APM), CL-29-EN-66 (FUA/FUI), CL-51-EN-01 (CCBHC clinic-collected set), and CL-51-EN-02 (ECDS/DEQM digital set) and emits this event on period finalization with the appropriate measure_id. These enhancement specs do not publish their own events. Publisher: CL (CL-51 engine) New subscribers: PM-25-EN-01 (incentive accrual waterfall), PM-77 (payer DEQM/ECDS submission), GR-28 (SPARS / CCBHC-E package — consumes values verbatim, zero recomputation), GR-31 (CCBHC QBP comparative measures — deferred PPS) Status: 📝 Planned Consumer idempotency: key by (organization_id, measure_id, period_start, period_end); on a restated period, PM-25-EN-01 recalculates the accrual waterfall and GR-28/GR-31 regenerate package rows.

clinical.outcome_assessment.recorded

Channel: cl_events Publisher: CL (CL-69 — GPRA→SUPRT instrument; SUPRT-A/SUPRT-C/NOMs at intake → 6-mo → annual → discharge) Consumers: GR-28 (SPARS batch-upload package), GR-30 (URS / NOMs Tables 14A/B), GR-31 (CCBHC outcomes) Status: 📝 Planned
PHI: None — pseudonymous client_ref + coded instrument/timepoint only; item-level responses live behind RLS in CL-69 tables. Idempotency: canonical key event_id; secondary domain guard (organization_id, client_ref, instrument, timepoint, grant_program_ref). Part 2: Consumers that produce a payer/grantor-facing export (GR-28 SPARS) MUST call CL-11 cl_check_sud_consent() per receiving entity for is_sud_derived rows and block generation when consent is absent; log to the CL-11 disclosure log.

clinical.care_gap.identified

Channel: cl_events Publisher: CL (CL-35 — population-health care-gap management) Consumers: PM-76 (gap → PM-03 reminder + PM-42 coordinator task), PM-25-EN-01 (due-for-measure flag) Status: 📝 Planned
PHI: None — pseudonymous patient_ref + coded gap type only. Idempotency: key event_id; secondary (organization_id, patient_ref, gap_type, COALESCE(due_at, timestamp)).

cl_cocm_registry_status_changed

Channel: cl_events Publisher: CL (CL-54-EN-01 — CoCM/BHI population registry) Consumers: PM-75 (CoCM billing eligibility gate) Status: 📝 Planned
PHI: None — pseudonymous patient_ref + coded registry/treat-to-target status; PHQ-9/GAD-7 scores stay behind RLS in CL-54-EN-01. Consumer behavior (PM-75): CoCM auto-post requires registry_active = true AND a consultant_review_on within the billing period. If the signal is unavailable, PM-75 withholds the charge (graceful degradation) and lands the enrollment on a worklist.

pm_care_management_charge_posted

Channel: pm_events Publisher: PM (PM-75 — care-management billing engine; CoCM/BHI/CCM/PCM) Consumers: PM-07/PM-08 (charge/claims — own routing; no direct write from PM-75), PM-25-EN-01 (accrual input) Status: 📝 Planned
PHI: None — pseudonymous patient_ref + billing codes/ids only. Idempotency: key event_id; secondary (organization_id, patient_ref, service_period, cpt_code) (concurrent-billing guardrails enforced upstream in PM-75 before emit).

CEEM: Community-Engagement / Work-Requirement Status Events (PF-117 / PF-115 / CL-70 / PM-65)

Status: 📝 Planned. CMS-2454-IFC / H.R.1 §71119 capability. PHI-minimal by contract: every payload carries only patient_identity_id (PF-71) + booleans/reason-codes/dates/provenance — never SUD diagnosis codes, ASAM/LOCUS, treatment-episode detail, or narrative. PF-117 is the sole consumer that resolves these into the authoritative status; CL-71 gates any onward SUD-derived disclosure. Payload schemas (PHI-minimal):
PHI: None — patient_identity_id + booleans/coded reasons/dates only; no SUD content on any CEEM event. Idempotency: key event_id; secondary (organization_id, patient_identity_id, source_spec_id, effective_from|service_period). DS4P / Part 2: these events are PHI-minimal and need no segmentation; any onward disclosure of an SUD-derived exemption to a state/MCO is gated by CL-71 (consent-or-TPO basis + minimum-necessary + DS4P labels).