The last few articles I have written have been about the problem MA plans are facing: what the NPD is, what it is not, what Phase 2 does to the stakes, and what the September 1 attestation requires.
This one is about what payers can do.
The short version is that today, the NPD is a distribution layer, and what every payer now needs is a remediation layer that sits underneath it. Call it a data trust fabric. Call it a provider data infrastructure layer. The label matters less than the function, which is to reconcile fragmented upstream sources into a clean, validated, continuously-updated record that can be published to any downstream destination, including the NPD.
I want to walk through what that layer does, in plain operational terms.
Ingestion
Every payer receives provider data in multiple formats from multiple sources. Credentialing systems. CAQH. Delegated roster files from IPAs and medical groups. NPPES and PECOS. State licensing boards. Provider portals. Claims feeds. Each source has a different cadence, format, and accuracy state. The first job of a remediation layer is to ingest all of them, which means handling CSV, Excel, JSON, PDF, Word, email, and EHR exports without manual rework.
Validation
Once ingested, the data needs to be validated against authoritative sources. NPI against NPPES. Licenses against state boards. Sanctions against the LEIE. Network participation against contracts. Validation is not a one-time pass; it is a continuous check that runs every time data changes.
Timeliness
Validation alone is not enough. Even when the data validates cleanly, freshness is often in question. Every authoritative source I cited above is itself fed from other sources, both digital and human. Without clarity on when each upstream record was last updated, it is hard to know whether the data you are validating against is current.
One example lives inside the NPD itself. An independent audit of the April 9 bulk release found that every record carries a meta.lastUpdated value, but the value reflects the day the NPD assembled and exported the file, not the day the underlying source updated the record. As the analyst put it: “100% lastUpdated, 0% freshness.” The published recommendation was direct: “Do not use NDH meta.lastUpdated as a freshness heuristic to decide which records to refresh from upstream.”
That is a distinction payer data teams need to internalize. A timestamp on the file is not a timestamp on the record. The remediation layer needs its own provenance tracking on every field, sourced from the system that actually owns the data.
Identity resolution
This is where most payers break down. The same provider can appear in your credentialing system as “Robert J Smith, MD,” in your claims system as “Bob Smith,” and in your delegated roster as “Smith, Robert, M.D.” Identity resolution is the work of deciding, at scale, which records refer to the same person, the same practice, and the same location, and then maintaining that mapping as records change.
Enrichment
The fields the NPD lacks (accepting-new-patients, languages, practice-to-location relationships, specialty hierarchy) are the same fields a payer needs for directory accuracy and network adequacy. Enrichment is the work of adding those fields from the sources that have them and keeping them current over time.
Compliance logging
Every change to every provider record should be logged with a timestamp, source, and evidence of verification. That is what makes an attestation defensible. That is what a state AG investigation wants to see. That is what a plaintiff’s firm evaluates when deciding whether to file a case.
An evidence log is not a nice-to-have. It is the central artifact of a defensible compliance posture.
Publishing
Once the data is clean, it needs to be published to every downstream destination the plan operates: the member-facing directory, the CMS FHIR API for Medicare Plan Finder, the NPD feed, partner systems, network adequacy submissions. Each destination has its own format requirements, and managing them manually at 30-day update cadence is not feasible.
Why this layer is complementary to the NPD, not competitive with it
The NPD is a destination. The remediation layer is a foundation. A healthy ecosystem has both.
If the NPD is the public marketplace where directory accuracy becomes visible, the remediation layer is the quality system that makes sure what you bring to market is actually what you say it is. No federal reference dataset can do that plan-specific work, and no specific plan can meet 2027 accuracy standards without that work being done somewhere, either inside the plan or through infrastructure built to do it.
What we built
Polus™ HCP is Datagence’s answer to this problem. We built it specifically to serve as the infrastructure underpinning every payer-side directory operation, with ingestion, validation, identity resolution, enrichment, compliance logging, FHIR-standard publishing, and a confidence score on every record, all integrated into a single platform. It is designed to feed the NPD, Medicare Plan Finder, and every other downstream destination from a single source of validated truth. It deploys in about 60 days, which matters when the first attestation is less than four months away.
I am biased about the product, and you should hold that bias against me. But the architectural argument stands on its own: this is the layer the industry needs, and the industry is about to find out how much it needs it.