Request for Information; National Directory of Healthcare Providers & Services

AGENCY:

Centers for Medicare & Medicaid Services (CMS), Health and Human Services (HHS).

ACTION:

Request for information.

SUMMARY:

This request for information solicits public comments on establishing a National Directory of Healthcare Providers & Services (NDH) that could serve as a “centralized data hub” for healthcare provider, facility, and entity directory information nationwide.

DATES:

To be assured consideration, comments must be received at one of the addresses provided below, no later than 5 p.m. on December 6, 2022.

ADDRESSES:

In commenting, please refer to file code CMS-0058-NC.

Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one of the ways listed):

1. Electronically. You may submit electronic comments on this regulation to http://www.regulations.gov. Follow the “Submit a comment” instructions.

2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0058-NC, P.O. Box 8013, Baltimore, MD 21244-8013.

Please allow sufficient time for mailed comments to be received before the close of the comment period.

3. By express or overnight mail. You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0058-NC, Mail Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.

For information on viewing public comments, see the beginning of the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT:

Alexandra Mugge, (410) 786-4457.

David Koppel, (303) 844-2883.

SUPPLEMENTARY INFORMATION:

Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. We post all comments received before the close of the comment period on the following website as soon as possible after they have been received: http://www.regulations.gov. Follow the search instructions on that website to view public comments. CMS will not post on Regulations.gov public comments that make threats to individuals or institutions or suggest that the individual will take actions to harm the individual. CMS continues to encourage individuals not to submit duplicative comments. We will post acceptable comments from multiple unique commenters even if the content is identical or nearly identical to other comments.

I. Introduction

Healthcare directories that contain aggregated information about healthcare providers, facilities, and other entities involved in patient care are crucial resources for consumers and the healthcare industry. Contemporary and comprehensive directories can support a variety of use cases, such as helping consumers choose a provider, comparing health plan networks, auditing network adequacy, and coordinating patients' care. Today, consumers use provider directories and online searches more than any other resource (such as word-of-mouth or physician referrals) to research healthcare providers. In a 2020 consumer preference report, a majority of the consumers surveyed indicated that the online availability of accurate directory information (address, insurance, specialty, hours, etc.) has affected their decisions when choosing a doctor.

Although these are important resources, the fragmentation of current provider directories requires inefficient, redundant reporting from providers. Directories often contain inaccurate information, rarely support interoperable data exchange or public health reporting, and are overall costly to the healthcare industry. According to one estimate from a provider survey completed in 2019 by the Council for Affordable Quality Healthcare (CAQH), physician practices collectively spend $2.76 billion annually on directory maintenance, which is equivalent to approximately $998.84 per month per practice, or one staff member workday per week.

The CAQH estimated that transitioning directory data collection to a single streamlined platform could save the average physician practice an estimated $4,746 annually, or an approximated $1.1 billion in collective annual savings across the nation. Directory maintenance costs for physician practices vary based on many factors including practice size, the number of payers with which they are contracted, number of practice locations, and importantly, how often and timely they verify or update their information in directories. Furthermore, providers reported that they must submit directory information in various ways, including by fax, credentialing software, provider management and enrollment software, phone, and physical mail. This disjointed system results in barriers to patient care, administrative burden on providers and their staff, and increased cost for the entire healthcare industry.

One driver of inaccuracy is the varying frequencies and levels of detail at which different directories require information. Some track directory information at the practice level, and others include directory information for each physical location. Without processes or internal audits for data accuracy, different practice staff may provide inconsistent information across directories. Administrative complexity and unclear accountability for data accuracy also contributes to data quality and accuracy challenges. Even when payers have legal obligations to maintain an accurate directory, as discussed in section II. of this document, they generally must rely on providers to update the information within their directories and are left with few options if a provider does not do so in a timely manner. This also puts a burden on provider staff, who must update their directory information for an average of 20 different payers per practice.

We believe that CMS may have an opportunity to alleviate some of these burdens and improve the state of provider directories through a CMS-developed and maintained, Application Programming Interface (API)-enabled, national directory. A National Directory of Healthcare Providers & Services (NDH) could serve as a “centralized data hub” for directory and digital contact information containing the most accurate, up-to-date, and validated (that is, data that is verified by CMS against primary sources) data in a publicly accessible index. An NDH could both streamline existing data across CMS systems and publish information in an easier-to-use format than is available today. More useful public data could help patients find providers, facilitate interoperable provider data exchange, and help payers improve the accuracy of their own directories. We use the term “centralized data hub” to describe the practice of aggregating data from many existing systems into a single location, which is a best practice within any industry, including healthcare. Establishing a “centralized data hub” breaks down technological barriers between various data sets and allows other databases to reference the source of the information without duplicating data. This aggregation and standardization of data could help avoid errors and inaccuracies in directories that reference data in an NDH. CMS could use an NDH as a mechanism to collect and maintain directory information in a standardized, interoperable, and sharable format that allows widespread access while maintaining privacy and security protocols to safeguard access to sensitive information.

To align with national standards for interoperability, an NDH could be built on the standards established by the Office of the National Coordinator for Health Information Technology (ONC) at 45 CFR part 170, subpart B. Specifically, an NDH could use HL7® Fast Healthcare Interoperability Resources (FHIR®) APIs, the latest standard for which is codified at 45 CFR 170.215(a)(1), to enable data exchange. FHIR is a standard for exchanging healthcare information electronically that enables rapid and efficient data transactions through an API. Systems with different data architecture can use FHIR APIs to exchange health data in a consistent manner, which gives providers, payers, and other relevant entities a fast and secure way to send and receive healthcare data. FHIR is a widely adopted standard that we already require for specific types of health data exchange. We expect ONC to periodically update the standards at 45 CFR part 170, subpart B through notice and comment rulemaking, and an NDH could use the most up-to-date standards, as appropriate.

