By DAN GOTTLIEB, MPA, JOSHUA MANDEL, MD, and KENNETH D. MANDL, MD, MPH
November 29, 2022
We applaud CMS’s vision for expanding availability and improving accuracy of healthcare directory information while reducing the provider burden associated with keeping directory listings up to date.
There is an opportunity to build on the existing, widely used, National Provider Plan and Enumeration System (NPPES) directory infrastructure to incrementally address these challenges. Crucially, improvements in incentives, user experience, and federation are needed to unlock the full potential of NPPES.
Overview. We propose that rather than developing a new centralized directory, enhanced NPPES listings could serve as a “primary key” for healthcare directory information, maintaining the unique id used to tie together data from multiple organizations and storing links to flat files in FHIR format with additional, frequently-updated, information maintained by payor and provider organizations (e.g., details about services, hours, plan participation, and facilities). The term “API” sometimes refers to fine-grained interfaces (e.g., supporting queries like “at which locations does Dr. Smith practice,” or “What time is Dr. Smith’s clinic open next Tuesday”), but we believe a simpler API might be a better starting point — beginning with the ability to host a set of “flat files” at a well-known URL. Hosting flat files that are updated on a frequent basis would satisfy many consumption use cases. Leveraging SMART/HL7 FHIR Bulk Data standards would take advantage of tools and infrastructure designed for working with FHIR data. Third-party aggregators could use the data in NPPES and the referenced flat files to create applications targeted at specific use cases (e.g., a user-friendly, patient-facing application for people to find new healthcare providers).
Incentives. The RFI notes that provider data in the NPPES directory is frequently inaccurate. Without strong incentives for providers to keep the data up to date, technology changes are unlikely to improve data quality. One approach to addressing this challenge would be attestation requirements, such as mandating that providers participating in CMS payment programs periodically attest to the accuracy of their information in the NPPES directory. Additionally, the more the NPPES data are actively used in CMS operations, the more likely providers are to keep it up to date, suggesting another avenue for incentives. For example, the contact information in the directory could be used for all communications around provider payment, necessitating up-to-date information and ongoing engagement with the system.
Improving User Experience. Anecdotally, we’ve heard from users that updating their information on the NPPES website can be cumbersome, particularly when managing listings for multiple providers. It seems common for organizations to be listed multiple times in NPPES, perhaps because creating a new entry is easier than gaining administrative control over a previous entry. CMS should launch a user centered design effort to understand how the site is being used and redesign it to better accommodate common use cases. For example, a simplified interface may be useful for solo practitioners, functionality to create or update listing by uploading a spreadsheet may be beneficial for users at mid-sized organizations, and the ability to integrate through an API may be preferred by users at large institutions.
Federation (hub and spoke). While a single repository for all healthcare directory data is an attractive notion, it would be costly to build and maintain, and would also risk a single point of failure for a system that has high uptime requirements. Furthermore, a single directory with multiple constituencies, varied data granularity, and a range of update frequencies for different data elements introduces substantial complexity in the data model. In a hub-and-spoke federated model, core metadata would be centrally hosted by NPPES while auxiliary information such as a provider’s hours at an institution and whether they are accepting new patients would be maintained in a file directly on the relevant organization’s website, and easily updated when the data changes. To aggregate this data, consuming systems would follow URLs to the files from the NPPES directory. Similarly, payer organizations could publish files listing plan information and participating providers, and the locations of the payer files could be published in a new section of the NPPES directory. By using providers’ NPPES ids to join the data in these files with those on provider sites, third parties can build up comprehensive databases to power specific apps without the need for novel, centrally maintained infrastructure. A similar approach has been successfully adopted with the SMART Scheduling Links project; working with the US Digital Service, participants enabled distributed discovery of COVID-19 immunization appointments across major pharmacies and healthcare providers (https://github.com/smart-on-fhir/smart-scheduling-links).