Version: 2.2.2Documentation Index
Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
Use this file to discover all available pages before exploring further.
Last Updated: 2026-05-18
Change Note: Added six BHRF (A.A.C. R9-10-701..722) lifecycle event contracts for CL-68 / GR-27 / PM-74 (
rh_resident_admitted BHRF-filtered, cl_bhrf_loc_determined, cl_bhrf_clinical_assessment_completed, pm_bhrf_continued_stay_review_required, gr_bhrf_compliance_finding_raised, pm_residential_charge_held) with R7 retry alignment and coded (non-free-text) hold_reason. Prior: added explicit “no events” entry for CL-31; cl_referral_status_updated (CL-12-EN-67) on cl_events.
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 matchKnownEventName in src/platform/events/types.ts and rows in fw_workflow_events / inserts into fw_domain_events:
| Legacy / doc alias (deprecated) | Canonical event_name | fw_domain_events.event_source (trigger) | Source table / condition |
|---|---|---|---|
resident_admitted | rh_resident_admitted | trigger_rh_episodes_domain_events | rh_episodes — status transitions to admitted |
resident_discharged | rh_resident_discharged | trigger_rh_episodes_domain_events | rh_episodes — status transitions to discharged |
phase_progressed / rh_phase_changed (draft) | rh_phase_advanced | trigger_rh_episode_phases_phase_advanced | rh_episode_phases — row becomes current phase |
bed_assigned (planned registry) | rh_bed_assigned ✅ (now in KnownEventName) | Planned | Bed assignment mutation — add when HR consumer is scheduled |
bed_released (planned registry) | rh_bed_released ✅ (now in KnownEventName) | Planned | Bed release mutation |
invoice_creation_requested | rh_invoice_creation_requested ✅ (now in KnownEventName) | Planned | Invoice creation request — align with FA consumer story to avoid duplicate invoicing |
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 fromspecs/_templates/INTEGRATION_CONTRACT_TEMPLATE.md when defining event contracts.
| Channel | Owning Core(s) | Purpose |
|---|---|---|
domain_events | PF / general | General lifecycle events, HR-style events when no dedicated channel |
automation_trigger | FW | Form submission/update events (FW-03) |
fw_events | FW | Forms & workflow events (external form submitted, approval submitted/completed) |
fa_events | FA | Finance events (journal posting, payments, budgets, consolidations) |
hr_events | HR | HR lifecycle (credentials, onboarding, offboarding, performance) |
it_events | IT | IT asset, license, ticket, vendor, procurement events |
lo_events | LO | Leadership (rocks, todos, meetings, issues) |
cl_pm_events | CL, PM | CL/PM cross-core (break-glass, eligibility, check-in, lab orders) |
cl_events | CL | CL clinical events (note finalized, assessment, group session) |
pm_events | PM | PM practice management (eligibility, appointments, claims) |
pm_rpa_events | PM | PM-51 RPA automation events (execution completed, consecutive failures) |
rh_events | RH | Recovery housing events (resident admission, discharge, census, episodes) |
gr_events | GR | Governance (incidents, audits) |
org_data_changes | PF | PF-18 org data sync events (department/site changes triggering cross-module propagation) |
{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_notifyto dedicated channels:domain_events- HR lifecycle events (credentials, onboarding, offboarding)automation_trigger- FW form submission/update eventsfa_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 eventscl_events- CL clinical events (note finalized, assessment completed, group session completed) — 📝 Reserved for CL-02+ internal events; not yet in usepm_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_logsfor permanent audit trail - Event consumer edge function:
supabase/functions/event-consumer/index.ts - Automation executor edge function:
supabase/functions/automation-executor/index.ts
- All events include
organization_idfor 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 keys: All event payloads MUST include a unique
event_id(uuid); workflow executions MUST useexecution_idas the idempotency key. Handlers in event-consumer and automation-executor MUST record processed keys and skip duplicates (e.g. checkfw_workflow_executionsor 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_idorexecution_idand 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
- 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)— wrapsuseRealtimePresencefrom@/platform/realtimeuseDiagramBroadcast(orgId, diagramId)— wrapsuseRealtimeBroadcast; eventdiagram_updated
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. viapf_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 toorgId. - 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:
supabase/functions/automation-executor/index.ts
- Listens to
automation_triggerchannel via pg_notify - Fetches matching automation rules
- Evaluates conditions
- Executes actions (email, notification, webhook, record update)
- Logs execution to
fw_automation_logs
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 namePublisher: HR (Workforce)
Subscribers: Event Consumer (audit logging), HR-04 (Scheduling)
Status: ✅ Complete
Implemented: 2025-11-25 Payload Schema:
hr_credential_verified (canonical)Legacy alias (deprecated):
credential_verified — maintained for backward compatibility but should migrate to canonical namePayload Schema:
supabase/functions/event-consumer/index.ts
- Logs all events to
pf_audit_logs - Future handlers ready for notifications and alerts
- HR-04 Scheduling subscribes to
hr_credential_expiredevents (canonical; legacycredential_expiredalias 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)
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:
offboarding_completedPayload Schema:
IT Trigger Events (📝 Planned - IT-08 Integration)
These events trigger IT-08 IT Onboarding/Offboarding workflows. Event 3:hr_onboarding_startedPublisher: HR (Workforce)
Subscribers: IT-08 (IT Provisioning)
Trigger: INSERT on
hr_onboarding_instances
Payload Schema:
hr_onboarding_task_createdPublisher: HR (Workforce)
Subscribers: IT-08 (IT Task Instance)
Trigger: INSERT on
hr_onboarding_task_instances WHERE category = ‘it_setup’
Payload Schema:
hr_offboarding_startedPublisher: HR (Workforce)
Subscribers: IT-08 (IT Offboarding)
Trigger: INSERT on
hr_offboarding_instances
Payload Schema:
hr_offboarding_task_createdPublisher: HR (Workforce)
Subscribers: IT-08 (IT Access Revocation)
Trigger: INSERT on
hr_offboarding_checklist_items WHERE category = ‘access_revocation’
Payload Schema:
supabase/functions/event-consumer/index.ts
- Logs all events to
pf_audit_logs - IT-08 handlers create corresponding IT provisioning/offboarding instances
HR-31: Policy Acknowledgment Events — ⛔ ARCHIVED
⛔ DEPRECATED (2026-03-26): HR-31 has been consolidated into GR-01. The HR-31 tables (Status: ⛔ Archived — consolidated into GR-01hr_policies,hr_policy_distributions,hr_policy_acknowledgments) were dropped in migration20260326034722. These event contracts are retained for historical reference only.
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):
(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):
(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: ✅ ImplementedImplemented: 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_eventsTrigger: INSERT on
hr_time_exceptions
Payload Schema:
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: ✅ ImplementedImplemented: 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:
Event 2: performance_goal_completed
Publisher: HR (Workforce)Subscribers: LO-03 (Goals)
Status: 📝 Planned Payload Schema:
Event 3: hr_pip_terminated
Publisher: HR (Workforce)Subscribers: HR-03 (Offboarding), HR-14 (Employee Relations)
Status: ✅ Implemented (2026-01-12) Payload Schema:
- Hook:
src/cores/hr/hooks/performance/usePIPTerminationIntegration.ts - Event registered in:
fw_workflow_eventstable - Triggered by:
usePIPMutation.completePIP()when outcome is ‘unsuccessful’ - Creates:
hr_disciplinary_actionsrecord withaction_type: 'termination' - UI Warning:
PIPCompleteDialog.tsxshows warning for unsuccessful outcome
- Creates disciplinary action record in HR-14
- Publishes
hr_pip_terminatedevent for workflow automation - 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. Seesrc/cores/hr/lib/reconcileEnrollmentDeductions.ts for enrollment-deduction sync pattern.
⚠️ BREAKING CHANGE (v2.2.0): The payloads forhr.benefit_enrollment.createdandhr.benefit_enrollment.terminatedwere restructured:
- Removed:
enrollment_id,benefit_plan_id,enrollment_date,coverage_tier- Added:
benefit_enrollment_id,amount,pre_tax- Structure: Event-specific fields moved into
payloadobject per Event Schema Standard Implementers consuming these events must update their handlers.
Event 1: hr.benefit_enrollment.created
Publisher: HR (Workforce) — HR-11 BenefitsSubscribers: HR-PAY-02 (Payroll Deductions) Payload Schema:
Event 2: hr.benefit_enrollment.terminated
Publisher: HR (Workforce) — HR-11 BenefitsSubscribers: HR-PAY-02 (Payroll Deductions) Payload Schema:
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 insrc/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-04Subscribers: FA (Finance) — for GL posting and liability tracking Payload Schema (Event Schema Standard):
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:
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:
Event 3: hr_contractor_credential_expiring
Publisher: HR (Workforce) — HR-34
Subscribers: PF-10 (Notifications — expiration alerts)
Status: 📝 Planned
Payload Schema:
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:
Note: Canonical event name isfa_expense_report_submitted. This is the canonical schema for the event. Previous versions usingevent_typeand simplified fields have been consolidated into this format. Consumers should migrate to useExpenseReportSubmittedEventinterface fields.
Event 2: fa_expense_report_approved (canonical)
Publisher: FA (Finance)Subscribers: FA-05 (Payment Processing), PF-10 (Notifications)
Status: ✅ Implemented Payload Schema:
Note: Consumers (FA-05, PF-10) MUST useevent_idfor deduplication and retry handling. Theevent_versionfield enables schema evolution tracking.
Event 3: fa_expense_report_rejected (canonical)
Publisher: FA (Finance)Subscribers: PF-10 (Notifications)
Status: ✅ Implemented Payload Schema:
Note: Consumers (PF-10) MUST useevent_idfor deduplication and retry handling. Theevent_versionfield enables schema evolution tracking.
Event 4: fa_reimbursement_processed (canonical)
Publisher: FA (Finance)Subscribers: FA-02 (GL), PF-10 (Notifications)
Status: ✅ Implemented Payload Schema:
Note: Consumers (FA-02, PF-10) MUST useevent_idfor deduplication and retry handling. Theevent_versionfield enables schema evolution tracking.
HR-14: Employee Relations Events
Status: ✅ CompleteImplemented: 2026-01-09
Event 1: disciplinary_action_termination
Publisher: HR (Workforce)Subscribers: HR-03 (Offboarding), PF-10 (Notifications) Payload Schema:
Event 2: incident_reported
Publisher: HR (Workforce)Subscribers: GR-06 (Incident Management), PF-10 (Notifications for critical/serious) Payload Schema:
Event 3: grievance_filed
Publisher: HR (Workforce)Subscribers: GR-03 (Compliance) Payload Schema:
HR-26: E-Verify Integration Events
Status: ✅ ImplementedPublisher: HR-26 (E-Verify orchestrator edge function)
Subscribers: PF-10 (notifications), audit log Event 1:
hr_everify_case_createdTrigger: Successful USCIS case creation via
hr-everify-orchestratorPayload:
hr_everify_status_changedTrigger: Status transition on poll or manual update
Payload:
hr_everify_tnc_openedTrigger: 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:
Event 2: compensation_analysis_completed
Publisher: HR (Workforce)Subscribers: FA (Analytics), PF-10 (Notifications)
Trigger:
hr_compensation_analyses.status → 'approved'
Payload Schema:
Event 3: compensation_cost_allocated
Publisher: HR (Workforce)Subscribers: FA (Budget adjustments), FA (Cost forecasting)
Trigger:
hr_merit_increases.status → 'approved'
Payload Schema:
- FA creates budget alert for significant cost increases
- FA updates departmental expense forecasts
- FA may trigger budget amendment workflow if over threshold
HR-16: Succession Planning Events
Status: 📝 PlannedImplemented: TBD
Event 1: successor_identified
Publisher: HR (Workforce)Subscribers: PF-10 (Notifications) Payload Schema:
Event 2: talent_promoted
Publisher: HR (Workforce)Subscribers: HR-16 (Succession Planning) Payload Schema:
HR-17: Employee Engagement Events
Status: 📝 PlannedImplemented: TBD
Event 1: survey_completed
Publisher: HR (Workforce)Subscribers: PF-10 (Notifications) Payload Schema:
Event 2: exit_interview_completed
Publisher: HR (Workforce)Subscribers: HR-03 (Offboarding) Payload Schema:
FA-02: Vendor Bill Approved Events
Event:vendor_bill_approvedPublisher: FA (Finance & Accounting)
Subscribers: FW-03 (Workflow completion), PF-10 (Notifications), FA-03 (Payment queue)
Status: ✅ Complete
Implemented: 2025-11-26 Payload Schema:
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
FA-03: Payment Processed Events
Event:payment_processedPublisher: FA (Finance & Accounting)
Subscribers: FA-02 (GL posting), PF-10 (Vendor notification), FA-06 (Bank reconciliation)
Status: ✅ Complete
Implemented: 2025-11-26 Payload Schema:
- 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
FA-03: Vendor Activated (domain event)
Registry ID: FA-E-06 (vendor_activated)Event name:
fa.vendor.activatedVersion:
1.0.0Publisher: 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 object):
FA-22: Accounts Payable Automation Events
Spec Reference: specs/fa/specs/FA-22-accounts-payable-automation.mdPublisher: 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_completedWhen: After fa-scan-invoice edge function completes and inserts into fa_invoice_scans. Payload Schema:
fa_bill_duplicate_flagged
Event type:fa_bill_duplicate_flaggedWhen: After fa-detect-duplicates creates a fa_duplicate_detection_log entry (on bill insert or cron). Payload Schema:
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: ✅ CompleteImplemented: 2026-01-27
Spec Reference: specs/fa/specs/FA-04-purchase-orders.md
FA-E-04: purchase_order_approved
Event:purchase_order_approvedPublisher: 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:
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)
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_receivedPublisher: FA (Finance & Accounting)
Subscribers: Event Consumer (audit logging), PF-10 (Notifications), FA-11 (Fixed Assets - asset receipt)
Status: ✅ Complete
Channel:
fa_events
Payload Schema:
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)
fa_publish_goods_received() fires on receipt creation
Testing: ✅ Complete - Event fires on receipt creation
FA-02: Journal Entry Posted Events
Event:journal_entry_postedPublisher: FA (Finance & Accounting)
Subscribers: Event Consumer (audit logging), FA-07 (Balance refresh), PF-10 (Notifications)
Status: ✅ Complete
Implemented: 2025-11-26 Payload Schema:
- 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
FA-08: Budget Approved Events
Event:budget_approvedPublisher: FA (Finance & Accounting)
Subscribers: FW-03 (Workflow completion), PF-10 (Notifications), FA-07 (Reporting)
Status: ✅ Complete
Implemented: 2025-11-26 Payload Schema:
- 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
FA-08: Budget Exceeded Events
Event:budget_exceededPublisher: FA (Finance & Accounting)
Subscribers: PF-10 (Notifications to budget owners), FA-08 (Alert log)
Status: ✅ Complete
Implemented: 2025-11-26 Payload Schema:
- PF-10 Notifications - Sends alerts to budget owners and finance managers
- FA-08 Budget Management - Logs alert and tracks budget compliance
FA-09: Consolidation Completed Events
Event:consolidation_completedPublisher: FA (Finance & Accounting)
Subscribers: FA-07 (Consolidated reports), PF-10 (Notifications), Event Consumer (audit)
Status: ✅ Complete
Implemented: 2025-11-26 Payload Schema:
- FA-07 Financial Reporting - Generates consolidated financial statements
- PF-10 Notifications - Alerts management of completed consolidation
- Event Consumer - Logs consolidation completion to audit trail
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
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
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()andredactSUDFields()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).
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_unblockedPublisher: 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:
- Event Consumer: Log to
pf_audit_logsfor audit trail - PF-10 Notifications (Future): Send notification to action assignee
LO-15: Action Status Changed Event
Event:action_status_changedPublisher: 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:
- Event Consumer: Log to
pf_audit_logsfor audit trail - PF-10 Notifications (Future): Send notifications based on status:
needs_review→ Notify reviewer/goal ownerblocked→ Notify assignee and goal ownercomplete→ Notify goal owner
Planned Events (FW-22 Execution Monitoring)
FW-22: Workflow Execution Failed Event
Event:execution_failedPublisher: 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:
- PF-10 Notifications: Send alert to workflow owner and org admins
- FW-22 Dashboard: Update failed execution count, trigger refresh
Planned Events (FW-32 External Form Portal)
FW-16-P2: Event Schema Updated
Event:fw_event_schema_updatedPublisher: 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_deprecatedPublisher: 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_submittedPublisher: 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:
- PF-10 Notifications: Send confirmation email to submitter
- FW-03 Automation Engine: Trigger any workflow automations configured for external form submissions
Planned Events (FW-34 Approval Workflows)
FW-34: Approval Request Submitted Event
Event:fw_approval_submittedPublisher: 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:
- PF-10 Notifications: Send notification to assigned approvers
- FW-03 Automation Engine: Trigger any related automations
FW-34: Approval Request Completed Event
Event:fw_approval_completedPublisher: 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:
- FW-03 Automation Engine: Trigger post-approval automations (e.g., update entity status)
- PF-10 Notifications: Notify submitter of decision
FW-34: Approval Escalated Event
Event:fw_approval_escalatedPublisher: 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:
- 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_capturedPublisher: 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:
- 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_generatedPublisher: 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:
- PF-11 Documents: Link document to submission, update document metadata
Planned Events (FW-16 Event Registry)
The following events are planned for registration infw_workflow_events as part of FW-16 (Event-Based Workflow Triggers):
HR Core Events (Planned)
| Event Name | Display Name | Category | Entity Type |
|---|---|---|---|
hr_employee_created | Employee Created (canonical) | lifecycle | hr_employees |
hr_employee_assigned_to_site | Employee Assigned to Site | lifecycle | hr_employees |
hr_employee_hired | Employee Hired | lifecycle | hr_employees |
hr_employee_terminated | Employee Terminated | lifecycle | hr_employees |
hr_credential_expired | Credential Expired | compliance | hr_employee_credentials |
hr_credential_verified | Credential Verified | compliance | hr_employee_credentials |
hr_onboarding_completed | Onboarding Completed | lifecycle | hr_onboarding_instances |
hr_leave_approved | Leave Approved | operational | hr_leave_requests |
hr_interview_scorecard_assigned | Scorecard Assigned | operational | hr_interview_scorecards |
hr_interview_scorecard_submitted | Scorecard Submitted | operational | hr_interview_scorecards |
hr_final_paycheck_status_changed | Final Paycheck Status Changed | compliance | hr_final_paycheck_requests |
hr_fingerprint_clearance_status_changed | Clearance Status Changed | compliance | hr_fingerprint_clearances |
hr_fingerprint_clearance_expiration_warning | Clearance Expiration Warning | compliance | hr_fingerprint_clearances |
hr_flsa_classification_changed | FLSA Classification Changed | compliance | hr_flsa_classifications |
hr_flsa_reclassification_approved | FLSA Reclassification Approved | compliance | hr_flsa_reclassifications |
HR-01 canonical events (confirmed 2026-04-28):hr_employee_created,hr_employee_assigned_to_site, andhr_employee_terminatedare published by HR-01 — see HR-01 Integration §Events for full payload schemas.hr_employee_hiredis treated as a synonym/legacy alias ofhr_employee_createdfor downstream consumers (FW-16 registry retains both names during transition; new subscribers SHOULD preferhr_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.
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 usinggoogle_user_idorprofile_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.
| Event Name | Display Name | Category | Entity Type |
|---|---|---|---|
pf_google_workspace_user_provisioned | Google Workspace User Provisioned | lifecycle | pf_google_workspace_user_links |
pf_google_workspace_connector_degraded | Google Workspace Connector Degraded | health | pf_google_workspace_connections |
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-28Publishes:
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.
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.
HR-30: Final paycheck (planned detail)
Spec: HR-30Consumes:
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)
| Event Name | Display Name | Category | Entity Type |
|---|---|---|---|
rh_resident_admitted | Resident Admitted | lifecycle | rh_episodes |
rh_resident_discharged | Resident Discharged | lifecycle | rh_episodes |
rh_phase_advanced | Episode phase advanced | operational | rh_episode_phases |
rh_bed_assigned | Bed Assigned | operational | rh_beds |
FA Core Events (Planned)
| Event Name | Display Name | Category | Entity Type |
|---|---|---|---|
fa_invoice_paid | Invoice Paid | financial | fa_invoices |
fa_budget_approved | Budget Approved | financial | fa_budgets |
fa_budget_exceeded | Budget Exceeded | alert | fa_budget_alerts |
fa_payment_processed | Payment Processed | financial | fa_customer_payments |
FA-10: Tax Reporting Events
Status: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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: 📝 PlannedSpec 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:
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:
total_revenue_amount. Tolerance comes from fa_module_settings.revenue_recognition_sum_tolerance (default 0.01).
FA-19: Financial Close Events
Status: 📝 PlannedSpec 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: ✅ CompleteImplemented: 2025-12-03 Payload Schema:
LO-04: To-Dos & Task Management Events
Event 1:todo_createdPublisher: LO (Leadership Operating System)
Subscribers: PF-10 (Notifications)
Status: ✅ Complete
Implemented: 2025-12-03 Payload Schema:
todo_completedStatus: ✅ Complete
Implemented: 2025-12-03 Payload Schema:
todo_overdueStatus: ✅ Complete
Implemented: 2025-12-03 Payload Schema:
LO-05: Scorecards & KPI Tracking Events
Event 1:scorecard_updatedStatus: ✅ Complete
Implemented: 2025-12-03 Event 2:
metric_threshold_breachedStatus: ✅ Complete
Implemented: 2025-12-03
LO-06: Structured Meetings Events
Event 1:meeting_scheduledStatus: ✅ Complete
Implemented: 2025-12-03 Event 2:
meeting_completedStatus: ✅ Complete
Implemented: 2025-12-03 Event 3:
action_item_createdStatus: ✅ Complete
Implemented: 2025-12-03
LO-07: Issues & Problem Solving Events
Event 1:issue_identifiedStatus: ✅ Complete Event 2:
issue_resolvedStatus: ✅ Complete
LO-09: Assessments & Surveys Events
Event 1:assessment_distributedStatus: ✅ Complete
Implemented: 2025-12-03 Event 2:
assessment_completedStatus: ✅ Complete
Implemented: 2025-12-03
Planned Events
RH-01: Resident Admission Events
Event (canonical):rh_resident_admittedDeprecated 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:
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_dischargedDeprecated 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:
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_assignedDeprecated alias:
bed_assignedPublisher: 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:
user_id captures the staff member who performed the assignment for audit and accountability.
RH-01: Bed Released Events
Event (target canonical):rh_bed_releasedDeprecated 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:
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_requestedLegacy alias (deprecated):
invoice_creation_requested — maintained for backward compatibility but should migrate to canonical namePublisher: 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:
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_reportedLegacy alias (deprecated):
critical_significant_event_reportedPublisher: RH (RH-03 Safety Events & Compliance)
Subscribers: PF-10 (notifications)
Channel:
rh_eventsStatus: 📝 Planned
Spec Reference: RH-03 Safety Events & Compliance
Integration Doc: RH-03-safety-events-compliance-INTEGRATION.md Payload Schema:
rh_significant_event_investigation_completedLegacy alias (deprecated):
significant_event_investigation_completedPublisher: RH (RH-03 Safety Events & Compliance)
Subscribers: PF-10, RH compliance/reporting consumers
Channel:
rh_eventsStatus: 📝 Planned
Spec Reference: RH-03 Safety Events & Compliance
Integration Doc: RH-03-safety-events-compliance-INTEGRATION.md Payload Schema:
rh_uds_test_positiveLegacy alias (deprecated):
uds_test_positivePublisher: RH (RH-03 Safety Events & Compliance)
Subscribers: RH-03 relapse/event workflows, PF-10 notifications
Channel:
rh_eventsStatus: 📝 Planned
Spec Reference: RH-03 Safety Events & Compliance
Integration Doc: RH-03-safety-events-compliance-INTEGRATION.md Payload Schema (consent-safe identifier-only):
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_createdPublisher: RH (Recovery Housing)
Subscribers: FA-05 (Accounts Receivable)
Status: 📝 Planned (RH-04 Implementation)
Spec Reference: FA-05: Accounts Receivable & Revenue Recognition Payload Schema:
- FA-05 looks up resident → customer mapping
- Creates invoice with charge as line item
- Sets invoice status to “sent” and auto-posts to GL (DR AR, CR Revenue)
- Links invoice to source charge via
fa_invoices.source_charge_id - Sends notification to billing coordinator (PF-10)
- Event contract defined in FA-05 spec (Section 9: Integration Points)
- Database schema ready:
fa_invoices.source_charge_idcolumn 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()orcurrent_setting('request.jwt.claims', true)::json->>'sub') and populate theuser_idfield 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_approachingPublisher: RH (Recovery Housing)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
Spec Reference: RH-06 (Compliance Tracking & Staff Operations) Payload Schema:
non_compliance_detectedPublisher: RH (Recovery Housing)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned Payload Schema:
FA-01: Payment Received Events
Event:payment_receivedPublisher: FA (Finance & Revenue)
Subscribers: RH (Recovery Housing)
Status: 📝 Planned (FA-01 Implementation) Payload Schema:
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:
HR-01: Employee Created Events
Event:employee_created
Publisher: HR (Workforce)
Subscribers: GR (Governance & Risk)
Channel: hr_events
Status: 📝 Planned (Q2 2026)
Payload Schema:
LO-01: Vision & Strategic Planning Events (Planned)
Event:vision_updatedStatus: 📝 Planned (LO-01 Implementation) Event:
strategic_goal_createdStatus: 📝 Planned (LO-01 Implementation) Event:
rock_createdStatus: 📝 Planned (LO-01 Implementation)
LO-02: Accountability Chart Events (Planned)
Event:role_assignedStatus: 📝 Planned (LO-02 Implementation) Event:
accountability_chart_updatedStatus: 📝 Planned (LO-02 Implementation)
LO-08: Feedback & 1-on-1s Events (Planned)
Event:one_on_one_scheduledStatus: 📝 Planned (LO-08 Implementation) Event:
feedback_submittedStatus: 📝 Planned (LO-08 Implementation)
LO-10: Knowledge Portal Events (Planned)
Event:knowledge_article_createdStatus: 📝 Planned (LO-10 Implementation) Event:
process_updatedStatus: 📝 Planned (LO-10 Implementation)
LO-16: Goals & Actions Event Integration (Planned)
Event:goal_createdPublisher: LO (Leadership Operating System)
Subscribers: FA (budget planning), GR (compliance), FW (workflow linking)
Status: 📝 Planned (LO-16 Implementation) Payload Schema:
goal_completedPublisher: LO
Subscribers: RH (program metrics), FA (financial tracking), GR (compliance tracking)
Status: 📝 Planned (LO-16 Implementation) Payload Schema:
action_assignedPublisher: LO
Subscribers: HR (employee development), PF-10 (notifications)
Status: 📝 Planned (LO-16 Implementation) Payload Schema:
action_completedPublisher: LO
Subscribers: LO-14 (unblock dependencies), PF-10 (notifications)
Status: 📝 Planned (LO-16 Implementation) Payload Schema:
- Events published via
lo_eventschannel (pg_notify) - Database triggers on
lo_quarterly_rocksandlo_rock_milestones - Events logged to
pf_audit_logsfor audit trail - Consumer examples provided for RH, FA, GR, FW modules
specs/lo/LO-16-goals-event-integration.md
Planned Events (GR Core)
GR-01: Policy Management Events
Event 1:policy_createdPublisher: 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:
policy_acknowledgedPublisher: 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— recomputesce_hours_completedon employee credentialsgr-evidence-from-training— inserts deduplicatedgr_compliance_evidencerows for linked requirements
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:
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: Consumespf_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):
GR-03: Compliance Tracking Events
Event 1:requirement_createdPublisher: 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_changedPublisher: 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_createdPublisher: GR (Governance & Compliance)
Subscribers: GR-06 (AI assistance)
Status: 📝 Planned (GR-04 Implementation)
Spec Reference: GR-04 Audit Management Event 2:
audit_finding_createdPublisher: GR (Governance & Compliance)
Subscribers: GR-05 (Risk assessment), GR-06 (AI monitoring)
Status: 📝 Planned (GR-04 Implementation) Payload Schema:
GR-05: Risk Assessment Events
Event 1:risk_createdPublisher: GR (Governance & Compliance)
Subscribers: GR-06 (AI assistance)
Status: 📝 Planned (GR-05 Implementation)
Spec Reference: GR-05 Risk Assessment Event 2:
risk_assessedPublisher: GR (Governance & Compliance)
Subscribers: GR-06 (AI monitoring)
Status: 📝 Planned (GR-05 Implementation) Payload Schema:
GR-11: Procedures Management Events
Event 1:procedure_approvedPublisher: GR (Governance & Compliance)
Subscribers: GR-02 (Training), GR-03 (Compliance)
Status: ✅ Complete (GR-11 Implementation)
Spec Reference: GR-11 Procedures Management Payload Schema:
| Consumer | Action | Status |
|---|---|---|
| GR-02 (Training) | Create training assignment for new procedure | 📝 Planned |
| GR-03 (Compliance) | Update compliance tracking for policy coverage | 📝 Planned |
| PF-10 (Notifications) | Notify procedure owner and stakeholders | 📝 Planned |
- 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_completedPublisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance evidence)
Status: ✅ Complete (GR-11 Implementation) Payload Schema:
| Consumer | Action | Status |
|---|---|---|
| GR-03 (Compliance) | Record execution as compliance evidence | 📝 Planned |
| PF-10 (Notifications) | Notify procedure owner of completion | 📝 Planned |
- 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_eventschannel (pg_notify) - Database triggers on
gr_procedures(status change to ‘approved’) andgr_procedure_executions(status change to ‘completed’) - Events logged to
pf_audit_logsfor audit trail withuser_idandcorrelation_idfields populated - Consumer examples provided for GR-02, GR-03 modules
- All trigger functions that publish events to the
gr_eventschannel MUST be created WITH SECURITY DEFINER - Coding Guideline: SQL trigger code for events must include
SECURITY DEFINERclause - 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_idfrom the current session context (e.g.,auth.uid()) in addition to any role-specific fields likeapproved_byorexecuted_by - When events may chain (e.g., procedure approval triggers training assignment), trigger functions should generate and propagate
correlation_idto enable event traceability
GR-06-EN-01: AI-Powered State Compliance Checking Events
Event:gr_state_gap_analysis_completedPublisher: 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 externalizesStatus: 📝 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):
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | yes | Literal gr_state_gap_analysis_completed |
event_id | uuid | yes | Unique event ID for deduplication |
organization_id | uuid | yes | Tenant scope |
state_code | string | yes | Jurisdiction state code (e.g. AZ) |
domain | string | yes | One of clinical, billing, compliance, training, comprehensive |
compliance_score | number | yes | 0–100 |
gap_count | integer | yes | Count of identified gaps |
timestamp | string (ISO 8601) | yes | Event time (timestamptz) |
correlation_id | string | null | no | Trace / workflow correlation |
| Consumer | Action | Status |
|---|---|---|
| PF-91 | Refresh compliance dashboard widgets / gap summaries | 📝 Planned |
| PF-10 | Notify compliance roles when gaps are critical | 📝 Planned |
GR-12: Procedure Templates Library Events
Event 1:gr_template_instantiatedPublisher: 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:
| Consumer | Action | Status |
|---|---|---|
| GR-03 (Compliance) | Update compliance coverage tracking | 📝 Planned |
| PF-10 (Notifications) | Notify compliance officer of new procedure from template | 📝 Planned |
Event 2:
gr_template_contributedPublisher: GR (Governance & Compliance)
Subscribers: GR-03 (Compliance tracking)
Status: 📝 Planned (GR-12 Implementation) Payload Schema:
GR-07: Quality Improvement Events
Event:qi_project_createdPublisher: 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_createdPublisher: 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: ✅ ImplementedImplemented: 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_eventsStatus: ✅ 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_eventsStatus: ✅ Implemented Payload Schema:
CL-07-EN-01: Zero Suicide Framework Events
Event 1:cl_safety_plan_sharedChannel:
cl_eventsPublisher: 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:
| Consumer | Action | Status |
|---|---|---|
| PF-10 Notifications | Send notification to clinician/support network with signed URL in action_url | 📝 Planned |
Event 2:
cl_zero_suicide_followup_scheduledChannel:
cl_eventsPublisher: 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:
| Consumer | Action | Status |
|---|---|---|
| PM Scheduling | Display follow-up in scheduling views | 📝 Planned |
| PF-10 Notifications | Send reminder to assigned clinician | 📝 Planned |
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.Event 1:
Regulatory driver: AHCCCS AMPM 1620-O; ARS 46-454; 42 CFR 482.13; CARF; Joint Commission EC.04.01.01.
cl_safety_plan_activatedChannel:
cl_eventsPublisher: 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:
| Consumer | Action | Status |
|---|---|---|
| GR-08/GR-09 | Create draft incident report; type = safety_plan_activation; link chart/safety_plan | 📝 Planned |
Event 2:
cl_restraint_event_documentedChannel:
cl_eventsPublisher: 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:
| Consumer | Action | Status |
|---|---|---|
| GR-08/GR-09 | Create draft incident report; type = restraint_seclusion; link chart/encounter | 📝 Planned |
Event 3:
gr_incident_createdChannel:
gr_eventsPublisher: 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:
| Consumer | Action | Status |
|---|---|---|
| CL | Set chart-level flag “open documentation required” / “related incident”; link to incident_id | 📝 Planned |
-
User-initiated flows: Must validate
organization_idagainst JWT claims (current_setting('jwt.claims.organization_id')) before any writes. Client-side checks are insufficient; server-side validation is mandatory. -
Service-initiated/pg_notify flows: Use a trusted organization context and MUST call a server-side
SECURITY DEFINERstored procedure that:- Enforces strict
organization_idchecks 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
- Enforces strict
- All emissions and consumptions MUST be logged to
pf_audit_logswithuser_id,organization_id,timestamp,correlation_id.
GR-09: Incident Reporting Events
Event 1:incident_createdPublisher: 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_resolvedPublisher: 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):GR-13: Procedure Analytics Events
Event 1:procedure_gap_identifiedChannel:
gr_eventsPublisher: GR (GR-13 Procedure Analytics)
Subscribers: GR-07 (QI project candidate creation)
Status: 📝 Planned
Spec Reference: GR-13 Procedure Analytics Payload Schema:
| Consumer | Action | Status |
|---|---|---|
| GR-07 | Create draft gr_qi_projects row with status='draft', source_event_id={fw_domain_events.id}, custom_fields.source_procedure_id={procedure_id}; prefilled title / problem statement / suggested owner. Idempotent on (organization_id, source_event_id) + secondary guard on (organization_id, source_procedure_id, status='draft'). | ✅ Complete (consumer shipped in GR-13-EN-01, 2026-04-19) |
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.
Event Infrastructure
Generic Event Publisher:- Location:
supabase/functions/event-consumer/index.ts - Listens to
domain_eventschannel - Logs all events to
pf_audit_logswith:- module = ‘hr’ (or relevant core)
- action = ‘domain_event’
- table_name = source table
- new_values = event payload
- Future-ready for event handlers (commented code included)
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 ContractsIT-01: Asset Management Events
Event 1:it_asset_purchasedPublisher: 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:
it_asset_assignedPublisher: IT (IT-01 Asset Management)
Subscribers: PF-10 (Notifications), HR
Status: ✅ Implemented Event 3:
it_asset_maintenance_requiredPublisher: IT (IT-01 Asset Management)
Subscribers: FM (Facilities), PF-10 (Notifications)
Status: 📝 Planned Event 4:
it_asset_disposedPublisher: 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_createdPublisher: IT (IT-02 Support Ticketing)
Subscribers: PF-10 (Notifications)
Status: ✅ Implemented
Spec Reference: IT-02 IT Support & Ticketing Payload Schema:
it_ticket_status_changedPublisher: IT (IT-02)
Subscribers: PF-10 (Notifications)
Status: ✅ Implemented
Last Verified: 2026-02-15 Implementation:
it_ticket_sla_breachedPublisher: IT (IT-02)
Subscribers: PF-10 (Notifications), IT-02 Dashboard
Status: ✅ Implemented
Implemented: 2026-01-05 Payload Schema:
IT-03: Vendor Management Events
Event:it_contract_expiringPublisher: 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_createdPublisher: IT (IT-04 Software License Management)
Subscribers: FA (Finance)
Status: 📝 Planned
Spec Reference: IT-04 Software License Management Event 2:
it_license_expiringPublisher: IT (IT-04)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned Event 3:
it_license_renewedPublisher: IT (IT-04)
Subscribers: FA (Finance)
Status: ✅ Implemented
Last Verified: 2026-02-15 Implementation:
it_license_compliance_alertPublisher: IT (IT-04)
Subscribers: PF-10 (Notifications), FA (cost tracking)
Status: ✅ Implemented
Implemented: 2026-01-05 Payload Schema:
IT-05: Security & Compliance Events
Event 1:it_security_incident_createdPublisher: 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:
it_vulnerability_detectedPublisher: IT (IT-05)
Subscribers: GR (Governance), PF-10 (Notifications)
Status: ✅ Implemented
Implemented: 2026-01-05 Payload Schema:
it_patch_deployedPublisher: IT (IT-05)
Subscribers: Event Consumer (audit logging), Asset tracking
Status: ✅ Implemented
Implemented: 2026-01-05 Payload Schema:
it_patch_deployment_overduePublisher: IT (IT-05)
Subscribers: PF-10 (Notifications)
Status: 📝 Planned
IT-06: Procurement Events
Event 1:it_purchase_request_submittedPublisher: 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_approvedPublisher: IT (IT-06)
Subscribers: FA-04 (Purchase Orders), PF-10 (Notifications)
Status: ✅ Implemented Payload Schema:
it_purchase_request_receivedPublisher: IT (IT-06)
Subscribers: IT-01 (Asset creation), PF-10 (Notifications)
Status: 📝 Planned
Implemented Events (FA Core)
FA-19: Financial Close Management Events
Status: ✅ CompleteImplemented: 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:
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:
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:
Event 4: close_task_assigned
Publisher: FA (Finance)Subscribers: PF-10 (Notifications)
Trigger: UPDATE on
fa_close_tasks when assigned_to changes
Payload Schema:
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:
supabase/functions/event-consumer/index.ts
- Logs all events to
pf_audit_logs - Handlers for notification delivery pending PF-10 integration
PF-11 / PF-60: Document Lifecycle Events (RAG)
Status: ✅ Implemented (triggers and migration)Implemented: Migration
20260226140000_pf_rag_document_knowledge_events.sqlSpec 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_eventsPublisher: 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)
extracted_content, title) from pf_documents using document_id under RLS.
Consumer actions
| Consumer | Action | Status |
|---|---|---|
| PF-60 (RAG Infrastructure) | Generate/update/delete embeddings | 🟡 In Progress (generate-embeddings invoked when event-consumer handler added) |
| Event Consumer | Log to pf_audit_logs | ✅ Implemented |
PF-61: Knowledge Base System Events
Status: 📝 PlannedImplemented: TBD
Spec Reference:
specs/pf/specs/PF-61-knowledge-base-system.md
Event: knowledge_article_published
Event: knowledge_article_publishedChannel:
domain_eventsPublisher: 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
draftorin_reviewtopublishedvia UPDATE - Note: Event only fires on UPDATE operations when status changes to
published. Consumers must fetch article details (title, tags, category) under RLS usingarticle_id.
Payload Schema
pf_knowledge_base table using article_id under RLS policies.
Implementation
Consumer Actions
| Consumer | Action | Status |
|---|---|---|
| PF-60 (RAG Infrastructure) | Generate embeddings for published article | 📝 Planned |
| Event Consumer | Log to pf_audit_logs | ✅ Implemented |
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_unpublishedChannel:
domain_eventsPublisher: 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
publishedtodraft,in_review, orarchived - Article is deleted
Payload Schema
Implementation
Consumer Actions
| Consumer | Action | Status |
|---|---|---|
| PF-60 (RAG Infrastructure) | Delete embeddings for unpublished article | 📝 Planned |
| Event Consumer | Log to pf_audit_logs | ✅ Implemented |
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.mdStatus: 📝 Planned (stubs); payload schemas to be defined in respective CL/PM specs.
CL/PM Event Summary
| Event Name | Channel | Publisher | Subscribers | Spec Reference | Definition Timeline | Owner |
|---|---|---|---|---|---|---|
| assessment_completed | cl_pm_events | CL | PM (optional), FW, PF-10 | CL-02 | Q2 2026; payload schema by sprint per CL-02 | CL team; tracking: CL-02 spec |
| treatment_plan_signed | cl_pm_events | CL | FW, PF-10 | CL-03 | Q2 2026 | CL team |
| treatment_plan_review_scheduled | cl_pm_events | CL | PF-10 | CL-03 | Q2 2026 | CL team |
| treatment_plan_event_triggered | cl_pm_events | CL | PF-10 | CL-03 | Q2 2026 | CL team |
| progress_note_signed | cl_pm_events | CL | PM (charge capture), PF-10 | CL-04 | Q2 2026 | CL team |
| medication_recon_completed | cl_pm_events | CL | PF-10 | CL-05 | Q2 2026 | CL team |
| prescription_sent | cl_pm_events | CL | PM, PF-10 | CL-06 | Q2 2026 | CL team |
| pdmp_query_completed | cl_pm_events | CL / external | CL (audit) | CL-17 | Q2 2026; Dec 31, 2026 CSPMP deadline | CL team |
| cds_alert_triggered | cl_events | CL (CL-08) | PF-10, CL (audit) | CL-08 | Q2 2026 | CL team |
| cds_rule_overridden | cl_events | CL (CL-08) | PF-10, PF-04 (audit) | CL-08 | Q2 2026 | CL team |
| cl_group_encounters_approved | cl_events | CL (CL-14-EN-01) | PM-07 | CL-14-EN-01 | Q2 2026 | CL team |
| cl_cohort_membership_recomputed | cl_events | CL (CL-54) | CE-09/10 (outreach audience refresh), FA (VBP attribution), CL-35 (panel/dashboard refresh) | CL-54 | Q2 2026 | CL team |
| cl_quality_measure_period_calculated | cl_events | CL (CL-35) | FA (VBP payment adjustment) | CL-35 · CL-FA-VBP-QUALITY-DATA-PIPELINE | Phase 3 (shipped 2026-04-01) | CL team |
| cl_care_gap_closed | cl_events | CL (CL-35) | FW (event automation) | CL-35 · CL-FW-EVENT-AUTOMATION-INTEGRATION | Phase 2 (shipped 2026-04-01) | CL team |
| cl_virtual_group_started | cl_pm_events | CL (CL-55) | PM-07, PF-10/FW-16 (optional) | CL-55 | Q2 2026; PHI-free payload | CL team |
| cl_virtual_group_concluded | cl_pm_events | CL (CL-55) | PM-07 (charge capture w/ jurisdiction-resolved modifier suggestions) | CL-55 | Q2 2026; PHI-free payload | CL team |
| cl_lab_order_created | cl_pm_events | CL (CL-09) | PF-10, FW | CL-09 | Q2 2026 | CL team |
| cl_lab_result_received | cl_pm_events | CL (CL-09) / External | CL-08 (abnormal alert), PF-10 | CL-09 | Q2 2026 | CL team |
| cl_lab_result_reviewed | cl_pm_events | CL (CL-09) | PF-10, PF-04 (audit) | CL-09 | Q2 2026 | CL team |
| cl_cda_document_generated | cl_events | CL (CL-48) | CL-25 (Audit Dashboard), PF-04 (audit) | CL-48 · INTEGRATION | Q3 2026; PHI-free payload (IDs only) | CL team |
| cl_cda_transmission_status_changed | cl_events | CL (CL-48 edge function) | PF-10 Notifications, CL-25 (Audit Dashboard) | CL-48 · INTEGRATION | Q3 2026; PHI-free payload (IDs + status only) | CL team |
| cl_problem_list_updated | cl_events | CL (CL-46) | CL-08 (CDS re-evaluation), PM-07 (advisory — diagnosis pre-pop via @/platform/clinical#usePatientActiveProblems) | CL-46 | Q2 2026; PHI-free payload { patient_id, problem_id, icd10_code, action: 'added'|'resolved'|'reactivated' }; idempotency key problem_id+action+changed_at | CL team |
| claim_submitted | cl_pm_events | PM | FA (optional), PF-10, FW-03 | PM-08 | Q2 2026 | PM team |
| claim_status_changed | cl_pm_events | PM | PM-09, PF-10, FW-03 | PM-08, PM-19 | Q2 2026 | PM team |
| claim_created | cl_pm_events | PM | FW-03 (optional) | PM-08, PM-19 | Q2 2026 | PM team |
| claim_adjudicated | cl_pm_events | PM | PM-09, PF-10 | PM-08, PM-09 | Q2 2026 | PM team |
| denial_received | cl_pm_events | PM | FW-03, PF-10 | PM-08, PM-19 | Q2 2026 | PM team |
| charge_approved | cl_pm_events | PM | FW-03, PF-10 | PM-07, PM-19 | Q2 2026 | PM team |
| charge_status_changed | cl_pm_events | PM | FW-03, PF-10 | PM-07, PM-19 | Q2 2026 | PM team |
| prior_auth_required | cl_pm_events | PM | CL, PF-10 | PM-10 | Q2 2026 | PM team |
| prior_auth_received | cl_pm_events | PM | CL, PM-07/08, PF-10 | PM-10 | Q2 2026 | PM team |
| eligibility_verified | cl_pm_events | PM | CL, PM-07, PF-10 | PM-02 | Q2 2026 | PM team |
| patient_registered | cl_pm_events | PM | CL, RH (optional), PF-10 | PM-01 | Q2 2026 | PM team |
| appointment_scheduled | cl_pm_events | PM | CL, PF-10 | PM-03 | Q2 2026 | PM team |
| encounter_completed | cl_pm_events | CL/PM | PM (charge capture), PF-10 | CL-04, PM-07 | Q2 2026 | CL/PM |
| payment_posted | cl_pm_events | PM (PM-09) | FA, FW-03 | PM-09, PM-19 | Q2 2026 | PM team |
| write_off_approved | cl_pm_events | PM (PM-09) / PF-10 | FA, FW-03 | PM-09, PM-19 | Q2 2026 | PM team |
| pm.rpa.execution_completed | pm_rpa_events | PM (PM-51 RPA) | PM-08, PM-09 | PM-51 | Q3 2026 | PM team |
| pm.rpa.consecutive_failures | pm_rpa_events | PM (PM-51 RPA) | PF-10 | PM-51 | Q3 2026 | PM team |
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.
| Event Name | Channel | Publisher | Subscribers | Payload Schema | Status |
|---|---|---|---|---|---|
referral_response (placeholder — rename to cl_referral_response_received) | cl_events (or TBD) | TBD (PM/CL when spec defines) | CL-23 | To be defined in spec | 📝 Planned |
chart_message (placeholder — rename to cl_chart_message_sent) | cl_events (or TBD) | TBD (PM/CL when spec defines) | CL-23 | To be defined in spec | 📝 Planned |
organization_id in payload or metadata for tenant isolation. Filterable fields used by PM-19 rules:
| Event Type | Required Payload Fields | Optional Filter Fields (for rule matching) |
|---|---|---|
claim_submitted | organization_id, claim_id, payer_id | payer_id |
claim_status_changed | organization_id, claim_id, new_status, payer_id | new_status, payer_id |
claim_created | organization_id, claim_id, payer_id | payer_id |
denial_received | organization_id, claim_id, payer_id | payer_id |
charge_approved | organization_id, charge_id | — |
charge_status_changed | organization_id, charge_id, new_status | new_status |
payment_posted | organization_id, payment_id, claim_id | — |
write_off_approved | organization_id, approval_id, payment_id, write_off_amount | — |
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 includeevent_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
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_finalizedPublisher: CL
Subscribers: PM-07 (charge capture)
Contract: CL-19 Peer Recovery Support
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)
consent_granted / consent_revoked (CL-11)
cl_sdoh_screening_completed (CL-18)
Consumers MUST resolve patient identity fromchart_id (e.g. cl_sdoh_screenings.chart_id → cl_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_completedChannel:
cl_eventsPublisher: 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_changedPublisher: 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_createdPublisher: PM (PM-08)
Subscribers: FW-03 (optional)
Spec Reference: PM-19
denial_received (PM-08 / PM-09)
Event:denial_receivedPublisher: 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_postedChannel:
cl_pm_eventsPublisher: 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:
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_approvedChannel:
cl_pm_eventsPublisher: 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:
event_id to avoid duplicate write-off GL entries. No PII/PHI in payload (IDs only).
Planned Events (FA Cross-Core — when CE/GR/CL ready)
| Event | Publisher | Consumer | Spec | Status |
|---|---|---|---|---|
donation_received | CE | FA-05, FA-02 | CE-18, FA-31 | 📝 Planned |
fundraising_campaign_completed | CE | FA-07 | CE-18, FA-31 | 📝 Planned |
compliance_cost_incurred | GR | FA-13, FA-15 | FA-34 | 📝 Planned |
clinical_program_cost_allocated | CL | FA-35 (→ FA-15 allocation bases) | FA-35 | 📝 Planned |
encounter_cost_calculated | PM-35 | FA-35 (Phase 2) | PM-35, FA-35 | 📝 Planned — schema pending FA-35 + PM-35 joint session (see PENDING_CONTRACTS.md) |
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.
- 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)
- FA-35 CL-FA Clinical Program Cost Allocation
- Subscriber identifier: FA-35
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):
- 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)
- PM-35 Encounter-Level Cost Accounting
- FA-35 CL-FA Clinical Program Cost Allocation
- PM-35 Integration Doc
CL/PM Event Error Handling and Idempotency
- Idempotency: Every event MUST include a unique
event_id. Consumers MUST record processedevent_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_completedChannel:
cl_pm_eventsPublisher: 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):
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "assessment_completed". |
organization_id | uuid | Yes | Tenant isolation; required. |
timestamp | timestamptz (ISO 8601) | Yes | Event occurrence time. |
site_id | uuid | Optional | If site-scoped. |
user_id | uuid | Optional | If user-initiated (e.g. completing clinician). |
correlation_id | string (uuid) | Optional | For event chaining and audit trail. |
assessment_id | uuid | Yes | Assessment record ID. Event payload must not contain PII/PHI; use IDs only. |
patient_id | uuid | Yes | Patient record ID. Event payload must not contain PII/PHI; use IDs only. |
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_scheduledChannel:
cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "treatment_plan_review_scheduled". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
site_id | uuid | Optional | If site-scoped. |
user_id | uuid | Optional | If user-initiated. |
correlation_id | string (uuid) | Optional | For audit/chain. |
treatment_plan_id | uuid | Yes | Plan record ID. |
chart_id | uuid | Yes | Patient chart ID. |
review_due_date | string (date) | Yes | Date plan review is due. |
CL-03: treatment_plan_event_triggered
Event:treatment_plan_event_triggeredChannel:
cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "treatment_plan_event_triggered". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
site_id | uuid | Optional | If site-scoped. |
user_id | uuid | Yes | User who recorded the event; required for user-initiated life-event triggers (omit only for explicit system-initiated events). |
correlation_id | string (uuid) | Optional | For audit/chain. |
chart_id | uuid | Yes | Patient chart ID. |
life_event_type | string | Optional | e.g. hospitalization, move, loc_change, incarceration. |
event_recorded_at | string (ISO 8601) | Yes | When the event was recorded in the system. |
treatment_plan_id | uuid | Optional | Current active plan ID if known. |
PM-02: Insurance & Eligibility Verification Events
Status: 📝 PlannedSpec Reference: PM-02-insurance-eligibility-verification.md
Event: pm_eligibility_verified
Channel: pm_eventsPublisher: 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 setStatus: 📝 Planned Payload Schema:
- Allowed:
check_id,patient_id(UUID only — no name/DOB),check_type,eligible,organization_id - Prohibited:
benefit_detailscontents,policy_number,subscriber_dob,subscriber_name - Retention: Event logged to
pf_audit_logs; no PHI in application logs or edge function stdout
- CL-01: Update patient chart coverage status display (coverage info widget)
- PM-08: Allow/block claim submission based on eligibility status (eligibility gate)
- FW automations: Trigger workflows on eligibility change (e.g., notify staff of inactive coverage)
- Register in
fw_workflow_eventstable via seed migration (Phase 0, T0 task) - Channel
pm_eventsmust be added to the Event Delivery Mechanism channel list - Published via
publishEvent()from@/platform/eventsafter 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:
- 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 (createLoggersanitization required)
- PM-48 (Patient Cost Estimation): Trigger refresh of patient responsibility estimates for affected appointments
- PM-07 (Charge Capture): Refresh copay/deductible defaults shown in charge entry form for the patient
- Published via
publishEvent()from@/platform/eventsafterpm-parse-271-benefitsedge function completes successful parsing - Channel
pm_events(already declared forpm_eligibility_verified) - Service-role edge function MUST scope all DB writes by
organization_idbefore 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.mdEvent: 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:
- Allowed: all payload fields above (UUIDs and timestamp only)
- Prohibited:
merge_reasonbody, demographics, MRN, any chart data - Retention: Event row retained in
fw_workflow_events; PF-44 audit row retained per HIPAA §164.312(b)
- Idempotency key:
merge_log_id - Delivery: at-least-once
- Ordering: per
survivor_patient_id - Undo: v1 publishes no
pm_patient_merge_undoneevent. Consumers MUST reconcile frompm_patient_merge_log(filterrolled_back_at IS NOT NULL) when maintaining long-lived projections.
- CL: Invalidate chart-by-patient caches keyed on
merged_patient_id; subsequent reads will resolve to the survivor via the re-pointedcl_patient_charts.patient_id. - PM-08 (Claims): Drop in-memory groupings keyed on
merged_patient_id. - CE-29 (Lead Conversion): Re-point lead↔patient mapping rows where applicable.
- PF-71 (Patient Identity Boundary): Refresh identity caches.
- Registered in
fw_workflow_eventsvia the PM-01-EN-01 migration (one row, schema_version = 1, owning_core =pm). - Channel
pm_eventsis already declared (PM-02 events). - Published from inside the SECURITY DEFINER function; if the
fw_workflow_eventsinsert 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.mdEvent 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:
- Event table:
fw_domain_events(viapublishEvent()from@/platform/events) - Retention: Standard event retention policy (see EVENT_DELIVERY.md)
- 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
- Register in
fw_workflow_eventstable via seed migration - Published via
publishEvent()from@/platform/eventsafter prediction record creation inpredict-denial-riskedge 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:
- Event table:
fw_domain_events(viapublishEvent()from@/platform/events) - Retention: Standard event retention policy (see EVENT_DELIVERY.md)
- 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
- PM-50 Retraining: Add outcome to training dataset for monthly model retraining
- Analytics: Track prediction accuracy over time (precision/recall metrics)
- Register in
fw_workflow_eventstable via seed migration - Published via database trigger on
pm_denial_predictionsUPDATE whenactual_outcomechanges 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_createdChannel:
cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "cl_lab_order_created". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
site_id | uuid | Optional | If site-scoped. |
user_id | uuid | Yes | Ordering clinician. |
correlation_id | string (uuid) | Optional | For audit/chain. |
order_id | uuid | Yes | Order record ID. |
chart_id | uuid | Yes | Patient chart ID. |
ordering_provider_id | uuid | Yes | Ordering provider ID. |
loinc_code | string | Yes | LOINC code for the ordered test. |
priority | string | Yes | routine or stat. |
lab_id | uuid | Optional | Reference lab ID if external. |
- 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
publishEvent() from @/platform/events.
CL-09: cl_lab_result_received
Event:cl_lab_result_receivedChannel:
cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "cl_lab_result_received". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
site_id | uuid | Optional | If site-scoped. |
user_id | uuid | Optional | Null for interface-ingested results. |
correlation_id | string (uuid) | Optional | For audit/chain. |
order_id | uuid | Yes | Parent order ID. |
result_id | uuid | Yes | Result record ID. |
chart_id | uuid | Yes | Patient chart ID. |
loinc_code | string | Yes | LOINC code for the resulted test. |
abnormal_flag | string | Optional | N, L, H, LL, HH, A per HL7 Table 0078. |
source | string | Yes | interface or manual. |
- 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 | Action | Status |
|---|---|---|
| CL-08 (CDS) | Evaluate evaluateCdsRules() for abnormal result alerts | 📝 Planned |
| PF-10 (Notifications) | Notify ordering provider of new result | 📝 Planned |
| Event Consumer | Log to pf_audit_logs | 📝 Planned |
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_reviewedChannel:
cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "cl_lab_result_reviewed". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
site_id | uuid | Optional | If site-scoped. |
user_id | uuid | Yes | Reviewing clinician. |
correlation_id | string (uuid) | Optional | For audit/chain. |
order_id | uuid | Yes | Parent order ID. |
result_id | uuid | Yes | Result record ID. |
chart_id | uuid | Yes | Patient chart ID. |
reviewed_by | uuid | Yes | Clinician who reviewed/signed off. |
- 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
publishEvent() from @/platform/events.
Related Documentation
- Platform Integration Layers - Platform layer integrations
- API Contracts - API-based integrations
- IT Integration Contracts - IT module integration contracts
- Integration Examples - Code examples
- Constitution - Engineering guardrails
PF-63: Teams Channel Notification Dispatch
Event:teams_channel_notification_dispatchedPublisher: PF (Platform Foundation) —
event-consumer edge functionSubscribers:
entra-teams-notify edge functionStatus: ✅ 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
hr_employee_hired— New hire announcementcredential_expiring— Credential expiry warningform_submitted— Form submission notificationleave_approved— Leave approval notificationrh_resident_admitted— New resident admission (canonical; replacesresident_admitted)
- 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_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "referral_accepted". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Yes | User who accepted the referral. |
correlation_id | string (uuid) | Optional | For audit/chain. |
referral_id | uuid | Yes | PM-06 referral record ID. |
patient_id | uuid | Yes | Patient ID. |
referral_direction | string | Yes | inbound or outbound. |
from_facility | string | Optional | Originating facility. |
to_facility | string | Optional | Destination facility. |
from_level_of_care | string | Optional | Source LOC. |
to_level_of_care | string | Optional | Destination LOC. |
referral_reason | string | Yes | Reason for referral. |
urgency | string | Yes | routine, urgent, or emergent. |
- 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
- Create
cl_transitionsrecord withtransition_type = 'referral'andreferral_id - If outbound: trigger discharge checklist creation
- Trigger medication reconciliation (CL-05)
- Generate C-CDA transition summary (CL-16, when available)
Event: transition_completed
Channel: cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "transition_completed". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Yes | User who completed the checklist. |
correlation_id | string (uuid) | Optional | For audit/chain. |
transition_id | uuid | Yes | CL-12 transition record ID. |
chart_id | uuid | Yes | Patient chart ID. |
referral_id | uuid | Yes | Linked PM-06 referral ID. |
transition_type | string | Yes | discharge, transfer, referral, etc. |
checklist_id | uuid | Yes | Completed discharge checklist ID. |
- 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
- Update
pm_referralsstatus tocompletedwhereid = referral_id
CL-15: Clinical Reporting & Quality Measures Events
Event: cl_incident_reported
Channel: cl_eventsPublisher: 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 | Action | Status |
|---|---|---|
| GR-03 (Compliance Tracking) | Invokes gr-handle-incident-reported edge function via fw_domain_events trigger; creates gr_compliance_checks row with result: fail, check_type: ad_hoc | ✅ Implemented |
| GR-04 (Audit Management) | Initiate audit workflow for reportable incidents | ✅ Implemented |
| GR-08 (Accreditation Management) | Log incident as accreditation evidence (Joint Commission, CARF) | ✅ Implemented |
| PF-10 (Notifications) | Notify compliance officers and administrators | ✅ Implemented |
- Safe to log:
incident_id,organization_id,incident_type,severity,reported_by - Log as flag only:
chart_id→ loghas_chart_id: true/false - Prohibited: patient names, chart content, clinical details
custom_fieldsmust be sanitized to remove any PII/PHI before logging
event_name + payload_hash.
CL-16-EN-01: TEFCA/QHIN Connectivity Events (Planned) \
Publisher: CL (Clinical & EHR) — CL-16-EN-01Status: 📝 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_idis required for idempotency and retry deduplication across at-least-once delivery.
Event: cl_tefca_query_submitted \
Channel: cl_pm_eventsPublisher: 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_eventsPublisher: 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_eventsPublisher: 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_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "cl_fhir_bundle_exported". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Yes | User who triggered the export. |
correlation_id | string (uuid) | Optional | For audit/chain. |
chart_id | uuid | Yes | Patient chart ID. |
exchange_log_id | uuid | Yes | cl_data_exchange_log record ID. |
exchange_type | string | Yes | fhir_api, bulk_export, or patient_access. |
resource_types | string[] | Yes | FHIR resource types included (e.g., ["Patient","Condition"]). |
record_count | number | Yes | Total resources in the bundle. |
has_part2_consent | boolean | Yes | Whether Part 2 consent was active (determines if SUD data was included). |
- 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
- PF-04 (Audit): Log export event to
pf_audit_logswith exchange details - PF-10 (Notifications): Optionally notify compliance officer for bulk/patient-access exports
(correlation_id, event_type). Consumers should deduplicate by exchange_log_id.
Event: cl_ccda_document_sent
Channel: cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "cl_ccda_document_sent". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Yes | User or service account that initiated the send. |
correlation_id | string (uuid) | Optional | For audit/chain. |
chart_id | uuid | Yes | Patient chart ID. |
exchange_log_id | uuid | Yes | cl_data_exchange_log record ID. |
document_type | string | Yes | CCD, discharge_summary, or referral_note. |
partner_id | uuid | Optional | Recipient organization/partner ID. |
partner_name | string | Optional | Recipient name (e.g., “Arizona Contexture”). |
has_part2_consent | boolean | Yes | Whether Part 2 consent was active. |
redisclosure_notice_included | boolean | Yes | Whether 42 CFR Part 2 redisclosure notice was attached. |
- 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
- PF-04 (Audit): Log send event with partner details and document type
- GR (Compliance): Track C-CDA exchanges for regulatory reporting; verify redisclosure notice compliance
(correlation_id, event_type). Consumers deduplicate by exchange_log_id.
Event: cl_ccda_document_received
Channel: cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "cl_ccda_document_received". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Optional | Service account or user who processed the document. |
correlation_id | string (uuid) | Optional | For audit/chain. |
chart_id | uuid | Yes | Matched patient chart ID (after MPI resolution). |
exchange_log_id | uuid | Yes | cl_data_exchange_log record ID. |
document_type | string | Yes | CCD, discharge_summary, referral_note, or adt_notification. |
partner_id | uuid | Optional | Sending organization/partner ID. |
partner_name | string | Optional | Sender name. |
resource_types_extracted | string[] | Yes | FHIR resource types parsed from the C-CDA (e.g., ["Condition","MedicationRequest"]). |
record_count | number | Yes | Number of discrete data elements extracted. |
reconciliation_needed | boolean | Yes | Whether new data conflicts with existing chart data. |
- 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
- CL-01 (Chart): Flag chart for reconciliation review if
reconciliation_needed = true; store document reference incl_patient_chart_documents - PF-10 (Notifications): Notify assigned clinician that new external data is available for review
(correlation_id, event_type). Consumers deduplicate by exchange_log_id.
PM-13: Telehealth Integration Events
Event: telehealth_session_started
Channel: cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "telehealth_session_started". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Yes | Provider who started the session. |
correlation_id | string (uuid) | Optional | For audit/chain. |
session_id | uuid | Yes | pm_telehealth_sessions.id. |
appointment_id | uuid | Yes | Linked pm_appointments.id. |
encounter_id | uuid | Optional | Linked encounter ID, if created. |
telehealth_modality | string | Yes | audio_video, audio_only, store_forward, or remote_monitoring. |
platform | string | Yes | Platform name (e.g., Zoom Healthcare, Doxy.me, stub). |
- 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
- FW-16 (Workflow): Trigger automation rules on session start (e.g., notify care team)
- PF-10 (Notifications): Send session-started notification to relevant staff
(correlation_id, event_type). Consumers deduplicate by session_id.
Event: telehealth_session_completed
Channel: cl_pm_eventsPublisher: 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:
| Field | Type | Required | Description |
|---|---|---|---|
event_type | string | Yes | Must equal "telehealth_session_completed". |
organization_id | uuid | Yes | Tenant isolation. |
timestamp | string (ISO 8601) | Yes | Event occurrence time. |
user_id | uuid | Yes | Provider who ended the session. |
correlation_id | string (uuid) | Optional | For audit/chain. |
session_id | uuid | Yes | pm_telehealth_sessions.id. |
appointment_id | uuid | Yes | Linked pm_appointments.id. |
encounter_id | uuid | Optional | Linked encounter ID. |
telehealth_modality | string | Yes | audio_video, audio_only, store_forward, or remote_monitoring. |
is_audio_only | boolean | Yes | Deprecated flag for backward compat with PM-07 modifier-logic.ts. |
patient_location | string | Optional | Patient location (e.g., home, office). Drives POS code (10 vs 02). |
provider_location | string | Optional | Provider location. |
duration_minutes | number | Optional | Session duration in minutes. |
- Allowed:
session_id,appointment_id,encounter_id,organization_id,telehealth_modality,is_audio_only,duration_minutes,user_id - Prohibited: Patient names, DOB, SSN, session URLs, recording URLs, patient_location (may reveal home address)
- Masking:
patient_locationlogged as presence flag (has_patient_location: true/false), not raw value - Retention: Event logged to
pf_audit_logs; no PHI in application logs
- PM-07 (Charge Capture): Apply telehealth modifiers (95/FQ/GQ) and POS (02/10) based on
telehealth_modalityandpatient_locationwhenclinical_note_finalizedfires - FW-16 (Workflow): Trigger post-session automation (e.g., satisfaction survey, follow-up scheduling)
- CL-04 (Progress Notes): Pre-fill telehealth fields (
is_telehealth,telehealth_modality,patient_location,provider_location) on the clinical note
(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:
- 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_nameonly if guaranteed safe (e.g.,BATCH_20260223_001.x12); otherwise hash or redact - Retention: Logged to
pf_audit_logs
- PM-08 (Claims): Update claim status to
submittedfor all claims in the batch - PM-11 (RCM Dashboard): Increment submission metrics
- 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:
- 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_messageto remove potential PHI before logging - Retention: Logged to
pf_audit_logs
- PM-08 (Claims): Update claim status to
error/draft(returned for correction) - 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:
- 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
- PM-09 (Payment Posting & ERA): Resolve storage location from
era_file_id, then run payment posting pipeline — createpm_paymentsandpm_payment_applicationsfrom CLP/SVC data; persist CARC/RARC intopm_transaction_log.error_codes - 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:
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
- PF-10 (Notifications): Alert billing admin on
downordegraded; send recovery notification onhealthy(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.mdEvent: 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:
- 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
- PM (dashboard): Refresh auth expiration dashboard counts
- 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:
no_active_auth— No active authorization found for the service date and service typeunits_exceeded— Claim line units exceed remaining authorized unitsdate_outside_auth— Service date falls outside the authorization’s valid date range
- 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 optionalmessagefield
- 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:
- Allowed:
monitoring_event_id,enrollment_id,monitoring_type,due_by,days_overdue,organization_id - Prohibited:
chart_idshould be logged ashas_chart_id: true/false, not as raw UUID - Retention: Logged to
pf_audit_logs
- 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:
- Allowed:
enrollment_id,adherence_status,consecutive_missed_count,organization_id - Prohibited:
chart_idshould be logged ashas_chart_id: true/false, not as raw UUID - Retention: Logged to
pf_audit_logs
- PF-10 (Notifications): Alert prescriber and care team of adherence risk
PF-48: Security Event Detected
Status: ✅ ImplementedEvent:
security_event_detectedChannel: Database Webhook on
pf_security_events INSERTPublisher: 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):
- Refetch full row from
pf_security_eventsbyevent_idbefore processing - Verify
organization_idmatches webhook payload (TOCTOU protection) - Match against
pf_security_alert_configsfor active alert rules - Deliver via PF-10 with retry (3 attempts, exponential backoff)
- Write to
pf_security_alert_delivery_failures(DLQ) on permanent failure
- PF-10 (Notifications): Deliver security alerts to configured recipients
- PF-04 (Audit): Log security event processing
- PF-36 (Health Dashboard): Display security event metrics
PF-43: Quota Violated
Status: 📝 PlannedEvent:
pf_quota_violatedPublisher: 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).
| Field | Type | Required | Description |
|---|---|---|---|
event_id | string (UUID) | Yes | Unique idempotency key; consumers MUST skip duplicates |
occurred_at | string | Yes | ISO 8601 timestamp when the event occurred |
source | string | Yes | Producer identifier (e.g. pf-43-quota-enforcement) |
spec_version | string | Yes | Event contract version (e.g. semver 1.0.0) for evolution |
event_version | string | Yes | Contract version for pf_quota_violated (semver); required for safe evolution |
organization_id | string (UUID) | Yes | Organization the quota applies to |
resource_type | string | Yes | One of: storage, api_calls, users, custom_objects, workflow_executions |
limit_type | string | Yes | soft or hard |
quota_value | number | Yes | Configured quota value |
actual_usage | number | Yes | Usage that caused the violation |
violated_at | string | Yes | ISO 8601 timestamp of the violation |
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.
- 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.
- PF-10 (Notifications): Deliver resolution notification to original alert recipients
PF-68: Website Chatbot — Lead Captured
pf_chatbot_lead_captured
Status: ✅ ImplementedPublisher:
chatbot-lead-capture edge functionChannel:
domain_events
Subscribers:
| Subscriber | Action |
|---|---|
| CE-01 (Contacts/Leads) | Create or update contact and lead records |
| PF-35 (Webhooks) | Dispatch webhook to external CRM integrations |
- CE-01: Link lead to chatbot session source, set
source_type = 'chatbot' - 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:
| Subscriber | Action |
|---|---|
| CE-08 (SMS) | Invalidate suppression cache for the contact |
| CE-09 (Email Campaigns) | Invalidate suppression cache; remove from in-flight campaign send lists |
| CE-03 (Call Management) | Invalidate DNC/phone cache before next outbound dial |
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_eventsSpec Reference: CE-17 CE–RH Admission Handoff Contract Subscribers:
| Subscriber | Action |
|---|---|
| RH-01 (Resident Management) | Create resident admission from converted lead |
- RH-01:
- Resolve contact PII by reading
ce_contactsviacontact_idwith authorized access (RLS-enforced) - Create resident admission record with mapped fields from resolved contact data
- Check idempotency via
lead_id+organization_id(or fallback toevent_idfrom audit table)
- Resolve contact PII by reading
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 ProgressPublisher: CE-29 (Lead-to-Patient Conversion Pipeline)
Channel:
domain_eventsSpec Reference: CE-29 Integration Subscribers:
| Subscriber | Action |
|---|---|
| PM-01 (Patient Registration) | Create patient record from converted lead |
| PM-38 (Intake Appointment Automation) | Auto-schedule intake appointment |
correlation_id — subscribers MUST deduplicate.
ce_lead_converted_to_resident
Status: 🔜 In ProgressPublisher: CE-29 (Lead-to-Patient Conversion Pipeline)
Channel:
domain_eventsSpec Reference: CE-29 Integration Subscribers:
| Subscriber | Action |
|---|---|
| RH-01 (Admission Wizard) | Create resident record from converted lead |
| PM-39 (Waitlist Management) | Add to waitlist if no bed available |
correlation_id — subscribers MUST deduplicate.
donation_received
Status: 📝 PlannedPublisher: CE-18 (Fundraising & Donation Events)
Channel:
domain_eventsSpec Reference: CE-18 Fundraising & Donation Events, FA-31 CE-FA Donation Revenue Integration Subscribers:
| Subscriber | Action |
|---|---|
| FA-31 (CE-FA Donation Revenue Integration) | Post donation revenue to GL (FA-02, FA-05) |
- FA-31: Create GL journal entry (debit cash/AR, credit revenue) with fund allocation; check idempotency via
event_id
event_ids and MUST NOT create duplicate GL entries.
fundraising_campaign_completed
Status: 📝 PlannedPublisher: CE-18 (Fundraising & Donation Events)
Channel:
domain_eventsSpec Reference: CE-18 Fundraising & Donation Events, FA-31 CE-FA Donation Revenue Integration Subscribers:
| Subscriber | Action |
|---|---|
| FA-07 (Financial Reporting) | Update campaign revenue reports |
| FA-31 (Optional) | Generate campaign summary entry |
- FA-07: Update campaign revenue reports with completion summary
- FA-31 (Optional): Generate campaign summary journal entry or report flag
event_ids or use campaign_id + organization_id + completion_date composite key.
ce_web_form_submitted
Status: 📝 PlannedPublisher: CE-10 (Web-to-Lead Capture)
Channel:
domain_eventsSpec Reference: CE-10 Web-to-Lead Capture Subscribers:
| Subscriber | Action |
|---|---|
| CE-01 (Contacts/Leads) | Lead already created by CE-10; event provides notification for workflow triggers |
| CE-05 (Pipeline & Reporting) | Update pipeline analytics (web form submission count, conversion tracking) |
| PF-10 (Notifications) | Send notification to assigned staff member (if lead assignment configured) |
- CE-01: Lead already created; event enables workflow automation triggers
- CE-05: Update pipeline analytics (web form submission metrics)
- PF-10: Send notification to assigned staff member
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.mdSee also: EVENT_DELIVERY.md — when these fire relative to the table-driven automation path.
workflow.execution.timed_out
Status: ✅ ImplementedPublisher: FW (via
workflow-timeout-checker Edge Function; pg_cron–scheduled)Channel:
fw_eventsConsumers: FW-47 (DLQ), FW-25 (compensation), FW-22 (monitoring)
workflow.execution.deadline_extended
Status: ✅ ImplementedPublisher: FW (via
extend-execution-deadline Edge Function)Channel:
fw_eventsConsumers: Audit trail, FW-22 (monitoring)
FW-47: Dead Letter Queue Alert Events
Integration: FW-47-dead-letter-queue-INTEGRATION.mdPublisher: 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: 📝 PlannedPublisher: PF (via
pf_refresh_process_health scheduled function)Channel:
domain_eventsConsumers: PF-36 (System Health Dashboard), PF-10 (Notifications)
process_discovered
Status: 📝 PlannedPublisher: PF (via auto-discovery cron)
Channel:
domain_eventsConsumers: PF-04 (Audit Logging)
PF-83: SLA Management Events
pf_sla_warning_triggered
Status: 📝 PlannedPublisher: PF (via
pf-sla-checker edge function)Channel:
domain_eventsConsumers: PF-10 (Notifications)
pf_sla_breached
Status: 📝 PlannedPublisher: PF (via
pf-sla-checker edge function)Channel:
domain_eventsConsumers: PF-10 (Notifications), FW-03 (Workflow Automation, optional)
pf_sla_completed
Status: 📝 PlannedPublisher: PF (via event-driven instance resolution)
Channel:
domain_eventsConsumers: PF-04 (Audit Logging)
PF-91: Compliance Automation & Regulatory Dashboard
Spec / integration: PF-91 spec, PF-91 integrationpf_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 integrationpf_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:
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
ce_screening_completed
Status: ✅ ImplementedPublisher: CE-28 (Intake Screening & Triage Workflow)
Channel:
domain_eventsSpec Reference: CE-28 Integration
Implementation:
src/cores/ce/hooks/useCreateScreening.ts (client-side, consent-gated per 42 CFR Part 2)
Subscribers:
| Subscriber | Action |
|---|---|
| PM-38 (Intake Appointment Automation) | Auto-create intake appointment when disposition = 'proceed' |
| PM-39 (Waitlist Management) | Route to waitlist when disposition = 'waitlist' or proceed+no-bed |
| CE-29 (Lead Conversion Pipeline) | Trigger lead-to-patient conversion |
| CL-40 (Clinical Intake Assessment) | Pre-populate intake assessment from screening data |
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: ✅ ImplementedPublisher: CE-28 (conditional — emitted when
disposition = 'proceed' but bed unavailable)Channel:
domain_eventsSpec Reference: CE-28 Integration
Implementation:
src/cores/ce/hooks/useCreateScreening.ts
Subscribers:
| Subscriber | Action |
|---|---|
| PM-39 (Waitlist Management) | Add lead to waitlist queue with program type and priority |
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:
| Subscriber | Action |
|---|---|
| PF-83 (SLA Platform) | Start crisis SLA timer (Tier-1 = 60s page; Tier-2 = 5min queue) |
| PF-10 (Notifications) | Page on-call user (Tier-1 only) |
| CE Crisis Queue UI | Refresh queue / unacknowledged-alert widget |
| CE-29 (Conversion Pipeline) | Mark conversion-pipeline aware of crisis hand-off |
alert_id (RLS-enforced).
Idempotency: correlation_id (alert ID) — subscribers MUST deduplicate.
CL-14-EN-01: Group Encounter Generation Events
cl_group_encounters_approved
Contract ID: EVT-CL-14-EN-01-001Publisher: CL-14-EN-01
Subscribers: PM-07
Channel:
cl_eventsVersion: 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:
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:
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:
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:
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:
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:
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.
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
| Event | Publisher | Subscribers | Purpose / Payload (in addition to common metadata) |
|---|---|---|---|
pf.transcription.session.created | PF-100 | CL-36 (encounter link), PM-08 (charge prep), PF-91 (evidence) | { event_id, module_key, recording_purpose, source, subject_of_record_type, subject_of_record_id?, encounter_id?, jurisdiction_profile_id, is_part2_program } |
pf.transcription.session.consent_verified | PF-100 | CL-11 (audit), PF-91 | { event_id, consent_record_type, consent_record_id, jurisdiction_profile_id, is_part2_program } |
pf.transcription.session.consent_revoked | PF-100 | All consumers (STOP downstream processing) | { event_id, revoked_by, revoked_at, reason? } |
pf.transcription.session.cancelled | PF-100 | All consumers | { event_id, reason, cancelled_by } |
pf.transcription.draft.ready | PF-100 | CL-36, HR/GR/CE/RH UIs, PF-10 (notify reviewer) | { event_id, draft_id, template_id, generation_latency_ms, requires_manual_drafting: boolean } |
pf.transcription.draft.attested | PF-100 | Consumer core (writes domain record), PF-91, PF-04 (audit) | { event_id, draft_id, reviewer_id, attested_at, attested_content_sha256, ai_vs_final_diff_pct, module_attest_payload?: object } |
pf.transcription.audio.deleted | PF-100 | PF-91, PF-04, subject-of-record portal | { event_id, deleted_at, retention_policy } |
pf.transcription.deletion_requested | PF-100 | Operator alert, PF-91 | { event_id, requested_by, requested_at, scope: 'audio' | 'transcript' | 'draft' | 'all' } |
pf.transcription.deletion_completed | PF-100 | PF-91, subject portal | { event_id, completed_at, scope } |
pf.transcription.policy.violation | PF-100 | PF-91 (evidence), PF-10 (notify admin) | { event_id, violation_type, blocked_at, policy_key } |
Consumed events
| Event | Publisher | PF-100 reaction |
|---|---|---|
pf.consent.cl_consent.revoked | CL-11 | Triggers session-revocation cascade for any active CL session referencing the consent (publishes pf.transcription.session.consent_revoked for each affected session). |
pf.encounter.created | PM | Optional auto-link of a clinical session in pre_record state to the new encounter. |
pf.encounter.cancelled | PM | Cancels any in-progress capture for that encounter (publishes pf.transcription.session.cancelled with reason='encounter_cancelled'). |
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.
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.
(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).
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_grantedandcl.part2_consent_revokedare required by PM-55. TBD by CL-11 owner — tracked inPENDING_CONTRACTS.mduntil CL-11 publishes them. If CL-11 cannot publish, PM-55 will fall back to pollingcl_consents.updated_atper 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)
(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)
(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)
(milestone_id) — published once per milestone status transition pending|in_progress → overdue. 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-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)
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)
(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_refare 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 uniqueevent_id(UUID) which is the canonical cross-system dedupe key. Consumers MUST record processedevent_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_admissionis a logical alias for the canonical RH-01.1rh_resident_admittedevent filtered tofacility_type = 'psychiatric_residential'(and likewiserh_resident_discharged). No new RH event is introduced — RH-01.1 canonical names remain authoritative; consumers subscribe to the canonical events and filter byfacility_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
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
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
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
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
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
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):
- Contract
created_byuser - All org users holding permission
ce.contracts.manage(resolved viace_users_with_permission(p_org_id, 'ce.contracts.manage')SECURITY DEFINER helper)
(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.