Overview
PM-49 provides a configurable rules engine for automating routine revenue cycle decisions with pre-built behavioral health rule templates. It builds on PM-19’s general business rule automation framework with RCM-specific templates, actions, and work queue prioritization.Platform Foundation Dependencies
Internal PM Dependencies
API Contracts
Full contract details: See API_CONTRACTS.mdPM-49 → PM-09 (Payment Posting)
Purpose: Auto-post small balance adjustments and contractual adjustments Endpoint pattern: Edge function or SECURITY DEFINER RPC Request Schema:CLAIM_NOT_FOUND: Claim ID does not existINSUFFICIENT_BALANCE: Balance lower than adjustment amountINVALID_ADJUSTMENT_CODE: Unrecognized codeORG_MISMATCH: Claim does not belong to organization
rule_execution_id as idempotency key; duplicate requests return existing adjustment_id
PM-49 → PM-29 (Denial Management)
Purpose: Auto-trigger denial re-submissions for correctable denial codes Endpoint pattern: Edge function or SECURITY DEFINER RPC Request Schema:DENIAL_NOT_FOUND: Denial ID does not existFILING_DEADLINE_PASSED: Resubmission past filing deadline (resolved via PF-96)ALREADY_RESUBMITTED: Denial already has pending resubmissionORG_MISMATCH: Denial does not belong to organization
rule_execution_id as idempotency key
Filing Deadline Resolution: Uses PF-96 jurisdiction profile to validate resubmission window (see PF-96 API contracts)
PM-49 → PM-45 (Collections)
Purpose: Auto-transfer accounts to collections tiers based on aging rules Endpoint pattern: Edge function or SECURITY DEFINER RPC Request Schema:ACCOUNT_NOT_FOUND: Account/claim ID does not existALREADY_IN_COLLECTIONS: Account already assigned to collections tierINELIGIBLE_PAYER: Payer type excluded from collections (e.g., Medicaid in some states)ORG_MISMATCH: Account does not belong to organization
rule_execution_id as idempotency key
Event Contracts
Events Consumed
Events Published
Scheduled Processing
Tenant-Timezone Execution Strategy:
Both
pm-rcm-rule-batch and pm-rcm-queue-scoring use a dispatcher pattern to execute at tenant-local time (2 AM and 3 AM respectively):
- Fixed hourly cron:
0 * * * *— runs every hour - Dispatcher logic:
- For each organization, resolve effective timezone (site timezone if available, otherwise org default)
- Calculate current local time in that timezone
- If local time matches target hour (02:00 for rules, 03:00 for scoring), enqueue/execute for that organization
- Skip organizations already processed in current day window
- Job targets:
pm-rcm-rule-batchinvokesrcm-execute-ruleswithorganization_idwhen tenant-local time is 02:00pm-rcm-queue-scoringinvokesrcm-score-work-queuewithorganization_idwhen tenant-local time is 03:00
- Metadata: Batch execution persists timezone used for audit reproducibility (see spec §Scope clarification table)
Security Considerations
- All tables enforce organization-scoped RLS
- Execution records are immutable (no UPDATE/DELETE policies)
- Rule activation requires segregation of duties (creator != activator, except Director override)
- No PHI in rule definitions — rules reference account properties only
- Jurisdiction-aware filing deadlines via PF-96
Validation Checklist
- Event contracts match EVENT_CONTRACTS.md entries
- API contracts documented for PM-09/PM-29/PM-45 interactions (see API_CONTRACTS.md and API Contracts section above)
- Platform layer usage aligned with PLATFORM_INTEGRATION_LAYERS.md
- Integration matrix entry in CROSS_CORE_INTEGRATIONS.md
Last Updated: 2026-04-07