ONC and the Federal Health Architecture (FHA), a former federal agency collaboration created to enhance interoperability among federal health information technology (IT) systems, developed the Validated Healthcare Directory (VHDir) FHIR Implementation Guide (IG), which describes the technical design considerations for collecting, validating, verifying, and exchanging data from a central source of provider data using FHIR standards. That IG is currently a “standard for trial use,” meaning it has been deemed “ready to implement” by the sponsoring work group, but there has not yet been significant implementation experience. Testing and development processes are ongoing toward establishing the IG as a normative standard through the American National Standards Institute (ANSI)-approved process. CMS will continue to monitor and work with the appropriate standards development organizations on this effort.

Previous healthcare directory technical efforts, described in section II. of this document, have identified CMS as the appropriate owner of a validated directory, such as an NDH. We agree that CMS, with collaborative input from industry and federal partners, is positioned to develop an NDH in a manner that serves all stakeholders, builds and maintains trust in the data, advances public health goals, improves data exchange, streamlines administrative processes, and promotes interoperability.

Through this RFI, we seek input on the current state of healthcare provider directories and steps that we could or should take if CMS concludes that adequate legal authority exists to establish an NDH and proceeds to do so.

We believe a modern healthcare provider directory should serve multiple purposes for end users. In addition to helping patients locate providers that meet their individual needs and preferences, a modern healthcare directory should enable healthcare providers, payers, and others involved in patient care to identify one another's digital contact information, also referred to as digital endpoints, for interoperable electronic data exchange. We are collecting feedback from the public regarding the topics and questions in the discussion that follows. We pose questions throughout this document; a response to every question is not required in order to submit comments.

II. Background

Provider directories have long been a focus of federal healthcare improvement efforts. On several occasions, Congress has acted to address the challenges of directory data availability and accuracy. Federal executive branch departments and agencies have also taken considerable steps to implement regulatory requirements aimed at addressing these challenges.

Section 4001 of the Balanced Budget Act of 1997 (BBA) (Pub. L. 105-33) established a new Medicare Part C (now also known as Medicare Advantage) program, and under section 1852(c)(1)(C) of the Social Security Act (the Act) required that Medicare Advantage organizations (MA organizations) annually disclose in a clear, accurate, and standardized form to each MA plan enrollee, the number, mix, and distribution of plan providers, among other information.

This requirement was implemented in regulations at 42 CFR 422.111(b)(3), which requires MA organizations to disclose a description of the number, mix, and distribution (addresses) of providers from whom enrollees may reasonably be expected to obtain services. CMS has issued updated guidance over several years regarding the responsibilities of MA organizations to have accurate provider directories, with guidance appearing in the Medicare Marketing Guidelines and Medicare Communications and Marketing Guidelines and section 110 of Chapter 4 of the Medicare Managed Care Manual.

Similarly, in section 4701 of the BBA, Congress added section 1932(a)(5)(B)(i) of the Act, which requires that the Medicaid managed care organizations that are specified in the statute make available, upon request, the identity, locations, qualifications, and availability of providers that participate with that entity. These same requirements were applied to Children's Health Insurance Program (CHIP) managed care entities via section 403 of the Children's Health Insurance Program Reauthorization Act (CHIPRA) of 2009 (Pub. L. 111-3), at section 2103(f)(3) of the Act.

In 2015, in the “Patient Protection and Affordable Care Act; HHS Notice of Benefit and Payment Parameters for 2016” final rule (80 FR 10829), we established a requirement, at 45 CFR 156.230(b), that Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges publish online an easily-accessible, up-to-date, accurate, and complete provider directory. Those directories must include information on which providers are accepting new patients, the provider's location, contact information, specialty, medical group, and any institutional affiliations. CMS also requires issuers to make this information publicly available on their own websites in a machine-readable file and format to allow third parties to create resources that aggregate information on different plans. CMS conducts annual reviews to assess the accuracy of issuers' machine-readable provider data files, comparing the data files to the issuers' online provider directories and other data sources, such as the National Plan and Provider Enumeration System (NPPES) and the United States Postal Service (USPS) address verification database. Over five plan years beginning in plan year (PY) 2017 through PY2021, CMS found that no more than 47 percent of the provider entries we reviewed from the machine-readable provider data files included a complete set of accurate telephone numbers, addresses, specialties, plan affiliations, and whether the provider is accepting new patients. Furthermore, only 73 percent of the providers reviewed could be fully matched to the published directories on the payer's website. Finally, when we compared provider information from the machine-readable data files to the NPPES National Provider Identifier (NPI) registry, only 28 percent of the provider names, addresses, and specialties matched. In addition to accuracy issues, we note that a machine-readable file is a static data source that must be entirely recreated to provide a snapshot of the dataset at any point in time. Conversely, the APIs that we discuss here could allow data to be accessed in real-time and with the most up-to-date information at the moment the system is queried.

In the Contract Year 2016 Call Letter for Part C (Medicare Advantage) and Part D plans, CMS announced it was initiating a monitoring effort of the accuracy of online provider directories for plans offered by MA organizations. Beginning in February 2016, CMS studied the accuracy of information in MA organizations' online directories. We released findings in July 2018 from three review rounds in which we identified at least one deficiency in 45 percent, 55 percent, and 49 percent of listed locations. Significant types of identified inaccuracies included providers who did not practice at the listed location, providers who did not accept the plan at the listed location, incorrect phone numbers or addresses, and mistaken “accepting new patients” flags. In that report, we identified a centralized database as a possible long-term solution.

On January 3, 2020, as a follow-up to the MA provider directory monitoring study conducted from 2016 to 2018, CMS issued a Health Plan Management System (HPMS) memo encouraging MA organizations to work with their contracted providers and to urge those providers to review and update their NPPES data. CMS announced that it would exercise enforcement discretion with regard to potential violations of § 422.111(b)(3) should CMS uncover errors in an MA organization's provider directory where the errors are consistent with NPPES data that were updated or certified between January 1 and April 30, 2020, provided the MA organization corrected any identified errors within 30 days.

