[Federal Register Volume 87, Number 194 (Friday, October 7, 2022)]
[Notices]
[Pages 61018-61029]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2022-21904]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

[CMS-0058-NC]
RIN 0938-ZB72


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.\1\ 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.\2\
---------------------------------------------------------------------------

    \1\ ONC Health IT. (2016, February). Strategic Implementation 
Guide: Provider Directories. See page 4. Retrieved from https://www.healthit.gov/sites/default/files/statestrategicimplementationguide-providerdirectories-v1-final.pdf.
    \2\ Doctor.com. (2020). Customer Experience Trends in 
Healthcare. Retrieved from https://cms.doctor.com/wp-content/uploads/2020/03/cxtrends2020-report-final.pdf.
---------------------------------------------------------------------------

    Although these are important resources, the fragmentation of 
current provider directories requires inefficient, redundant reporting 
from providers.\3\ 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.\4\
---------------------------------------------------------------------------

    \3\ We use the term ``providers'' generally in this RFI to refer 
to healthcare facilities and practitioners and do not intend that to 
include or exclude any specific category of individuals or entities.
    \4\ CAQH. (2019). The Hidden Causes of Inaccurate Provider 
Directories. Retrieved from https://www.caqh.org/sites/default/files/explorations/CAQH-hidden-causes-provider-directories-whitepaper.pdf.
---------------------------------------------------------------------------

    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.\5\
---------------------------------------------------------------------------

    \5\ Ibid.
---------------------------------------------------------------------------

    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

[[Page 61019]]

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.\6\
---------------------------------------------------------------------------

    \6\ CAQH. (2019). The Hidden Causes of Inaccurate Provider 
Directories, See page 2. Retrieved from https://www.caqh.org/sites/default/files/explorations/CAQH-hidden-causes-provider-directories-whitepaper.pdf.
---------------------------------------------------------------------------

    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.\7\ 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.
---------------------------------------------------------------------------

    \7\ To address digital contact information, section 4003(c)(1) 
of the 21st Century Cures Act requires the Secretary of Health and 
Human Services to ``establish a provider digital contact information 
index to provide digital contact information for health 
professionals and health facilities.''
---------------------------------------------------------------------------

    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[supreg] Fast Healthcare 
Interoperability Resources (FHIR[supreg]) 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.8 9 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.\10\ 
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.
---------------------------------------------------------------------------

    \8\ HL7. (2022, May 28). Welcome to FHIR. Retrieved from http://hl7.org/fhir/.
    \9\ Health IT. (2021, June 16). FHIR Fact Sheets. Retrieved from 
https://www.healthit.gov/topic/standards-technology/standards/fhir-
fact-
sheets#:~:text=What%20is%20HL7%C2%AE%20FHIR,be%20quickly%20and%20effi
ciently%20exchanged.
    \10\ CMS. (2020, May 1). 85 FR 25510. See page 25521-22, 25530. 
Retrieved from https://www.federalregister.gov/d/2020-05050.
---------------------------------------------------------------------------

    ONC and the Federal Health Architecture (FHA), a former federal 
agency collaboration created to enhance interoperability among federal 
health information technology (IT) systems,\11\ 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.\12\ 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.
---------------------------------------------------------------------------

    \11\ Health IT. (2020, January 17). Federal Health Architecture 
(FHA). Retrieved from https://www.healthit.gov/archive/topic/onc-hitech-programs/federal-health-architecture-fha.
    \12\ McKenzie, L. & Peters, M. (2021, March 3). HL7 Balloting. 
Retrieved from https://confluence.hl7.org/display/HL7/HL7+Balloting.
---------------------------------------------------------------------------

    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.\13\ 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.
---------------------------------------------------------------------------

    \13\ FAST. (2020, December 17). Proposed Solutions Working 
Document: Directory (V3). Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Directory%2C+Versions+and+Scale+Tiger+Team?preview=/46301216/183107855/FAST-PS-Directory%20V3_122320.docx.
---------------------------------------------------------------------------

    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,\14\ 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.
---------------------------------------------------------------------------

    \14\ CMS. (2022, February 11). OBRHI FAQs. Retrieved from 
https://www.cms.gov/about-cms/obrhi/faqs.
---------------------------------------------------------------------------

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

[[Page 61020]]

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 
15 16 and section 110 of Chapter 4 of the Medicare Managed 
Care Manual.17 18
---------------------------------------------------------------------------

    \15\ CMS. (2022, February 9). Medicare Communications and 
