Healthcare’s provider directory problem is an inherent trust issue
As the industry moves toward FHIR-based exchange, including Provider Directory APIs, the trust gap beneath directory data is more difficult to ignore.
As health plans, providers and technology vendors continue modernizing healthcare data exchange, one persistent issue keeps rising to the surface – provider directories are still not reliable enough for the level of digital interaction that the industry now requires.
We can clean records, publish APIs, improve outreach workflows and increase the frequency of directory updates. But without a reliable way to verify who is making a directory assertion, whether that organization has authority to make it and whether the information can be trusted at the moment it is used, provider directory accuracy will continue to depend on manual processes that do not scale.
The reality is simple. Provider directories do not just have a data quality problem. They have a trust problem.
This matters because provider directories are no longer just static reference tools. They now sit at the center of network adequacy, member access, credentialing, delegated credentialing oversight, prior authorization workflows and API-based interoperability. As CMS continues pushing the industry toward FHIR-based exchange, including Provider Directory APIs under CMS-0057, the trust gap beneath directory data becomes more difficult to ignore.
A modern API can move directory information faster. It does not, by itself, make that information authoritative.
Directory accuracy is really about trust
The most visible symptom of the provider directory problem is bad data.
A provider is listed at the wrong location. A phone number is outdated. A clinician appears as in a network but is not accepting new patients. A physician has left a group, but the payer directory has not caught up. A facility is shown as participating in a network where the relationship has changed.
These problems are often grouped under the term “ghost networks.” But ghost networks are not only the result of outdated records. They are the result of a system that lacks a consistent, verifiable way to establish current provider status.
Today, the workflow usually depends on periodic outreach, attestation, file exchange, manual verification and database reconciliation. These processes can work in limited settings, but they struggle at national payer scale. A large payer may manage hundreds of thousands of providers across multiple lines of business, products, delegated arrangements and state-specific requirements.
In that environment, directory accuracy is not simply a matter of asking for updated data more often. The system needs a way to know that the data came from the right source, that the source had authority to make the assertion, and that the assertion can be independently verified.
That is a trust architecture problem.
NPI identifies, but it does not prove
The National Provider Identifier is essential infrastructure. It gives healthcare a standard way to identify providers and organizations across administrative transactions. But identification is not the same as proof.
An NPI can identify a provider or organization. It does not prove, in real time, that the entity presenting that identifier is the entity to which it was assigned. It does not prove current affiliation with a medical group. It does not prove network participation. It does not prove that a state license, board certification, DEA registration or delegated credentialing attestation is current and authoritative.
That distinction becomes more important as healthcare workflows become more automated.
In a manual environment, a credentialing analyst can resolve uncertainty by checking a board website, calling an issuing authority, reviewing a document or comparing records across systems. In an API-driven environment, the transaction needs a way to carry trust with it.
The NPI is a useful identifier. But provider directory infrastructure needs verifiable identity.
CAQH helps, but it still leaves gaps
CAQH ProView has been an important step forward for credentialing and provider data management. It reduces duplicate form completion, creates a common repository and gives participating payers a more consistent way to access provider-supplied information.
But CAQH is still built around a trusted intermediary model. In that model, payers trust the platform because CAQH collected and manages the data. Providers attest to information. Verification processes occur through established workflows. Payers access the data through the CAQH environment.
This model improves consolidation, but it does not fully solve the underlying trust issue. The credential does not travel with independently verifiable proof. The data remains inside a proprietary platform. Verification depends on access to that platform. Updates and revocations depend on database synchronization and notification workflows. A payer, regulator or other relying party still needs the intermediary to confirm what is true.
This doesn’t imply that CAQH is not valuable. It means that the next layer of provider directory infrastructure needs to do something different.
CAQH helps organize provider data. Healthcare still needs a way to verify provider identity, organizational authority, credential status and network participation across systems without requiring every relying party to recreate the same manual verification process.
Data is not the same as proof
Healthcare does not lack provider data. It lacks portable, verifiable proof. Those are different things.
A payer may have data showing that a provider is affiliated with a group. A directory may show that the provider participates in a network. A credentialing file may include evidence that a license was checked. A delegated credentialing report may indicate that a health system completed its required review.
But deeper questions remain. Who issued the credential or assertion? Was that issuer authoritative? Has the information been altered? Is it still valid? Was the organization making the assertion legally identifiable? Was the person or system acting on behalf of that organization authorized to do so? Can another relying party verify the same evidence without repeating the same manual process?
These are not database questions. They are trust questions.
The current approach answers many of them through manual workflows – spreadsheets, portals, PDFs, phone calls, proprietary APIs, static directories, attestation forms and periodic revalidation. These methods may be familiar, but they do not scale well when thousands of entities need to interact through standardized APIs and shared networks.
Interoperability cannot scale without identity for both individuals and organizations. Provider directory accuracy cannot scale without proof.
APIs do not establish trust
FHIR APIs are a major step forward for healthcare interoperability. CMS-0057 and related interoperability rules are pushing the industry toward more standardized, real-time exchange across payers, providers, and patients.
But an API is not a trust framework. An API can expose provider directory data. It can make that data easier to retrieve. It can standardize how the data is structured and exchanged. But it does not automatically prove that the underlying assertion is current, authoritative or connected to the right legal entity.
This is the risk in the next phase of interoperability. Healthcare may modernize how directory data is exchanged while leaving the underlying trust model largely unchanged. If the source data is uncertain, the API simply moves uncertainty faster.
That is why provider directory modernization needs to be understood as more than an API compliance exercise. It requires a way to bind directory assertions to verifiable organizational identity with traceable delegated authority to act, authoritative credential issuers and auditable evidence.
What this means for provider directories
A trust-based provider directory model would change several things the current system struggles with.
Directory accuracy would depend on verifiable assertions, not just better records. The question would not only be whether a payer has the latest data, but whether the assertion behind that data can be verified.
Network participation could become more dynamic. Providers, groups and networks could make signed, time-stamped assertions about participation status, rather than relying only on payer-pull outreach cycles.
Credentialing could rely more on portable proof. State boards, credentialing bodies, federal agencies and delegated credentialing organizations could issue credentials that can be independently verified by multiple relying parties.
Delegated credentialing could become more auditable. A health system or delegated entity could sign attestations in a way that establishes a clearer chain of accountability.
API-based exchange could include identity and authority. The transaction would not only carry data. It would carry stronger evidence of who is making the assertion and why they are authorized to make it.
These capabilities would not replace existing systems overnight. But they would reduce friction, improve auditability and create a stronger foundation for directory accuracy at scale.
The next step is verifiable trust
Healthcare has spent years modernizing how data moves. FHIR gives us a common data language. CMS rules are accelerating standardized exchange. UDAP and related security frameworks, such as FAST Security, are strengthening API access and registration.
But provider directory accuracy depends on something deeper than transport, format or compliance. It depends on trust.
The next phase of provider directory modernization should focus on creating a verifiable trust layer for organizational identity, credential status, delegated authority and network participation. That is the shift from static data to dynamic, evidence-based trust.
In the next article, we will explore the architectural model that makes this possible – moving from “trust the platform” to “verify the claim” through cryptographic provider identity and the verifiable legal entity identifiers for organizations.
Mark Scrimshire is chief interoperability officer at Onyx Health, where he leads its standards and interoperability strategy. He was the architect of CMS Blue Button 2.0 and author of the HL7 Da Vinci PDex standard on which CMS-0057 is built.