Version: 1.0.0Documentation Index
Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
Use this file to discover all available pages before exploring further.
Status: 📝 Planned
Last Updated: 2026-02-23
Spec: PM-17 Provider Credentialing & Enrollment Verification
Constitution Reference: Section 1.3 (Integration Patterns), Section 2.1 (Integration points documented in
/docs/architecture/integrations/)
Overview
PM-17 provides provider payer-enrollment tracking, NPI/taxonomy validation, re-credentialing deadlines and alerts, and claim-scrub integration for enrollment verification. It consumes HR provider/credential context via the Platform Integration Layer (no direct PM→HR imports). Integration points: PM-08 (claim scrub), PM-15 (clearinghouse readiness), HR (provider identity/credential context), PF-10 (alerts).Quick Reference
| I need to… | Pattern | Location |
|---|---|---|
| Validate NPI/taxonomy state | pm.credentialing.validate permission-gated workflow | Permission Keys |
| Gate claims by enrollment status | PM-08 consumes PM-17 enrollment state | Integration Points |
| Verify submission readiness | PM-15 checks enrollment/validation outputs | API / Event Contracts |
Decision Tree
- Is provider enrollment status eligible for payer submission?
enrolled→ proceed.pending/denied/inactive→ enforce PM-08/PM-15 hold or override policy.
- Is NPI/credential validation current?
- Yes → continue.
- No → run validation flow and re-check before submission.
- Is re-credentialing deadline approaching?
- Yes → trigger PF-10 alerts and assign follow-up.
Pattern Library
- Platform integration layer pattern: consume HR provider context via contracts only.
- Enrollment-state gating pattern: use PM-17 status as hard/soft stop in PM-08/PM-15 workflows.
- Deadline-alert pattern: route expiring enrollment events/notifications through PF-10.
Common Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Missing org scope in enrollment queries | Cross-tenant leakage risk | Enforce organization_id in queries and RLS |
| Using view/manage permissions interchangeably | Unauthorized modifications | Separate action permissions by role and operation |
| Skipping NPI active-date validation | Claim rejection risk | Require validation checks before submission workflows |
Pre-Flight Checklist
-
organization_idscoping and RLS policies validated on PM-17 tables. - Permission keys seeded and mapped for view/manage/validate/override.
- PM-08 and PM-15 consuming contracts verified against PM-17 status model.
- Re-credentialing alert flow validated through PF-10.
Integration Points
| Dependency | Pattern | Purpose |
|---|---|---|
| PM-08 | Data / API | Claim scrub enrollment verification rules; consume enrollment status as hard/soft stop. |
| PM-15 | Data / API | Clearinghouse and payer-submission readiness checks. |
| HR | Platform Integration Layer | Provider identity, license/credential context (contract-based; no direct core import). |
| PF-10 | Platform | Alerts for expiring enrollments and re-credential windows. |
API / Event Contracts
Inbound (consumed by PM-17)
- Provider/credential context: Consumed via Platform Integration Layer contract from HR (provider identity, credential attributes). Request/response schema TBD in HR–PM integration contract.
- PM-08: Reads enrollment status for claim scrub (query or shared types). Contract: enrollment status per provider/payer for given claim context.
Outbound (provided by PM-17)
- Enrollment status: PM-08 and PM-15 consume enrollment state (enrolled/pending/denied/inactive) and validation results for scrub and submission readiness.
- Alerts: PF-10 receives enrollment/re-credential deadline events for alert generation (event or API TBD).
Planned Events (Deferred)
pm_enrollment_expiring — Planned but deferred from v1. V1 uses direct PF-10 notification insert for re-credentialing alerts. Domain event will be added if downstream consumers (PM-08 automation, GR compliance) need to subscribe.
Security & Tenant Isolation
- All PM-17 tables are scoped by
organization_id; RLS and SECURITY DEFINER helpers enforce isolation per constitution §5. - Provider and enrollment data are operationally sensitive; access via permission keys below.
- No PHI sent to external AI; HR integration uses platform contract only.
Permission Keys
| Key | Purpose | Typical role assignments |
|---|---|---|
pm.credentialing.view | View enrollment/credentialing data | org_admin, billing_manager, staff |
pm.credentialing.manage | Create/update enrollment and credentialing records | org_admin, billing_manager |
pm.credentialing.validate | Run validation (e.g. NPI/taxonomy checks) | org_admin, billing_manager |
pm.credentialing.override | Override validation or restrictions | org_admin only |
pm.credentialing.validate and pm.credentialing.manage tie to AHCCCS NPI requirements: NPI must be present on submission forms and active for date of service.