In 2016, Congress enacted the 21st Century Cures Act (Cures Act) (Pub. L. 114-255). Section 4003(c) of the Cures Act requires the Secretary of HHS (the Secretary), directly or through a partnership with a private entity, to establish a provider digital contact information index to provide digital contact information for health professionals and health facilities. To implement that requirement of section 4003(c) of the Cures Act, in June 2018 we updated NPPES, a system authorized by section 1173(b) of the Act and that we administer, to be able to capture digital contact information, also referred to as digital endpoints, for both healthcare professionals and facilities. NPPES currently supplies NPI numbers to healthcare providers (both individuals and facilities), maintains their NPI record, and publishes the records online. NPPES has been updated to include the capability to capture one or more fields of digital contact information that can be used to facilitate secure health information exchange. For instance, providers can submit a type of digital endpoint such as a Direct address, which functions similar to a regular email address, but includes additional security measures to ensure that messages are only accessible by the intended recipient in order to keep the information confidential and secure. As NPPES is publicly searchable on CMS' website, many other entities use the data included in the NPPES Downloadable File for other business and research purposes (for example, the Kaiser Family Foundation completed a 2020 report on the availability of active critical care physicians and nurses in a state-by-state analysis, relating to COVID-19).

Additionally, section 4003(b) of the Cures Act amended section 3001(c) of the Public Health Service Act (PHSA) to add a new paragraph (9)(A) that directed the National Coordinator to “develop or support a trusted exchange framework, including a common agreement among health information networks nationally.” The overall goal of the Trusted Exchange Framework and Common Agreement (TEFCA) is to establish a universal floor for interoperability across the country. Paragraph (9)(D) of section 3001(c) of the PHSA requires the National Coordinator to create and publish on ONC's website, “a list of the health information networks that have adopted the common agreement and are capable of trusted exchange pursuant to the common agreement.” On January 18, 2022, ONC released the Common Agreement for Nationwide Health Information Interoperability Version 1 (Common Agreement). The Common Agreement and the incorporated by reference Qualified Health Information Network (QHIN) Technical Framework Version 1 (QTF) establish a technical infrastructure model and governing approach for different health information networks and their users to securely share clinical information with each other. The Common Agreement and the QTF do not require FHIR-based exchange because network enablement of FHIR is still maturing in key areas. However, the ONC Recognized Coordinating Entity (RCE), a private-sector entity that implements the Common Agreement, released a 3-year FHIR Roadmap for TEFCA Exchange, which lays out a deliberate strategy to add FHIR-based exchange under TEFCA in the near future. The Common Agreement also includes requirements for maintaining a directory of exchange participants' digital endpoints.

Section 5006 of the Cures Act requires Medicaid agencies to publish online a directory of certain physicians who participate in the state's fee-for-service (FFS) program. Medicaid agencies must update these directories at least annually and include providers' names, specialties, addresses, and telephone numbers. For physicians participating in a primary care case-management system, the directory must also indicate whether they are accepting Medicaid beneficiaries as new patients and the physician's cultural and linguistic capabilities. Other providers may be included at the state's option, as may certain additional information such as the physician's or provider's internet website.

In 2016, ONC and FHA hosted a provider directory workshop to convene public and private stakeholders, including health IT developers, organizations, and vendors involved in directory solutions, to discuss provider directory issues and challenges. The workshop highlighted widely held concerns about provider directory data quality, administrative burden, and consumer satisfaction. To address these concerns, ONC and FHA launched the Healthcare Directory initiative. This group developed the VHDir FHIR IG to define the underlying architecture for a proposed national directory of validated healthcare data and to provide technical specifications for the exchange of such information. FHIR standards and IGs, including the VHDir IG, are developed through an industry-led, consensus-based public process. ONC, HHS, and CMS are all engaged in work to promote the adoption and use of the FHIR standards for interoperability beyond the provider directory domain.

Building on that work, in 2020, ONC, through the FHIR At Scale Taskforce (FAST), identified numerous technical challenges associated with directories, particularly related to digital endpoints. Specifically, FAST determined that there is neither an authoritative source for digital contact information nor a consistent method for locating such information. ONC conducted research, stakeholder engagement, and key technical development activities to establish the technical framework and capabilities for an adaptable and scalable NDH.

The FAST analysis concluded that a more robust directory is the needed long-term solution to overcome the technical barriers of using NPPES as a digital endpoint repository. The Taskforce noted that NPPES was not originally designed to hold, validate, and maintain digital contact information required to “appropriately describe the endpoints for FHIR.” They described that NPPES cannot sufficiently capture the data complexity necessary to fully facilitate electronic data exchange. For instance, provider-organization relationship information may be necessary to determine which endpoints are relevant for particular use cases. The Taskforce noted that other organizations that are not currently included in NPPES, such as payers, are vital to capture in a directory to effectively utilize digital endpoint information. These challenges to using NPPES as a digital endpoint directory are evidenced by the low rate of provider digital endpoint submission. In 2021, CMS determined that 2.9 million providers still had missing digital endpoints in NPPES. Additionally, the Taskforce found that the majority of the Direct addresses and FHIR endpoints that providers had submitted were invalid, a strong indication of the issues associated with using NPPES as an endpoint repository. The Taskforce described that there has “historically [been a] low rate of publication of valid Direct addresses in NPPES,” and “that only 4.3 percent of FHIR endpoints were valid as of 8/20/2020.” The FAST report concluded that for a digital endpoint directory to be effective, the directory “needs to be based on a broader set of validated healthcare participants and relationships.” This means that such a directory must be designed to adapt to industry or market demands for its use. FAST proposed a “national repository for validated information related to healthcare endpoints,” which described the development of a centralized directory as a critical next step in promoting digital contact information discovery, and therefore interoperability, across the healthcare system. FAST described that “one authoritative national source of truth” is needed to help address the issues with current directory systems and identified CMS as the potential owner of this asset.

In May 2020, CMS published a final rule, “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Healthcare Providers” (CMS Interoperability and Patient Access final rule), in which we required that, by January 1, 2021, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities make standardized information about their provider networks available through a Provider Directory API that is conformant with technical standards finalized by ONC. Those Provider Directory APIs are required to be accessible via a public-facing digital endpoint on the payer's website to ensure public discovery and access. Payers must make all directory information available to current and prospective enrollees and the public through the Provider Directory API within 30 calendar days of receiving new or updated provider directory data.

