Provider Credentialing & Enrollment Operations Platform

Credentialing and enrollment teams still run the provider lifecycle across disconnected systems: NPPES, CAQH, PECOS, licensing boards, sanctions databases, payer records, and internal directories. A single clinician or physician professional corporation can exist in all of them, and those records do not always agree. Operators are left reconciling mismatches by hand, then guessing what to do next.

Somewhere between a signed contract and a patient booking an appointment, credentialing, enrollment, sanctions screening, and directory accuracy have to work. Failures here keep providers out of network, misrepresent them in directories, create audit exposure, and delay patient access. This is the operational infrastructure patients never see and depend on.

Typical flow: contracting connects the provider, a credentialing package is assembled, ownership and required materials are reviewed, the provider is presented to committee, approved or passed onward, and entity/NPI structure is validated — then enrollment, activation, and ongoing monitoring happen in other tools. Evidence lives in inboxes, spreadsheets, and source portals. Readiness is tribal knowledge.

• A standalone operations platform — not a Salesforce-only prototype — so the domain model, rules, and source adapters are not trapped in a single CRM.
• First-class objects for individual clinicians, physician PCs, groups, MSOs, Type 1 and Type 2 NPIs, affiliations, and ownership/control.
• Source adapters that normalize verification results before any rule or AI layer sees them.
• Deterministic enrollment readiness with ordered next actions, recurring monitoring, and an audit trail.
• AI summaries only after verification and rules have already produced a conclusion.

AI should explain verified operational facts, not replace deterministic compliance logic. The platform follows a strict pipeline so language models never become the decision layer.

Sources are labeled by access type. Restricted commercial or federal feeds are never presented as live credentials.

Readiness is a deterministic state, not a model score. States: CLEAR, PENDING, ACTION_REQUIRED, BLOCKED. Rules fire on verified facts (inactive NPI, unmatched exclusion evidence, missing affiliation, failed source check) and create EnrollmentIssues with an ordered next action. A potential name match is never treated as a confirmed exclusion — identity and source evidence matter.

Inactive NPI → NPI_ACTIVE_REQUIRED fires → EnrollmentIssue created → BLOCKED → next action: resolve NPI status before enrollment.

Public government sources are designed as live integrations. Restricted commercial and federal sources (CAQH, NPDB, CMS Preclusion, some Medicaid/board APIs) are labeled mock or adapter — they are not represented as production credentials. FHIR demonstrations use sandbox environments. This case study describes architecture and product thinking; it is not a claim of a production deployment.

• Modular monolith with a REST / OpenAPI surface.
• Domain model: Provider, HealthcareEntity, ProviderAffiliation, OwnershipControl, License, CredentialingCase, CredentialingCommitteeDecision, Enrollment, VerificationResult, EnrollmentIssue, ReadinessResult, IntegrationRun, AuditEvent.
• Python / FastAPI / Pydantic / SQLAlchemy / Alembic / PostgreSQL on the backend; Next.js / React / TypeScript on the operator UI.
• pytest for rules and adapter contracts so compliance logic stays testable.

Editorial workflow layouts — not screenshots of a claimed production product.

1. View 01

   Operator view: a provider case with source evidence, current readiness state, open issues, and the next required action — not a chatbot transcript.

2. View 02

   Source map: each verification result tagged LIVE, SANDBOX, or MOCK so an auditor can see what was actually checked.

3. View 03

   Committee packet: normalized facts plus an AI narrative that restates the evidence after the rules have already run.

• The hard problem is not generating text. It is modeling clinicians vs. organizations, Type 1 vs. Type 2 NPIs, affiliations, and ownership so rules have something true to evaluate.
• Operators need ordered next actions more than dashboards. Readiness without a next step just recreates the backlog in software.
• Honest labeling of live vs. mocked sources is part of the product, not a footnote — especially in healthcare compliance.

• Finish public-source adapters (NPPES, OIG, CMS public enrollment, NUCC) with audit events on every run.
• Operator UX for exception queues and committee packets.
• Keep restricted adapters synthetic until real access exists.