Automated Charge Reconciliation — Integration Doc

​

Overview

​

Integration Points

​

PF-29 (Tasks) — Platform Integration Layer

{
  source_type: 'charge_reconciliation',
  source_id: reconciliation_result.id,   // pm_charge_reconciliation_results.id
  organization_id: org.id,
  title: `<gap_type> — <days_outstanding> days`,
  // assigned_to: null (biller self-assigns from task queue)
  // status: 'open'
}

​

PM-07 (Charge Capture) — Same-Core Data

• PM-36 reads pm_charges to detect encounter_no_charge gaps
• No event contract; direct table query within same core

​

PM-08 (Claims Management) — Same-Core Data

• PM-36 reads pm_claims to detect charge_no_claim gaps
• No event contract; direct table query within same core

​

PM-09 (Payment Posting) — Same-Core Data

• PM-36 reads pm_payments to detect claim_no_payment gaps
• No event contract; direct table query within same core

​

PM-11 (Revenue Cycle Dashboard) — Shared Table

• PM-36 populates pm_charge_recon_daily_summary (1 row per org per night)
• PM-11 queries pm_charge_recon_daily_summary for gap count KPIs, charge lag, and 30/60/90-day trends
• Integration: shared table within same core; no event needed

​

Pending Contracts

​

Permissions

​

Security

• All pm_charge_reconciliation_results and pm_charge_recon_daily_summary rows are scoped by organization_id
• RLS uses pm_has_org_access(organization_id, auth.uid()) (SECURITY DEFINER)
• Edge function uses service-role key; PHI (patient_id) must not appear in logs
• See PM-36 spec Security Considerations for full detail

​

PF-96 (Jurisdiction Profiles) — Read-Only

• PM-36 uses org-level pm_module_settings thresholds for v1
• Phase 2 enhancement: baseline thresholds read from PF-96 jurisdiction profile, with org settings as overrides
• No direct PF-96 table dependency in v1; listed for architecture awareness
• API Contract: See API_CONTRACTS.md § PF-96 and PF-96 Integration Doc for resolver function signatures and fallback semantics

​

Integration Matrix Entry