In the same final rule, CMS finalized a policy to publicly report the names and NPIs of those providers who do not have digital contact information included in NPPES. In December 2021, CMS published a report of approximately 2.9 million NPIs associated with providers and clinicians without digital contact information in NPPES, an initiative CMS has undertaken to improve provider engagement. CMS noted that the NPPES Missing Digital Contact Information Report will be updated quarterly. The most recent data for the second quarter of 2022, reported July 25, 2022, do not show any significant improvements in the number of providers with missing digital contact information compared to the December 2021 report. These data underscore FAST's call for a more robust long-term digital endpoint directory solution.

In 2020, the Consolidated Appropriations Act, 2021 (CAA) (Pub. L. 116-260), Division BB, section 116 added a new section 2799A-5 to the PHSA, section 720 to the Employee Retirement Income Security Act of 1974 (ERISA), and section 9820 to the Internal Revenue Code of 1986. These provisions require group health plans and health insurance issuers offering group or individual health insurance coverage to publish a provider directory and to establish a process to verify data in the directory at least every 90 days, beginning with plan years that start on or after January 1, 2022. Those directories must include names, addresses, specialty, telephone numbers, and digital contact information for healthcare providers and healthcare facilities. In addition, the CAA added a new section 2799B-9 to the PHSA, which requires each healthcare provider and healthcare facility to have in place business processes to ensure the timely provision of provider directory information to those payers.

To address part of the issue of inaccurate directory information, the CAA established consumer protections for incorrect provider directory information identifying a provider or facility as in-network for an item or service. If a patient receives provider directory information identifying a provider or healthcare facility as in-network with regard to an item or service, and receives that item or service from that provider or healthcare facility, and that provider or healthcare facility is actually out-of-network, their plan or issuer must limit cost-sharing to in-network terms that would apply to items or services that were furnished by an in-network provider or facility, and apply the deductible or out-of-pocket maximums as if the provider or facility were in-network. We note that further rulemaking is forthcoming for the provider directory requirements of that law, as discussed in the “Requirements Related to Surprise Billing; Part I” interim final rule (86 FR 36872).

In addition to these efforts, industry stakeholders have stepped in to try and fill this directory gap by developing large commercial digital endpoint directories. Although industry-developed directories have helped facilitate communication among users, access to their data is often fee-based, which inherently creates barriers to use and inequity for healthcare entities that do not have the resources or funds to buy access to these privately-owned endpoint directories. A free and publicly available CMS-sponsored NDH could minimize and may even eliminate this cost barrier associated with private industry created digital endpoint directories, and ensure all stakeholders have equal access to the relevant digital contact information they may need to securely exchange health data. Additionally, competing directories can lead to fragmentation and still require providers to submit similar information to multiple directories if information is not shared among directories. The FAST team concluded there should be one directory that acts as a centralized data hub to build trust, improve accuracy, and reduce the administrative burden on providers that submit data to multiple directories. As discussed in section III, industry stakeholders could utilize the data contained in an NDH to populate their own directories, supplementing it with additional data that could be beneficial for end users.

The efforts noted previously have continued to drive improvements to provider directories and lead the discussion on how to improve patient access to information about healthcare services. However, the effort required to update and maintain these numerous and varied directories presents a significant burden across the healthcare industry, and we continue to see challenges with data availability and accuracy. We believe that CMS could build upon the previous work in NPPES to help address some of these challenges by streamlining our own data and making that data available in an enhanced form for public use.

III. National Directory of Healthcare Providers & Services Concept and Perceived Benefits

A. National Directory of Healthcare Providers & Services Concept and Perceived Benefits

A centralized, validated NDH could help to alleviate current directory challenges by acting as a “centralized data hub” for healthcare directory information. By consolidating data into one source and reducing the number of places directory information must be maintained, an NDH could reduce the overall burden of keeping healthcare directory data up-to-date and accurate. For example, currently, when a provider changes their office location, that provider must update at least two separate CMS systems, NPPES and the Medicare Provider Enrollment, Chain, and Ownership System (PECOS), as well as an average of 20 separate payers' directories per physician practice. With the establishment of an NDH, that provider may be able to update their information one time, through a single point of entry in an NDH, which would make that data available not only to CMS, but also publicly available for other payers and developers to utilize in their own directories. We believe that providers and their staff would be more likely to keep a single NDH updated, and verify it more frequently, thus improving accuracy within an NDH, CMS systems, and in payers' directories.

A core requirement of an NDH would be the capability to validate and verify submitted information. In the context of an NDH, validation and verification can refer to separate but related processes. First, it is important to validate that the format of submitted data meets the required standards. This could be done, for example, by checking for the existence of required data elements, that those data elements are in the appropriate format, that references to existing resources are correct, and that any codes are from appropriate value sets. Second, it is important to verify the accuracy of data against a primary source. For example, a digital endpoint could be verified by sending a secure message to that endpoint asking the provider to complete verification through some action. We do not expect that all data elements would require the same level of validation and verification. As part of initial phases of NDH planning and development, CMS would assess possible verification methods and sources. Through this RFI, we hope to receive comments on this topic that could inform that assessment.

To support the “centralized data hub” concept, and improve directory function, CMS seeks feedback on potentially establishing an NDH that would overlay existing CMS systems that have directory-like functions, consolidate the data within them, and provide a single point of entry for providers to streamline workflows. We also believe that CMS could reduce the burden on providers and payers by building this directory using the most up-to-date technology, leveraging FHIR APIs. FHIR APIs would allow external stakeholders to pull data from an NDH to use as a data source for their own directories, thus avoiding duplicative data collection efforts. We note that in this use case example, the payers pulling provider data from an NDH would be responsible for verifying their own list of network providers.