Marketing Guidelines (MCMG). Retrieved from https://www.cms.gov/files/document/medicare-communications-marketing-guidelines-2-9-2022.pdf.
    \16\ Prior to 2020, CMS issued the Medicare Marketing Guidelines 
(historical versions are available through the HHS Guidance Portal, 
available online here: https://www.hhs.gov/guidance/) but replaced 
that document with the Medicare Communications and Marketing 
Guidelines when the applicable regulations were revised in a final 
rule that appeared in the Federal Register on April 16, 2018 (83 FR 
16440, 16624 through 16633).
    \17\ CMS. (2015, April 22). Medicare Managed Care Manual 
Publication # 100-16: Chapter 4--Benefits and Beneficiary 
Protections. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/internet-Only-Manuals-IOMs-Items/CMS019326.
    \18\ CMS. (2016, April 22). Medicare Managed Care Manual: 
Benefits and Beneficiary Protections. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Downloads/mc86c04.pdf.
---------------------------------------------------------------------------

    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.19 20 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.\21\ 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.\22\ 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.
---------------------------------------------------------------------------

    \19\ CMS. (2022, January 7). 2023 Letter to Issuers in the 
Federally-facilitated Exchanges, Chapter 3, Section 1. Retrieved 
from https://www.cms.gov/files/document/2023-draft-letter-issuers-508.pdf.
    \20\ CMS. (2017, February 17). Addendum to 2018 Letter to 
Issuers in the Federally-facilitated Marketplaces. Retrieved from 
https://www.cms.gov/CCIIO/Resources/Regulations-and-Guidance/Downloads/Final-2018-Letter-to-Issuers-in-the-Federally-facilitated-Marketplaces-and-February-17-Addendum.pdf.
    \21\ CMS selected a sample of 25 providers from 45 QHP and 5 
SADP issuers, For each issuer, the target sample was selected to 
equally distribute primary care physician (PCP), obstetrics/
gynecology (OB/GYN), pediatrics, and specialty providers for QHPs, 
and general dentists, pediatric dentists, and specialty dentists for 
SADPs. The provider's National Provider Identification number (NPI) 
was used to ensure providers were not chosen more than once during 
each plan year review. One SADP in the sample had only 15 unique 
NPIs from which a sample could be selected; this resulted in the 
final sample size of 1,235 unique NPIs.
    \22\ CMS. (2022, March 22). Machine-Readable Provider Directory 
Review Summary Report Plan Years 2017-2021. Retrieved from https://www.cms.gov/files/document/2017-2021mrpdsummaryreportfinal508.pdf.
---------------------------------------------------------------------------

    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.\23\ 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.\24\ 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.\25\
---------------------------------------------------------------------------

    \23\ CMS. (2015, April 6). Announcement of Calendar Year (CY) 
2016 Medicare Advantage Capitation Rates and Medicare Advantage and 
Part D Payment Policies and Final Call Letter. Retrieved from 
https://www.cms.gov/Medicare/Health-Plans/MedicareAdvtgSpecRateStats/Downloads/Announcement2016.pdf.
    \24\ CMS. (2018, November 28). Online Provider Directory Review 
Report. Retrieved from https://www.cms.gov/Medicare/Health-Plans/ManagedCareMarketing/Downloads/Provider_Directory_Review_Industry_Report_Round_3_11-28-2018.pdf.
    \25\ Ibid.
---------------------------------------------------------------------------

    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 Sec.  
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.\26\
---------------------------------------------------------------------------

    \26\ CMS. (2020, January). HPMS Memo. Retrieved from https://www.cms.gov/httpseditcmsgovresearch-statistics-data-and-systemscomputer-data-and-systemshpmshpms-memos-archive/hpms-memo-3.

---------------------------------------------------------------------------

[[Page 61021]]

    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,\27\ 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,\28\ 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.\29\ 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).\30\
---------------------------------------------------------------------------

    \27\ CMS. NPPES NPI Registry. Retrieved from https://npiregistry.cms.hhs.gov/.
    \28\ CMS. (2022, February 11). OBRHI FAQs. Retrieved from 
https://www.cms.gov/about-cms/obrhi/faqs.
    \29\ Health IT. (2014, May). Direct Basics: Q&A for Providers. 
Retrieved from https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf.
    \30\ Lopez, E. (2020, July 30). The Critical Care Workforce and 
COVID-19. Retrieved from https://www.kff.org/report-section/the-critical-care-workforce-and-covid-19-a-state-by-state-analysis-data-note/.
---------------------------------------------------------------------------

    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).\31\ 
