Back in September, we introduced four key fields critical to Directory data quality. Perhaps at the top of the key fields list is the provider’s National Provider Identifier (NPI). NPI is important because it’s the core identifier for matching, discoverability, and association of providers who may be practicing across organizations. The NPI is also how many systems and workflows find the intended provider recipient, making NPI one of the most effective search parameters in the new FHIR-based query tools coming to the DirectTrust Aggregated Directory. The NPI field in the Directory is labeled as PROV_NPI.
Current Status of Provider NPI in our Directory
If we agree that PROV_NPI is a key Directory field, then the amount of published NPIs in our Directory is too low. Our most recent report shows that 78.5% of all Directory entries contain a Type 1 NPI in PROV_NPI. Type 1 NPI is individual provider information, whereas Type 2 NPI is organization information. This doesn’t mean we are missing 21.5% of NPIs since not every Directory entry is meant for an individual. The exact number is nearly impossible to track down with our current Directory size and structure, but manual review of the data clearly shows that many provider entries are missing an NPI.
Why Are Some NPIs Missing in Our Directory?
There is no single answer why an NPI might not be published, but when we review the data with HISPs, we hear some common themes. To first try to answer this question, we need to understand the general data flow of how a Directory entry gets populated.
There are multiple levels within the Directory “data chain”:
- Healthcare organization and/or the provider themselves
- EHR/vendor
- HISP
The HISP is ultimately responsible for submitting entries to the greater Aggregated Directory but much of the underlying data is often captured “upstream”. Missing NPIs could be the result of the data capture process (or lack thereof) from the EHR, healthcare organization, or provider. In general, our conversations with HISPs indicate that this problem is on the mend which will help with NPI contributions going forward. However, this improvement will not always solve the issue for older Directory entries that originally made it to Directory publishing without the NPI. Resolving these issues will require community buy in from the entire Directory data chain. We encourage our community that cares about their Directory presence to review the data that applies to them and provide missing information when appropriate.
When Should an NPI be Included in a Directory Entry
Not every single record in the Directory needs to have a Type 1 NPI. Why? Because not every individual in the Directory is a provider with an NPI. Furthermore, not every Directory entry is for an individual. For instance, workflow, departmental, or organization-level Directory entries are not associated with an individual and therefore shouldn’t contain a Type 1 NPI.
The bottom line? Any provider with an NPI should have their NPI published in the Directory (PROV_NPI is a “required if known” field). Our Directory Best Practices state any provider who would benefit from receiving clinical information should be published in the Directory with both their Type 1 and their organization’s Type 2 NPI.
Benefits of Searching on PROV_NPI
How would you find a provider in any type of directory? You might start with searching by their name but this doesn’t always work well. Providers might get married and change their last name, or their first name might be different across systems and directories. Maybe you know the organization where they practice as an additional search parameter, but that has shortcomings too; complex organizational hierarchies, legal entity names vs. common names, etc. can make searching ineffective.
As an example, reporting capabilities of our Directory illustrate massive variance in organization names between our Directory, NPPES, and Google Maps. Even with fuzzy matching, our detailed reporting shows over 100,000 examples of the organization name not matching the expected organization name in NPPES or Google Places API.
The provider NPI solves this problem. The NPI is a unique identifier commonly captured across the vast healthcare ecosystem. The benefits of searching on PROV_NPI increase as we move to FHIR-based APIs. A query on NPI will return all Directory entries that contain that NPI. By extension, any provider entry missing the NPI will not be discoverable with this search. A standardized and unique identifier for providers is ideal for finding the intended provider.
System to System Bridge using NPI
Another value proposition of the NPI is its ability to act as a link to other systems and databases. The NPI is a standardized identifier that doesn’t change, and is already widely referenced throughout healthcare infrastructure. For these reasons, the simplest way to cross reference a record in our Directory to other external sources is with the NPI. No other data point in our Directory can bridge to other systems as effectively.
Specifically, our data validation engine runs every NPI, both Type 1 and Type 2, through NPPES (the source of truth for NPI). The response from NPPES returns the provider’s name, specialty, and organization demographics. If there is a mismatch in any area, we report the details to the HISP. We understand that NPPES is not always perfectly up to date either, but the check against NPPES adds value as it points to potential data quality issues. Without the NPI we couldn’t effectively check a Directory record’s information against external sources.
Summary
The provider NPI is perhaps the most important data point in a provider’s Directory record. We need help from the community to achieve our goal of all applicable Directory entries being published with the correct NPI. As our Directory Improvement Initiative outlines, improvement of publication in the PROV_NPI field increases searchability and Directory data quality, ultimately leading to timelier identification and communication with the correct provider.
Learn more about the Directory Improvement Initiative and see prior blog posts here.
This post was contributed by Alex Young, DirectTrust Network Services Technical Project Manager.