Using a FHIR API, stakeholders could access and use NDH data to support a variety of use cases. Industry would be able to transform the data for purposes beyond what a public-facing CMS portal would be able to provide, and present it in a customized format for consumers, commercial, or operational use. We envision the following as other potential use cases for a FHIR API-enabled NDH:

• A patient or consumer could use an NDH directly, or through an app of their choosing that connects to an NDH via a FHIR API, to locate a provider.
• To support interoperability, a provider could connect to an NDH through the FHIR API to request the digital endpoint a particular payer uses to receive prior authorization requests. Once returned by an NDH, the provider's electronic health record (EHR) or practice management system could use that digital contact information to direct a prior authorization request to the appropriate payer.
• A payer (such as an MA organization, a private insurer, or state Medicaid agency) could use an NDH, via a FHIR API, to update its own provider directory with the latest information. This would allow the payer to present a provider directory without having to bear the burden of collecting data that is already available through an NDH from individual providers. The providers would also experience less burden because they would only need to update data in an NDH, and not multiple payer-specific directories. We note that payers would still be required to verify the accuracy of their network information to ensure that the provider directory is accurate.

We recognize that widespread adoption of, and trust in, an NDH would be necessary to fulfill this role as a “centralized data hub” for directory data. Without up-to-date, useful, and comprehensive directory data, an NDH would not be able to address existing healthcare directory challenges. We seek feedback on both positive and negative incentives that could be put into place to encourage widespread NDH use. These incentives may be for providers to update and maintain data and/or for payers to use the data from an NDH rather than requiring duplicative submissions from providers. We want to understand what incentives, programs, or policies might promote timely and accurate data reporting, as well as robust NDH usage by stakeholders.

We note that we previously requested comments, summarized in the 2020 CMS Interoperability and Patient Access final rule, regarding policies that we could implement to encourage providers to update their digital contact information in NPPES. Several commenters suggested incorporating a requirement to have up-to-date digital contact information in NPPES into the Merit-based Incentive Payment System (MIPS) program. We acknowledge a logical relationship with the Promoting Interoperability category of MIPS and continue to explore that avenue. However, we also realize the limitations of that possibility, as only certain types of clinicians who see Medicare patients are eligible to participate in MIPS and many Medicare providers participate in alternative programs.

We understand that it would be critical to allow listed entities, particularly providers, to delegate or authorize other individuals, either in their organization or intermediary organizations, to submit directory data on their behalf to reduce burden and ensure that data submission is feasible, timely, and accurate. We are using the term “listed entities” to refer to individuals and groups whose data could be available in an NDH. We want to understand current industry best practices for delegating authority and aspects of this functionality that could be used with an NDH.

B. Interactions With Current CMS Data Systems and Impacts to Business Processes

Integrating an NDH with current CMS-maintained systems, such as NPPES, PECOS, and Care Compare, could streamline data collection by acting as the single entry-point for listed entities to update their data across multiple CMS systems. Such data interactions could address provider data accuracy and consistency issues among CMS systems.

Examples of existing CMS data collection and reporting systems that an NDH could interface with to streamline data processes include:

• NPPES: Developed to assign NPIs to healthcare providers. Once an NPI is assigned, CMS, through NPPES, publishes the parts of the NPI record that have public relevance, including the provider's name, location, phone number, gender, specialty (taxonomy), practice address, and other identifiers for public use. Authorized under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (section 1173(b) of the Act and at 45 CFR 160.103, 162.402, and 162.408 of the regulations).

• PECOS: Supports the Medicare provider and supplier enrollment process. Registered providers and suppliers use PECOS to securely submit and manage their Medicare enrollment and revalidation processes. This system and its information attestation workflows are integral to program integrity prevention, investigation, and enforcement activities. We note that PECOS data are not publicly available. Rather, the system only contains information on Medicare providers and suppliers, and updates are limited by Medicare enrollment requirements. Authorized under sections 1102(a), 1128, 1814(a), 1815(a), 1833(e), 1871, and 1886(d)(5)(F) of the Act; 1842(r); section 1124(a)(1), and 1124A, section 4313, as amended, of the BBA of 1997; and section 31001(I) (31 U.S.C. 7701) of the Debt Collection Improvement Act of 1996 (DCIA) (Pub. L. 104-134), as amended.
• Medicare Care Compare: Public, consumer-facing directory containing contact and quality information on certain types of Medicare providers, suppliers, and provider organizations, including doctors, clinicians, hospitals, nursing homes, home health and hospice care, inpatient rehabilitation facilities, long-term care hospitals, and dialysis facilities. Care Compare data are populated from several data sources, including PECOS, NPPES and CMS quality reporting programs. Care Compare allows for comparison of Medicare providers and suppliers. We are authorized to collect and publicly report the following:

++ Certain physician quality data, in part, by section 10331(a)(1) of the Affordable Care Act, section 104(e) of the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) and section 1848 of the Act.

++ Certain hospital quality data under section 501(b) of MMA of 2003 and section 5001(a) of the Deficit Reduction Act of 2005 and section 1886 of the Act.

++ Certain hospice quality data under section 3004 of the Affordable Care Act and section 1814 of the Act.

++ Certain long-term care hospital quality data under section 3004 of the Affordable Care Act and section 1886(m)(5) of the Act.

++ Certain inpatient rehabilitation facility quality data under section 3004 of the Affordable Care Act and section 1886(j)(7) of the Act.

++ Certain home health quality data under section 1895(b)(3)(B)(v) of the Act.

++ Certain dialysis facility quality data under section 1881 of the Act and required by 42 CFR 405.2100 through 405.2171 (now at 42 CFR 414.330, 488.60, and 494.100 through 494.180).

++ Certain skilled nursing home quality data under section 1888(e)(6) of the Act, modified under the Improving Medicare Post-Acute Care Transformation (IMPACT) Act of 2014.