The Common Agreement and the incorporated by reference Qualified Health 
Information Network (QHIN) Technical Framework Version 1 (QTF) \32\ 
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),\33\ 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.\34\ The Common Agreement also 
includes requirements for maintaining a directory of exchange 
participants' digital endpoints.
---------------------------------------------------------------------------

    \31\ ONC. (2022, January). Common Agreement for National Health 
Information Interoperability, Version 1. Retrieved from https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.
    \32\ ONC TEFCA Recognized Coordinating Entity. (2022, January). 
Qualified Health Information Network (QHIN) Technical Framework 
(QTF) Version 1.0. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.
    \33\ In August 2019, ONC awarded a cooperative agreement to The 
Sequoia Project to serve as the initial RCE. The RCE will 
operationalize and enforce the Common Agreement, oversee QHIN-
facilitated network operations, and ensure compliance by 
participating QHINs. The RCE will also engage stakeholders to create 
a roadmap for expanding interoperability over time. See The Sequoia 
Project. (2019, September 4). ONC Awards The Sequoia Project a 
Cooperative Agreement for the Trusted Exchange Framework and Common 
Agreement to Support Advancing Nationwide Interoperability of 
Electronic Health Information. Retrieved from https://sequoiaproject.org/onc-awards-the-sequoia-project-a-cooperative-agreement-for-the-trusted-exchange-framework-and-common-agreement-to-support-advancing-nationwide-interoperability-of-electronic-health-information.
    \34\ ONC TEFCA Recognized Coordinating Entity. (2022, January). 
FHIR Roadmap for TEFCA Exchange, Version 1. Retrieved from https://rce.sequoiaproject.org/wp-content/uploads/2022/01/FHIR-Roadmap-v1.0_updated.pdf.
---------------------------------------------------------------------------

    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.35 36 
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.\37\ 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.
---------------------------------------------------------------------------

    \35\ ONC. (2016, June 24). ONC/FHA Provider Directory Workshop. 
Retrieved from https://www.ca-hie.org/site-content/CAHIE-Knowledge-Network-2016-06-24-Healthcare-Directory.pdf.
    \36\ Health IT.gov. (2020, January 17). Federal Health 
Architecture (FHA). Retrieved from https://www.healthit.gov/archive/topic/onc-hitech-programs/federal-health-architecture-fha.
    \37\ ONC Tech Lab Standards Coordination. (2019, June 25). 
Healthcare Directory. Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Healthcare+Directory.
---------------------------------------------------------------------------

    Building on that work, in 2020, ONC, through the FHIR At Scale 
Taskforce (FAST),\38\ identified numerous technical challenges 
associated with directories, particularly related to digital 
endpoints.39 40 Specifically, FAST

[[Page 61022]]

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.41 42
---------------------------------------------------------------------------

    \38\ FAST. (2022, March 16), FAST Home. Retrieved from https://confluence.hl7.org/display/FAST/FHIR+at+Scale+Taskforce+%28FAST%29+Home.
    \39\ FAST. (2020, December 17). Proposed Solutions Working 
Document: Directory (V3). Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Directory%2C+Versions+and+Scale+Tiger+Team?preview=/46301216/183107855/FAST-PS-Directory%20V3_122320.docx.
    \40\ Endpoints provide a simple, secure, scalable, and 
standards-based way for participants to send authenticated, 
encrypted health information directly to known, trusted recipients 
over the internet. See CMS. (2016). Health Information Exchange 
(HIE) Page. Retrieved from https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.
    \41\ ONC Tech Lab Standards Coordination. (2019, June 27). 
Healthcare Directory Workshop--2019. Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Provider+Directory+Workshop+-+2016.
    \42\ ONC Tech Lab Standards Coordination. (2019, June 27). Day 1 
Agenda Presentations. Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Day+1-+Agenda-Presentations.
---------------------------------------------------------------------------

    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.'' \43\ 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.\44\ 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.\45\ 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 \46\ were valid as of 8/20/2020.'' \47\ 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.'' \48\ 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.\49\ 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.50 51
---------------------------------------------------------------------------

    \43\ FAST. (2020, December 17). Proposed Solutions Working 
Document: Directory (V3). Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Directory%2C+Versions+and+Scale+Tiger+Team?preview=/46301216/183107855/FAST-PS-Directory%20V3_122320.docx.
    \44\ Ibid.
    \45\ CMS. (2021, December 11). Public Reporting of Missing 
