Ghost networks are a latency problem

When a payer directory lists the wrong address or a provider who no longer practices there, the natural question is: who failed to update it?

That question assumes the inaccuracy began as bad data. What if it began as current data that took too long to arrive?

Across more than 15,000 unique provider NPIs on Rota, our customers’ rosters generally look current and internally consistent. The provider organizations know who works for them and where those providers practice. They update their own systems because hiring, scheduling, billing, and patient access all depend on getting that information right.

The data starts to break down in transit. Moving one provider change from the source roster into every payer directory can take months. During those months, the source roster keeps changing.

That makes ghost networks, at least in part, a latency problem.

Accuracy has a timestamp

In software, latency is the delay between an action and its visible result. Provider roster operations have the same problem, except the delay is spread across spreadsheets, portals, inboxes, processing queues, and several teams.

Take a provider who adds a new practice location on July 1. The provider organization’s system may reflect the change that day. A roster analyst then has to translate it into each payer’s format. After submission, the payer has to validate and load the update. Its public directory may update on yet another schedule.

Several versions of the same provider now exist at once. There is the current source roster, the file being prepared, the file the payer received, the payer’s internal record, and the member-facing directory. Each version can accurately represent a different day.

This is why accuracy cannot be separated from time. A roster file that was correct 90 days ago is still a correct record of what the provider organization knew then. It may be a poor description of where the provider practices now.

The first delay happens before submission

Every payer has its own spreadsheet, required fields, validation rules, and submission process. The provider data underneath may be the same, but the team has to express it differently for each payer.

One payer wants every practice location as its own row. Another caps how many service locations a provider can list. A third only accepts changes keyed into its portal. Field names, taxonomy rules, address requirements, and delivery channels all vary. The work depends on a mix of templates and knowledge that lives in specific people’s heads.

Provider teams doing this manually tell us it can take two to five weeks to prepare and submit an update. That is not payer processing time. It is the time required to turn the provider organization’s current roster into the files its payers will accept.

For a health system with a relatively stable network, that delay is painful. For a telehealth organization with clinicians joining, leaving, and changing state coverage every week, it can be longer than the useful life of the file. The roster may change again before the submission is finished.

Submission starts a second delay

Once a payer receives the file, a second clock starts. In our customers’ experience, it can take another 30 to 120 days for the change to appear in the payer’s directory.

The provider team often has little visibility during that period. It knows what it sent, but may not know whether the payer accepted the file, rejected a record, or placed the submission in a queue. An upload receipt, when one exists, usually proves delivery rather than processing.

Run the math with the low end of both ranges. A roster changes on day zero. The provider team spends 14 days preparing and submitting the payer’s file. The payer reflects it 30 days later. On day 44, the directory finally shows what the source roster said six weeks earlier. Any change made during those six weeks has to wait for another cycle. At the high end of both ranges, the gap is measured in months.

The payer can process the file exactly as received and still publish stale information. The provider organization can maintain a current roster and submit every required update, yet still find old information in the directory. Neither fact excuses an inaccurate directory. They explain how one can exist without either side fabricating the network.

Volume makes the receiving side harder

The payer does not receive one clean, authoritative roster. It receives updates from telehealth companies, health systems, medical groups, and individual practices. Many of those rosters overlap.

Across the customer rosters on Rota, 741 NPIs appear in more than one organization’s roster. That is not a duplicate-data problem. A provider can validly practice for several organizations, at different locations, under different contracts. The payer has to preserve that context while processing updates from each source. The provider team, meanwhile, needs to know which organization-provider-location relationships were accepted and ultimately reflected. A submission receipt alone cannot answer that.

Now apply that overlap to thousands of provider organizations, each submitting through a different operational workflow. That mix of volume and variation pushes work into queues and human review, adding more time between a provider-side change and the directory a patient sees.

This does not make the resulting errors harmless. A 2026 review from the HHS Office of Inspector General found that about one-quarter of maternal-health providers on Medicaid managed care plan network lists said they were not in-network. More than one-quarter had no accurate phone number supplied by the plans, and almost half were absent from the online directories members used. The plan network lists and public directories did not agree with each other. CMS concurred with OIG’s recommendations.

The OIG review does not tell us why each record diverged. It does show what happens when several representations of a changing network no longer agree.

Enforcement is arriving ahead of the fix. In July 2026, Molina Healthcare took a $5.25 million judgment and a four-year injunction over ghost networks in California. Health Net settled a parallel case for $40 million last fall, and a third case, against Kaiser, is still pending. The remedies are all directory-side: minimum accuracy percentages, 60-day correction timelines, verification hotlines, visible timestamps. Each of those audits the output. None of them speeds up the pipe that feeds it.

Shorten what we can and make the rest visible

Provider organizations should not have to solve this by hiring more people to prepare more spreadsheets. They already maintain the roster. Software should start with that roster instead of asking the team to rebuild it.

Rota takes the roster a provider organization already maintains, turns it into the format each payer requires, and validates it before submission. This reduces the first delay and catches errors before they enter a payer queue.

After submission, Rota monitors the directory against what the provider organization sent. The team can see which changes appeared, which records still disagree, and where it has evidence to follow up. That does not shorten the payer’s internal queue, but it replaces a blind wait with a provider-level worklist.

The payer’s queue is still the payer’s, for now. What Rota can do is remove time from the preparation side and show the provider team what happened on the other side.

The longer-term answer is a verified, machine-readable connection between the provider organization’s current roster and the payer’s system of record. A provider change should not have to be rebuilt as a new spreadsheet for every payer. It should move as data, with validation and a visible status attached to the record.

Directory accuracy is usually treated as periodic cleanup. Provider rosters do not change periodically. They change whenever a provider joins, leaves, moves, or updates how they practice.

A payer directory can only stay current if updates move faster than the roster changes. Today, too often, they do not.