We note that we are not specifically requesting comment on replacing any of these or other CMS systems with an NDH. Rather, we believe that an NDH could be a tool that works in combination with these systems to streamline and improve the processes for collecting, maintaining, and presenting information in a more user-friendly manner. As discussed earlier, we envision that an NDH would create efficiencies by serving as a “centralized data hub” that would feed data to these other systems to use within their intended functions. An NDH built with modern data exchange capabilities, such as APIs, could share data with other CMS systems in real-time, improving data accuracy across CMS while eliminating the need for stakeholders to update information in multiple places.

Within these systems, CMS collects various demographic, contact, and healthcare practice data from or about many provider types and payer entities. These systems, in combination with other data systems that CMS maintains, have been established over time to perform their specific roles and in total contain a significant breadth of provider and payer data. By strengthening current efforts to streamline data processes, CMS could further improve the value and usability of its data. For example, linking provider contact information and quality data into one streamlined CMS resource could help consumers identify, compare, and locate providers who meet their specific needs and preferences. We also note that linking this information may be valuable for providers and payers participating in value-based payment models. We seek feedback on how we could combine these datasets into a single interface to be able to display more complex information, such as a clinician's relationship with hospitals or nursing facilities. This data aggregation may better support patients when choosing a healthcare facility or help providers locate one another for improved data exchange and care coordination.

We have increasingly emphasized improving the interoperability of data collected across our systems. As we have discussed, we believe existing directory-like information within CMS' systems could benefit from the operational efficiencies and streamlined effort of an NDH. We seek comment, prompted by the questions below, on various aspects that we should consider as we evaluate the feasibility, scope, and functionality of an NDH.

C. Comment Solicitation

We solicit comments on the following topics related to the establishment of an NDH:

• What benefits and challenges might arise while integrating data from CMS systems (such as NPPES, PECOS, and Medicare Care Compare) into an NDH? What data elements from each of these systems would be important to include in an NDH versus only being available directly from the system in question?
• Are there other CMS, HHS (for example, HPMS, Title X family planning clinic locator, ACL's Eldercare Resource Locator, SAMHSA's Behavioral Health Resource Locator, HRSA's National Practitioner Data Bank, or HRSA's Get Health Care), or federal systems with which an NDH could or should interface to exchange directory data?

++ What are these systems, how should an NDH interact with these systems, and for what purpose?

++ What data elements from each of these systems would be important to include in an NDH?

• Are there systems at the state or local level that would be beneficial for an NDH to interact with, such as those for licensing, credentialing, Medicaid provider enrollment, emergency response (for example, the Patient Unified Lookup System for Emergencies (PULSE) ) or public health?

++ What data elements would be beneficial to include in an NDH for interaction with state or local systems, including State-based Exchanges or existing state-level provider directories?