Digital Contact Information. Retrieved from https://data.cms.gov/provider-compliance/public-reporting-of-missing-digital-contact-information.
    \46\ FHIR endpoints are just one type of endpoint collected in 
NPPES and refer to a FHIR-compatible endpoint such as a FHIR URL. 
Other types of endpoints used by providers are not necessarily FHIR-
compatible, such as a Direct address.
    \47\ FAST. (2020, December 17). Proposed Solutions Working 
Document: Directory (V3). Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Directory%2C+Versions+and+Scale+Tiger+Team?preview=/46301216/183107855/FAST-PS-Directory%20V3_122320.docx.
    \48\ Ibid.
    \49\ Ibid.
    \50\ Ibid.
    \51\ Note, the FAST Initiative will transition from an ONC-
convened initiative into an official HL7 FHIR Accelerator in 2022.
---------------------------------------------------------------------------

    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),\52\ in which we 
required that, by January 1, 2021, MA organizations, Medicaid \53\ and 
CHIP FFS \54\ programs, Medicaid managed care plans,\55\ and CHIP 
managed care entities \56\ make standardized information about their 
provider networks available through a Provider Directory API that is 
conformant with technical standards finalized by ONC.57 58 
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.
---------------------------------------------------------------------------

    \52\ CMS. (2020, May 1). 85 FR 25510, See page 25513. Retrieved 
from https://www.federalregister.gov/d/2020-05050.
    \53\ We note 42 CFR 431.70 as the current regulation requiring 
provider directory APIs.
    \54\ We note 42 CFR 457.760 as the current regulation requiring 
provider directory APIs.
    \55\ We note 42 CFR 438.242(b)(6) as the current regulation 
requiring provider directory APIs.
    \56\ We note 42 CFR 457.1233(d), through cross-reference to 
Sec.  438.242, as the current regulation requiring provider 
directory APIs.
    \57\ While other aspects of that rule applied to issuers of QHPs 
on the FFEs, this requirement did not.
    \58\ ONC. (2020, May 1). 45 CFR 170.215. Retrieved from https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification.
---------------------------------------------------------------------------

    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.\59\ In December 2021, CMS published a 
report of approximately 2.9 million NPIs associated with providers and 
clinicians without digital contact information in NPPES,\60\ 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.\61\ These data underscore FAST's call for 
a more robust long-term digital endpoint directory solution.
---------------------------------------------------------------------------

    \59\ CMS. (2020, May 1). 85 FR 25510. See page 25584. Retrieved 
from https://www.federalregister.gov/d/2020-05050/p-767.
    \60\ CMS. (2021, December 11). Public Reporting of Missing 
Digital Contact Information. Retrieved from https://data.cms.gov/provider-compliance/public-reporting-of-missing-digital-contact-information.
    \61\ CMS. (2021, July 25). Public Reporting of Missing Digital 
Contact Information. Retrieved from https://data.cms.gov/provider-compliance/public-reporting-of-missing-digital-contact-information.
---------------------------------------------------------------------------

    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

[[Page 61023]]

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).62 63
---------------------------------------------------------------------------

    \62\ ``Requirements Related to Surprise Billing; Part I (86 FR 
36872, 36876).
    \63\ Interim guidance can be found at p. 7-8 of ``FAQs About 
Affordable Care Act and Consolidated Appropriations Act, 2021 
Implementation Part 49'' at https://www.cms.gov/CCIIO/Resources/Fact-Sheets-and-FAQs/Downloads/FAQs-Part-49.pdf.
---------------------------------------------------------------------------

    In addition to these efforts, industry stakeholders have stepped in 
to try and fill this directory gap by developing large commercial 
digital endpoint directories.64 65 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.\66\ 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.
---------------------------------------------------------------------------

    \64\ CAQH. (2022). CAQH Endpoint Directory. Retrieved from 
https://www.caqh.org/solutions/caqh-endpoint-directory.
    \65\ GlobeNewswire. (2022, March 10). CareMESH Launches 
Developer Portal and APIs for its National Provider Directory. 
Retrieved from https://www.globenewswire.com/news-release/2022/03/10/2401103/0/en/careMESH-Launches-Developer-Portal-and-APIs-for-its-National-Provider-Directory.html.
    \66\ FHIR at Scale Taskforce (FAST). (2020, June 1 & 15). SME 
