Overview
PM-48 provides pre-admission cost estimation for insured patients and a financial clearance workflow that gates admission on cost transparency and payment arrangements. It integrates with several PM-internal specs and PF platform layers.Platform Foundation Dependencies
PM Internal Dependencies
Event Contracts
Events Published
1. pm_cost_estimate_generated
- Publisher: PM-48
- Subscribers: PM-32 (conditional — when threshold exceeded), PM-11
- Payload Schema:
- Purpose: Notify downstream of new estimate; trigger financial counseling referral if threshold exceeded
- Status: 📝 Planned
2. pm_financial_clearance_completed
- Publisher: PM-48
- Subscribers: PM-11, Admission workflow
- Payload Schema:
- Purpose: Signal financial clearance complete for admission gate
- Status: 📝 Planned
Events Consumed
- None (PM-48 reads data directly from PM-02, PM-23 tables; PM-09 writes back via adjudication pipeline)
API Contracts
No external API contracts. PM-48 uses internal Supabase queries and frontend hooks only.Platform Integration Layer Usage
- PF-10 (Notifications):
@/platform/notifications— send estimate-ready notifications to patients, pending-clearance alerts to staff - PF-11 (Documents):
@/platform/documents— store generated PDF cost estimates - PF-96 (Jurisdiction Profiles):
@/platform/jurisdiction—useJurisdictionProfile()for jurisdiction-scoped financial counseling referral threshold
Boundary Notes
- PM-20 boundary: PM-48 does NOT generate GFEs for uninsured/self-pay; those are owned by PM-20. If a patient has no active insurance, PM-48 routes to PM-20.
- PM-23 boundary: PM-48 reads contracted rates but does not modify them. Rate lookup includes fallback to org fee schedule.
- PM-32 boundary: PM-48 creates the referral trigger; PM-32 owns the counseling workflow and charity care determination.
- PM-11 boundary: PM-48 provides clearance metrics as a data source; PM-11 owns the dashboard UI. PM-48 US-3 may include a focused clearance metrics view, but comprehensive RCM analytics remain in PM-11.
Validation Checklist
- All integration points from spec documented
- Event contracts have payload schemas
- Boundary with adjacent specs documented
- PF dependencies listed with integration type
- Contract validation checklist passed (pending implementation)