Auditing every payer enrollment for a 4,000-provider telehealth network

Customer snapshot

The challenge

An enrollment tracker only knows what someone typed into it

The company in our case study enrolls more than 4,000 clinicians with payers across the states where they practice, and adds roughly 2,000 new enrollments a month. Each enrollment lives as a row in a tracker: provider, payer, location, and a status such as Submitted, Enrolled, or Denied. The status reflects the last thing a payer told someone, on the day they were told it.

Payers do not send updates when the picture changes. An application marked Submitted may have been approved weeks ago without a letter arriving. A provider marked Enrolled may have been dropped at recredentialing, or may have been enrolled under a different tax ID than the one the company bills under. Across thousands of rows and dozens of payers, the tracker slowly stops describing reality, and nothing inside it can tell you where.

Telehealth makes the reconciliation harder

A brick-and-mortar practice has an address that payers list consistently. A virtual practice does not. The company’s clinicians appear in payer systems under corporate addresses, state-level placeholders, and mail drops, and payers handle virtual-only providers inconsistently in their directories. Some payers list the company’s clinician type reliably; others list it sporadically or under unexpected specialty codes. Checking a single provider by hand means logging into a portal, searching several ways, and still not being sure a blank result means “not enrolled” rather than “not published.”

Manually auditing 6,400 records is simply not something modern credentialing teams can take on. Because of this, the company operated on the tracker, and the revenue cycle team found out about the gaps the way revenue cycle teams usually do: one denied claim at a time.

The question that mattered

The company needed one answer at scale: for every tracked enrollment, does the payer agree with us? The discrepancies run in two directions, and both cost money. A provider marked Submitted who is already enrolled is billable today and sitting idle. A provider marked Enrolled who is not in the payer’s network will deny on every visit until someone notices.

The approach

CredFlow ran the audit with its enrollment data lake, the same comparison layer that sits inside the CredFlow platform, applied here to a customer running a different system of record. The company exported its tracker; CredFlow did the rest.

One input

The company provided a single CSV export of its enrollment tracker, one row per provider, payer, and location, carrying the provider’s NPI, the group tax ID and NPI, the enrollment location, the payer name, and the tracker status. About 6,400 rows.

What the data lake did with it

1. Normalize. Providers were resolved by NPI, payer names were mapped to CredFlow’s payer model, and locations were standardized so that a corporate suite address and a payer’s abbreviated version of it could be recognized as the same place.
2. Pull payer-side data. For each payer in scope, CredFlow pulled network and provider data from its data lake across proprietary and public sources, supplemented by claims-derived signals, and matched it to each enrollment row on provider, payer, and location or tax ID linkage.
3. Compare. The tracker’s status for each row was compared against what the payer-side data showed: is the provider in network with this payer, at this location or under this tax ID, and does that agree with the status the company has on file.
4. Classify. Every row was assigned a finding type and a recommendation: no action, update the status, or confirm with the payer and correct the record.
5. Deliver. The company received a findings workbook with every row classified and the payer-side evidence beside it, plus a written report covering methodology, data caveats, and next steps. Eight days after the file arrived.

The results

22% of tracked enrollment data needed resolution

Of roughly 6,400 enrollment records, 22% carried a discrepancy that required someone to act: more than 1,400 rows where the tracker and the payer disagreed in a way that affects billing. The remainder either matched (the tracker was right) or needed only a status update to reflect what the payer already showed.

The discrepancies were not random noise. They fell into a small number of recognizable patterns, each with a specific fix.

More than $1 million in annual claims payments tied to flagged records

The flagged records carry more than $1 million in annual claims payments. That exposure runs in both directions described above. Providers marked Submitted who are already enrolled represent revenue the company was entitled to and had not started collecting. Providers marked Enrolled with no payer record, and providers in network under the wrong tax ID, represent claims that were going out the door with a high likelihood of denial.

Before the audit, the only way to find either kind of record was to wait for it to show up as a denial or a puzzled provider asking why they had no visits with a given payer. After the audit, the company had a list.

What the data lake found

A work queue instead of a spreadsheet

The findings workbook doubled as the work queue. Each row already carried the recommendation and the payer-side evidence, so the enrollment team could sort by finding type and revenue exposure and start at the top. Records that needed only a status update were handled in bulk. Records that needed payer confirmation were routed for follow-up with the evidence attached, so the specialist making the call knew what the payer’s own data said before dialing. Link-to-TIN cases went into a separate queue because the paperwork is different and faster.

Before and after the audit

From a one-time audit to continuous status checks

An audit answers “where are we wrong today.” With 2,000 new enrollments a month, the answer starts aging the day it is delivered. After reviewing the findings, the company scoped the same capability as an ongoing service: automated status checks against payer-side data every two weeks for every enrollment submitted more than 45 days earlier, so that approvals, terminations, and tax ID mismatches surface within a cycle instead of at claim adjudication.

That cadence turns the data lake from a snapshot into a control. Each cycle produces the same classified output as the audit, limited to what changed, and the enrollment team works a short list every two weeks rather than a long one once a year.

Why this matters for other enrollment operations

Every organization that enrolls providers has a tracker, and every tracker drifts. What was unusual here was the scale and the difficulty: thousands of virtual clinicians, state-by-state enrollments, a provider type payers publish inconsistently, and a system of record CredFlow does not own. The audit still ran on one file, and still produced a row-level reconciliation in eight days.

The same audit applies to a medical group checking its enrollment records ahead of a payer contract renewal, an RCM company validating a new client’s roster before taking over billing, or a health system reconciling enrollments after an acquisition. The input is the same: whatever you have on file, one row per provider, payer, and location. The output is a list of where the payers disagree with you, and what to do about each one.