• Added by the Cures Act, Section 3001(c)(9)(D)(i) of the PHSA requires ONC to create, annually update, and publish on its website a “list of the health information networks that have adopted the common agreement and are capable of trusted exchange pursuant to the common agreement.” Are there beneficial ways an NDH could interface with such a list or provide additional information that may be useful, such as a directory of services? Are there use cases for integrating such health information network data in an NDH?
• What types of data should be publicly accessible from an NDH (either from a consumer-facing CMS website or via an API) and what types of data would be helpful for CMS to collect for only internal use (such as for program integrity purposes or for provider privacy)?
• Are there particular data elements that CMS currently collects or should collect as part of an NDH that we should not make publicly available, regardless of usefulness to consumers, due to its proprietary nature? To the extent that an NDH might collect proprietary data from various entities, what privacy protections should be in place for these data?
• We want an NDH to support health equity goals throughout the healthcare system. What listed entities, data elements, or NDH functionalities would help underserved populations receive healthcare services? What considerations would be relevant to address equity issues during the planning, development, or implementation of an NDH?
• How could NDH use within the healthcare industry be incentivized? How could CMS incentivize other organizations, such as payers, health systems, and public health entities to engage with an NDH?
• How could CMS evaluate whether an NDH achieves the targeted outcomes for its end users (for example, that it saves providers time or that it simplifies patients' ability to find care)? We solicit comments on an NDH concept and high-level functionality:
• Would an NDH as described provide the benefits outlined previously?

• Would an NDH as described reduce the directory data submission burden on providers?

• How could a centralized source for digital contact information benefit providers, payers, and other stakeholders?
• We have heard interest in including additional healthcare-related entities and provider types beyond physicians in an NDH-type directory beyond those providers included in current CMS systems or typical payers' directories? For example, should an NDH include allied health professionals, post-acute care providers, dentists, emergency medical services, nurse practitioners, physician assistants, certified nurse midwives, providers of dental, vision, and hearing care, behavioral health providers (psychiatrists, clinical psychologists, licensed professional counselors, licensed clinical social workers, etc.), suppliers, pharmacies, public health entities, community organizations, nursing facilities, suppliers of durable medical equipment or health information networks? We specifically request comment on entities that may not currently be included in CMS systems.

++ For what use cases should these various entities be included?

• Are there NDH use cases to address social drivers and/or determinants of health? If so, what are they? Are there other entities, relationships, or data elements that would be helpful to include in an NDH to help address the social drivers and/or determinants of health (for example, community-based organizations that provide housing-related services and supports, non-medical transportation, home-delivered meals, educational services, employment, community integration and social supports, or case management)? What types of entities or data elements relating to social drivers and/or determinants of health should not be included in an NDH?
• What provider or entity data elements would be helpful to include in an NDH for use cases relating to patient access and consumer choice (for example, finding providers or comparing networks)?

++ What data elements would be useful to include in an NDH to help patients locate providers who meet their specific needs and preferences?

++ Would it be helpful to include data elements such as provider languages spoken other than English, specific office accessibility features for patients with disabilities and/or limited mobility, accessible examination or medical diagnostic equipment, or a provider's cultural competencies, such as the National Committee for Quality Assurance's Health Equity accreditation (though we note that these data elements may be difficult to verify in some cases)?

• What provider or entity data elements would be helpful to include in an NDH for use cases relating to care coordination and essential business transactions (for example, prior authorization requests, referrals, public health reporting)?

++ What specific health information exchange or use cases would be important for an NDH to support?

++ Are there other types of data transactions or use cases beyond those already discussed that would be helpful for an NDH to support?

++ Are there additional data elements beyond those already discussed that would be useful for these use cases?

++ Beyond using FHIR APIs, what strategic approaches should be taken to ensure that directory data are interoperable?

• The COVID-19 pandemic has highlighted a need for public health systems to be better connected to providers and with each other. Would there be benefits to including public health entities in an NDH?

++ What public health use cases would it be helpful for an NDH to support (for example, facilitating digital contact endpoint discovery for public health reporting, or to provide additional data for public health entities' analytics)?

++ What data elements would be useful to collect from these entities to advance public health goals?

• Understanding that individuals often move between public and commercial health insurance coverage, what strategies could CMS pursue to ensure that an NDH is comprehensive both nationwide and market-wide?

++ Are there specific strategies, technical solutions, or policies CMS could pursue to encourage participation in an NDH by group health plans and health insurance issuers offering group or individual health insurance coverage for programs or product lines not currently under CMS' purview?

• Are there use cases for which it would be helpful for an NDH to support state and local governments? For example, are there specific types of providers, data elements, or technical requirements that would allow for infrastructure planning support, resource allocation, policy analysis, research, evaluation, emergency preparedness and response (such as PULSE), care coordination, planning, establishing partnerships, and determining service gaps?

++ How should CMS work with states to align federal and state policies to allow all parties to effectively use an NDH?

• Are there use cases for which an NDH could be used to help prevent fraud, waste, abuse, improper payments, or privacy breaches? Conversely, are there any concerns that an NDH, as described, could increase the possibility of those outcomes, and, if so, what actions could be taken to mitigate that risk?
• What specific functionality or use cases, including any not discussed here, would it be helpful for CMS to consider developing within an NDH? What types of data elements would need to be included (or excluded) to support these use cases (for example, licensing, certification, and credentialing)?
• Beyond identifying providers associated with specific organizations, and organizations that may be under the umbrella of a single health system, what other relationships would be important to capture and why?
• We have received feedback that individual providers may not use their individual digital endpoints in many cases where the communications involve patients receiving institutional care. How can we associate group- or practice-level digital contact information with appropriate providers to ensure that data get to the right place?
• What types of entities should be encouraged to use data from an NDH? For what purposes and why?
• What are some of the functions or features of current provider directories that work particularly well?
• What are some of the lessons learned or mistakes to avoid from current provider directories of which we should be aware?

We solicit comments on key considerations related to data submission and maintenance for potential NDH development:

• What policy or operational factors should be considered for new data collection interfaces as part of a single point of entry?
• How can data be collected, updated, verified, and maintained without creating or increasing burden on providers and others who could contribute data to an NDH, especially for under-resourced or understaffed facilities?
• What are barriers to updating directory data in current systems that could be addressed with an NDH?
• What are current and potential best practices regarding the frequency of directory data updates?

• What specific strategies, technical solutions, or policies could CMS implement to facilitate timely and accurate directory data updates? How could consistent and accurate NDH data submission be incentivized within the healthcare industry?

• How should duplicate information or conflicting information reported from different sources be resolved to balance the reporting burden versus confidence in data accuracy?
• The Healthcare Directory initiative and FAST both identified validation and verification as important functions of a centralized directory. What data types or data sources are important to verify (for example, provider endpoint information, provider credentialing) versus relying on self-reported information? Are there specific recommendations for verifying specific data elements?
• What use cases would benefit from data being verified and what sort of assurances would be necessary for trust and reliance on those data?
• Are there use cases where an NDH could provide data that has already been verified to reduce that burden on payers or other entities and, if so, how could that be achieved?
• What concerns might listed entities have about submitting data to an NDH? We solicit comments on provider delegation of authority to submit data on a provider's behalf:
• Outside of CMS, what mechanisms, standards, or processes are currently used to enable provider delegation of authority to submit data?
• What challenges, if any, occur in the processes for delegating authority to submit data on behalf of providers or in the processes for submitting directory data on behalf of providers?
• What specific strategies, technical solutions, or policies could be implemented to enable delegation of authority to submit data to an NDH?
• Should CMS consider including role-based access management to submit provider data to an NDH, and, if so, what kind of role-based access management?
• Are there entities that currently exist that would be helpful to serve as intermediaries for bulk data verification and upload or submission to an NDH? If so, are there existing models that demonstrate how this can be done (for instance, the verifications performed through the Federal Data Services Hub)?
• How do intermediaries currently perform bulk data verification and upload or submission to provider directories?

IV. Technical Framework for an NDH

A. Overview

The technical approach to establishing an NDH could leverage the extensive work the federal government has already done, in collaboration with industry stakeholders and standards development organizations, to develop healthcare directory information exchange standards. CMS could build on existing work to develop FHIR-based standards for healthcare directories. For years, ONC has collaborated with HL7, an ANSI-accredited standards development organization, to support the scalability and industry adoption of FHIR standards for use in a healthcare directory. Through an industry-led and consensus-based workgroup process, HL7 publishes various technical architecture standards, known as Implementation Guides (IGs). In 2016, HL7, in cooperation with the ONC and FHA Healthcare Directory initiative, developed and published the Validated Healthcare Directory (VHDir) IG. The VHDir IG was developed to describe the technical design considerations for collecting, validating, verifying, and exchanging data from a healthcare directory. The IG also provides technical guidance for a FHIR API for accessing data from a validated healthcare directory and could be used, for example, for provider credentialing and privileging. Building on this initial work, FAST has collaborated with HL7's Patient Administration Work Group to develop and maintain new FHIR IGs to further describe data attestation and verification processes, as well as a standard API for local directories to make verified data available to stakeholders: the National Directory Endpoint Query IG, the National Directory Exchange IG, and the National Directory Attestation and Validation IG.

Additionally, CMS could build on work done by FAST. FAST identified numerous technical challenges associated with directories, particularly related to digital contact information, and conducted research, stakeholder engagement, and key technical development activities to establish the framework and capabilities needed for a scalable NDH. In their proposed directory technical solutions document, FAST also identified CMS as the appropriate potential maintainer of an NDH.

Given these existing efforts to establish FHIR-based standards for healthcare directory information exchange, CMS could leverage this work to serve as the technical foundation on which to develop a FHIR API-enabled NDH. Additionally, using FHIR standards would help align an NDH with the technical standards at 45 CFR 170.215 finalized by ONC in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (85 FR 25642).

B. Comment Solicitation

We are soliciting comments on technical considerations for a potential NDH:

• In addition to FHIR, what technical standards are currently used or show promise to exchange directory data?
• What technical standards should an NDH support?
• What work related to developing FHIR standards for an NDH, such as building and refining IGs, still needs to be completed?
• How could CMS and ONC ensure that an NDH improves interoperability by promoting the adoption of TEFCA and supporting participating health information networks and healthcare entities? What are key opportunities for an NDH and TEFCA to work together in a mutually beneficial fashion?
• Are there use cases for providers accessing an NDH through their EHRs and, if so, what are the technical requirements?
• Are there use cases for individuals accessing an NDH through a patient-facing health app and, if so, what are the technical requirements?
• What security standards should be used to support an NDH?

• How should authentication and access to an NDH be managed for data submission? Should authentication and access processes vary based on the type of data being submitted, and if so, how?

• What other technical considerations should CMS be aware of?

V. Phased Approach to Implementation

A. Overview

The primary goal of an NDH would be to serve as a “centralized data hub” for accurate directory information in the healthcare market. To achieve that goal, CMS is seeking comments on a potential phased approach to establishing an NDH, in alignment with IT industry best practices. We would assess our statutory authorities to establish an NDH and take appropriate action. The initial phases of implementation would focus on consolidating and verifying existing data, building trust, and gaining industry buy-in. Subsequent phases would build on that foundation by incorporating additional data elements, listed entity types, and functionality while maintaining trust in the integrity of the system and data. This phased approach would allow CMS to gather consumer and industry input while focusing on scalability, data validity and governance, ethics, and equity for needed agency action or NDH development.

B. Comment Solicitation

We are soliciting comments on the feasibility of a phased approach to implementation and potential opportunities to build stakeholder trust and adoption along the way:

• What entities or stakeholders should participate in the development of an NDH, and what involvement should they have?
• What stakeholders could have valuable feedback in the scoping and early implementation processes to ensure viability of an NDH and sufficient uptake across the healthcare industry?
• What functionality would constitute a minimum viable product?
• What specific strategies, technical solutions, or policies could CMS employ to best engage stakeholders and build trust throughout the development process?
• What use cases should be prioritized in a phased development and implementation process for immediate impact and burden reduction?
• What types of entities and data categories should be prioritized in a phased development and implementation process for immediate impact and burden reduction?
• How could human-centered design, including equity-centered design, principles be used to optimize the usability of an NDH?
• What issues should CMS anticipate throughout an NDH system development life cycle?

++ Development (for example: timelines, technologies).

++ Implementation (for example: phased roll out, obtaining buy-in).

++ Operations (for example: updating content, access, and security).

++ Maintenance (for example: updating technologies, ensuring data accuracy).

VI. Prerequisites and CMS Actions To Address Challenges and Risks

A. Overview

We are aware of the many prerequisites, risks, and challenges associated with the implementation of such a directory and would consider these throughout the development process. As noted previously, the federal government has led numerous technical efforts that would help inform the planning and development of an NDH. Challenges associated with establishing an NDH include, but are not limited to, project planning and scoping, stakeholder and collaborator engagement, development risks, use of existing identifiers (for example, NPI or TIN), data publication, system maintenance, and stakeholder adoption.

B. Comment Solicitation

We are soliciting comments on risks, challenges, and prerequisites associated with implementing such a directory:

• What technical or policy prerequisites would need to be met prior to developing an NDH?
• What specific risks or challenges should be anticipated throughout the system development life cycle of an NDH? How can these risks and challenges be minimized?
• What are the most promising efforts that exist to date in resolving healthcare directory challenges? How could CMS best incorporate outputs from these efforts into the requirements for an NDH? Which gaps remain that are not being addressed by existing efforts?

VII. Information Collection Requirements

Please note, this is a request for information (RFI) only. In accordance with the implementing regulations of the Paperwork Reduction Act of 1995 (PRA), specifically 5 CFR 1320.3(h)(4), this general solicitation is exempt from the PRA. Facts or opinions submitted in response to general solicitations of comments from the public, published in the Federal Register or other publications, regardless of the form or format thereof, provided that no person is required to supply specific information pertaining to the commenter, other than that necessary for self-identification, as a condition of the agency's full consideration, are not generally considered information collections and therefore not subject to the PRA.

This RFI is issued solely for information and planning purposes; it does not constitute a Request for Proposal (RFP), applications, proposal abstracts, or quotations. This RFI does not commit the U.S. Government to contract for any supplies or services or make a grant award. Further, CMS is not seeking proposals through this RFI and will not accept unsolicited proposals. Responders are advised that the U.S. Government will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party's expense. Not responding to this RFI does not preclude participation in any future procurement, if conducted. It is the responsibility of the potential responders to monitor this RFI announcement for additional information pertaining to this request. Please note that CMS will not respond to questions about the policy issues raised in this RFI. CMS may or may not choose to contact individual responders. Such communications would only serve to further clarify written responses. Contractor support personnel may be used to review RFI responses. Responses to this notice are not offers and cannot be accepted by the U.S. Government to form a binding contract or issue a grant. Information obtained as a result of this RFI may be used by the U.S. Government for program planning on a non-attribution basis. Respondents should not include any information that might be considered proprietary or confidential. This RFI should not be construed as a commitment or authorization to incur cost for which reimbursement would be required or sought. All submissions become U.S. Government property and will not be returned. CMS may publicly post the comments received, or a summary thereof.

Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid Services, approved this document on September 28, 2022.