Session Summary Report. Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+Proposed+Solutions+-+Subject+Matter+Expert+%28SME%29+Panel+Sessions?preview=/149848177/181174490/FAST-Directory%20SME%20Session%20Summary%20Report.pdf.
---------------------------------------------------------------------------

    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.\67\
---------------------------------------------------------------------------

    \67\ CMS. (2022, February 11). OBRHI FAQs. Retrieved from 
https://www.cms.gov/about-cms/obrhi/
faqs#:~:text=Digital%20contact%20information%2C%20also%20known,truste
d%20recipients%20over%20the%20internet.
---------------------------------------------------------------------------

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.\68\ 
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.
---------------------------------------------------------------------------

    \68\ CAQH. (2019, November 13). CAQH Survey: Maintaining 
Provider Directories Costs US Physician Practices 2.76 Billion 
Annually. Retrieved from https://www.caqh.org/about/press-release/caqh-survey-maintaining-provider-directories-costs-us-physician-practices-276.
---------------------------------------------------------------------------

    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,

[[Page 61024]]

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,\69\ 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.
---------------------------------------------------------------------------

    \69\ CMS. (2020, May 1). 85 FR 25510. See pages 25581-84. 
Retrieved from https://www.federalregister.gov/d/2020-05050.
---------------------------------------------------------------------------

    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.\70\
---------------------------------------------------------------------------

    \70\ Levinson, D. R. (2013, May). Improvements Needed to Ensure 
Provider Enumeration and Medicare Enrollment Data are Accurate, 
Complete, and Consistent. Retrieved from https://oig.hhs.gov/oei/reports/oei-07-09-00440.pdf.
---------------------------------------------------------------------------

    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.\71\ 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.\72\ 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).
---------------------------------------------------------------------------

    \71\ CMS. NPPES. Retrieved from https://nppes.cms.hhs.gov/#/.
    \72\ CMS. NPPES NPI Registry. Retrieved from https://npiregistry.cms.hhs.gov/.
---------------------------------------------------------------------------

     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

[[Page 61025]]

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) 
\73\) or public health?
---------------------------------------------------------------------------

    \73\ ONC. (2022, March 4). Patient Unified Lookup System for 
Emergencies (PULSE). Retrieved from https://www.healthit.gov/topic/health-it-health-care-settings/public-health/patient-unified-lookup-system-for-emergencies-pulse.
---------------------------------------------------------------------------

    ++ 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?

[[Page 61026]]

     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

[[Page 61027]]

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.\74\ \75\ 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.\76\ \77\ 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.\78\
---------------------------------------------------------------------------

    \74\ ONC. (2021, April). What is HL7 FHIR? Retrieved from 
https://www.healthit.gov/topic/standards-technology/standards/fhir-fact-sheets.
    \75\ Hadassah, G. & Marcelonis, D. (2022, May 20). National 
Healthcare Directory. Retrieved from https://confluence.hl7.org/display/PA/National+Healthcare+Directory.
    \76\ ONC Tech Lab Standards Coordination. (2019, June 25). 
Healthcare Directory. Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Healthcare+Directory.
    \77\ HL7. (2022). Validated Healthcare Directory. Retrieved from 
http://build.fhir.org/ig/HL7/VhDir/index.html.
    \78\ Hadassah, G. & Marcelonis, D. (2022, May 20). National 
Healthcare Directory. Retrieved from https://confluence.hl7.org/display/PA/National+Healthcare+Directory.
---------------------------------------------------------------------------

    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.\79\ 
\80\ In their proposed directory technical solutions document, FAST 
also identified CMS as the appropriate potential maintainer of an 
NDH.\81\
---------------------------------------------------------------------------

    \79\ FAST. (2020, December 17). Proposed Solutions Working 
Document: Directory (V3). Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Directory%2C+Versions+and+Scale+Tiger+Team?preview=/46301216/183107855/FAST-PS-Directory%20V3_122320.docx.
    \80\ ONC Tech Lab Standards Coordination. (2022, April 1). FHIR 
at Scale Taskforce (FAST). Retrieved from https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=43614268.
    \81\ FAST. (2020, December 17). Proposed Solutions Working 
Document: Directory (V3). Page 13. Retrieved from https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Directory%2C+Versions+and+Scale+Tiger+Team?preview=/46301216/183107855/FAST-PS-Directory%20V3_122320.docx.
---------------------------------------------------------------------------

    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

[[Page 61028]]

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.


[[Page 61029]]


    Dated: October 3, 2022.
Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2022-21904 Filed 10-5-22; 8:45 am]
BILLING CODE 4120-01-P