[Federal Register Volume 85, Number 244 (Friday, December 18, 2020)]
[Proposed Rules]
[Pages 82586-82682]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-27593]



[[Page 82585]]

Vol. 85

Friday,

No. 244

December 18, 2020

Part II





Department of Health and Human Services





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





Centers for Medicare & Medicaid Services





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





42 CFR Parts 431, 435, 438, et al.

45 CFR Parts 156 and 170





Medicaid Program; Patient Protection and Affordable Care Act; Reducing 
Provider and Patient Burden by Improving Prior Authorization Processes, 
and Promoting Patients' Electronic Access to Health Information for 
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and 
CHIP Managed Care Entities, and Issuers of Qualified Health Plans on 
the Federally-Facilitated Exchanges; Health Information Technology 
Standards and Implementation Specifications; Proposed Rule

Federal Register / Vol. 85 , No. 244 / Friday, December 18, 2020 / 
Proposed Rules

[[Page 82586]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

42 CFR Parts 431, 435, 438, 440, and 457

Office of the Secretary

45 CFR Parts 156 and 170

[CMS-9123-P]
RIN 0938-AT99


Medicaid Program; Patient Protection and Affordable Care Act; 
Reducing Provider and Patient Burden by Improving Prior Authorization 
Processes, and Promoting Patients' Electronic Access to Health 
Information for Medicaid Managed Care Plans, State Medicaid Agencies, 
CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified 
Health Plans on the Federally-Facilitated Exchanges; Health Information 
Technology Standards and Implementation Specifications

AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS; Office of 
the National Coordinator for Health Information Technology (ONC), HHS.

ACTION: Proposed rule.

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

SUMMARY: This proposed rule would place new requirements on state 
Medicaid and CHIP fee-for-service (FFS) programs, Medicaid managed care 
plans, CHIP managed care entities, and Qualified Health Plan (QHP) 
issuers on the Federally-facilitated Exchanges (FFEs) to improve the 
electronic exchange of health care data, and streamline processes 
related to prior authorization, while continuing CMS' drive toward 
interoperability, and reducing burden in the health care market. In 
addition, on behalf of the Department of Health and Human Service 
(HHS), the Office of the National Coordinator for Health Information 
Technology (ONC) is proposing the adoption of certain specified 
implementation guides (IGs) needed to support the proposed Application 
Programming Interface (API) policies included in this rule. Each of 
these elements plays a key role in reducing overall payer and provider 
burden and improving patient access to health information.

DATES: To be assured consideration, comments must be received at one of 
the addresses provided below, no later than 5 p.m. on January 4, 2021.

ADDRESSES: In commenting, please refer to file code CMS-9123-P.
    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-9123-P, P.O. Box 8016, 
Baltimore, MD 21244-8016.
    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-9123-P, 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, for general issues related to this 
rule and CMS interoperability initiatives.
    Denise St. Clair, (410) 786-4599, for the API policies, 
implementation guides (IGs), general issues related to this rule, and 
CMS interoperability initiatives.
    Lorraine Doo, (443) 615-1309, for prior authorization process 
policies and CMS interoperability initiatives.
    Amy Gentile, (410) 786-3499, for issues related to Medicaid managed 
care.
    Kirsten Jensen, (410) 786-8146, for issues related to Medicaid fee 
for service (FFS).
    Cassandra Lagorio, (410) 786-4554, for issues related to the 
Children's Health Insurance Program (CHIP).
    Russell Hendel, (410) 786-0329, for issues related to the 
Collection of Information and Regulatory Impact Analysis.
    Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified 
Health Plans (QHPs).

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.

Table of Contents

I. Background and Summary of Provisions
    A. Purpose
    B. Summary of Major Proposals
II. Provisions of the Proposed Rule
    A. Patient Access API
    B. Provider Access APIs
    C. Documentation and Prior Authorization Burden Reduction 
Through APIs
    D. Payer-to Payer Data Exchange on FHIR
    E. Adoption of Health IT Standards and Implementation 
Specifications
III. Requests for Information
    A. Request for Information: Methods for Enabling Patients and 
Providers to Control Sharing of Health Information
    B. Request for Information: Electronic Exchange of Behavioral 
Health Information
    C. Request for Information: Reducing Burden and Improving 
Electronic Information Exchange of Prior Authorization
    D. Request for Information: Reducing the Use of Fax Machines
    E. Request for Information: Accelerating the Adoption of 
Standards Related to Social Risk Data
IV. Incorporation by Reference
V. Collection of Information
VI. Response to Comments
VII. Regulatory Impact Analysis
Regulations Text

I. Background and Summary of Provisions

A. Purpose

    In the May 1, 2020 Federal Register, we published the first phase 
of CMS interoperability rulemaking in the ``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 Health Care Providers'' final rule 
(85 FR 25510) (hereinafter referred to as the ``CMS Interoperability 
and Patient Access final rule'').
    This proposed rule emphasizes improving health information exchange

[[Page 82587]]

and achieving appropriate and necessary access to complete health 
records for patients, providers, and payers, while simultaneously 
reducing payer, provider, and patient burden by improving prior 
authorization processes, and helping to ensure that patients remain at 
the center of their own care. In this rule, we are proposing to enhance 
certain policies from the CMS Interoperability and Patient Access final 
rule, as described below, and add several new proposals to increase 
data sharing and reduce overall payer, provider, and patient burden 
through proposed changes to prior authorization practices. ``Prior 
authorization'' refers to the process through which a provider must 
obtain approval from a payer before providing care and prior to 
receiving payment for delivering items or services. In some programs, 
this may be referred to as ``pre-authorization'' or ``pre-claim 
review.'' Prior authorization requirements are established by payers to 
help control costs and ensure payment accuracy by verifying that an 
item or service is medically necessary, meets coverage criteria, and is 
consistent with standards of care before the item or service is 
provided rather than undertaking that review for the first time when a 
post-service request for payment is made.
    We are taking an active approach to move participants in the health 
care market toward interoperability and reduced burden by proposing 
policies for the Medicaid program; the Children's Health Insurance 
Program (CHIP); and qualified health plan (QHP) issuers on the 
individual market Federally-facilitated Exchanges (FFEs).
    For purposes of this proposed rule, references to QHP issuers on 
the FFEs exclude issuers offering only stand-alone dental plans 
(SADPs). Likewise, we are also excluding QHP issuers only offering QHPs 
in the Federally-facilitated Small Business Health Options Program 
Exchanges (FF-SHOPs) from the proposed provisions of this rule. We 
believe that the proposed standards would be overly burdensome to both 
SADP and SHOP issuers, as their current enrollment numbers and premium 
intake from QHP enrollment are unlikely to support the costs of the 
requirements that this proposed rule would impose, and could result in 
those issuers no longer participating in the FFEs, which would not be 
in the best interest of enrollees. We note that, in this proposed rule, 
FFEs include those Exchanges in states that perform plan management 
functions. State-based Exchanges on the Federal Platform (SBE-FPs) are 
not FFEs, even though consumers in these states enroll in coverage 
through HealthCare.gov, and QHP issuers in SBE-FPs would not be subject 
to the requirements in this proposed rule. We encourage states 
operating Exchanges to consider adopting similar requirements for QHPs 
on the State-based Exchanges (SBEs).
    In the CMS Interoperability and Patient Access final rule (85 FR 
25510), we finalized policies impacting Medicare Advantage 
organizations, state Medicaid and CHIP FFS programs, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs. 
The policies finalized in that rule requiring those impacted payers to 
build and maintain application programing interfaces (APIs) were 
critical and foundational policies, increasing patient access and data 
exchange and improving interoperability in health care. In this 
proposed rule, we are proposing certain policies to expand upon those 
foundational policies for state Medicaid and CHIP FFS programs, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers on the FFEs. As further addressed later in this section of the 
preamble, starting with this payer population is a critical first step 
for these new proposals. For instance, state Medicaid and CHIP FFS 
programs were excluded from the payer-to-payer data exchange policies 
finalized in the CMS Interoperability and Patient Access final rule (85 
FR 25564 through 25569). In our first phase of interoperability policy, 
we chose to limit the burden on these programs so they could focus 
their attention and resources on implementing the Patient Access and 
Provider Directory APIs. This proposed rule is a critical step in 
proposing to require state Medicaid and CHIP FFS programs to similarly 
exchange patient health information in a more efficient and 
interoperable way, as discussed in section II.D. of this proposed rule, 
leveraging the technology and experience gained from implementing the 
initial set of API policies to these new proposed policies.
    ``Churn'' in health care refers to the movement of patients between 
payers and in and out of health care coverage. Churn occurs when a 
patient moves between payer types and plans or dis-enrolls from 
coverage (voluntarily or involuntarily) for a period of time. Patients 
enrolled in Medicaid, CHIP, and QHPs in particular may move between and 
among these payers due to a change in their eligibility status, or a 
change in the availability of subsidies in the case of QHP enrollees. 
Medicaid beneficiaries who churn in and out of Medicaid tend to have 
higher utilization of emergency services. Overall, these patients face 
more coverage instability than those enrolled in Medicare. Several of 
the API proposals outlined in this proposed rule would particularly 
benefit patients enrolled in Medicaid, CHIP, and QHPs by allowing them 
to retain their health information in an electronic form, and have 
their health information move with them from payer to payer and 
provider to provider.
    Our authority to regulate Medicaid and CHIP FFS, Medicaid and CHIP 
managed care, and QHP issuers on the FFEs puts us in a unique position 
to be able to align policies across these programs to the benefit of 
patients across the nation. Patients enrolled in these programs may 
churn from payer to payer within a given program, as well as from 
program to program. For example, a Medicaid enrollee may change 
eligibility status for Medicaid and enroll with a QHP issuer and back 
in a given year. For this reason, our API proposals discussed in the 
following sections are particularly valuable because they allow 
patients to maintain an electronic copy of their health information 
(Patient Access API discussed in section II.A.), share data directly 
with their providers (Provider Access API discussed in section II.B. of 
this proposed rule), and to bring their health information with them as 
they move from one payer to another (Payer-to-Payer API discussed in 
section II.D.), which is especially valuable to patients covered by 
Medicaid and QHPs who experience churn both within and between 
programs, and may also experience churn in and out of coverage.
    While we are not making any proposals for MA organizations at this 
time, we acknowledge that payers with multiple lines of business may 
choose to implement these polices for their MA lines of business to 
support better internal alignment as well as to create more 
efficiencies and transparency for their patients. Neither the 
provisions in the CMS Interoperability and Patient Access final rule 
nor the proposed provisions here would preclude any payer from 
implementing these proposed policies regardless of whether the payer is 
directly impacted by the rule. We believe aligning these policies 
across all payers would benefit all payers alike. However, we do not 
believe our approach to start with state Medicaid and CHIP FFS 
programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers on the FFEs will have a negative impact on patients. We 
believe these policies would provide a net benefit to these patients, 
bringing these programs closer in alignment with one another. We are 
aware that these proposals, if finalized,

[[Page 82588]]

would create misalignments between Medicaid and Medicare that could 
affect dually eligible individuals enrolled in both a Medicaid managed 
care plan and an MA plan. While we currently do not believe it is 
necessary to apply these policies to Medicare Advantage organizations 
at this time, we intend to further evaluate the implementation of these 
policies to determine whether they would also be appropriate to apply 
to Medicare Advantage organizations for future rulemaking. In this 
proposed rule, when we refer to ``impacted payers,'' we are referring 
to state Medicaid and CHIP FFS programs, Medicaid managed care plans, 
CHIP managed care entities, and QHP issuers on the FFEs.
    Throughout this proposed rule, we refer to terms such as 
``patient'', ``consumer'', ``beneficiary'', ``enrollee'', and 
``individual.'' We note that every reader of this proposed rule is a 
patient and has or will receive medical care at some point in their 
life. In this proposed rule, we use the term ``patient'' as an 
inclusive term, but because we have historically referred to patients 
using the other terms noted above in our regulations, we use specific 
terms as applicable in sections of this proposed rule to refer to 
individuals covered under the health care programs that we administer 
and regulate. We also note that when we discuss patients, the term 
includes a patient's personal representative. Per the privacy 
regulations issued under the Health Insurance Portability and 
Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted on August 
21, 1996), as modified, at 45 CFR 164.502(g), a personal 
representative, generally, is someone authorized under state or other 
applicable law to act on behalf of the individual in making health 
care-related decisions (such as a parent, guardian, or person with a 
medical power of attorney).\1\ A patient's personal representative 
could address policies in this proposed rule that require a patient's 
action.
---------------------------------------------------------------------------

    \1\ See OCR guidance regarding personal representatives at 
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.
---------------------------------------------------------------------------

    We also use terms such as ``payer'', ``plan'', and ``issuer'' in 
this proposed rule. Certain portions of this proposed rule are 
applicable to state Medicaid FFS programs, state CHIP FFS programs, 
Medicaid managed care plans (managed care organizations (MCOs)), 
prepaid inpatient health plans (PIHPs), and prepaid ambulatory health 
plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), 
and QHP issuers on the FFEs. We use the term ``payer'' in the preamble 
of this proposed rule as an inclusive term for all these programs and 
(in the case of plans) plan types, but we also use specific terms as 
applicable in sections of this proposed rule.
    We reference ``items and services'' when discussing prior 
authorization. Throughout this proposed rule, when we discuss ``items 
and services,'' this does not include prescription drugs and/or covered 
outpatient drugs. We did not include information about prescription 
drugs and/or covered outpatient drugs in any of the proposals in this 
rule.
    Finally, we use the terms ``provider'' and ``supplier'' too, as 
inclusive terms comprising individuals, organizations, and institutions 
that provide health services, such as clinicians, hospitals, skilled 
nursing facilities, home health agencies, hospice settings, 
laboratories, suppliers of durable medical equipment (such as portable 
X-ray services), community based organizations, etc., as appropriate in 
the context used.

B. Summary of Major Proposals

    To drive interoperability, improve care coordination, reduce burden 
on providers and payers, and empower patients, we are proposing several 
initiatives that would impact state Medicaid FFS programs, Medicaid 
managed care plans, state CHIP FFS programs, CHIP managed care 
entities, and QHP issuers on the FFEs. We are also including several 
Requests for Information (RFIs) to gather information that may support 
future rulemaking or other initiatives. As with the CMS 
Interoperability and Patient Access rulemaking, our proposals provide 
for program requirements to cross-reference technical specifications in 
HHS regulations codified at 45 CFR part 170; in this rule, ONC is 
proposing the adoption of certain specified implementation guides (IGs) 
needed to support the proposed new API policies we are proposing here 
for impacted payers.
    In the CMS Interoperability and Patient Access final rule, we 
required certain payers to implement and maintain standards-based 
Patient Access and Provider Directory application programming 
interfaces (APIs).\2\ The Patient Access API must allow patients to 
easily access their claims and encounter information and a specified 
sub-set of their clinical information as defined in the US Core for 
Data Interoperability (USCDI) version 1 data set through third-party 
applications of their choice (85 FR 25558 through 25559). The Provider 
Directory API must make provider directory information publicly 
available to third-party applications (85 FR 25563 through 25564). 
Additionally, in the same final rule we required certain payers, with 
the approval and at the direction of a patient, to exchange specified 
clinical data (specifically the USCDI version 1 data set) through a 
Payer-to-Payer Data Exchange (85 FR 25568 through 25569).
---------------------------------------------------------------------------

    \2\ Impacted payers under that rule include MA organizations, 
state Medicaid FFS programs, Medicaid managed care plans, state CHIP 
FFS programs, CHIP managed care entities, and QHP issuers on the 
FFEs for the Patient Access API. The Provider Directory API 
requirement applies to all those impacted payers except the QHP 
issuers on the FFEs. The Payer-to-Payer Data Exchange applies to all 
those impacted payers except state Medicaid and CHIP FFS programs.
---------------------------------------------------------------------------

    In this proposed rule, we are proposing to enhance the Patient 
Access API for impacted payers by requiring the use of specific IGs, 
proposed for adoption by ONC on behalf of HHS, and by proposing payers 
include information about pending and active prior authorization 
decisions. In addition, we are proposing to require that impacted 
payers establish, implement, and maintain a process to facilitate 
requesting an attestation from a third-party app developer requesting 
to retrieve data via the Patient Access API that indicates the app 
adheres to certain privacy provisions. We are also proposing to require 
these impacted payers to report certain metrics about patient data 
requests via the Patient Access API quarterly to CMS. In addition, we 
are proposing to require use of a specific IG for the Provider 
Directory API. And, we are proposing to extend the patient-initiated 
Payer-to-Payer Data Exchange requirements to state Medicaid and CHIP 
FFS programs.
    We also propose to enhance and expand the Payer-to-Payer Data 
Exchange, and to require this exchange be conducted via a specified 
Health Level Seven International[supreg] (HL7) Fast Healthcare 
Interoperability Resources[supreg] (FHIR)-based API. We are proposing 
that impacted payers must implement and maintain a Payer-to-Payer API 
to facilitate the exchange of patient information between impacted 
payers, both with the approval and at the direction of the patient and 
when a patient moves from one payer to another as permitted, and in 
accordance with applicable law. Specifically, we are proposing that 
impacted payers implement the Payer-to-Payer API in accordance with the 
specified HL7 FHIR version 4.0.1 IGs, as well as the HL7

[[Page 82589]]

FHIR Bulk Data Access (Flat FHIR) specification, to support exchanging 
patient data including but not limited to: Adjudicated claims and 
encounter data (not including cost information), clinical data as 
defined in the USCDI, and information related to pending and active 
prior authorization decisions.
    To better facilitate the coordination of care across the care 
continuum and in support of a move to value-based care, we are 
proposing to require that impacted payers implement and maintain a 
Provider Access API that, consistent with the APIs finalized in the 
Interoperability and Patient Access final rule (85 FR 25510), utilizes 
HL7 FHIR version 4.0.1 to facilitate the exchange of current patient 
data from payers to providers, including adjudicated claims and 
encounter data (not including cost information), clinical data as 
defined in the USCDI, and information related to pending and active 
prior authorization decisions.
    In an effort to improve patient experience and access to care, we 
are proposing several policies associated with the prior authorization 
process that may ultimately reduce burden on patients, providers, and 
payers. As described in the CMS Interoperability and Patient Access 
proposed rule published on March 4, 2019 (84 FR 7610, 7613), we 
partnered with industry stakeholders to build a FHIR-based web service 
that would enable providers to search documentation and prior 
authorization requirements for Medicare FFS directly from their 
electronic health records (EHRs). This has significant potential to 
decrease the burden associated with providers determining which items 
and services need a prior authorization and what documentation is 
needed to submit the prior authorization request. And, this could 
reduce burden on payers who would receive fewer incomplete prior 
authorization requests and fewer denied and appealed requests simply as 
the result of missing or incorrect documentation. In this second phase 
of interoperability proposals, we are proposing to require impacted 
payers to implement and maintain a similar prior authorization 
Documentation Requirement Lookup Service (DRLS) API. To further 
streamline the process of submitting a prior authorization request, and 
reduce processing burden on both providers and payers, we are also 
proposing to require impacted payers to implement and maintain a FHIR-
based Prior Authorization Support (PAS) API that would have the 
capability to accept and send prior authorization requests and 
decisions, and could be integrated within a provider's workflow, while 
maintaining alignment with, and facilitating the use of, HIPAA 
transaction standards. Provider use of the PAS API would be voluntary 
and payers may maintain their existing methods for processing prior 
authorization requests.
    We are also proposing several policies that would require impacted 
payers, with the exception of QHP issuers on the FFEs, to respond to 
prior authorization requests within certain timeframes. And, we are 
proposing that impacted payers publicly report certain metrics about 
prior authorization processes for transparency.
    Finally, on behalf of HHS, the Office of the National Coordinator 
for Health IT (ONC) is proposing to adopt the implementation 
specifications described in this regulation at 45 CFR 170.215--
Application Programming Interfaces--Standards and Implementation 
Specifications as standards and implementation specifications for 
health care operations. ONC is proposing these implementation 
specifications for adoption by HHS as part of a nationwide health 
information technology infrastructure that supports reducing burden and 
health care costs and improving patient care. By ONC proposing these 
implementation specifications in this way, CMS and ONC are together 
working to ensure a unified approach to advancing standards in HHS that 
adopts all interoperability standards in a consistent manner, in one 
location, for HHS use. Once adopted for HHS use, these specifications 
would facilitate implementation of the proposed API policies in this 
rule if finalized.
    Although Medicare FFS is not directly impacted by this rule, we do 
note that we are targeting to implement these proposed provisions, if 
finalized. In this way, the Medicare implementations would conform to 
the same requirements that apply to the impacted payers under this 
rulemaking, as applicable, so that Medicare FFS beneficiaries would 
also benefit. And, we encourage other payers not directly impacted by 
this rule to join us in moving toward reduced burden and greater 
interoperability.
    We are also including several RFIs to gather information that may 
support future rulemaking or other initiatives. Specifically, we are 
seeking input for potential future rulemaking on whether patients and 
providers should have the ability to selectively control the sharing of 
data in an interoperable landscape. We request comment on whether 
patients and/or providers should be able to dictate which data elements 
from a medical record are shared when and with whom.
    We are additionally seeking comment on how CMS might leverage APIs 
(or other solutions) to facilitate electronic data exchange between and 
with behavioral health care providers, and also community based 
organizations, who have lagged behind other provider types in adoption 
of EHRs.
    We are also seeking comment on how to reduce barriers, and actively 
encourage and enable greater use of electronic prior authorization, 
particularly among providers who could benefit most by being able to 
engage in the prior authorization process directly from their 
workflows. And, we request comment specifically on including an 
Improvement Activity under the Merit-based Incentive Payment System 
(MIPS) to support the use of the Prior Authorization Support (PAS) API.
    We are continually looking for ways to facilitate efficient, 
effective, and secure electronic data exchange to help ensure timely, 
better quality, and highly coordinated care. We believe one way to do 
this is to generally reduce or eliminate the use of facsimile (fax) 
technology across CMS programs, as possible and appropriate. The use of 
fax technology limits the ability of the health care sector to reach 
true interoperability. To work toward this goal and enable electronic 
data exchange, we request information on how CMS can reduce or 
eliminate the use of fax technology across programs where fax 
technology is still in use.
    Finally, we request information on barriers to adopting standards, 
and opportunities to accelerate adoption of standards, related to 
social risk data. We recognize that social risk factors (for example, 
housing instability and food insecurity) influence patient health and 
health care utilization. In addition, we understand that providers in 
value-based arrangements rely on comprehensive, high-quality social 
risk data. Given the importance of these data, we look to understand 
how to better standardize and liberate these data.

II. Provisions of the Proposed Rule

A. Patient Access API

1. Background
    Claims and encounter data, used in conjunction with clinical data, 
can offer a more complete picture of an individual's health care 
experience. In the CMS Interoperability and Patient Access final rule 
(85 FR 25523), we noted examples of how claims data can be used to 
benefit patients, as well as providers. For example, inconsistent

[[Page 82590]]

benefit utilization patterns in an individual's claims data, such as a 
failure to fill a prescription or receive recommended therapies, can 
indicate to a provider or a payer that the individual has had 
difficulty financing a treatment regimen, may require less expensive 
prescription drugs or therapies, or may need additional explanation 
about the severity of their condition. Claims data can also include 
other information that could be used to understand care utilization and 
create opportunities for future services or care coordination or 
management. These are a few examples of how access to these data can 
improve patient care.
    Patients tend to access care from multiple providers throughout 
their lifetime, leading to fractured patient health records in which 
various pieces of an individual's data are locked in disparate, siloed 
data systems. With patient data scattered among these segregated 
systems, it can be challenging for providers to get a clear picture of 
the patient's care history, and patients may forget or be unable to 
provide critical information to their provider during an office visit. 
This lack of comprehensive patient data can impede care coordination 
efforts and access to appropriate care. Through the FHIR-based Patient 
Access API, finalized in the CMS Interoperability and Patient Access 
final rule (85 FR 25558 through 25559), we required certain impacted 
payers to share, among other things, patient claims and encounter data 
and a sub-set of clinical data with the third-party apps of a patient's 
choice so that patients could get their health information in a way 
that was most meaningful and useful to them. We noted that this FHIR-
based API could also allow the patient to facilitate their data moving 
from their payer to their provider, and discussed the benefits of 
sharing patient claims and encounter data with providers, which we 
discuss in more detail in section II.B. of this proposed rule.
2. Enhancing the Patient Access API
    In the CMS Interoperability and Patient Access final rule that 
certain payers, specifically MA organizations, state Medicaid and CHIP 
FFS programs, Medicaid managed care plans, CHIP managed care entities, 
and QHP issuers on the FFEs, must permit third-party applications to 
retrieve, with the approval and at the direction of a current enrollee, 
data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221, 
respectively. We required that the Patient Access API must, at a 
minimum, make available adjudicated claims (including provider 
remittances and enrollee cost-sharing); encounters with capitated 
providers; and clinical data, including laboratory results when 
maintained by the payer. We required that data must be made available 
no later than one (1) business day after a claim is adjudicated or 
encounter data are received. And, that these payers make available 
through the Patient Access API the specified data they maintain with a 
date of service on or after January 1, 2016.
a. Patient Access API Implementation Guides (IGs)
    When we finalized the Patient Access API, we provided a link to a 
CMS website that identified IGs and related reference implementations 
demonstrating use of these IGs available to support implementation (85 
FR 25529): https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. On this website, we provide links and 
information about certain IGs, including:
    <bullet> HL7 Consumer Directed Payer Data Exchange (CARIN IG for 
Blue Button[supreg]) IG: Version STU 1.0.0 to facilitate the exchange 
of the claims and encounter data; \3\
---------------------------------------------------------------------------

    \3\ HL7 International. (n.d.). Consumer Directed Payer Data 
Exchange (CARIN IG for Blue Button[supreg]) Implementation Guide 
Publication (Version) History. Retrieved from http://hl7.org/fhir/us/carin-bb/history.html.
---------------------------------------------------------------------------

    <bullet> HL7 FHIR US Core IG: Version STU 3.1.0 or HL7 FHIR Da 
Vinci Payer Data Exchange (PDex) IG: Version STU 1.0.0 to facilitate 
the exchange of the clinical information as defined in the USCDI; 
<SUP>4 5</SUP> and
---------------------------------------------------------------------------

    \4\ HL7 International. (n.d.). US Core Implementation Guide 
(FHIR IG) Publication (Version) History. Retrieved from http://hl7.org/fhir/us/core/history.html.
    \5\ HL7 International. (n.d.). Da Vinci Payer Data Exchange 
(FHIR IG) Publication (Version) History. Retrieved from http://hl7.org/fhir/us/davinci-pdex/history.html.
---------------------------------------------------------------------------

    <bullet> HL7 FHIR Da Vinci Payer Data Exchange (PDex) US Drug 
Formulary IG: Version STU 1.0.1 to facilitate the exchange of current 
formulary information.\6\
---------------------------------------------------------------------------

    \6\ HL7 International. (n.d.). US Drug Formulary (FHIR IG) 
Publication (Version) History. Retrieved from http://hl7.org/fhir/us/Davinci-drug-formulary/history.html.
---------------------------------------------------------------------------

    On this website, we explain how these IGs can help payers meet the 
requirements of the final rule efficiently and effectively in a way 
that reduces burden on them and ensures patients are getting timely 
access to their health information in a way that they can best make use 
of these data so that they can make informed decisions about their 
health. Although these IGs were available for payers and third-party 
app vendors, we did not require payers to use these IGs in the CMS 
Interoperability and Patient Access final rule. We did not specifically 
propose these IGs for possible finalizing in the final rule as general 
practice had been to include such information in sub-regulatory 
guidance. However, the June 3, 2019 Azar v. Allina Health Services, 139 
S. Ct. 1804 (2019) decision held that under section 1871 of the Act, 
CMS must undertake notice-and-comment rulemaking for any rule, 
requirement, or other statement of policy that establishes or changes a 
``substantive legal standard'' for the Medicare Program. IGs are 
considered a ``substantive legal standard'' per this decision. As such, 
we are now officially proposing to finalize these IGs through notice-
and-comment rulemaking to ensure that all impacted payers are using 
these IGs in order to support true interoperability. If these IGs 
remain optional, there is a chance that the required APIs could be 
built in such a way that creates misalignment between and among payer 
APIs and with third-party apps. For example, where there is optionality 
in the technical build of the API, if that optionality is interpreted 
differently by the payer and a third-party app, that app may be unable 
to access and use the data as needed. By removing this optionality in 
the technical implementation, we better ensure that the APIs can 
support true interoperability and facilitate the desired data exchange. 
Additionally, as these same IGs are proposed for use for other APIs 
proposed in this rule, it would mean that providers (see section II.B. 
of this proposed rule) and payers (see section II.D. of this proposed 
rule) would also not be able to access and use the data as needed if 
misalignment is introduced during implementation. Proposing these IGs 
be required removes the current optionality resulting from only 
suggested use of the IGs, which could be a barrier to interoperability.
    We are proposing to require these specific IGs for the Patient 
Access API, by amending 42 CFR 431.60(c)(3)(iii) for state Medicaid FFS 
programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS programs, and 45 
CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs. These requirements 
would be equally applicable to Medicaid managed care plans and CHIP 
managed care entities based on cross-references to the state Medicaid 
and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed 
care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. If 
finalized, beginning January 1, 2023, impacted payers would be required 
to ensure their APIs are

[[Page 82591]]

conformant with these IGs (for Medicaid managed care plans and CHIP 
managed care entities, by the rating period beginning on or after 
January 1, 2023). The CARIN IG for Blue Button, the PDex IG, and the 
PDex US Drug Formulary IG are proposed for HHS use at 45 CFR 
170.215(c). The US Core IG was adopted by HHS at 45 CFR 170.215(a)(2) 
in the ONC 21st Century Cures Act final rule.
    We recognize that while we have proposed to require compliance with 
the specific IGs noted above, the need for continually evolving IGs 
typically outpaces our ability to amend regulatory text. Therefore, we 
propose to amend 431.60(c)(4), 438.242(b)(5), 457.730(c)(4), 
457.1233(d)(2), and 45 CFR 156.221(c)(4) to provide that, if finalized, 
regulated entities would be permitted to use an updated version of any 
or all IGs proposed for adoption in this rule if use of the updated IG 
does not disrupt an end user's ability to access the data through any 
of the specified APIs discussed in this rule. This would then amend the 
process to allow payers to use new standards as they are available, as 
we finalized in the CMS Interoperability and Patient Access final rule 
to these proposed IGs.
    In making these proposals, we note that these IGs are publicly 
available at no cost to a user (see section IV. of this proposed rule 
for more information). All HL7 FHIR IGs are developed through an 
industry-led, consensus-based public process. HL7 is an American 
National Standards Institute (ANSI)-accredited standards development 
organization. HL7 FHIR standards are unique in their ability to allow 
disparate systems that otherwise represent data differently and speak 
different languages to exchange such information in a standardized way 
that all systems can share and consume via standards-based APIs. HL7 
FHIR IGs are also open source, so any interested party can go to the 
HL7 website and access the IG. Once accessed, all public comments made 
during the balloting process as well as the IG version history are 
available for review. In this way, all stakeholders can fully 
understand the lifecycle of a given IG. Use of IGs developed through 
such a public process would facilitate a transparent and cost-effective 
path to interoperability that ensures the IGs are informed by, and 
approved by, industry leaders looking to use technology to improve 
patient care.
    We request comment on these proposals.
    We finalized in the CMS Interoperability and Patient Access final 
rule that the Patient Access API at 42 CFR 422.119(b)(1)(iii), 
431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) must 
make available clinical data, including laboratory results. We 
specified at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and 
457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i) that such clinical data 
must comply with the content and vocabulary standards at 45 CFR 
170.213, which is the USCDI version 1. Through a cross-reference to 45 
CFR 170.215(a)(2) and (c)(6), at 42 CFR 431.60(c)(3)(iii) for state 
Medicaid FFS programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS 
programs, and 45 CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs, we 
propose that payers would be allowed to conform with either the US Core 
IG or the PDex IG to facilitate making the required USCDI data 
available via the Patient Access API. In section II.E. of this proposed 
rule, ONC, on behalf of HHS, proposes to adopt the PDex IG at 45 CFR 
170.215(c)(6); currently, the US Core IG is adopted at 45 CFR 
170.215(a)(2). These proposed new requirements to conform with either 
IG would be equally applicable to Medicaid managed care plans and CHIP 
managed care entities based on cross-references to the state Medicaid 
and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed 
care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. 
When we first finalized the CMS Interoperability and Patient Access 
final rule and suggested IGs payers could use to implement the APIs, we 
only suggested the US Core IG; however, some payers informed us that 
they preferred to leverage the PDex IG because it offered additional 
resources for payer-specific use cases and was compatible with the US 
Core IG ensuring interoperable data regardless of which IG was used 
(see https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index for additional information). We seek comment on 
the pros and cons of requiring the use of either one of these IGs or if 
only one of the two proposed IGs should ultimately be required and why.
b. Additional Information
    In addition to enhancing the Patient Access API by proposing to 
require that the API be conformant with the specified IGs, we are also 
proposing to require that information about prior authorization 
decisions be made available to patients through the Patient Access API 
in addition to the accessible content finalized in the CMS 
Interoperability and Patient Access final rule (85 FR 25558 through 
25559). The primary goal of the Patient Access API is to give patients 
access to and use of their health information. By ensuring patient 
access to this additional information, we intend to help patients be 
more informed decision makers and true partners in their health care.
    In section II.C. of this proposed rule, we advance a number of 
proposals focused on making the prior authorization process less 
burdensome for payers and providers, and in turn, avoiding care delays 
for patients, which we anticipate would also improve patient outcomes. 
Patients can only truly be informed if they understand all aspects of 
their care. We believe that more transparency would help ensure that 
patients better understand the prior authorization process. By having 
access to their pending and active prior authorization decisions via 
the Patient Access API, a patient could see, for instance, that a prior 
authorization is needed and has been submitted for a particular item or 
service, and might better understand the timeline for the process and 
plan accordingly. If a patient can see the supporting documentation 
shared with their payer they might better understand what is being 
evaluated and even potentially help providers get the best and most 
accurate information to payers to facilitate a successful prior 
authorization request, thus potentially avoiding unnecessary delays in 
care and reducing burden on providers and payers. As a result, we are 
proposing to require impacted payers to provide patients access to 
information about the prior authorization requests made on their behalf 
through the Patient Access API. Specifically, we are proposing at 
431.60(b)(5) for state Medicaid FFS programs, at 438.242(b)(5) for 
Medicaid managed care plans, at 457.730(b)(5) for state CHIP FFS 
programs, at 457.1233(d)(2) for CHIP managed care entities, and at 45 
CFR 156.221(b)(1)(iv) for QHP issuers on the FFEs to require these 
payers to make available to patients information about any pending and 
active prior authorization decisions (and related clinical 
documentation and forms) for items and services via the Patient Access 
API conformant with the HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG 
no later than one (1) business day after a provider initiates a prior 
authorization request or there is a change of status for the prior 
authorization. We believe one (1) business day is appropriate because 
in order for patients to have true transparency into the process, they 
need to see the information timely. As discussed more in section II.C. 
of this proposed rule, we are proposing expedited prior authorization

[[Page 82592]]

timeframes. If this information is provided any later, it would be of 
less value in supporting the process. We propose that this requirement 
begin January 1, 2023 (for Medicaid managed care plans and CHIP managed 
care entities, by the rating period beginning on or after January 1, 
2023).\7\
---------------------------------------------------------------------------

    \7\ HL7 International. (n.d.). Da Vinci Payer Data Exchange 
(FHIR IG) Publication (Version) History. Retrieved from http://hl7.org/fhir/us/davinci-pdex/history.html.
---------------------------------------------------------------------------

    By ``active prior authorization decisions,'' we mean prior 
authorizations that are currently open and being used to facilitate 
current care and are not expired or no longer valid. By ``pending prior 
authorization decisions,'' we mean prior authorizations that are under 
review, either pending submission of documentation from the provider, 
or being evaluated by the payer's medical review staff, or for another 
reason have not yet had a determination made. As discussed in section 
I.B. of this proposed rule, for the purposes of this rule, when we say 
``items and services,'' we are talking about items and services 
excluding prescription drugs and/or covered outpatient drugs. And, 
``status'' of the prior authorization means information about whether 
the prior authorization is approved, denied, or if more information is 
needed to complete the request. We also note that the required 
information and documentation through the API would include the date 
the prior authorization was approved, the date the authorization ends, 
the units and services approved, and those used to date.
    Similarly, as further discussed in section II.B. of this proposed 
rule, we are proposing to require impacted payers to share the same 
information about prior authorization decisions with a patient's 
provider via the Provider Access API upon a provider's request, and, in 
section II.D. of this rule, we are proposing that the same information 
about prior authorization decisions be made available via the Payer-to-
Payer API. In this way, if a patient authorizes their new payer to 
access data from their old payer, this data exchange would include 
information about pending and active prior authorizations, if such 
information is applicable.
    We did not include information about denied or expired prior 
authorization decisions in this proposed requirement because this could 
result in a significant amount of information being shared that may or 
may not be clinically relevant at the moment in time the data are 
exchanged. Pending and active prior authorizations are much more likely 
to be clinically relevant and important for patients, providers, and 
payers to know in order to support treatment and care coordination, as 
well as efficient and effective payer operation that can lead to the 
best possible outcomes for patients. We do note that if a prior 
authorizations is ``pending,'' and the status changes to ``denied,'' 
that information would be shared as a ``change in status.'' As a 
result, a patient would have access to that information via the API per 
this proposal.
    We anticipate that requiring payers to share prior authorization 
information through the Patient Access API, with their patient's 
approval and at their direction, might help patients better understand 
the items and services that require prior authorization, the 
information being considered and specific clinical criteria being 
reviewed to determine the outcome of that prior authorization, and the 
lifecycle of a prior authorization request. This proposed requirement 
could provide patients with an opportunity to better follow the prior 
authorization process and help their provider and payer by producing 
missing documentation or information when needed. The proposed 
requirement might also help to reduce the need for patients to make 
repeated calls to the provider and payer to understand the status of a 
request, or to inquire why there is a delay in care. We therefore 
believe this proposal would help give patients more agency in their 
health care journey and reduce burden on both the providers and the 
payers working through prior authorization requests, allowing them to 
more simply and efficiently administer the prior authorization process. 
As with all information being made available via the Patient Access 
API, we believe industry is in the best position to develop 
applications, or apps, that patients can use to most effectively use 
this information, and we look to innovators in industry to produce apps 
that would help patients understand this information and access it in a 
way that is useful to them.
    In addition, we believe it would be highly valuable for payers to 
share pending and active prior authorization decisions with providers, 
as proposed in section II.B. of this proposed rule, and other payers, 
as proposed in section II.D. of this proposed rule. Currently, 
providers know which prior authorizations they have initiated for a 
patient, but they may not be able to see pending and active prior 
authorizations other providers have outstanding or in place for the 
patient. Having this information could support care coordination and 
more informed decision making. Additionally, if a new payer has 
information from a previous payer about pending and active prior 
authorization decisions, it could support improved care coordination 
and continuity of care, also potentially improving patient outcomes.
    We request comment on this proposal.
    We also request comment for possible future consideration on 
whether or not impacted payers should be required to include 
information about prescription drug and/or covered outpatient drug 
pending and active prior authorization decisions with the other items 
or services proposed via the Patient Access API, the Provider Access 
API, or the Payer-to-Payer API. We did not include information about 
prescription drugs and/or covered outpatient drugs in any of the 
proposals in this rule. However, we are interested in better 
understanding the benefits and challenges of potentially including drug 
information in future rulemaking. For example, what specific 
considerations should we take into account? Are there unique 
considerations related to the role Pharmacy Benefit Managers (PBMs) 
play in this process? Overall, we do think it would be very valuable to 
payers, providers, and patients to have information about a patient's 
prescription drug and/or covered outpatient drug pending and active 
prior authorization decisions, and we would like to better understand 
how to most efficiently and effectively consider including this 
information in these API provisions in the future.
c. Privacy Policy Attestation
    As we discussed in detail throughout the CMS Interoperability and 
Patient Access final rule, one of the most important aspects of 
unleashing patient data is protecting the privacy and security of 
patient health information, especially appreciating that once a 
patient's data is received by a third-party app, it is no longer 
protected under HIPAA. Throughout the final rule, we noted the 
limitations to our authority to directly regulate third-party 
applications. We previously finalized a provision that payers could 
deny Patient Access API access to a third-party app that a patient 
wished to use only if the payer determined that such access would pose 
a risk to the PHI on their system. See 42 CFR 422.119(e) for Medicare 
Advantage organizations, 431.60(e) for state Medicaid FFS programs, 
438.242(b)(5) for Medicaid managed care plans, 457.730(e) for state 
CHIP FFS programs, and 45 CFR 156.221(e) for QHP issuers on the FFEs.

[[Page 82593]]

    In the ONC 21st Century Cures Act final rule (85 FR 25814 through 
25815), ONC noted that it is not information blocking to provide 
information that is factually accurate, objective, unbiased, fair, and 
non-discriminatory to inform a patient about the advantages and 
disadvantages and any associated risks of sharing their health 
information with a third party. We previously finalized provisions at 
42 CFR 422.119(g) for Medicare Advantage organizations, at 431.60(f) 
for state Medicaid FFS programs, at 438.242(b)(5) for Medicaid managed 
care plans, at 457.730(f) for state CHIP FFS programs, at 
457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(g) 
for QHP issuers on the FFEs, requiring that impacted payers share 
educational resources with patients to help them be informed stewards 
of their health information and understand the possible risk of sharing 
their data with third-party apps. In response to comments on the CMS 
Interoperability and Patient Access proposed rule, we noted in the 
final rule (85 FR 25549 through 25550) commenters' beliefs that it is a 
risk when patients do not understand what happens after their data are 
transmitted to a third-party app and are no longer protected by the 
HIPAA Rules. Commenters were specifically concerned about secondary 
uses of data, such as whether or not their data would be sold to an 
unknown third-party for marketing purposes or other uses. In the final 
rule, we noted that a clear, plain language privacy policy is the 
primary way to inform patients about how their information will be 
protected and how it will be used once shared with a third-party app.
    Taking into consideration comments indicating strong public support 
for additional privacy and security measures, we encouraged, but did 
not require, impacted payers to request an attestation from third-party 
app developers indicating the apps have certain privacy provisions 
included in their privacy policy prior to the payer providing the app 
access to the payer's Patient Access API (85 FR 25549 through 25550). 
We are now proposing to make it a requirement that impacted payers 
request a privacy policy attestation from third party app developers 
when their app requests to connect to the payer's Patient Access API.
    We are proposing at 42 CFR 431.60(g) for state Medicaid FFS 
programs, at 42 CFR 438.242(b)(5) for Medicaid managed care plans, at 
42 CFR 457.730(g) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2) 
for CHIP managed care entities, and at 45 CFR 156.221(h) for QHP 
issuers on the FFEs that beginning January 1, 2023 (for Medicaid 
managed care plans and CHIP managed care entities, by the rating period 
beginning on or after January 1, 2023), that impacted payers must 
establish, implement, and maintain a process for requesting an 
attestation from a third-party app developer requesting to retrieve 
data via the Patient Access API that indicates the app adheres to 
certain privacy provisions.
    We recognize that there are many ways that an impacted payer could 
meet this proposed requirement and we do not wish to be overly 
prescriptive regarding how each payer could implement this process. For 
instance, a reliable private industry third party may offer a pathway 
for apps to attest that they have established a minimum set of privacy 
provisions to be in compliance with this proposed requirement. A payer 
could work with such an organization to meet this requirement. Or, an 
impacted payer could establish its own process and procedures to meet 
this proposed requirement. This process could be automated.\8\ We 
believe it is important to allow the market to develop and make 
available innovative solutions, and we do not look to preclude use of 
such options and services. Regardless of this proposed flexibility, 
impacted payers must not discriminate in implementation of this 
proposed requirement, including for the purposes of competitive 
advantage. Whatever method a payer might choose to employ to meet this 
proposed requirement, the method must be applied equitably across all 
apps requesting access to the payer's Patient Access API.
---------------------------------------------------------------------------

    \8\ See Example 1 in ONC's 21st Century Cures at final rule (85 
FR 25816).
---------------------------------------------------------------------------

    At a minimum, we propose that the requested attestation include 
whether:
    <bullet> The app has a privacy policy that is publicly available 
and accessible at all times, including updated versions, and that is 
written in plain language,\9\ and the third-party app developer has 
affirmatively shared this privacy policy with the patient prior to the 
patient authorizing the app to access their health information. To 
``affirmatively share'' means that the patient had to take an action to 
indicate they saw the privacy policy, such as click or check a box or 
boxes.
---------------------------------------------------------------------------

    \9\ Plain Language Action and Information Network. (2011, May). 
Federal Plain Language Guidelines. Retrieved from https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf.
---------------------------------------------------------------------------

    <bullet> The app's privacy policy includes, at a minimum, the 
following important information:
    ++ How a patient's health information may be accessed, exchanged, 
or used by any person or other entity, including whether the patient's 
health information may be shared or sold at any time (including in the 
future);
    ++ A requirement for express consent from a patient before the 
patient's health information is accessed, exchanged, or used, including 
receiving express consent before a patient's health information is 
shared or sold (other than disclosures required by law or disclosures 
necessary in connection with the sale of the application or a similar 
transaction);
    ++ If an app will access any other information from a patient's 
device; and
    ++ How a patient can discontinue app access to their data and what 
the app's policy and process is for disposing of a patient's data once 
the patient has withdrawn consent.
    As we discussed in the CMS Interoperability and Patient Access 
final rule (85 FR 25550), payers can look to industry best practices, 
including the CARIN Alliance's Code of Conduct and the ONC Model 
Privacy Notice for other provisions to include in their attestation 
request that best meet the needs of their patient 
population.<SUP>10 11</SUP> In particular, we believe that explaining 
certain practices around privacy and security in a patient-friendly, 
easy-to-read privacy policy would help inform patients about an app's 
practices for handling their data. It helps patients understand if and 
how the app will protect their health information and how they can be 
an active participant in the protection of their information. Also, as 
explained in the CMS Interoperability and Patient Access final rule (85 
FR 25517), if an app has a written privacy policy and does not follow 
the policies as written, the Federal Trade Commission (FTC) has 
authority to take action.
---------------------------------------------------------------------------

    \10\ See https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.
    \11\ See https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
---------------------------------------------------------------------------

    We propose that impacted payers must request the third-party app 
developer's attestation at the time the third-party app engages the 
API. Under our proposal, the payer must inform the patient within 24 
hours of requesting the attestation from the app developer of the 
status of the attestation--positive, negative, or no response, with a 
clear explanation of what each means. The patient would then have 24 
hours to respond to this information. For

[[Page 82594]]

instance, if the app developer cannot attest that the app meets these 
provisions, or if there is no response to the payer's request for the 
attestation, the payer can inform the patient there may be risk 
associated with sharing their health information with the app. The 
patient may choose to change his or her mind and, at that point, the 
payer would no longer be obligated to release the patient's data via 
the API. However, if the patient does not respond or the patient 
indicates they would like their information made available regardless, 
the payer would be obligated to make the data available via the API. 
The patient would have already authorized the app to access their data, 
as the request from the payer for an attestation could only happen 
after the patient has already authorized the app to access their 
information and provided information about their payer to the app. As a 
result, the patient's original request must be honored. Because the 
patient has already consented to the app receiving their data, it is 
important that this process not overly delay the patient's access to 
their health information via the app of their choice. However, we are 
interested in comments from the public that discuss this process, and 
the payer's obligation to send the data regardless of whether or not 
the patient responds to the payer after notification of the app's 
attestation results, specifically notification if the app does not 
attest to meeting the above privacy provisions.
    We believe it is important for patients to have a clear 
understanding of how their health information may be used by a third 
party, as well as how to stop sharing their health information with a 
third party, if they so choose. We believe the use of this required 
attestation, if finalized as proposed, in combination with patient 
education,\12\ would help patients be as informed as possible. 
Therefore, we propose that the payer must include information about the 
specific content of their privacy policy provisions included in the 
attestation in the required enrollee resources. The enrollee resources 
must also include, at a minimum, the timeline for the attestation 
process, the method for informing enrollees about the app developer's 
attestation response or non-response. The enrollee resources would also 
have to include the enrollee's role and rights in this process, such as 
what actions the enrollee may take when a payer informs the enrollee 
about the status of the attestation, and information about an 
enrollee's right to access their data via a third-party app of their 
choice no matter what the status of the attestation request is. 
Together, this privacy policy attestation framework and the requirement 
for payers to provide patients with educational resources would help 
ensure a more secure data exchange environment and more informed 
patients. And, this would help build patient trust in apps, therefore 
encouraging them to take advantage of this opportunity to access their 
health information through a third-party app.
---------------------------------------------------------------------------

    \12\ In the CMS Interoperability and Patient Access final rule, 
we required impacted payers to make available enrollee resources 
regarding privacy and security on its public website and through 
other appropriate mechanisms through which it ordinarily 
communicates with current and former patients at 42 CFR 422.119(g), 
42 CFR 431.60(f), 42 CFR 457.30(f), and 45 CFR 156.221(g).
---------------------------------------------------------------------------

    Privacy and security remain a critical focus for CMS, and we look 
forward to continuing to work with stakeholders to keep patient privacy 
and data security a top priority. Accordingly, we request comment on 
additional content requirements for the attestation that impacted 
payers must request and additional required enrollee resources that 
impacted payers must make available related to the attestation in this 
proposal. We are particularly interested in hearing feedback on how 
best to engage available industry-led initiatives, as well as the level 
of flexibility payers think is appropriate for defining the process for 
requesting, obtaining, and informing patients about the attestation. 
For instance, would payers prefer that CMS require the specific types 
of communication methods payers can use to inform patients about the 
attestation result, such as via email or text or other electronic 
communication only? How should CMS account for third-party solutions 
that present a list of apps that have already attested? In this 
situation a payer would not need to take action for these apps, but 
would need to have a process in place for apps not included on such a 
list.
    We also request comment on whether the request for the app 
developer to attest to certain privacy provisions should be an 
attestation that all provisions are in place, as it is currently 
proposed, or if the app developer should have to attest to each 
provision independently. We wish to understand the operational 
considerations of an ``all or nothing'' versus ``line-item'' approach 
to the attestation for both the app developers and the payers who would 
have to communicate this information to patients. And, we wish to 
understand the value to patients of the two possible approaches.
    We request comment on the proposal to require impacted payers to 
request a privacy policy attestation from third-party app developers.
d. Patient Access API Metrics
    We are proposing to require impacted payers to report metrics about 
patient use of the Patient Access API to CMS.\13\ We believe this is 
necessary to better understand whether the Patient Access API 
requirement is efficiently and effectively ensuring that patients have 
the required information and are being provided that information in a 
transparent and timely way. We would be better able to evaluate whether 
policy requirements are achieving their stated goals by having access 
to aggregated, patient de-identified data on the use of the Patient 
Access API from each payer. With this information, we expect that we 
would be better able to support payers in making sure patients have 
access to their data and can use their data consistently across payer 
types. As a first step in evaluating the adoption of the Patient Access 
API, we propose to require states operating Medicaid and CHIP FFS 
programs at the state level, Medicaid managed care plans at the plan 
level, CHIP managed care entities at the entity level, and QHP issuers 
on the FFEs at the issuer level to report to CMS. We also seek comment 
on whether we should consider requiring these data be reported to CMS 
at the contract level for those payers that have multiple plans 
administered under a single contract or permit Medicaid managed care 
plans, CHIP managed care entities, or QHP issuers on the FFEs to 
aggregate data for the same plan type to higher levels (such as the 
payer level or all plans of the same type in a program).
---------------------------------------------------------------------------

    \13\ We note that the regulation text for QHP issuers on the 
FFEs in part 156 refers to HHS. In the regulation text for QHPs on 
the FFEs, we propose the reporting to HHS for consistency, noting 
that CMS is a part of HHS.
---------------------------------------------------------------------------

    Specifically, we propose that these payers report quarterly:
    <bullet> The total number of unique patients whose data are 
transferred via the Patient Access API to a patient designated third-
party app; and
    <bullet> The number of unique patients whose data are transferred 
via the Patient Access API to a patient designated third-party app more 
than once.
    Tracking multiple transfers of data would indicate repeat access 
showing patients are either using multiple apps or are allowing apps to 
update their information over the course of the quarter.
    We are proposing these new reporting requirements at 42 CFR 
431.60(h) for state Medicaid FFS programs, at 42 CFR 438.242(b)(5) for 
Medicaid managed

[[Page 82595]]

care plans, at 42 CFR 457.730(h) for state CHIP FFS programs, at 42 CFR 
457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(i) 
for QHP issuers on the FFEs. Under this proposal, we would redesignate 
existing paragraphs as necessary to codify the new proposed text. We do 
not intend to publicly report these data at the state, plan, or issuer 
level at this time, but may reference or publish them at an aggregate, 
de-identified level. We are proposing that by the end of each calendar 
quarter, payers would report the previous quarter's data to CMS 
starting in 2023. In the first quarter the requirement would become 
applicable, payers would be required to report, by the end of the first 
calendar quarter of 2023, data for the fourth calendar quarter of 2022. 
Therefore, beginning March 31, 2023 all impacted payers would need to 
report to CMS the first set of data, which would be the data for 
October, November, and December 2022.
    We request comment on this proposal.
    We are proposing a quarterly data collection. We seek comment on 
the burden associated with quarterly reporting versus annual reporting, 
as well as stakeholder input on the benefits and drawbacks of quarterly 
versus annual reporting. In addition, we request comment on what other 
metrics CMS might require payers to share with CMS, and potentially the 
public, on Patient Access API use, so that CMS can consider this 
information for possible future rulemaking.\14\ In particular, we seek 
comment on the potential burden if payers were required to report the 
names of the unique apps that access the payer's API each quarter or 
each year. We are considering collecting this information to help 
identify the number of apps being developed, potentially review for 
best practices, and evaluate consumer ease of use.
---------------------------------------------------------------------------

    \14\ We note that the regulation text for QHP issuers on the 
FFEs in Part 156 refers to HHS. In the regulation text for QHP 
issuers on the FFEs, we propose the reporting to HHS for 
consistency, noting that CMS is a part of HHS.
---------------------------------------------------------------------------

e. Patient Access API Revisions
    We note that to accommodate the proposed requirements regarding the 
use of the Patient Access API, we are proposing two minor changes to 
the requirements finalized in the CMS Interoperability and Patient 
access final rule.
    First, we are proposing to revise language about the clinical data 
to be made available via the Patient Access API 42 CFR 431.60(b)(3) for 
state Medicaid FFS programs, 42 CFR 457.730(b)(3) for state CHIP FFS 
programs, and 45 CFR 156.221(b)(1)(iii) for QHP issuers on the FFEs. In 
the CMS Interoperability and Patient Access final rule, these specific 
provisions require payers to make available ``clinical data, including 
laboratory results.'' We are proposing to revise these paragraphs to 
read, ``clinical data, as defined in the USCDI version 1.'' Lab results 
are part of the USCDI, and clinical data were operationalized as the 
USCDI version 1 under the ``technical requirements'' where the content 
standard at 45 CFR 170.213 is adopted. Specifically calling out the 
USCDI here would help avoid unnecessary confusion, as it would be 
explicitly noted that the clinical data that must be available through 
the Patient Access API is the USCDI version 1 data elements.
    Second, we are proposing to revise the language previously 
finalized for denial or discontinuation of access to the API to require 
that the payer make such a determination to deny or discontinue access 
to the Patient Access API using objective, verifiable criteria that are 
applied fairly and consistently across all applications and developers 
through which parties seek EHI. We are proposing to change the terms 
``enrollees'' and ``beneficiaries'' to ``parties'' as we are proposing 
to apply this provision to the Provider Access API, Payer-to-Payer API, 
and the prior authorization APIs discussed further in sections II.B., 
II.C., and II.D. of this proposed rule. As other parties may be 
accessing these APIs, such as providers and payers, we believe it is 
more accurate to use the term ``parties'' rather than ``enrollees'' or 
``beneficiaries.'' We are proposing these revisions 431.60(e)(2), 
457.730(e)(2), and 45 CFR 156.221(e)(2).
    We request comment on these proposals.
    Although Medicare FFS is not directly impacted by this rule, we do 
note that we are targeting to implement the provisions, if finalized. 
In this way, the Medicare FFS implementation would conform to the same 
requirements that apply to the impacted payers under this rulemaking, 
so that Medicare FFS beneficiaries would also benefit from this data 
sharing. CMS started to liberate patients' data with Blue Button 2.0, 
which made Parts A, B, and D claims data available via an API to 
Medicare beneficiaries. In an effort to align with the API provisions 
included in the CMS Interoperability and Patient Access final rule, we 
are updating the Blue Button 2.0 API to FHIR R4, and will begin use of 
the CARIN IG for Blue Button.\15\ If the provisions in this rule are 
finalized, we will work to align and enhance Blue Button accordingly, 
as possible.
---------------------------------------------------------------------------

    \15\ https://bluebutton.cms.gov/blog/FHIR-R4-coming-to-the-blue-button-api.html.
---------------------------------------------------------------------------

f. Provider Directory API Implementation Guide
    We are also proposing to require that the Provider Directory API 
finalized in the CMS Interoperability and Patient Access final rule (85 
FR 25563 through 25564) be conformant with a specified IG. The Provider 
Directory API provision requires impacted payers to ensure provider 
directory information availability to third-party applications. 
Specifically, payers need to make, at a minimum, provider names, 
addresses, phone numbers, and specialties available via the public-
facing API. All directory information must be available through the API 
within 30 calendar days of a payer receiving the directory information 
or an update to the directory information. We are proposing a new 
requirement at 42 CFR 431.70(d) for Medicaid state agencies, and at 42 
CFR 457.760(d) for CHIP state agencies that the Provider Directory API 
be conformant with the implementation specification at 45 CFR 
170.215(c)(8) beginning January 1, 2023. Therefore, we are proposing 
that the Provider Directory API be conformant with the HL7 FHIR Da 
Vinci PDex Plan Net IG: Version 1.0.0.\16\ Currently, because QHP 
issuers on the FFEs are already required to make provider directory 
information available in a specified, machine-readable format, the 
Provider Directory API proposal does not include QHP issuers.\17\
---------------------------------------------------------------------------

    \16\ HL7 International. (n.d.). Da Vinci Payer Data Exchange 
PlanNet (FHIR IG) Publication (Version) History. Retrieved from 
http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.
    \17\ Available at http://cmsgov.github.io/QHP-provider-formulary-APIs/developer/index.html.
---------------------------------------------------------------------------

    Currently, because of the existing cross-references at 42 CFR 
438.242(b)(6) (cross referencing the Medicaid FFS Provider Directory 
API requirement at 42 CFR 431.70) and 42 CFR 457.1233(d)(3) (cross 
referencing the CHIP FFS Provider Directory API requirement at 42 CFR 
457.760), Medicaid managed care plans and CHP managed care entities 
must also implement and maintain Provider Directory APIs. We are 
proposing here that Medicaid managed care plans and CHIP managed care 
entities must comply with the implementation specification at 45 CFR 
170.215(c)(8) (that is, the HL7 FHIR Da Vinci PDex Plan Net IG: Version 
1.0.0) by the rating period that begins on or after January 1, 2023. 
Because of the different compliance deadline for the managed care 
programs, we are also proposing

[[Page 82596]]

additional revisions at 42 CFR 438.242(b)(6) and 42 CFR 457.1233(d)(3). 
We request comment on these proposals.
3. Statutory Authorities for the Patient Access and Provider Directory 
API Proposals
a. Medicaid and CHIP
    For the reasons discussed below, our proposed requirements in this 
section for Medicaid managed care plans and Medicaid state agencies 
fall generally under our authority in section 1902(a)(4) of the Act, 
which requires that a state Medicaid plan provide such methods of 
administration as are found by the Secretary to be necessary for the 
proper and efficient operation of the state Medicaid plan. The 
proposals in this section are also authorized under section 1902(a)(8) 
of the Act, which requires states to ensure that Medicaid services are 
furnished with reasonable promptness to all eligible individuals. 
Additionally, they are authorized by section 1902(a)(19) of the Act, 
which requires states to ensure that care and services are provided in 
a manner consistent with simplicity of administration and the best 
interests of the recipients.
    We are proposing to require that state Medicaid agencies and 
Medicaid managed care plans implement the Patient Access and Provider 
Directory APIs finalized in the CMS Interoperability and Patient Access 
final rule conformant with specific IGs, as discussed in section 
II.A.2. above in this proposed rule. In sections II.B.3., II.B.5., 
II.C.3., II.C.4., and II.D.2. of this proposed rule, we are also 
proposing that these payers be required to implement new APIs, 
specifically the Provider Access APIs, the DRLS API, the PAS API, and 
the Payer-to-Payer API, in a manner that is conformant with specific 
IGs. Use of these APIs would support more efficient administration of 
the state plan, because, as discussed in more detail below, CMS expects 
that the APIs would improve the flow of information relevant to the 
provision of Medicaid services among beneficiaries, providers, and the 
state Medicaid program and its contracted managed care plans. Improving 
the flow of that information could also help states to ensure that 
Medicaid services are provided with reasonable promptness and in a 
manner consistent with simplicity of administration and the best 
interests of the beneficiaries, as discussed in the CMS 
Interoperability and Patient Access final rule related to the Patient 
Access and Provider Directory APIs and the Payer-to-Payer data exchange 
(for Medicaid managed care) (see 85 FR 25526). The state is also 
required to make provider directory data for the FFS program available 
per section 1902(a)(83) of the Act; Medicaid managed care plans are 
similarly required to make a provider directory available under 42 CFR 
438.10(g). Making provider directory information available via a 
standards-based API, and updating this information through this API, 
again adds efficiencies to administration of this process and our 
proposal here is intended to further standardize implementation of the 
Provider Directory API. The DRLS API and the PAS API both have the 
potential to significantly improve the efficiency and response time for 
Medicaid prior authorization processes, making them more efficient in 
many ways, including limiting the number of denials and appeals or even 
eliminating requests for additional documentation. In all of these 
ways, the APIs are expected to make administration of the Medicaid 
program more efficient.
    Proposing to require these APIs be conformant with specific IGs is 
expected to simplify the process of implementing and maintaining each 
API, including preparing the information that must be shared via each 
specific API, and ensuring data are provided as quickly as possible to 
beneficiaries (in the case of the Patient Access API and the Provider 
Directory API), to providers (in the case of the Provider Access API), 
and to other payers (in the case of the Payer-to-Payer API). 
Implementing these APIs across payers using the same IGs, as would be 
the case via the Payer-to-Payer API, would ensure these APIs are 
functioning as intended, and are able to perform the data exchanges 
specified in a way that is interoperable and of value to both the 
sender and receiver of the information, and thus could help to ensure 
the APIs would improve the efficient operation of the state Medicaid 
program, consistent with section 1902(a)(4) of the Act. These IGs, by 
further ensuring that each API is built and implemented in a consistent 
and standardized way, transmitting data that are mapped and 
standardized as expected by both the sending and receiving parties, 
would further increase the efficiency of the APIs. It would help ensure 
that the data sent and received are usable and valuable to the end 
user, whether that is the patient looking to have timely access to 
their records or the provider or payer looking to ensure efficient care 
and increased care coordination to support the timely administration of 
services. As a result, proposing to adopt these IGs would further 
contribute to proper and efficient operation of the state plan, and is 
expected to facilitate data exchange in a way that is consistent with 
simplicity of administration of the program and the best interest of 
the participants. Requiring that the APIs be conformant with these IGs 
is therefore expected to make the APIs more effective in terms of 
improving the efficient operation of the Medicaid state plan and 
Medicaid managed care plans. If the APIs operate more efficiently, 
that, in turn, may help to ensure that beneficiaries and enrollees 
receive care with reasonable promptness and in a manner consistent with 
simplicity of administration and beneficiaries' and enrollees' best 
interests.
    The proposed requirement to make available information about 
pending and active prior authorization decisions and associated 
documentation through the Patient Access API is expected to allow 
beneficiaries to more easily obtain the status of prior authorization 
requests submitted on their behalf, so that they could ultimately use 
that information to make more informed decisions about their health 
care, improve the efficiency of accessing and scheduling services, and 
if needed, provide missing information needed by the state to reach a 
decision. Receiving missing information more quickly could allow states 
to respond more promptly to prior authorization requests, thus 
improving providers' and beneficiaries' experience with the process by 
facilitating more timely and successful prior authorizations, which 
would help states fulfill their obligations to provide care and 
services in a manner consistent with simplicity of administration and 
the best interests of the recipients, and to furnish services with 
reasonable promptness to all eligible individuals. Improving the prior 
authorization process could also help states improve the efficient 
operation of the state plan. In these ways, these proposals are 
consistent with our authorities under section 1902(a)(4), (8), and (19) 
of the Act.
    We also propose that payers would be required to ask app developers 
to attest to whether they have certain privacy policy provisions in 
place prior to making a beneficiary's or enrollee's data available via 
the Patient Access API. Proposing to require state Medicaid agencies 
and Medicaid managed care plans to implement a privacy policy 
attestation process is expected to help ensure beneficiaries be 
informed about how their information would be protected or not 
protected when it is provided by the state Medicaid agency

[[Page 82597]]

or Medicaid managed care plan to a third-party app at their request. 
This attestation process is expected to help a beneficiary or enrollee 
better understand how their data would be used, and what they can do to 
further control how and when their data is shared by other entities 
associated with the app. Taking additional steps to protect patient 
privacy and security would help to ensure that the Medicaid program, 
whether through FFS or managed care, is providing Medicaid-covered care 
and services in a manner consistent with the best interests of 
beneficiaries and enrollees. In this way, it is within our authority 
under section 1902(a)(19) of the Act to propose to require this privacy 
policy attestation.
    We are also proposing to require state Medicaid agencies and 
Medicaid managed care plans to report Patient Access API metrics to CMS 
quarterly. We believe that having these metrics would support CMS' 
oversight, evaluation, and administration of the Medicaid program, as 
it would allow us to evaluate beneficiary and enrollee access to the 
Patient Access API. Use of the API could indicate that the policy is 
supporting program efficiencies and ensuring access to information in a 
timely and efficient way and in the best interest of beneficiaries, as 
intended. Section 1902(a)(6) of the Act authorizes CMS to request 
reports in such form and containing such information as the Secretary 
from time to time may require. These metrics would serve as a report to 
evaluate the implementation and execution of the Patient Access API.
    For CHIP, we propose these requirements under the authority in 
section 2101(a) of the Act, which sets forth that the purpose of title 
XXI is to provide funds to states to provide child health assistance to 
uninsured, low-income children in an effective and efficient manner 
that is coordinated with other sources of health benefits coverage. 
This provision provides us with authority to adopt these requirements 
for CHIP because the proposed requirements increase access to patient 
data, which can improve the efficacy of CHIP programs, allow for more 
efficient communication and administration of services, and promote 
coordination across different sources of health benefits coverage.
    As discussed above for Medicaid programs, requiring that the APIs 
finalized in the CMS Interoperability and Patient Access final rule, as 
well as those APIs proposed in this rule, be conformant with specific 
IGs would support program efficiency. By ensuring that these APIs are 
implemented in a consistent, standardized way, use of the IGs is 
expected to help support patient, provider, and payer access to data 
they can best use to make informed decisions, support care 
coordination, and for the state, support efficient operations.
    We believe that requiring CHIP agencies, as well CHIP managed care 
entities, to make CHIP enrollees' prior authorization data and other 
standardized data available through standards-based APIs would 
ultimately lead to these enrollees accessing that information in a 
convenient, timely, and portable way. This improved access would help 
to ensure that services are effectively and efficiently administered in 
the best interests of beneficiaries, consistent with the requirements 
in section 2101(a). We believe making patient data available in this 
format would result in better health outcomes and patient satisfaction 
and improve the cost effectiveness of the entire health care system, 
including CHIP. Allowing beneficiaries or enrollees easy and simple 
access to certain standardized data can also facilitate their ability 
to detect and report fraud, waste, and abuse--a critical component of 
an effective program.
    These proposals align with section 2101(a) in that they also 
improve the efficiency of CHIP programs. For example, adding 
information about pending and active prior authorization decisions to 
the Patient Access API allows beneficiaries to easily obtain the status 
of prior authorization requests made on their behalf. This allows 
patients to make scheduling decisions, and provide any missing 
information needed by a payer to reach a decision, which makes the 
prior authorization process more efficient, ultimately streamlining the 
prior authorization process.
    Additionally, proposing to require the CHIP programs (FFS and 
managed care) to put a process in place to ask third-party app 
developers to attest to whether they have certain privacy provisions in 
place would allow CHIP to provide services in a way that is in the 
beneficiary's best interest by providing additional information to them 
about how they can best protect the privacy and security of their 
health information.
    Finally, proposing to require state CHIP agencies and CHIP managed 
care plans report Patient Access API metrics to CMS quarterly would 
help states and CMS understand how this API can be used to continuously 
improve the effectiveness and efficiency of state CHIP operations by 
providing information about its use, which is an indication of the 
effectiveness of the API. The more we understand about the use of the 
Patient Access API, the better we can assess that the API is leading to 
improved operational efficiencies and providing information to 
beneficiaries in a way that supports their best interests.
    Regarding the requiring the use of the PlanNet IG for the Provider 
Directory API under CHIP, we note that 42 CFR 457.1207 requires CHIP 
managed care entities to comply with the provider directory (and other 
information disclosure) requirements that apply to Medicaid managed 
care plans under 42 CFR 438.10.
b. QHP Issuers on the FFEs
    For QHP issuers on the FFEs, we propose these new requirements 
under our authority in section 1311(e)(1)(B) of the Affordable Care 
Act, which affords the Exchanges the discretion to certify QHPs if the 
Exchange determines that making available such health plans through the 
Exchange is in the interests of qualified individuals in the state in 
which the Exchange operates.
    Existing and emerging technologies provide a path to make 
information and resources for health care and health care management 
universal, integrated, equitable, more accessible, and personally 
relevant. Requiring the APIs discussed in this rule, including the 
Patient Access API, the Provider Access API, the DRLS API, the PAS API, 
and the Payer-to-Payer API be conformant with specific IGs would permit 
QHP issuers on the FFEs to meet the proposed requirements of this 
rulemaking efficiently by simplifying the process of implementing and 
maintaining each API, including preparing the needed information to be 
shared via each specific API, and ensuring data, and ultimately 
services, are provided to enrollees as quickly as possible. These IGs, 
by further ensuring that each API is built and implemented in a 
consistent and standardized way, transmitting data that are mapped and 
standardized as expected by both the sending and receiving parties, 
would further increase the efficiency of the APIs. It would help ensure 
that the data sent and received are usable and valuable to the end 
user, whether that is the patient looking to have timely access to 
their records or the provider or payer looking to ensure efficient care 
and increased care coordination to support the timely administration of 
services. This could add significant operational efficiencies for QHP 
issuers on the FFEs. This would help each proposed policy be most 
effective, the API solutions to be truly interoperable, and for QHP 
issuers on the FFEs to meet

[[Page 82598]]

these requirements in a way that ensures enrollees' needs are best met.
    We believe generally that certifying only health plans that take 
steps to make enrollees' pending and active prior authorization 
decisions and related clinical documentation available through 
interoperable technology would ultimately lead to these enrollees 
having access to that information in a convenient, timely, and portable 
way, which is in the best interests of enrollees. Having simple and 
easy access, without special effort, to their health information also 
facilitates enrollees' ability to detect and report fraud, waste, and 
abuse--a critical component of an effective program. Adding information 
about pending and active prior authorization decisions to the Patient 
Access API would allow enrollees to easily obtain the status of prior 
authorization requests submitted on their behalf and use that 
information effectively to make more informed decisions about their 
health care, improve the efficiency of accessing and scheduling 
services, and if needed, provide missing information needed by the 
issuer to reach a decision. This could allow QHP issuers on the FFEs to 
more promptly address prior authorization requests, streamlining this 
process, and thus simplifying prior authorization processes, and 
enrollees' experience with the process, by facilitating timelier and 
potentially more successful initial prior authorization requests. We 
encourage State-based Exchanges (SBEs) to consider whether a similar 
requirement should be applicable to QHP issuers.
    Proposing to require QHP issuers on the FFEs to implement a privacy 
policy attestation process would ensure enrollees are informed about 
how their information would be protected and how it would be used, and 
would add an additional opportunity for issuers to promote the privacy 
and security of their enrollees' information. This again ensures 
enrollees' needs are best met.
    Finally, proposing to require QHP issuers on the FFEs report 
Patient Access API metrics to CMS quarterly would help CMS understand 
the impact this API is having on enrollees and would inform how CMS 
could either enhance the policy or improve access or use through such 
things as additional consumer education. These data could help CMS 
understand how best to leverage this API, and consumer access to it, to 
ensure this requirement is being met efficiently and adding value to 
CMS operations, including leading to the efficiencies intended.

B. Provider Access APIs

1. Background
    As mentioned in the CMS Interoperability and Patient Access final 
rule, the Patient Access API (85 FR 25558 through 25559) could allow 
the patient to facilitate their data being accessible to their 
provider. A patient could use their mobile phone during a visit with 
their provider to show the provider their data to help inform their 
discussion. In the CMS Interoperability and Patient Access final rule 
(85 FR 25555), we discussed the benefits of sharing patient health 
information with providers. We also encouraged payers to consider an 
API solution to allow providers to access patient health information 
through payer APIs, such as for treatment purposes, and received 
comments in support of this type of data exchange. We sought comment 
for possible consideration in future rulemaking on the feasibility of 
providers being able to request information on a shared patient 
population using a standards-based API. Among the comments we received, 
some comments stated that allowing providers to receive data directly 
from payers would allow the FHIR-based data exchange to be 
significantly more valuable for patients, providers, and payers, as the 
data would be available at the moment of care when providers need it 
most, affording patients the maximum benefit from the data exchange. We 
also received some comments that having providers receive information 
about prior authorization decisions would reduce burden on providers 
and their staff (85 FR 25541).
    While the use of the Patient Access API is a significant first step 
in facilitating sharing individual patient health information, we 
believe the benefits of making patient data available via a standards-
based API would be greatly enhanced if providers had direct access to 
their patients' data. As discussed later in this section we are now 
working to get providers direct access to data through certain CMS 
programs, and based on this experience to date, we believe it would 
benefit providers if they were allowed ongoing access to information 
about their patients, particularly if they could access that 
information directly from clinical workflows in their EHRs or other 
health IT systems. We further believe provider access to patient 
information would improve both the provider and patient experience. 
Ensuring that providers have access to comprehensive patient data at 
the point of care could potentially reduce the burden on patients to 
recall certain information during an appointment, and might provide an 
additional way for both the provider and patient to confirm that the 
patient's recollection of a prior care episode is accurate. If 
providers could access information about the care their patient 
received outside of the provider's care network prior to a patient's 
visit, the information might improve clinical efficiency and provide a 
more comprehensive understanding of the patient's health, thus 
potentially saving time during appointments and potentially improving 
the quality of care delivered.
    While we have no data, we anticipate that putting patient data in 
the hands of the provider at the point of care would reduce provider 
burden and improve patient care. Providers would be empowered to view 
their patient's claims history and available clinical data, including 
the identity of other providers who are working, or have worked, with 
the patient. This proposal might also improve a patient's care 
experience as it may lessen the burden on patients not only in relation 
to recall, as noted above, but it may spare patients from having to 
fill out the same medical history forms repeatedly. Used wisely, the 
data available to providers under these proposals might give patients 
and providers more time to focus on the patient's needs. In addition, 
if a patient's entire care team has access to the same information, 
this may help improve the efficiency and effectiveness of patient care.
2. HIPAA Disclosures and Transaction Standards
    As reflected in our proposals below, providers would be allowed to 
request the claims and encounter data for patients to whom they provide 
services for treatment purposes. The HIPAA Privacy Rule, at 45 CFR 
164.502, generally permits a covered entity to use or disclose 
protected health information (PHI) for treatment, payment, or health 
care operations without individual authorization. Covered entities must 
reasonably limit their disclosures of, and requests for, PHI for 
payment and health care operations to the minimum necessary to 
accomplish the intended purpose of the use, disclosure, or request (45 
CFR 164.502(b)). However, covered entities are not required to apply 
the minimum necessary standard to disclosures to or requests by a 
health care provider for treatment purposes (45 CFR 
164.502(b)(2)(i)).\18\
---------------------------------------------------------------------------

    \18\ See, Office for Civil Rights. (2013, July 26). Uses and 
Disclosures for Treatment, Payment, and Health Care Operations (45 
CFR 164.506). Retrieved from https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html.

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

[[Page 82599]]

    HIPAA also identifies specific transactions for which the Secretary 
must adopt standards and specifies a process for updating those 
standards. A HIPAA transaction is an electronic exchange of information 
between two parties to carry out financial or administrative activities 
related to health care (for example, when a health care provider sends 
a claim to a health plan to request payment for medical services). 
Under HIPAA, HHS has adopted multiple standards for transactions 
involving the exchange of electronic health care data, including:
    <bullet> Health care claims or equivalent encounter information.
    <bullet> Health care electronic funds transfers (EFT) and 
remittance advice.
    <bullet> Health care claim status.
    <bullet> Eligibility for a health plan.
    <bullet> Enrollment and disenrollment in a health plan.
    <bullet> Referrals certification and authorization.
    <bullet> Coordination of benefits.
    <bullet> Health plan premium payments.
    <bullet> Medicaid pharmacy subrogation.
    We note that the HHS Secretary has not adopted an applicable HIPAA 
transaction standard for communications of claims or encounter data 
that are not sent for the purpose of requesting payment. Although our 
proposals detailed below would facilitate payers sharing claims data 
with providers, this would not be done for the purpose of obtaining (or 
making) payment (as described under 45 CFR 162.1101(a)). We are not 
proposing to report health care encounters in connection with a 
reimbursement contract that is based on a mechanism other than charges 
or reimbursement rates for specific services (as described under 45 CFR 
162.1101(b)). Therefore, the use of a HIPAA transaction standard is not 
required for our proposals in this section, or for our proposals 
regarding data sharing in sections II.C. and II.D. of this proposed 
rule, because the Secretary has not adopted a HIPAA transaction 
applicable to communications of claims or encounter information for a 
purpose other than requesting payment.\19\
---------------------------------------------------------------------------

    \19\ See 45 CFR 162.923(a).
---------------------------------------------------------------------------

    In this section, we propose to require that certain payers 
implement a standards-based Provider Access API that makes patient data 
available to providers both on an individual patient basis and for one 
or more patients at once using a bulk specification, as permitted by 
applicable law, so that providers could use data on their patients for 
such purposes as facilitating treatment and ensuring their patients 
receive better, more coordinated care. As noted, the HIPAA Privacy Rule 
generally permits HIPAA covered entities to use and disclose PHI for 
these purposes without need of an individual's authorization.\20\ 
However, under other federal, state, local, or tribal laws (for 
example, the ``part 2'' regulations addressing substance use disorder 
data at 42 CFR part 2), payers and providers may need to obtain some 
specified form of patient consent to request or disclose behavioral 
health, certain substance use disorder treatment, or other sensitive 
health-related information, or they may have to use specified 
transactions to carry out certain defined data transfers between 
certain parties for specific purposes. We note these proposals do not 
in any way alter a payer's or a provider's obligations under all 
existing federal, state, local, or tribal laws.
---------------------------------------------------------------------------

    \20\ See 45 CFR 164.506.
---------------------------------------------------------------------------

3. Proposed Requirements for Payers: Provider Access API for Individual 
Patient Information Access
    In the CMS Interoperability and Patient Access final rule (85 FR 
25558 through 25559), we required impacted payers to make certain 
health information available to third-party apps with the approval and 
at the direction of a patient though the Patient Access API for patient 
use. We believe there would be value to providers having access to the 
same patient data through a FHIR-based API that allows the provider to 
request data for a single patient as needed. And, we recognize that the 
impacted payers under this proposed rule will have largely prepared the 
necessary infrastructure and implemented the FHIR standards to support 
the Patient Access API finalized in the CMS Interoperability and 
Patient Access final rule (85 FR 25558 through 25559) by January 1, 
2021 (for QHP issuers on the FFEs, for plan years beginning on or after 
January 1, 2021). As a result, we are now proposing to require impacted 
payers to implement a Provider Access API.
    Both this proposed Provider Access API and the Patient Access API 
would facilitate the FHIR-based exchange of claims and encounter data, 
as well as the same set of clinical data as defined in the USCDI 
version 1, where such clinical data are maintained by the payer, and 
formulary data or preferred drug list data, where applicable. Both APIs 
also require the sharing of pending and active prior authorization 
decisions (and related clinical documentation and forms) for items and 
services. One difference is that the Provider Access API would not 
include remittances and beneficiary cost-sharing information. Another 
key difference is that in the case of the Provider Access API 
proposals, the provider, not the patient, requests and ultimately 
receives the patient's information, and would typically make such a 
request for treatment or care coordination purposes. Where a patient 
would receive this data via a third-party app for use on a mobile 
device, in the case of the Provider Access API, the provider would 
receive the data directly from the payer and incorporate it into their 
EHR or other practice management system.
    Through a proposed cross-reference to the Patient Access API 
requirements, the Provider Access API also requires adherence to the 
same technical standards, API documentation requirements, and 
discontinuation and denial of access requirements. For a complete 
discussion of these requirements, we refer readers to the CMS 
Interoperability and Patient Access final rule (85 FR 25526 through 
25550) and to section II.A. of this proposed rule.
    We are proposing two approaches to the Provider Access API. First, 
we are proposing a Provider Access API that allows providers to have 
access to an individual patient's information. Second, we are proposing 
that the Provider Access API allow access to multiple patients' 
information at the same time; this is discussed in section II.B.5. of 
this proposed rule. The individual request approach may be better 
suited for situations such as, but not limited to, when the provider 
needs ``real-time'' access to a patient's data prior to or even during 
a patient visit or for small practices with limited server bandwidth. 
In these situations, providers may wish to gain access to patient data 
through an API that yields the data through an individual patient 
request.
    To support this individual patient use case, we are proposing to 
require state Medicaid and CHIP FFS programs at 42 CFR 431.61(a)(1)(i) 
and 457.731(a)(1)(i) respectively; and QHP issuers on the FFEs at 45 
CFR 156.222(a)(1)(i), to implement and maintain a Provider Access API 
conformant with the requirements at 45 CFR 170.215, as detailed in 
section II.A.2. of this proposed rule for the Patient Access API. This 
proposed Provider Access API would leverage the same IGs in the same 
way as proposed for the Patient Access API. These requirements would be 
equally applicable to Medicaid managed care plans and CHIP managed care

[[Page 82600]]

entities based on cross-references to the state Medicaid and CHIP FFS 
requirements at 42 CFR 438.242(b)(7) for Medicaid managed care plans 
other than Non-Emergency Medical Transportation (NEMT) PAHPs \21\ and 
42 CFR 457.1233(d)(4) for CHIP managed care entities. We propose that 
payers implement this Provider Access API individual patient data 
approach for data maintained by the payer with a date of service on or 
after January 1, 2016 by January 1, 2023 (for Medicaid managed care 
plans and CHIP managed care entities, by the rating period beginning on 
or after January 1, 2023). We note that providers may or may not have a 
provider agreement with or be in- or out-of-network with the payer that 
is providing the information, as we believe providers should have 
access to their patients' data regardless of their relationship with 
the payer. Therefore, our proposal does not permit a payer to deny use 
of or access to the Provider Access API based on whether the provider 
using the API is under contract with the payer. A provider that is not 
in network would need to demonstrate to the patient's payer that they 
do have a care relationship with the patient.
---------------------------------------------------------------------------

    \21\ See 42 CFR 438.9(b)(7).
---------------------------------------------------------------------------

    In the context of Medicaid managed care, we are proposing that NEMT 
PAHPs, as defined at 42 CFR 438.9(a), would not be subject to the 
requirement to establish a Provider Access API. MCOs, PIHPs, and non-
NEMT PAHPs are subject to this proposed rule. We believe that the 
unique nature and limited scope of the services provided by NEMT PAHPs 
is not consistent with the proposed purposes of the Provider Access API 
proposed at 42 CFR 431.61(a). Specifically, we do not believe that 
providers have any routine need for NEMT data nor that having NEMT 
PAHPs implement and maintain a Provider Access API would help achieve 
the goals of the proposal, namely to help avoid patients needing to 
recall prior services, ensure that providers are able to spend time 
with patients focusing on care versus collecting redundant information, 
or improve patient care through enhanced care coordination. However, we 
include NEMT PAHPs in the scope of some of our other requirements that 
apply to all other Medicaid managed care plans under proposed 42 CFR 
438.242(b)(5) through (8). Currently, NEMT PAHPs are exempt from 
compliance with requirements in 42 CFR part 438 unless the provision is 
listed in Sec.  438.9(b), which does currently apply 42 CFR 438.242 to 
NEMT PAHPs. We are therefore proposing to revise 42 CFR 438.9(b)(7) to 
require compliance with the requirements in 42 CFR 438.242(b)(5) 
through (8) other than the reference to 42 CFR 431.61(a) and (c) at 
438.242(b)(7).
    We request public comment on this proposal for impacted payers to 
implement a Provider Access API for individual patient information 
access.
4. The MyHealthEData Initiative Experience With Sharing Patient Data 
With Providers
    Understanding the benefits of provider access to patient 
information discussed above, as part of the MyHealthEData initiative, 
we launched the Beneficiary Claims Data API (BCDA), which enables 
Accountable Care Organizations (ACOs) participating in the Shared 
Savings Program to retrieve Medicare Part A, Part B, and Part D claims 
data for their prospectively assigned or assignable beneficiaries.\22\ 
To better facilitate the coordination of care across the care continuum 
and in support of a move to value-based care, the BCDA utilizes the HL7 
FHIR Bulk Data Access (Flat FHIR) specification to allow us to respond 
to requests for large amounts of patient-level Medicare FFS claims data 
on behalf of ACO participating practices.\23\ Using a bulk data 
exchange reduces burden for ACOs and CMS, and adds a number of 
efficiencies for ACOs and their participating practices by facilitating 
the exchange of data for many patients at once. It also gets data to 
providers when and where they need it most.
---------------------------------------------------------------------------

    \22\ Centers for Medicare and Medicaid Services. (n.d.). 
Beneficiary Claims Data API. Retrieved from https://bcda.cms.gov/.
    \23\ HL 7 International. (n.d.). FHIR Bulk Data Access (Flat 
FHIR). Retrieved from https://hl7.org/fhir/uv/bulkdata/history.html.
---------------------------------------------------------------------------

    In addition, in July 2019, we announced a pilot program called 
``Data at the Point of Care'' (DPC) \24\ in support of our mission to 
transform the health care system. Also part of the MyHealthEData 
initiative, DPC-- utilizing the HL7 FHIR Bulk Data Access (Flat FHIR) 
specification--allows health care providers to access synthetic 
Medicare FFS claims data, either by integrating with their EHR or with 
the health IT system they utilize to support care, without requiring 
access to other applications. Currently, approximately 1,000 
organizations representing over 130,000 providers have engaged with the 
synthetic data in the pilot. Participants include a diversity of 
practice types including primary care practices, single or small office 
specialist practices, academic medical centers, non- and for-profit 
health systems, and dialysis centers. The provider organization is the 
official demonstration participant, but each organization is taking 
part with its EHR vendor.
---------------------------------------------------------------------------

    \24\ Data at the Point of Care. (n.d.). Retrieved from https://dpc.cms.gov/.
---------------------------------------------------------------------------

    Both BCDA and DPC have started to demonstrate the value of 
exchanging data on multiple patients at once via FHIR. The HL7 FHIR 
Bulk Data Access (Flat FHIR) specification can reduce the number of API 
requests and support a secure connection for third-party application 
access to specified data stored in EHRs and data warehouse 
environments.\25\ CMS has developed our projects leveraging the HL7 
FHIR Bulk Data Access (Flat FHIR) specification using open source 
programming. The documentation, specifications, and reference 
implementations are available at https://github.com/CMSgov/bcda-app and 
https://github.com/CMSgov/dpc-app.
---------------------------------------------------------------------------

    \25\ Office of the National Coordinator, Computational Health 
Informatics Program, & Boston Children's Hospital. (2017, December 
15). The Intersection of Technology and Policy: EHR Population Level 
Data Exports to Support Population Health and Value. Retrieved from 
https://smarthealthit.org/an-app-platform-for-healthcare/meetings/bulk-data-export-meeting-and-report/.
---------------------------------------------------------------------------

    When leveraged, the HL7 FHIR Bulk Data Access (Flat FHIR) 
specification permits the efficient retrieval of data on entire patient 
populations or defined cohorts of patients via the bulk transfer of 
data using standard data exchanges. Providers who are responsible for 
managing the health of multiple patients may need to access large 
volumes of data. Exchanging patient data for large numbers of patients 
may require large exports, which would usually require multiple 
requests and a number of resources to manage the process that can 
overburden organizations and be time consuming and costly. Even using 
more efficient methods of data exchange like secure APIs can present 
challenges for a large number of patient records. For example, for a 
health system with thousands of Medicaid patients, accessing those 
patients' claims data one by one would require thousands of API 
calls.\26\ We believe that providing a streamlined means of accessing 
this information via FHIR-based APIs utilizing the HL7 FHIR Bulk Data 
Access (Flat FHIR) specification greatly improves providers' ability to 
deliver quality, value-based care, and ultimately better manage patient 
health.
---------------------------------------------------------------------------

    \26\ A `call' is an interaction with a server using an API to 
deliver a request and receive a response in return.

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

[[Page 82601]]

5. Proposed Requirements for Payers: Bulk Data Provider Access API
    We believe that the benefits of data sharing would be greatly 
enhanced if other payers were sharing health information about their 
patients with health care providers for multiple patients at once, as 
CMS is now beginning to do under BCDA and as we are also further 
testing through the DPC pilot, for instance. As a result, we are 
proposing a second approach to require impacted payers to implement 
payer-to-provider data sharing using the HL7 FHIR Bulk Data Access 
(Flat FHIR) specification--a Bulk Data Provider Access API.
    Given the many benefits of giving providers efficient access to 
their patients' data, and the relative ease of doing so by leveraging 
the HL7 FHIR Bulk Data Access (Flat FHIR) specification, we are 
proposing to require that all Medicaid and CHIP FFS programs at 42 CFR 
431.61(a)(1)(ii) and 457.731(a)(1)(ii), Medicaid managed care plans at 
42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 
457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.222(a)(1)(ii) 
implement and maintain a standards-based Provider Access API using the 
HL7 FHIR Bulk Data Access (Flat FHIR) specification at 45 CFR 
170.215(a)(4) to allow providers to receive the same information as 
indicated above for the individual patient request Provider Access 
API--their patients' claims and encounter data (not including cost 
information such as provider remittances and enrollee cost-sharing); 
clinical data as defined in the USCDI version 1, where such clinical 
data are maintained; and formulary data or preferred drug list data, 
where applicable; as well as information on pending and active prior 
authorization decisions. The regulations for Medicaid managed care 
plans and CHIP managed care entities are cross-referenced and 
incorporate the regulations we propose for state Medicaid and CHIP FFS 
programs.
    We are proposing that payers would be required to implement this 
Bulk Data Provider Access API approach for data maintained by the payer 
with a date of service on or after January 1, 2016, by January 1, 2023 
(for Medicaid managed care plans and CHIP managed care entities, by the 
rating period beginning on or after January 1, 2023). We request public 
comment on whether this timeline is feasible and whether the benefits 
would out weight the costs of this Bulk Data Provider Access API 
proposal.
    We understand and acknowledge that payers and developers may view 
these proposed requirements as burdensome, as they could involve 
building multiple APIs to share data between payers and providers. We 
invite public comment on the benefits of having the Provider Access API 
available with and without the use of the HL7 FHIR Bulk Data Access 
(Flat FHIR) specification. As we look to balance providing this 
flexibility with the burden of potentially implementing and maintaining 
multiple APIs, we invite input on whether we should require payers to 
implement just one API that leverages the HL7 FHIR Bulk Data Access 
(Flat FHIR) specification for when they are requesting data for just 
one patient, or for more than one patient, or should we finalize as we 
are proposing here to have payers implement one API solution that does 
not leverage the Bulk specification for a single patient request (as 
discussed in section II.B.3. above in this proposed rule), and a second 
solution that uses the Bulk specification for requests for more than 
one patient. We believe both proposed functionalities offer necessary 
benefits to providers depending on the specifics of the situations in 
which they would need patient data. For example, a large health system 
or large group practice may benefit from using the bulk specification 
if it is updating records annually. We also believe that requiring 
payers to have both API approaches available gives providers 
flexibility. For example, a provider practicing within a large health 
system, such as in the example above, may want quick access to a 
specific patient's information right before that patient's scheduled 
appointment.
    We request comment on this proposal.
    States operating Medicaid and CHIP programs may be able to access 
federal matching funds to support their implementation of this Provider 
Access API, because the API is expected to help the state administer 
its Medicaid and CHIP state plans properly and efficiently, consistent 
with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more 
detail in section II.B.7.a. of this proposed rule.
    We do not consider state expenditures for implementing this 
proposal to be attributable to any covered item or service within the 
definition of ``medical assistance.'' Thus, we would not match these 
expenditures at the state's regular federal medical assistance 
percentage. However, federal Medicaid matching funds under section 
1903(a)(7) of the Act, at a rate of 50 percent, for the proper and 
efficient administration of the Medicaid state plan, might be available 
for state expenditures related to implementing this proposal for their 
Medicaid programs, because use of the Provider Access API would help 
ensure that providers can access data that could improve their ability 
to render Medicaid services effectively, efficiently, and 
appropriately, and in the best interest of the patient, and thus help 
the state more efficiently administer its Medicaid program.
    States' expenditures to implement these proposed requirements might 
also be eligible for enhanced 90 percent federal Medicaid matching 
funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can 
be attributed to the design, development, or installation of mechanized 
claims processing and information retrieval systems. Additionally, 75 
percent federal matching funds under section 1903(a)(3)(B) of the Act 
may be available for state expenditures to operate Medicaid mechanized 
claims processing and information retrieval systems to comply with this 
proposed requirement.
    States request Medicaid matching funds under section 
1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning 
Document (APD) process described in 45 CFR part 95, subpart F. States 
are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to 
ensure that any system for which they are receiving enhanced federal 
financial participation under section 1903(a)(3)(A)(i) or (B) of the 
Act aligns with and incorporates the ONC Health Information Technology 
standards adopted in accordance with 45 CFR part 170, subpart B. The 
Provider Access API, and all APIs proposed in this rule, complement 
this requirement because these APIs further interoperability through 
the use of HL7 FHIR standards proposed for adoption by ONC for HHS use 
at 45 CFR 170.215.\27\ In addition, states are reminded that 42 CFR 
433.112(b)(10) explicitly supports exposed APIs as a condition of 
receiving enhanced federal financial participation under section 
1903(a)(3)(A)(i) or (B) of the Act.
---------------------------------------------------------------------------

    \27\ See SHO #20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

    Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of 
Medicaid technologies and systems as a condition of receiving enhanced 
federal financial participation under section 1903(a)(3)(A)(i) or (B) 
of the Act. CMS would interpret that sharing and re-use requirement 
also to apply to technical documentation associated with a technology 
or system, such as technical documentation for connecting to a state's 
APIs. Making the needed

[[Page 82602]]

technical documentation publicly available so that systems that need to 
connect to the APIs proposed in this rule can do so would be required 
as part of the technical requirements at 42 CFR 431.60(d) for all 
proposed APIs in this rule, including the Provider Access API.
    Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, 
limiting administrative costs to no more than 10 percent of CHIP 
payments to the state, would apply in developing the APIs proposed in 
this rule.
    We note that the temporary federal medical assistance percentage 
(FMAP) increase available under section 6008 of the Families First 
Coronavirus Response Act (Pub. L. 116-127) does not apply to 
administrative expenditures.
6. Additional Proposed Requirements for the Provider Access APIs
    In general, the proposals discussed in this section would align 
with the requirements for the Patient Access API finalized in the CMS 
Interoperability and Patient Access final rule (85 FR 25558 through 
25559) and as proposed in section II.A.2. of this rule with respect to 
the data that are available through the API and the technical 
specifications (other than the proposed use of the Bulk specification). 
We anticipate that this alignment would provide consistency and help 
ensure that payers could build on the foundation of work done to meet 
the final Patient Access API requirements to meet the proposed 
requirements related to the Provider Access API. The accessible 
content, technical standards, API documentation requirements, and 
discontinuation and denial of access requirements would generally be 
consistent between the Patient Access API and the Provider Access API 
proposals, and thus we will not repeat the details of these 
requirements here. There are additional proposed requirements specific 
to the Provider Access API proposals related to attribution, patient 
opt-in, and provider resources. These are discussed in this section.
a. Attribution
    Data sharing between the payer and provider via the Provider Access 
API starts with a request from the provider for one or more patients' 
health information. Data sharing via the Provider Access API would be 
possible only if the patients for whom the provider is requesting 
information can be identified, especially if the provider is requesting 
data for more than one patient at a time using the proposed Bulk 
specification. We do not believe there is only one approach to 
identifying the patients whose information would be requested, and we 
look to provide impacted payers with the opportunity to establish a 
process that will work best for them in light of their existing 
provider relationships.
    As discussed in the CMS Interoperability and Patient Access final 
rule, use of a standards-based FHIR API consistent with the privacy and 
security technical standards required provides a base level of 
protections (see 85 FR 25515 through 25519 and 85 FR 25544 through 
25547). For instance, use of the API would allow payers to determine if 
the provider who is requesting the data is who they say they are by 
leveraging the required authorization and authentication protocols at 
45 CFR 170.215. And, as mentioned above, the existing HIPAA Privacy and 
Security Rules apply. As a covered entity under HIPAA, it is the 
provider's responsibility to use and disclose data in accordance with 
these existing rules.
    As part of the DPC pilot, as one example, we are planning to test a 
process that allows for the provider to add their active patients to a 
roster through self-attestation, which is further checked against 
claims to verify the provider has furnished services to the patient. 
The provider must attest electronically that they have an active 
treatment need for the data, and the provider must agree to the DPC 
terms of use for each roster submitted or updated.\28\ This approach 
was identified given the specific goals of the DPC pilot and the 
provider and patient population involved. For new patients, payers 
could consider a process for confirming a patient has an upcoming 
appointment scheduled to facilitate data sharing when there is not a 
claims history to use to verify a care relationship.
---------------------------------------------------------------------------

    \28\ Data at the Point of Care. (n.d.). Terms of Service. 
Retrieved from https://dpc.cms.gov/terms-of-service.
---------------------------------------------------------------------------

    We recognize that the payers impacted by this proposed rule have a 
variety of provider relationships to consider. We are therefore 
proposing that each payer establish, implement, and maintain for 
itself, a process to facilitate generating each provider's current 
patient roster to enable this proposed payer-to-provider data sharing 
via the Provider Access API.
    We are proposing this at 42 CFR 431.61(a)(2) for state Medicaid 
FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 
431.61(a)) for Medicaid managed care plans other than non-emergency 
transportation (NEMT) PAHPs, at 42 CFR 457.731(a) for state CHIP FFS, 
at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 
457.731(a)) for CHIP managed care, and at 45 CFR 156.222(a)(2) for QHP 
issuers on the FFEs. To facilitate this data sharing, it is necessary 
that providers give payers a list of the patients whose data they are 
requesting. We do not wish to be overly prescriptive about how to 
generate this list for all payers. But, we note that it would be 
necessary for payers to put a process in place that is compliant with 
existing HIPAA Privacy and Security Rules and provides the information 
they need to complete their payer-specific compliance processes.
    We request comments on this proposal. And, we also seek comment on 
whether payers would like to maintain the option to define their own 
process or if they would prefer us to require a process across payers, 
such as the one we plan to test as part of the DPC pilot.
b. Opt-In
    We are proposing that impacted payers would be permitted to put a 
process in place for patients to opt-in to use of the Provider Access 
API for data sharing between their payer and their providers. As with 
the attribution process discussed above, we did not want to be overly 
prescriptive regarding how this opt-in process might be implemented. 
However, we are considering whether to suggest a specific process for 
all payers who choose to implement this opt-in. One possible approach 
might be for CMS to have all payers engaging in an opt-in approach to 
include information about the ability to opt-in to this data sharing as 
part of their annual notice or regular communication with patients--
such as when they communicate with patients about claims, and to permit 
opt-in via a variety of options, including by phone, via a website, or 
using an app, for instance.
    Currently the HIPAA Privacy Rule does not require health plans to 
obtain patient consent to share data with health care providers for 
treatment purposes or care coordination, for instance. However, we 
believe it is important to honor patient privacy preferences, and thus 
see value in possibly providing patients with options regarding which 
providers have access to their information as it relates to this 
proposed policy. We do note, as discussed above, that all existing 
applicable laws and regulations apply. This opt-in option is only 
specific to using the Provider Access API as the means to share data 
that the payer otherwise has authority to share with the provider. 
Therefore, we are specifically proposing at 42 CFR

[[Page 82603]]

431.61(a)(3) for state Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply 
with the requirement at 42 CFR 431.61(a)(3)) for Medicaid managed care, 
at 42 CFR 457.731(a)(3) for state CHIP FFS, at 42 CFR 457.1233(d)(4) 
(to comply with the requirement at 42 CFR 457.731(a)(3)) for CHIP 
managed care, and at 45 CFR 156.222(a)(3) for QHP issuers on the FFEs 
that payers may put a process in place to allow a patient to opt-in to 
the Provider Access API data exchange for each provider from whom they 
are currently receiving care or are planning to receive care.
    We request comment on this proposal. In addition, we seek comment 
on whether payers would like to maintain the option to define their own 
process or if they would prefer CMS to suggest a process, such as the 
examples provided above, for all payers who would be required to 
implement and maintain the Provider Access API. We do note that we also 
considered the following alternatives: (1) Permit an opt-out process, 
(2) default to data sharing without patient engagement in the process 
consistent with the HIPAA Privacy Rule, and require an opt-out process. 
We seek comment on whether stakeholders would prefer we finalize an 
opt-out versus an opt-in approach, and whether either opt-out, or as 
currently proposed--opt-in, be permitted but not required. We request 
comment on the associated benefits and burdens with these different 
approaches, and any other considerations we should take into 
consideration as we consider a final policy.
c. Provider Resources
    We are proposing that payers make educational resources available 
to providers that describe how a provider can request patient data 
using the payer's Provider Access APIs in non-technical, simple, and 
easy-to-understand language. This requirement would be codified at 42 
CFR 431.61(a)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply 
with the requirement at 42 CFR 431.61(a)) for Medicaid managed care 
other than NEMT PAHPs as defined at 42 CFR 438.2, at 42 CFR 
457.731(a)(4) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with 
the requirement at 42 CFR 457.731(a)) for CHIP managed care, and at 45 
CFR 156.222(a)(4) for QHP issuers on the FFEs. As proposed, this would 
include information on using both the individual patient request 
function as well as the bulk data request function. We are proposing 
that these resources be made available on the payer's website and 
through other appropriate mechanisms through which the payer ordinarily 
communicates with providers. We believe these resources would help 
providers understand how they can leverage the available APIs to access 
patient data, thus helping to ensure that the full value of the 
proposed APIs is realized and that providers gain access to needed 
patient data for use at the moment of care.
    We request comment on this proposal.
d. Extensions and Exemptions for Medicaid and CHIP FFS Programs
    If our proposals regarding the Provider Access API are finalized, 
we would strongly encourage state Medicaid and CHIP FFS programs to 
implement the Provider Access API as soon as possible understanding the 
many benefits of the API as discussed previously in this section.
    However, we also recognize that state Medicaid or CHIP FFS agencies 
could face certain unique circumstances that would not apply to other 
impacted payers, as discussed in more detail later in this section. As 
a result, a few states might need to seek an extension of the 
compliance deadline or an exemption from these requirements. To address 
this concern, we are proposing a process through which states may seek 
an extension of and, in specific circumstances, an exemption from, the 
Provider Access API requirements if they are unable to implement these 
API requirements. Providing for these flexibilities might allow these 
states to continue building technical capacity in support of overall 
interoperability goals consistent with their needs. We therefore 
propose the following.
    Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1), 
respectively, we propose to provide states--for Medicaid FFS and CHIP 
FFS--the opportunity to request a one-time extension of up to one (1) 
year for implementation of the Provider Access API specified at 42 CFR 
431.61(a) and 42 CFR 457.731(a). Unique circumstances that might 
present a challenge to specific states to meet the proposed compliance 
date could include resource challenges, such as funding. Depending on 
when the final rule is published in relation to a state's budget 
process and timeline, some states may not be able to secure the needed 
funds in time to both develop and execute implementation of the API 
requirements by the proposed compliance date. A one-year extension 
could help mitigate this issue. And, some states may need to initiate a 
public procurement process to secure contractors with the necessary 
skills to support a state's implementation of these proposed API 
policies. The timeline for an open, competed procurement process, 
together with the time needed to onboard the contractor and develop the 
API, could require additional time as well. Finally, a state might need 
to hire new staff with the necessary skillset to implement this policy. 
Again, the time needed to initiate the public employee hiring process, 
vet, hire, and onboard the new staff may make meeting the proposed 
compliance timeline difficult, because, generally speaking, public 
employee hiring processes include stricter guidelines and longer time-
to-hire periods than other sectors.\29\ In all such situations, a state 
might need more time than other impacted payers to implement the 
requirements.
---------------------------------------------------------------------------

    \29\ State hiring processes are comparable with federal hiring 
processes. According to OMB, the average time-to-hire for federal 
employees was 98.3 days in 2018, significantly higher than the 
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

    If a state believes it can demonstrate the need for an extension, 
its request must be submitted and approved as a part of its annual 
Advance Planning Document (APD) for Medicaid Management Information 
System (MMIS) operations costs and must include the following: (1) A 
narrative justification describing the specific reasons why the state 
cannot reasonably satisfy the requirement(s) by the compliance date, 
and why those reasons result from circumstances that are unique to 
states operating Medicaid or CHIP FFS programs, (2) a report on 
completed and ongoing implementation activities to evidence a good 
faith effort toward compliance, and (3) a comprehensive plan to meet 
implementation requirements no later than one year after the initial 
compliance date.
    An extension would be granted if CMS determines based on the 
information provided in the APD that the request adequately establishes 
a need to delay implementation, a good faith effort to implement the 
proposed requirements as soon as possible, and a clear plan to 
implement no later than one year after the proposed compliance date. We 
would expect states to explain why the request for an extension results 
from circumstances that are unique to states operating Medicaid or CHIP 
FFS programs. We also solicit comment on whether our proposal would 
adequately address the unique circumstances that affect states, and 
that might make timely compliance with the proposed API requirement 
sufficiently difficult for states and thus justify an extension. In 
particular, we seek comment on

[[Page 82604]]

whether we should require or use additional information on which to 
base the determination or whether we should establish different 
standards in the regulation text for evaluating and granting the 
request.
    Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457.731(e)(2), 
respectively, we propose two circumstances that would permit state 
requests for exemption; namely, (1) when at least 90 percent of all 
covered items and services are provided to Medicaid or CHIP 
beneficiaries through Medicaid or CHIP managed care contracts with 
MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or 
(2) when at least 90 percent of the state's Medicaid or CHIP 
beneficiaries are enrolled in Medicaid or CHIP managed care 
organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 
for CHIP. In both circumstances, the time and resources that the state 
would need to expend to implement the API requirements may outweigh the 
benefits of implementing and maintaining the API. Unlike other impacted 
payers, state Medicaid and CHIP FFS programs do not have a diversity of 
plans to balance implementation costs for those plans with low 
enrollment. If there is low enrollment in a state Medicaid or CHIP FFS 
program, there is no potential for the technology to be leveraged for 
additional beneficiaries as states, unlike other payers, do not 
maintain additional lines of business.
    We acknowledge that the proposed exemption could mean that a few 
Medicaid or CHIP FFS systems would not receive the benefits of having 
this API available to facilitate health information exchange. To 
address this, we propose that states meeting the above thresholds would 
be expected to employ an alternative plan to enable the electronic 
exchange and accessibility of health information for those 
beneficiaries who are served under the FFS program.
    A state meeting the above criteria would be permitted to submit a 
request for an exemption to the requirements for the Provider Access 
API once per calendar year for a one (1) year exemption. The state 
would be required to submit this annual request as part of a state's 
annual APD for MMIS operations costs. The state would be required to 
include in its request documentation that it meets the criteria for the 
exemption using data from any one of the three most recent and complete 
calendar years prior to the date the exemption request is made. We note 
we propose that this request be made annually as from year-to-year the 
nature of the FFS population could change and so it is important that 
the state provide the most current information for CMS' consideration.
    Exemptions would be granted for a one-year period if a state 
establishes to CMS' satisfaction that it meets the criteria for the 
exemption and has established a plan to ensure that providers will have 
efficient electronic access to the same information through alternative 
means.
    We request comment on the proposed extension and exemption.
    For Medicaid and CHIP managed care, we are not proposing an 
extension process at this time because we believe that managed care 
plans are actively working to develop the necessary IT infrastructure 
to be able to comply with the existing requirements in 42 CFR part 438 
and part 457 and also benefit from efficiencies resulting from their 
multiple lines of business impacted by these interoperability policies. 
Many managed care plans are part of parent organizations that maintain 
multiple lines of business, including Medicaid managed care plans and 
plans sold on the Exchanges. As discussed in the CMS Interoperability 
and Patient Access final rule (85 FR 25607, 25612, 25620), work done by 
these organizations can benefit all lines of business and, as such, we 
do not believe that the proposals in this rule impose undue burden or 
are unachievable by the compliance date. We are soliciting comment on 
whether our belief concerning the scope of resources and ability of 
managed care parent organizations to achieve economies of scale is 
well-founded. Further, we seek comment on whether an extension process 
is warranted for certain managed care plans to provide additional time 
for the plan to comply with the requirement at 42 CFR 438.61(a) (which 
cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans 
and at proposed 42 CFR 457.731(a) (which cross references 42 CFR 
457.1223(d)(4)) for CHIP managed care entities. While we are not 
proposing such a process for managed care plans and entities and do not 
believe one is necessary for the reasons outlined here, we are open to 
considering one if necessary. If we adopt an extension process for 
these managed care plans and entities, what criteria would a managed 
care plan or entity have to meet to qualify for an extension? Should 
the process consider, for example, enrollment size, plan type, or some 
unique characteristic of certain plans that could hinder their 
achievement of the proposed requirements by the proposed compliance 
date? Also, we seek comment on whether, if finalized such a process for 
Medicaid managed care plans or CHIP managed care entities, the state or 
CMS should manage the process and whether states could successfully 
adopt and implement the process on the timeline necessary to fulfill 
the goals and purposes of the process. Consistent with the exception 
process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we 
would expect any extension request to include, at a minimum, a 
narrative justification describing the reasons why a plan or entity 
cannot reasonably satisfy the requirements by the proposed compliance 
date, the impact of non-compliance upon enrollees, the current or 
proposed means of providing electronic health information to providers, 
and a corrective action plan with a timeline to achieve compliance.
e. Exception for QHP issuers
    For QHP issuers on the FFEs, we propose an exception at 45 CFR 
156.222(d) to these Provider Access API proposals. We propose that if 
an issuer applying for QHP certification to be offered through a FFE 
believes it cannot satisfy the proposed requirements in 45 CFR 
156.222(a) for the Provider Access APIs, the issuer must include as 
part of its QHP application a narrative justification describing the 
reasons why the issuer cannot reasonably satisfy the requirements for 
the applicable plan year, the impact of non-compliance upon providers 
and enrollees, the current or proposed means of providing health 
information to providers, and solutions and a timeline to achieve 
compliance with the requirements of this section. We propose that the 
FFE may grant an exception to the requirements in 45 CFR 156.222(a) for 
the Provider Access APIs if it determines that making such health plan 
available through such FFE is in the interests of qualified individuals 
in the state or states in which such FFE operates. This proposal would 
be consistent with the exception for QHP issuers on the FFEs we 
finalized for the Patient Access API in the Interoperability and 
Patient Access final rule (85 FR 25552 through 25553). For instance, as 
noted in that final rule, that exception could apply to small issuers, 
issuers who are only in the individual or small group market, 
financially vulnerable issuers, or new entrants to the FFEs who 
demonstrate that deploying standards based API technology consistent 
with the required interoperability standards would pose a significant 
barrier to the issuer's ability to provide coverage to consumers, and 
not certifying the issuer's QHP or QHPs would result in consumers 
having few

[[Page 82605]]

or no plan options in certain areas. We believe that having a QHP 
issuer offer QHPs through an FFE is in the best interest of consumers 
and would not want consumers to have to go without access to QHP 
coverage because the issuer is unable to implement this API timely.
    As mentioned in section II.A. of this proposed rule, although 
Medicare FFS is not directly impacted by this rule, we do note that we 
are targeting to implement a Provider Access API, if finalized. In this 
way, the Medicare FFS implementation would conform to the same 
requirements that apply to the impacted payers under this rulemaking, 
as applicable, so that Medicare FFS beneficiaries would also benefit 
from this data sharing.
7. Statutory Authorities for Provider Access API Proposals
a. Medicaid and CHIP
    As is discussed in more detail below, our proposed requirements in 
this section for Medicaid managed care plans and Medicaid state 
agencies fall generally under the authority in the following provisions 
of the statute.
    <bullet> Section 1902(a)(4) of the Act, which requires that a state 
Medicaid plan provide such methods of administration as are found by 
the Secretary to be necessary for the proper and efficient operation of 
the state Medicaid plan.
    <bullet> Section 1902(a)(8) of the Act, which requires states to 
ensure that Medicaid services are furnished with reasonable promptness 
to all eligible individuals.
    <bullet> Section 1902(a)(19) of the Act, which requires states to 
ensure that care and services are provided in a manner consistent with 
simplicity of administration and the best interests of the recipients.
    We note statutory authority for proposals to require specific IGs 
for this and all APIs proposed in this rule is discussed in section 
II.A.3. of this proposed rule.
    We believe these proposals are generally consistent with all these 
provisions of the Act, because they would help ensure that providers 
can access data that could improve their ability to render Medicaid 
services effectively, efficiently, and appropriately. The proposals are 
thus expected to help states fulfill their obligations to operate their 
state plans efficiently and to ensure that Medicaid services are 
furnished with reasonable promptness and in a manner consistent with 
the best interest of patients.
    Proposing to require states to implement a Provider Access API to 
share data about certain claims, encounter, and clinical data, 
including data about pending and active prior authorization decisions, 
for a specific individual beneficiary or for more than one beneficiary 
at a time could improve the efficiency of and simplify how states 
ensure the delivery of Medicaid services. This API would enable 
providers to easily access accurate and complete beneficiary 
utilization and authorization information at the time of care, or prior 
to a patient encounter, and that, in turn, would enable the provider to 
spend more time on direct care. This would support efficient and prompt 
delivery of care as well as care in the best interest of patients. 
These proposals also are expected to allow for better access to other 
providers' prior authorization decisions. This would give a provider a 
more holistic view of a patient's care that could reduce the likelihood 
of ordering duplicate or misaligned services. This could also 
facilitate easier and more informed decision making by the provider and 
would therefore support efficient provision of care in the best 
interest of patients. Additionally, because the data could be 
incorporated into the provider's EHR or other practice management 
system, the proposal is expected to support efficient access to and use 
of the information. The proposal is expected to make it more likely 
that a more complete picture of the patient could be available to the 
provider at the point of care, which could result in the provision of 
more informed and timely services. These process efficiencies may 
ultimately improve practice efficiency and make more of providers' time 
available for appointments. These outcomes and process efficiencies 
would help states fulfill their obligations to ensure prompt access to 
services in a simpler manner and in a manner consistent with the best 
interest of beneficiaries, consistent with section 1902(a)(8) and (19) 
of the Act, and the efficiencies created for providers might help the 
state to administer its Medicaid program more efficiently, consistent 
with section 1902(a)(4) of the Act.
    The proposal related to the Bulk specification for the Provider 
Access API would help facilitate data sharing about one or more 
beneficiaries at once. This could further improve the efficiency and 
simplicity of operations because it would eliminate the need for a 
provider to make individual API calls when seeking information about a 
large number of beneficiaries, taxing both the payer's and provider's 
systems. The ability to receive beneficiary data in bulk would also 
permit practices to analyze practice and care patterns across patient 
populations, thus helping them to improve processes and maximize 
efficiencies that could lead to better health outcomes. All of these 
expected positive outcomes could help states fulfill their obligations 
to ensure prompt access to services in a simpler manner and in a manner 
consistent with the best interest of beneficiaries, consistent with 
section 1902(a)(8) and (19) of the Act, and the efficiencies created 
for providers might help the state to administer its Medicaid program 
more efficiently, consistent with section 1902(a)(4) of the Act.
    For CHIP, we are proposing these requirements under the authority 
in section 2101(a) of the Act, which states that the purpose of title 
XXI is to provide funds to states to provide child health assistance to 
uninsured, low-income children in an effective and efficient manner 
that is coordinated with other sources of health benefits coverage. We 
believe this proposed rule could strengthen states' ability to fulfill 
these title XXI statutory obligations in a way that recognizes and 
accommodates the use of electronic information exchange in the health 
care industry today and would facilitate a significant improvement in 
the delivery of quality health care to CHIP beneficiaries.
    When providers have access to patient utilization and authorization 
information directly from their EHRs or other health IT systems, they 
can provide higher quality care. Improving the quality of care aligns 
with section 2101(a), which requires states to provide CHIP services in 
an effective and efficient manner. The more information a provider has 
to make informed decisions about a patient's care, the more likely it 
is that patients will receive care that best meets their needs. 
Additionally, providers can be more effective and efficient in their 
delivery of CHIP services by having direct access to patient 
utilization and authorization information. If a provider has 
information about a patient prior to or at the point of care, the 
provider will be able to spend more time focused on the patient versus 
on their need to collect information. And, the information they do 
collect will not be based solely on patient recall. As noted above for 
Medicaid, this could save time, improve the quality of care, and 
increase the total amount of direct care provided to CHIP 
beneficiaries. When data are standardized, and able to be incorporated 
directly into the provider's EHR or practice management system, they 
can be leveraged as needed at the point of care by the provider, but 
also be used to support coordination across

[[Page 82606]]

providers and payers. This is inherently more efficient, and 
ultimately, more cost effective, as the information does not have to be 
regularly repackaged and reformatted to be shared or used in a valuable 
way. As such, the Provider Access API proposals also align with section 
2101(a) in that these proposals could improve coordination between CHIP 
and other health coverage. For these reasons, we believe this proposal 
is in the best interest of the beneficiaries and within our 
authorities.
b. QHP Issuers on the FFEs
    For QHP issuers on the FFEs, we are proposing these new 
requirements under our authority in section 1311(e)(1)(B) of the 
Affordable Care Act, which affords the Exchanges the discretion to 
certify QHPs if the Exchange determines that making available such 
health plans through the Exchange is in the interests of qualified 
individuals in the state in which the Exchange operates. We note 
statutory authority for proposals to require specific IGs for this and 
all APIs proposed in this rule are discussed in section II.A.3. of this 
proposed rule.
    We believe that certifying only health plans that make enrollees' 
health information available to their providers via the Provider Access 
API is in the interests of enrollees. Giving providers access to their 
patients' information supplied by QHP issuers on the FFEs would ensure 
that providers are better positioned to provide enrollees with seamless 
and coordinated care, and helps to ensure that QHP enrollees on the 
FFEs are not subject to duplicate testing and procedures, and delays in 
care and diagnosis. Access to the patients' more complete medical 
information may also maximize the efficiency of an enrollee's office 
visits. We encourage SBEs to consider whether a similar requirement 
should be applicable to QHP issuers participating in their Exchanges.
    We also believe that requiring QHP issuers on the FFEs to use the 
Bulk specification for the Provider Access API would improve the 
efficiency and simplicity of data transfers by allowing the provider to 
get all the info for a full panel of patients at once.

C. Reducing the Burden of Prior Authorization Through APIs

1. Background
    Improving the prior authorization process is an opportunity to 
reduce burden for payers, providers, and patients. The proposals in 
this rule build on the foundation set out in the CMS Interoperability 
and Patient Access final rule to improve health information exchange 
and increase interoperability in the health care system. Proposals in 
this section were developed based on industry input from CMS sponsored 
listening sessions, stakeholder meetings, and reports.
    We use the term ``prior authorization'' to refer to the process 
through which a provider must obtain approval from a payer before 
providing care and prior to receiving payment for delivering items or 
services. In some programs, this may be referred to as ``pre-
authorization'' or ``pre-claim review.'' Prior authorization 
requirements are established by payers to help control costs and ensure 
payment accuracy by verifying that an item or service is medically 
necessary, meets coverage criteria, and is consistent with standards of 
care before the item or service is provided rather than undertaking 
that review for the first time when a post-service request for payment 
is made. However, stakeholders have stated that diverse payer policies, 
provider workflow challenges, and technical barriers have created an 
environment in which the prior authorization process is a primary 
source of burden for both providers and payers, a major source of 
burnout for providers, and a health risk for patients when it causes 
their care to be delayed.
    The policies in this proposed rule would apply to any formal 
decision-making process by which impacted payers render an approval or 
disapproval determination, or decision, regarding payment for clinical 
care based on the payer's coverage guidelines and policies before 
services are rendered or items provided.
    We have been studying prior authorization and its associated burden 
to identify the primary issues that stakeholders believe need to be 
addressed to alleviate that burden. To advance the priorities of the 
21st Century Cures Act,\30\ specifically the aim to reduce burden, ONC 
and CMS created a working group to investigate the prior authorization 
ecosystem and identify opportunities for potential solutions. Burdens 
associated with prior authorization include difficulty in determining 
payer-specific requirements related to items and services that require 
prior authorization; inefficient use of provider and staff time to 
submit and receive prior authorization requests through burdensome 
channels such as fax, telephone, and various web portals; and 
unpredictable and lengthy amounts of time to receive payer decisions.
---------------------------------------------------------------------------

    \30\ ONC Strategy to reduce provider burden. Report required 
under the 21st Century Cures Act: https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.
---------------------------------------------------------------------------

    In 2018, the American Medical Association (AMA) conducted a 
physician survey that indicated a weekly per-physician average of 31 
prior authorization requests, consuming an average of 14.9 hours of 
practice time per workweek for physicians and their staff. 
Additionally, 36 percent of physicians have staff that work exclusively 
on prior authorizations.\31\ In 2019, CMS conducted a number of 
listening sessions with payers, providers, patients, and other industry 
representatives to gain insight into issues with prior authorization 
processes and to identify potential areas for improvement. While both 
providers and payers agreed that prior authorization provides value to 
the health care system through cost control, utilization management, 
and program integrity measures, some stakeholders expressed concerns 
that certain steps in the prior authorization processes are burdensome. 
For example, the information required from payers to receive prior 
authorization can be inconsistent from payer to payer, and it can be 
difficult for providers to determine the rules for items or services 
that require prior authorization or what documentation is needed to 
obtain approval. Furthermore, the documentation requirements are not 
centralized because the rules vary for each payer, and access to those 
requirements may require the use of proprietary portals. These 
challenges were described in the ONC 2020 report on reducing electronic 
health record burdens, which stated, ``Each payer has different 
requirements and different submission methods, and clinicians report 
finding it burdensome and time-consuming trying to determine whether 
prior authorization requirements exist for a given patient, diagnosis, 
insurance plan, or state.'' \32\
---------------------------------------------------------------------------

    \31\ American Medical Association. (2019, February). 2018 AMA 
Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2019-02/prior-auth-2018.pdf.
    \32\ Office of the National Coordinator for Health Information 
Technology. (n.d.) Strategy on Reducing Regulatory and 
Administrative Burden Relating to the Use of Health IT and EHRs [PDF 
file]. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

    In the CMS listening sessions, as well as the surveys and reports 
referenced throughout this section, stakeholders suggested that payers 
should disclose their prior authorization requirements in a standard 
format. Stakeholders raised concerns that once a provider has 
identified the appropriate prior authorization requirement for a given

[[Page 82607]]

patient, payer, and item or service, the process of submitting a prior 
authorization request relies on an array of cumbersome submission 
channels, including payer-specific web-based portals, telephone calls, 
and fax exchange technology. In addition, after a provider has 
completed the process of submitting a prior authorization request and 
received approval for an item or service from a particular payer, the 
provider may need to re-submit a new prior authorization request for 
the same, already approved, item or service should the patient 
experience a change in health coverage, which could include switching 
payers, or switching between private coverage and public coverage. 
Should this occur, the provider must start the prior authorization 
process anew with the patient's new payer, which may have different 
documentation requirements and submission formats.
    In 2017, a coalition of 16 provider organizations collaborated with 
payer associations to develop a set of principles to identify ways to 
reduce administrative burdens related to prior authorizations and 
improve patient care. The coalition published a consensus paper 
identifying 21 specific opportunities for improvement in prior 
authorization programs and processes and specifically called out the 
need for industry-wide adoption of electronic prior authorization to 
improve transparency and efficiency.\33\ Nonetheless, industry is still 
at a point where payers and IT developers have addressed prior 
authorization in an ad hoc manner with the implementation of unique 
interfaces that reflect their own technology considerations, lines of 
business, and customer-specific constraints.\34\ The proposals in this 
proposed rule reflect several principles cited in the industry 
consensus statement, including transparency and communication regarding 
prior authorization to encourage effective communication between health 
plans, providers, and patients to minimize care delays and articulate 
prior authorization requirements, as well as automation to improve 
transparency, through the adoption and implementation of electronic 
prior authorization with the potential to streamline and improve the 
process for all stakeholders.
---------------------------------------------------------------------------

    \33\ American Medical Association. (2018). Consensus Statement 
on Improving the Prior Authorization Process. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc-public/prior-authorization-consensus-statement.pdf.
    \34\ Office of the National Coordinator for Health Information 
Technology. (2020, February). Strategy on Reducing Regulatory and 
Administrative Burden Relating to the Use of Health IT and EHRs. 
Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

    There is increasing demand from providers, with support from the 
payer and vendor community, as well as the Secretary's advisory 
committees, to address the burdens associated with the prior 
authorization process. In March and November of 2019, the Health IT 
Advisory Committee (HITAC) and National Committee on Vital and Health 
Statistics (NCVHS) held joint hearings with stakeholders to discuss the 
ongoing challenges with prior authorization workflow, standards, and 
payer policies. During these hearings, payers and providers agreed that 
solutions to address prior authorization issues may not rest with one 
single action, but, rather, they believed that the opportunity to use 
new standards and/or technology, coupled with the movement towards more 
patient focused policies, would provide substantial relief and 
progress. At the November 13, 2019 NCVHS Full Committee meeting,\35\ 
ONC joined NCVHS and invited six industry experts to discuss ongoing 
challenges with prior authorization standards, policies, and practices. 
The themes from panelists were consistent with information provided 
elsewhere in this proposed rule, that changes are still needed in 
technology, payer policies, and payer/provider workflow. America's 
Health Insurance Plans (AHIP) reported the results of its 2019 fall 
plan survey, which included both AHIP and non-AHIP members, and 
reported that plans were evaluating opportunities for prior 
authorization policy changes to address issues. AHIP launched a pilot 
of alternative prior authorization strategies with several plans in 
2020.\36\ In early 2020, NCVHS and HITAC convened another task force, 
the Intersection of Clinical and Administrative Data (ICAD), which met 
weekly to address an overarching charge to convene industry experts and 
produce recommendations related to electronic prior authorizations.\37\ 
The task force report was presented to HITAC in November 2020.\38\ 
Several recommendations pertaining to the use of FHIR based APIs for 
prior authorization were included in the ICAD report, and are 
consistent with proposals in this proposed rule. Those recommendations 
and others are described in more detail in the section II.E. of this 
proposed rule.
---------------------------------------------------------------------------

    \35\ National Committee on Vital and Health Statistics. (2019, 
November 13). Committee Proceedings [Transcript]. Retrieved from 
https://ncvhs.hhs.gov/wp-content/uploads/2019/12/Transcript-Full-Committee-Meeting-November-13-2019.pdf.
    \36\ America's Health Insurance Plans. (2020, January 6). New 
Fast PATH Initiative Aims to Improve Prior Authorization for 
Patients and Doctors. Retrieved from https://www.ahip.org/new-fast-path-initiative-aims-to-improve-prior-authorization-for-patients-and-doctors/.
    \37\ See https://www.healthit.gov/hitac/committees/intersection-clinical-and-administrative-data-task-force.
    \38\ Final report from ICAD Task Force November 17, 2020: 
https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf.
---------------------------------------------------------------------------

    In a November 4, 2019 letter to the CMS Administrator, the American 
Hospital Association (AHA) described the ongoing impact of prior 
authorization on patient care, health system costs, and burdens.\39\ In 
the letter, the AHA shared results from the previously referenced 2018 
AMA survey of more than 1,000 physicians, which indicated that 90 
percent of respondents stated prior authorization had a significant or 
somewhat negative clinical impact on care.\40\ Furthermore, 27 percent 
of survey respondents stated that delays in the provision of care due 
to prior authorization processes had led to a serious adverse event 
such as a death, hospitalization, disability, or permanent bodily 
damage. The AHA's letter affirmed what we have stated above--prior 
authorization is a burden that can lead to patient harm. According to 
the AHA, hospitals and provider offices have many full-time employees 
whose sole role is to manage payer prior authorization requests. One 
hospital system spends $11 million annually just to comply with payer 
prior authorization requirements. Operational costs such as these are 
often factored into negotiated fees or charges to patients to ensure 
financial viability for health care organizations including providers 
and facilities, and we believe this to be the case for small and large 
organizations. We believe our proposals in the following sections would 
make meaningful progress in alleviating the burdens described above and 
facilitating more efficient and prompt health care service delivery to 
patients.
---------------------------------------------------------------------------

    \39\ American Hospital Association. (2019, November 4). RE: 
Health Plan Prior Authorization [PDF file]. Retrieved from https://www.aha.org/system/files/media/file/2019/11/aha-to-cms-health-plan-prior-authorization-11-4-19.pdf.
    \40\ American Medical Association. (2019, February). 2018 AMA 
Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2019-02/prior-auth-2018.pdf.
---------------------------------------------------------------------------

2. Electronic Options for Prior Authorization
    To mitigate provider burden, and improve care delivery to patients, 
we are proposing requirements for payers to implement APIs that are 
conformant with certain implementation guides that

[[Page 82608]]

would facilitate the exchange of information between payers and 
providers and allow providers to more effectively integrate the prior 
authorization process within their clinical workflow. We believe, and 
stakeholder input has confirmed, that payers and providers do not take 
advantage of standards that are currently available for the exchange of 
electronic prior authorization transactions and resort to proprietary 
interfaces and web portals supplemented by inefficient and time 
consuming manual processes such as phone calls or faxes. However, if 
payers made the requirements for prior authorization more accessible 
and understandable through APIs, and providers had access to the tools 
to initiate a prior authorization from within their workflow, providers 
would be more likely to submit the request and necessary documentation 
to the payer using electronic standards.
    In section II.B.2. of this proposed rule, we reference transactions 
for which the Secretary must adopt electronic standards for use by 
covered entities (health plans, health care clearinghouses, and certain 
health care providers), and list the transactions there. The two 
standards adopted for referrals certifications and authorizations 
(hereafter referred to as the prior authorization transaction standard) 
under HIPAA (45 CFR 162.1302) include:
    <bullet> NCPDP Version D.0 for retail pharmacy drugs; and
    <bullet> X12 Version 5010x217 278 (X12 278) for dental, 
professional, and institutional request for review and response for 
items and services.
    Though payers are required to use the X12 278 standard for 
electronic prior authorization transactions, and providers have been 
encouraged to conduct the transaction electronically, the prior 
authorization standard transaction has not achieved a high adoption 
rate by covered entities. The Council for Affordable and Quality Health 
Care (CAQH) releases an annual report called the CAQH Index, which 
includes data on payer and provider adoption of HIPAA standard 
transactions. In the 2019 report, among the seven transactions 
benchmarked, prior authorization using the X12 278 standard was the 
least likely to be supported by payers, practice management systems, 
vendors, and clearinghouse services.\41\ According to this report, 14 
percent of the respondents indicated that they were using the adopted 
standard in a fully electronic way while 54 percent responded that they 
were conducting electronic prior authorization using web portals, 
Integrated Voice Response (IVR) and other options, and 33 percent were 
fully manual (phone, mail, fax, and email). Reported barriers to use of 
the HIPAA standard include lack of vendor support for provider systems, 
inconsistent use of data content from the transaction, and lack of an 
attachment standard to submit required medical documentation (CAQH 
Index). The proposed PAS API could support increased use of the HIPAA 
standard through its capability to integrate with a provider's system 
directly, automation, and improved timeliness for obtaining a response 
to a prior authorization request, particularly when paired with the 
DRLS API. However, we are interested in hearing from commenters if 
there are other steps CMS could take to further implementation of the 
X12 278 standard and what challenges would remain if the standard was 
more widely utilized.
---------------------------------------------------------------------------

    \41\ CAQH. (2019). 2019 CAQH Index: A Report of Healthcare 
Industry Adoption of Electronic Business Transactions and Cost 
Savings [PDF file]. Retrieved from https://www.caqh.org/sites/default/files/explorations/index/report/2019-caqh-index.pdf?token=SP6YxT4u.
---------------------------------------------------------------------------

    HIPAA also requires that HHS adopt operating rules for the HIPAA 
standard transactions. Operating rules are defined at 45 CFR 162.103 as 
the ``necessary business rules and guidelines for the electronic 
exchange of information that are not defined by a standard or its 
implementation specifications as adopted for purposes of HIPAA 
Administrative Simplification.'' The NCVHS reviews potential HIPAA 
operating rules and advises the Secretary as to whether HHS should 
adopt them (section 1173(g) of the Act). The Secretary adopts operating 
rules in regulations in accordance with section 1173(g)(4) of the Act. 
To date, HHS has adopted operating rules for three of the HIPAA 
standard transactions: Eligibility for a health plan and health care 
claim status (76 FR 40458), health care electronic funds transfers 
(EFT), and remittance advice (77 FR 48008). In February 2020, CAQH, 
which develops operating rules for HIPAA standards, submitted two 
operating rules for the HIPAA referral certification and authorization 
transaction for consideration to NCVHS, which held a hearing to discuss 
those operating rules in August 2020. Should HHS adopt operating rules 
for the HIPAA referral certification and authorization transaction, we 
would evaluate them to determine their effect, if any, on proposals in 
this proposed rule.
3. Proposed Requirement for Payers: Documentation Requirement Lookup 
Service (DRLS) API
    Based on information from the listening sessions and non-
governmental surveys, we believe one of the most highly burdensome 
parts of the prior authorization process for payers and providers 
include identifying the payer rules and determining what documentation 
is required for an authorization. As described earlier, this issue is 
one of the key principles in the industry consensus paper \42\ under 
transparency and communication, in which the parties agreed to 
``encourage transparency and easy accessibility of prior authorization 
requirements, criteria, rationale, and program changes to contracted 
health care providers and patients/enrollees.'' In concert with this 
effort towards collaboration, the AMA launched an outreach campaign 
called #fixpriorauth \43\ to drive awareness to the scope of the 
challenges of the prior authorization process. Industry input 
underscores the fact that while there is no single solution to 
improving the prior authorization process, some action on certain 
burdens could be transformative. Therefore, we propose to streamline 
access to information about prior authorization and related 
documentation requirements to potentially reduce this burden. To that 
end, at 42 CFR 431.80(a)(1), 438.242(b)(7), 457.732(a)(1), 
457.1233(d)(4), and 45 CFR 156.223(a)(1), we propose to require that, 
beginning January 1, 2023 (for Medicaid managed care plans and CHIP 
managed care entities, by the rating period beginning on or after 
January 1, 2023), state Medicaid and CHIP FFS programs, Medicaid 
managed care plans, CHIP managed care entities, and QHP issuers on the 
FFEs, implement and maintain a FHIR-based DRLS API conformant with the 
HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG: Version STU 
1.0.0 \44\ and the HL7 FHIR Da Vinci Documentation Templates and Rules 
(DTR): Version STU 1.0.0 \45\ IG, populated with their list of covered 
items and services, not

[[Page 82609]]

including prescription drugs and/or covered outpatient drugs, for which 
prior authorization is required, and with the organization's 
documentation requirements for submitting a prior authorization 
request, including a description of the required documentation.
---------------------------------------------------------------------------

    \42\ Consensus Statement for Improving Prior Authorization: 
https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc-public/prior-authorization-consensus-statement.pdf.
    \43\ AMA website link with resources regarding the prior 
authorization challenges: https://fixpriorauth.org/resources.
    \44\ HL7 International. (n.d.). Da Vinci Coverage Requirements 
Discovery (CRD) FHIR Implementation Guide. Retrieved from http://hl7.org/fhir/us/davinci-crd/history.html.
    \45\ HL7 International. (n.d.). Da Vinci Documentation Templates 
and Rules. Retrieved from http://hl7.org/fhir/us/davinci-dtr/history.html.
---------------------------------------------------------------------------

    Through a proposed cross-reference to the Patient Access API 
requirements at 42 CFR 431.80(a)(1) for Medicaid FFS; at 42 CFR 
438.242(b)(7) (to comply with the requirement at 42 CFR 431.80) for 
Medicaid managed care; at 42 CFR 457.732(a)(1) for CHIP FFS; at 42 CFR 
457.1233(d)(4) (to comply with the requirement at 42 CFR 457.732) for 
CHIP managed care; and at 45 CFR 156.223(a)(1) for QHP issuers on the 
FFEs, we are proposing to require that the DRLS API comply with the 
same technical standards, API documentation requirements, and 
discontinuation and denial of access requirements as apply to the 
Patient Access API (and as proposed for the Provider Access API in 
section II.B. of this proposed rule). For a complete discussion of 
these requirements, we refer readers to the CMS Interoperability and 
Patient Access final rule (85 FR 25526 through 25550).
    We believe payer implementation of DRLS APIs conformant with the 
CRD and DTR IGs which are proposed at 45 CFR 170.215(c)(1) and (2) in 
section II.E. of this proposed rule, would make prior authorization 
requirements and other documentation requirements electronically 
accessible and more transparent to health care providers at the point 
of care. As explained, because each payer has different rules to 
determine when a prior authorization is required, and what information 
is necessary to obtain approval, providers must use different methods 
to keep track of the rules and requirements, which is often time 
consuming and cumbersome. The payer's DRLS API would enable a query to 
their prior authorization requirements for each item and service and 
identify in real time the specific rules and documentation 
requirements. Based on the information, the provider could be prepared 
to submit any necessary documentation to the payer based on those 
requirements, and complete any available electronic forms or templates, 
which would be incorporated into the API. For example, once the payer 
has built a DRLS API and made it available, a provider could initiate a 
query to the payer's DRLS API to determine if a prior authorization and 
documentation is required. If the response is affirmative, the DLRS API 
would indicate what is required, and might provide a link to submit the 
required documentation. In some cases, certain patient data available 
in the provider's system could be used to meet documentation 
requirements.
    Payers who implement and maintain a DRLS API could see improvements 
and efficiencies in the prior authorization process within their own 
organization, by reducing the number of unnecessary requests, 
minimizing follow up, and through fewer denials or appeals. For similar 
reasons, this could contribute to burden reduction for providers as 
well. We believe that requiring impacted payers to implement the API 
would increase provider demand for this functionality if offered by 
these payers. Providers would want access to the API if the payer does 
offer it. We are interested in comments on steps that HHS could take to 
encourage development of these functions within provider EHR systems. 
We are also interested in comments for consideration for future 
policies to require or incentivize providers to use the payer DRLS API 
in their workflows.
    By the time this proposed DRLS API would be required to be 
implemented beginning January 1, 2023 should this proposal be finalized 
as proposed, impacted payers would have the technology needed to 
support a FHIR API, because they would have implemented the Patient 
Access API as adopted in the CMS Interoperability and Patient Access 
final rule (85 FR 25558 through 25559). We intend to enforce the 
requirement for a Patient Access API, as adopted in that rule, starting 
July 1, 2021, taking into account the 6 months of enforcement 
discretion we are exercising due to the public health emergency.\46\ In 
order to implement the Patient Access API, payers will have installed 
the FHIR servers, mapped claims and clinical data for data exchange via 
FHIR, and implemented a FHIR API. We believe the experience of 
implementing the Patient Access API, including having made upgrades to 
their computer systems and trained or hired staff to support its use, 
would enable impacted payers under this proposed rule to implement the 
DRLS API by January 1, 2023 (or, for Medicaid managed care plans and 
CHIP managed care entities, by the rating period beginning on or after 
January 1, 2023). We considered whether it would be beneficial for 
payers to implement the proposed DRLS APIs in phases. For example, we 
considered whether payers should implement the DRLS API via an 
incremental approach, incorporating the top 10 percent or top 10 
highest volume prior authorization rules in the first year, and 
continue adding to the DRLS API over a 2- or 3-year period before the 
DRLS is fully implemented. However, we believe that fully implementing 
the DRLS API in year one of such a phased timeline, by January 1, 2023, 
would be critical to streamlining the prior authorization process, and 
would be instrumental in moving towards increased use of electronic 
prior authorization.
---------------------------------------------------------------------------

    \46\ For more information, visit: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
---------------------------------------------------------------------------

    We request comments on this proposal for impacted payers to 
implement a DRLS API. We also request input on a potential short-term 
solution to address the challenge of accessing payer requirements for 
prior authorizations. We solicit feedback on how payers currently 
communicate prior authorization requirements, and on the potential for 
payers to post, on a public-facing website, their list of items and 
services for which prior authorization is required, populate the 
website with their associated documentation rules as in interim step 
while they implement the DRLS. This is not intended to harmonize prior 
authorization requests, but rather to quickly address the issue 
identified by stakeholders regarding access to prior authorization 
information. If payers could post their prior authorization 
requirements on a website, how could that information be presented and 
organized for providers to easily identify the services and items which 
require prior authorization? Finally, we request comments on how the 
posting of this information on payer websites would provide a 
satisfactory interim solution to the challenge of accessing payer 
requirements for prior authorizations in advance of implementing the 
DRLS API.
4. Proposed Requirement for Payers: Implementation of a Prior 
Authorization Support API
    Electronic prior authorizations are not used consistently between 
payers and providers, even with the availability of an adopted HIPAA 
standard. The burden of navigating the various submission mechanisms 
falls on the provider and can detract from providing care to patients. 
Additionally, many provider administrative practice management systems 
and vendors do not support the adopted HIPAA standard. To help address 
this issue, we are proposing that impacted payers implement a Prior 
Authorization Support (PAS) API that facilitates a HIPAA compliant 
prior authorization request and response, including any forms or 
medical record documentation

[[Page 82610]]

required by the payer for items or services for which the provider is 
seeking authorization.
    Specifically, we propose to require that Medicaid and CHIP FFS 
programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers on the FFEs implement and maintain a PAS API conformant 
with the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG 
beginning January 1, 2023 (for Medicaid managed care plans and CHIP 
managed care entities, by the rating period beginning on or after 
January 1, 2023). We propose to codify this requirement at 42 CFR 
431.80(a)(2) and 457.732(a)(2), and 45 CFR 156.223(a)(2) and, as with 
our proposal for the Provider Access API (discussed in section II.B. of 
this proposed rule), we propose to use cross-references in 42 CFR 
438.242(b)(7) and 42 CFR 457.1233(d)(4) to impose this new PAS API 
requirement on Medicaid managed care plans and CHIP managed care 
entities. The API would be required to be conformant with the 
implementation specification at 45 CFR 170.215(c)(3). If this provision 
is finalized as proposed, the payer would be required to implement the 
API, and, when sending the response, include information regarding 
whether the organization approves (and for how long), denies, or 
requests more information for the prior authorization request, along 
with a reason for denial in the case of a denial. The PAS API would 
provide an opportunity to leverage the convenience of API technology, 
while maintaining compliance with the adopted HIPAA transaction 
standard. Furthermore, use of the PAS API would accelerate adoption and 
use of electronic prior authorization transactions by impacted payers 
and by providers, particularly when coupled with implementation of the 
DRLS API, increasing efficiencies for both parties.
    We are aware that the flow of the payer API may not be intuitive to 
all readers, therefore, please refer to the implementation guides for 
payer API flow details. We also provide a high-level description here. 
The payer would make a PAS API available for providers. When a patient 
needs authorization for a service, the payer's PAS API would enable the 
provider, at the point of service, to send a request for an 
authorization. The API would send the request through an intermediary 
(such as a clearinghouse) that would convert it to a HIPAA compliant 
X12 278 request transaction for submission to the payer. It is also 
possible that the payer converts the request to a HIPAA compliant X12 
278 transaction, and thus the payer acts as the intermediary. The payer 
would receive and process the request and include necessary information 
to send the response back to the provider through its intermediary, 
where the response would be transformed into a HIPAA compliant 278 
response transaction. The response through the API would indicate 
whether the payer approves (and for how long), denies, or requests more 
information related to the prior authorization request, along with a 
reason for denial in the case of a denial.
    We believe it would be valuable for payers to implement the PAS API 
for prior authorizations, because doing so would enhance the overall 
process generally, and, specifically, would increase the uptake of 
electronic prior authorizations by providers. Implementation of the PAS 
API would also maintain compliance with the adopted HIPAA standards, so 
other legacy system changes may not be necessary. We also believe that 
existing business arrangements with intermediaries or clearinghouses 
would remain in place to support transmission of the X12 transaction. 
Payers who implement the PAS API would likely see an improvement in 
efficiencies, particularly when coupled with implementation of the DRLS 
API because when providers know clearly what documentation is required 
to support a prior authorization request, they do not need to call or 
fax for additional instructions. Fewer phone calls or errors would 
decrease administrative costs for a payer. Use of the PAS API could 
facilitate a real time exchange of the authorization request, so that 
payers could provide a real time response.
    In particular, we expect that our proposals to require payers to 
implement the DRLS and PAS APIs would improve the electronic data 
exchange landscape between the impacted payers and providers once 
providers' practice management system or EHR make the connection to the 
payer's API. That is why it is important for the payers to make the 
APIs available first. It is burdensome and time-consuming for providers 
to use multiple mechanisms--including numerous payer-specific web 
portals and fax numbers--to submit prior authorization requests and 
receive prior authorization decisions. Our outreach and industry 
research show that providers are eager for the opportunity to have 
access to this technology to reduce burden.
    We request comment on these proposals.
    We believe that requiring the impacted payers to implement the FHIR 
based APIs that would be available for providers might ultimately 
result in broader industry-wide changes to address the prior 
authorization issues identified by stakeholders and discussed above. 
Similarly, if the APIs are successfully implemented by the impacted 
payers as proposed, the demand for this functionality would motivate 
EHR vendors to invest in integrating a PAS API directly into a 
provider's workflow, which might ultimately result in APIs becoming the 
preferred and primary method to facilitate prior authorization 
processes. As with the proposed DRLS API, we note that functionality to 
interact with the proposed PAS API is not standardized across provider 
systems today, but that industry interest in this initiative is 
extremely high. Industry participation is increasing in the HL7 work 
groups developing and testing the IGs for these APIs, including 
increased participation by providers, payers, and vendors. We believe 
that EHR developers would increasingly make this functionality 
available to their customers to support increased use of the payer APIs 
should this proposed rule be finalized. We request comment on steps 
that HHS could take to educate providers on the benefits of these APIs 
and incentive their use. We also request comment on opportunities to 
encourage health IT developers to implement these functions within 
EHRs, including the potential future addition of certification criteria 
in the ONC Health IT Certification Program.
a. Requirement To Provide a Reason for Denial
    When a provider has submitted an electronic prior authorization 
request, there is an expectation for a response to indicate that an 
item or service is approved (and for how long), denied, or if there is 
a request for more information. Regardless of the mechanism through 
which a prior authorization request is received and processed, in the 
case of a denial, providers need to know why the request has been 
denied, so that they can either re-submit it with updated information, 
identify alternatives, appeal the decision, or communicate the decision 
to their patients. A payer might deny a prior authorization because the 
items or services are not covered, because the items or services are 
not medically necessary, or because documentation to support the 
request was missing or inadequate. However, payers do not always 
provide consistent communication about the reasons for denials or 
information about what is required for approval.

[[Page 82611]]

    To improve the timeliness, clarity, and consistency of information 
for providers regarding prior authorization status, specifically 
denials, we are proposing that impacted payers send certain response 
information regarding the reason for denying a prior authorization 
request. Based on the surveys referenced above, stakeholders agree that 
payers do not provide consistent information about the status of a 
prior authorization or the reasons for a denial, nor do they use the 
adopted X12 278 HIPAA standard transaction to communicate prior 
authorization status information. Therefore, we propose at 42 CFR 
431.80(a)(2)(iii) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply 
with the requirement at 42 CFR 431.80) for Medicaid managed care, at 42 
CFR 457.732(a)(2)(iii) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to 
comply with the requirement at 42 CFR 457.732) for CHIP managed care, 
and at 45 CFR 156.223(a)(2)(iii) for QHP issuers on the FFEs that 
impacted payers transmit, through the proposed PAS API, information 
regarding whether the payer approves (and for how long), denies, or 
requests more information related to the prior authorization request. 
In addition, we propose at 42 CFR 431.80(a)(2)(iv) for Medicaid FFS, at 
42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.80) 
for Medicaid managed care, at 42 CFR 457.732(a)(2)(iv) for CHIP FFS, at 
42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 
457.732) for CHIP managed care, and at 45 CFR 156.223(a)(2)(iv) for QHP 
issuers on the FFEs that impacted payers include a specific reason for 
denial with all prior authorization decisions, regardless of the method 
used to send the prior authorization decision.
    Under our proposal, impacted payers would be required to provide a 
specific reason a prior authorization request is denied, such as 
indicating necessary documentation was not provided, the services are 
not determined to be medically necessary, or the patient has exceeded 
limits on allowable (that is, covered) care for a given type of item or 
service, so that a provider is notified why a request was denied and 
can determine what their best next steps may be to support getting the 
patient the care needed in a timely manner. A clear and specific reason 
for a denial would help ensure both providers and payers have the 
opportunity to benefit from consistent communication, and supports our 
drive to reduce payer, provider, and even patient burden.
    States operating Medicaid and CHIP programs may be able to access 
federal matching funds to support their implementation of the DRLS and 
PAS APIs, because these APIs are expected to help the state administer 
its Medicaid and CHIP state plans properly and efficiently by 
supporting a more efficient prior authorization process, consistent 
with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more 
detail in section II.C.7.a. of this proposed rule.
    We do not consider state expenditures for implementing this 
proposal to be attributable to any covered item or service within the 
definition of ``medical assistance.'' Thus, we would not match these 
expenditures at the state's regular federal medical assistance 
percentage. However, federal Medicaid matching funds under section 
1903(a)(7) of the Act, at a rate of 50 percent, for the proper and 
efficient administration of the Medicaid state plan, might be available 
for state expenditures related to implementing this proposal for their 
Medicaid programs, because use of the DRLS and PAS APIs would help the 
state more efficiently administer its Medicaid program by increasing 
the efficiencies in the prior authorization process. For instance, use 
of these APIs would allow administrative efficiencies by making the 
process more timely, and by helping reduce the number of denied and 
appealed prior authorization decisions, making the process more clear 
and transparent via the APIs.
    States' expenditures to implement these proposed requirements might 
also be eligible for enhanced 90 percent federal Medicaid matching 
funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can 
be attributed to the design, development, or installation of mechanized 
claims processing and information retrieval systems. Additionally, 75 
percent federal matching funds under section 1903(a)(3)(B) of the Act 
may be available for state expenditures to operate Medicaid mechanized 
claims processing and information retrieval systems to comply with this 
proposed requirement.
    States request Medicaid matching funds under section 
1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 
45 CFR part 95, subpart F. States are reminded that 42 CFR 
433.112(b)(12) and 433.116(c) require them to ensure that any system 
for which they are receiving enhanced federal financial participation 
under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and 
incorporates the ONC Health Information Technology standards adopted in 
accordance with 45 CFR part 170, subpart B. The DRLS and PAS APIs, and 
all APIs proposed in this rule, would complement this requirement 
because these APIs further interoperability through the use of HL7 FHIR 
standards proposed for adoption by ONC for HHS use at 45 CFR 
170.215.\47\ And, states are reminded that 42 CFR 433.112(b)(10) 
explicitly supports exposed APIs as a condition of receiving enhanced 
federal financial participation under section 1903(a)(3)(A)(i) or (B) 
of the Act.
---------------------------------------------------------------------------

    \47\ See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

    Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of 
Medicaid technologies and systems as a condition of receiving enhanced 
federal financial participation under section 1903(a)(3)(A)(i) or (B) 
of the Act. CMS would interpret that sharing and re-use requirement 
also to apply to technical documentation associated with a technology 
or system, such as technical documentation for connecting to a state's 
APIs. Making the needed technical documentation publicly available so 
that systems that need to connect to the APIs proposed in this rule can 
do so would be required as part of the technical requirements at 42 CFR 
431.60(d) for all proposed APIs in this rule, including the DRLS and 
PAS APIs.
    Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, 
limiting administrative costs to no more than 10 percent of CHIP 
payments to the state, would apply in developing the APIs proposed in 
this rule.
    We note that the temporary federal medical assistance percentage 
(FMAP) increase available under section 6008 of the Families First 
Coronavirus Response Act (Pub. L. 116-127) does not apply to 
administrative expenditures.
b. Program Specific Notice Requirements To Accompany Prior 
Authorization Denial Information--Medicaid and CHIP Managed Care
    Some of the payers impacted by this proposed rule are required by 
existing regulations to notify providers and patients when they have 
made an adverse decision regarding a prior authorization. The proposal 
above to send a denial reason would not reduce or replace such existing 
notification requirements. Rather, the proposed requirement to use the 
PAS API to provide a notification whether the authorization has been 
approved (and for how long) or denied (along with a reason for the 
denial) would supplement current notice requirements for those payers, 
and offer an efficient method of providing such information for those 
payers who currently do not have a requirement to notify providers of 
the decision on a prior authorization request. We believe use of the 
proposed

[[Page 82612]]

denial reasons in addition to the notification requirements provides 
enhanced communication which increases transparency and would reduce 
burden and improve efficiencies for both payers and providers.
    For Medicaid managed care plans and CHIP managed care entities,\48\ 
existing regulations at 42 CFR 438.210(c) requires notice to the 
provider without specifying the format or method while 42 CFR 
438.210(c) and 42 CFR 438.404(a) require written notice to the enrollee 
of an adverse benefit determination. As part of our proposal, we intend 
that an indication of whether the payer approves, denies, or requests 
more information for the prior authorization request, if transmitted to 
providers via the PAS API, and a denial reason in the case of denial, 
would be sufficient to satisfy the current requirement for notice to 
providers at 42 CFR 438.210(c) and (d). Therefore, the payer would not 
be required to send the response via the PAS API and a denial reason, 
as well as a separate notice in another manner to the provider with 
duplicate information. We remind managed care plans that their 
obligations to provide these required notices would not be reduced or 
eliminated regardless of the proposals included in this rule. We 
acknowledge that some providers may need more time to adapt to 
submitting prior authorization requests via an API and until such time, 
we encourage managed care plans to comply with other applicable 
regulations to ensure that their prior authorization practices and 
policies do not lead to impeding timely access to care or affect 
network adequacy. Lastly, we note that the proposal to electronically 
transmit information through the PAS API about whether the payer 
approves, denies, or requests more information for the prior 
authorization request is about notice to the provider and is limited to 
transmission to a provider's EHR or practice management system. This 
proposal would have no effect on the requirements for notice to an 
enrollee at 42 CFR 438.210(c) and (d) and 438.404.
---------------------------------------------------------------------------

    \48\ CHIP managed care entities are required to comply with 
these standards by 42 CFR 57.1230(d).
---------------------------------------------------------------------------

    We would like to hear from the provider community how current 
notifications are received and whether the proposed communication via 
the PAS API could be more useful than the current notification process. 
For instance, are the current notifications integrated into EHRs and 
could this proposal improve communications?
5. Seeking Comment on Prohibiting Post-Service Claim Denials for Items 
and Services Approved Under Prior Authorization
    During the listening sessions, stakeholders raised concerns about 
denials of claims for approved prior authorizations explaining that 
provider staff spend significant time on appeals to resolve these 
denials, and in some cases, patients receive unexpected bills for the 
services, after the fact. Generally, a prior authorization is currently 
only a determination by a payer that an item or service is medically 
necessary, and is not a promise of payment. However, when a valid claim 
for an approved service is denied, this creates inefficiencies in 
processes for both payers and providers and could affect patient care. 
We wish to learn how new policies could help improve this process, and 
therefore request input from payers and other industry stakeholders, on 
the issues that could inform a future proposal to prohibit impacted 
payers from denying claims for covered items and services for which a 
prior authorization has been approved.
    We are requesting input on the criteria that could be included in a 
new policy, and the potential costs of such a policy on payers. 
Specifically we are soliciting input on what requirements would be 
appropriate to include in a policy to ensure that claims that meet 
certain guidelines for approved authorizations are not denied. In 
addition, we seek comment on whether it would be important that the 
patient be enrolled with the payer at the time the items or services 
were provided, or that certain conditions exist for the provider's 
contract status with the payer. And, we seek comment on what other 
requirements would be appropriate to include in a policy to ensure that 
the claims that meet certain guidelines for approved authorizations are 
not denied.
    We would also like input on the criteria payers could use to deny 
claims once they are submitted to the claims processing system. For 
example, do payers deny claims when there is reliable evidence of 
technical errors, a duplicate claim for the approved item or service, 
or evidence that an approved prior authorization was procured based on 
material inaccuracy or by fraud? We believe payers have program 
integrity practices through which they determine if a prior 
authorization was procured by fraud, and coordinate investigations 
under relevant programmatic authorities or state laws. Commenters are 
encouraged to provide examples of program integrity practices used by 
payers to identify and address fraudulent claims.
    We also seek comment on whether all payer types should be required 
to comply with a policy to prohibit payers from denying a claim for 
payment after approving a prior authorization for covered items and 
services, or if any payer types should be excluded, and for what 
reasons. Finally, we would like input on the unintended consequences, 
cost implications, and cost estimates related to prohibiting a prior 
authorized claim from being denied, to the extent data can be provided. 
We are interested in what legitimate reasons for denial could be 
restricted by the adoption of specific criteria. We also invite payers 
to comment on whether such a policy could increase improper payments or 
program costs, decrease state use of prior authorization, or impact 
enforcement of third-party liability.
    If we were to address these topics, we would do so in a future 
notice and proposed rulemaking.
6. Requirements for Prior Authorization Decision Timeframes and 
Communications
a. Overview of Decision Timeframe Issue
    We also heard from providers that excessive wait times for prior 
authorization decisions often caused delays in the delivery of services 
to patients. One risk of the time burden associated with some of the 
prior authorization processes is the potential patient harm resulting 
from delays in responses to prior authorization requests--whether for 
the approval of the initial request, or delays in the resolution of the 
request--for example, waiting for a payer's review and decision based 
on required documentation for the request. The AMA study reported that 
28 percent of physicians stated that delays in care due to the prior 
authorization process, specifically the wait for approval, led to 
serious, life-threatening adverse events, including death, for their 
patients.\49\ In addition, 91 percent of physicians reported that 
delays related to prior authorization have had other negative impacts 
on their patients.\50\ As described earlier, in 2019 CMS conducted 
outreach with external

[[Page 82613]]

stakeholders through listening sessions, interviews, observational 
visits, RFIs and a special email box, to obtain information about how 
to improve the transparency, efficiency, and standardization of the 
prior authorization process. From the high volume of comments we 
received on the subject of timeframes for processing prior 
authorizations, it is apparent that delays in securing approvals for 
prior authorization directly affect patient care by, for example, 
delaying access to services, transfers between hospitals and post-acute 
care facilities, treatment, medication, and supplies. These delays 
occur, in part, because of the variation in processes used by each 
payer to review prior authorization requests, inconsistent use of 
available technologies to process prior authorizations, and the ongoing 
reliance on manual systems such as phone, fax, and mail, which require 
more labor-intensive human interactions. Some commenters noted that the 
large variations in payer prior authorization policies for the same 
items and services and the difficulty discovering each payer's 
policies--which requires substantial staff research and time--
contribute to delays in care.
---------------------------------------------------------------------------

    \49\ American Medical Association. (n.d.). 2017 AMA Prior 
Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc/prior-auth-2017.pdf.
    \50\ American Medical Association. (n.d.). 2017 AMA Prior 
Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc/prior-auth-2017.pdf.
---------------------------------------------------------------------------

    In this proposed rule, we use the term ``standard'' prior 
authorization to refer to non-expedited request for prior authorization 
and the term ``expedited'' prior authorization to indicate an urgent 
request. This is consistent with the provisions at 42 CFR 438.210(d) 
(for Medicaid managed care plans). A standard prior authorization is 
for non-urgent items and services. An expedited prior authorization is 
necessary when failure to decide could jeopardize the health or life of 
the patient.
b. Current Regulations Establishing Timeframes for Certain Payers for 
Standard and Expedited Prior Authorization Requests
    We have regulated in this area previously and have established 
timeframes for certain payers to make decisions and provide notice 
regarding prior authorizations as well as time requirements for certain 
decisions on appeals. Specifically, in the Medicaid managed care 
program, and for CHIP managed care entities, payers must, for standard 
authorization decisions, make a decision, and send notice of that 
decision, as expeditiously as the enrollee's condition requires and 
within state-established timeframes that may not exceed 14 calendar 
days following receipt of the request for items or services (42 CFR 
438.210(d)(1), 457.495(d), and 457.1230(d)). For cases in which a 
provider indicates or the payer determines that following the standard 
timeframe could seriously jeopardize the enrollee or beneficiary's 
life, health or ability to attain, maintain, or regain maximum 
function, the Medicaid managed care plan, or CHIP managed care entity 
must make an expedited authorization decision and provide notice as 
expeditiously as the enrollee's health condition requires, but no later 
than 72 hours after receiving the request (42 CFR 438.210(d)(2) and 
457.1230(d)).
    In addition, under these existing regulations, the enrollee or the 
provider may request an extension of up to 14 additional calendar days 
from the standard timeframe to make a decision on a prior authorization 
request for an item or service, or the payer may also initiate the 
extension up to 14 additional calendar days if the payer can justify a 
need for additional information and how the extension is in the 
enrollee or beneficiary's interest (42 CFR 438.210(d)(2) and 
457.1230(d)). For example, a payer may need to gather additional 
information by consulting with additional providers with expertise in 
treating a particular condition to enable the payer to make a more 
informed decision.
    Under existing CHIP regulations, prior authorization of health 
services must be completed within 14 days after receipt of a request 
for services or in accordance with existing state law regarding prior 
authorization of health services (42 CFR 457.495(d)). This means the 
CHIP managed care entities must decide, and send notice of that 
decision within 14 calendar days following receipt of the request for a 
medical item or service by the provider. An extension of 14 days may be 
permitted if the enrollee requests the extension or if the physician or 
health plan determines that additional information is needed (42 CFR 
457.495(d)(1)). For cases in which a provider indicates, or the payer 
determines, that the standard timeframe of 14 days could seriously 
jeopardize the enrollee's life; health; or ability to attain, maintain, 
or regain maximum function, the CHIP managed care entity must make an 
expedited authorization decision and provide notice no later than 72 
hours after receiving the request (42 CFR 457.1230(d)).
c. Proposals To Address Timeframes for Standard Prior Authorization 
Requests
    Given our interest in patient health outcomes, we are proposing to 
require that state Medicaid and CHIP FFS programs, Medicaid managed 
care plans, and CHIP managed care entities provide notice of prior 
authorization decisions as expeditiously as a beneficiary's health 
condition requires and under any circumstances not later than 72 hours 
of receiving a request for expedited decisions. Notice should be 
provided no later than 7 calendar days after receiving a request for 
standard decisions. For Medicaid managed care plans, we are also 
proposing to maintain that an extension of 14 days is authorized if the 
enrollee requests it or a health plan determines additional information 
is needed.
    We are not proposing at this time to change timeframes for prior 
authorization (pre-service) claims processes for QHP issuers on the 
FFEs, as further discussed below.
    We are not proposing that a prior authorization would be 
automatically approved should the impacted payer fail to meet the 
required timeframe. If the deadline is missed, providers may need to 
contact the payer to determine the status of the request and whether 
additional information is needed. Further, under the Medicaid managed 
care rules (at 42 CFR 438.404(c)(5)), a payer's failure to decide 
within the required timeframe is considered a denial and the right to 
appeal that denial is available to the enrollee or provider. We are not 
proposing to change this existing rule. In addition to these proposals, 
we request comments on the impact of proposing a policy whereby a payer 
would be required to respond to a prior authorization request within 
the regulated timeframes, and if the payer failed to meet the required 
timeframe, the prior authorization would be automatically approved. We 
are interested in stakeholder feedback on the potential volume of such 
occurrences, the costs to payers in increasing prior authorization 
staffing levels or inappropriate items and services and the benefits to 
providers and patients in terms of reduced burden and faster access to 
necessary items and services.
    We propose at 42 CFR 440.230(d)(1)(i) for Medicaid FFS, at 42 CFR 
457.495(d) for CHIP FFS, at 42 CFR 438.210(d) for Medicaid managed 
care, at 42 CFR 457.1233 for CHIP managed care (through the existing 
requirement to comply with 42 CFR 438.210), that impacted payers must 
meet these timeframes beginning January 1, 2023 (for Medicaid managed 
care plans and CHIP managed care entities, by the rating period 
beginning on or after January 1, 2023). We are not proposing to change 
the timeframes that apply to expedited authorization decisions made by 
Medicaid managed care plans and CHIP managed care entities under 42 CFR 
438.210(d)(2) and 457.1230(d), which already apply a 72 hour

[[Page 82614]]

timeframe, with an opportunity to extend the timeframe by up to 14 days 
under certain conditions.
d. Requirements for Notifications Related to Prior Authorization 
Decision Timeframes
    This section addresses current requirements for certain impacted 
payers to maintain communications about prior authorization decisions 
with patients through notifications, in concert with our proposals to 
improve the timeliness of prior authorization decisions.
    For Medicaid, we are proposing a new paragraph (d)(1)(i) at 42 CFR 
440.230 to specify regulatory timeframes for providing notice of both 
expedited and standard prior authorization requests. The new 
requirements would be applied to prior authorization decisions 
beginning January 1, 2023.
    Under this proposal for Medicaid, notice of the state Medicaid 
program's decision regarding an expedited request for prior 
authorization would have to be communicated as expeditiously as a 
beneficiary's health condition requires, and in any event not later 
than 72 hours after receiving a provider's request for an expedited 
determination. Notice of a decision on a standard request for a prior 
authorization would have to be communicated to the requesting provider 
as expeditiously as a beneficiary's health condition requires, and 
under any circumstance, within 7 calendar days. If the state determines 
that it needs additional information from a provider to make a 
decision, or if the beneficiary or provider requests an extension, this 
proposed decision-making and communication timeframe could be extended 
by up to 14 calendar days. State Medicaid FFS programs must also comply 
with the requirements in section 1927 of the Act regarding coverage and 
prior authorization of covered outpatient drugs. Nothing in this 
proposed rule would change these requirements.
    This proposal is consistent with section 1902(a)(19) of the Act, 
which requires that care and services be provided in a manner 
consistent with simplicity of administration and the best interests of 
recipients, because it is expected to help make the prior authorization 
process less burdensome for the state, providers, and beneficiaries. 
The proposed requirements and standards could result in more prompt 
prior authorization decisions, improve delivery of covered services, 
reduce burden on providers, and improve efficiency of operations for 
the program, thereby serving the best interest of Medicaid 
beneficiaries.
    Under current Medicaid notice and fair hearing regulations, notice 
and fair hearing rights already apply to state decisions about Medicaid 
fee-for-service prior authorization requests. Specifically, Medicaid 
notice and fair hearing regulations apply to all prior authorization 
decisions, including partial or total denials of prior authorization 
requests, failures to make prior authorization decisions in a timely 
fashion, and terminations, suspensions of, and reductions in benefits 
or services for which there is a current approved prior authorization. 
We propose the following changes in regulation text to make it explicit 
that existing Medicaid notice and fair hearing rights apply to Medicaid 
fee-for-service prior authorization decisions. First, we propose a new 
paragraph (1)(ii) in 42 CFR 440.230(d) to specify that states must 
provide beneficiaries with notice of the Medicaid agency's prior 
authorization decisions and fair hearing rights in accordance with 42 
CFR 435.917 and part 431, subpart E. Second, we propose to revise the 
definition of an ``action'' at 42 CFR 431.201 to include termination, 
suspension of, or reduction in benefits or services for which there is 
a current approved prior authorization. We also propose to revise the 
definition of the term ``action'' to improve readability. Third, to 
align with our proposal at 42 CFR 431.201 (definition of ``action'') 
and 42 CFR 440.230(d)(1)(ii), we propose to modify 42 CFR 431.220(a)(1) 
to add a new paragraph (vi) to add a prior authorization decision to 
the list of situations in which a state must provide the opportunity 
for a fair hearing. Fourth, we propose a modification to 42 CFR 
435.917(b)(2) to add a notice of denial or of change in benefits or 
services to the types of notices that need to comply with the 
requirements of 42 CFR 431.210. Finally, we propose modifications to 
the headers at 42 CFR 435.917(a) and (b) to clarify that the 
information contained in 42 CFR 435.917 relates broadly to eligibility, 
benefits, and services notices. Specifically, we propose to remove the 
word ``eligibility'' from the headers of paragraphs (a) and (b) of 42 
CFR 435.917 to more accurately reflect the content of these paragraphs.
    These proposed changes are intended to make it explicit in 
regulation text how existing Medicaid fair hearing regulations apply to 
states' prior authorization decisions. As noted above, the partial or 
total denial of a prior authorization request is appealable through a 
state fair hearing under current regulations. Even though current 
regulations at 42 CFR 431.220(a)(1) do not expressly refer to denials 
of prior authorization requests, a denial of a prior authorization 
request is a denial of benefits or services as described in that 
section because a prior authorization denial results in denial of 
coverage of a benefit or service requested by the beneficiary. 
Therefore, the state must provide a beneficiary who receives a partial 
or total denial of a prior authorization request the opportunity to 
have a fair hearing.\51\
---------------------------------------------------------------------------

    \51\ See discussion in the ``Medicaid and Children's Health 
Insurance Programs: Eligibility Notices, Fair Hearing and Appeal 
Processes for Medicaid and Other Provisions Related to Eligibility 
and Enrollment for Medicaid and CHIP'' final rule (hereinafter 
``Eligibility and Appeals Final Rule''), published in the Federal 
Register on November 30, 2016 (81 FR 86382, 86395)(approvals of 
prior authorization requests for an amount, duration, or scope that 
is less than what the beneficiary requested are subject to fair 
hearing requirements in 42 CFR 431, subpart E).
---------------------------------------------------------------------------

    Similarly, under current regulations at 42 CFR 431.220(a)(1), the 
state must provide beneficiaries the opportunity to request a fair 
hearing if the state fails to act on a claim with reasonable 
promptness. Just as states must furnish medical assistance to eligible 
individuals with reasonable promptness under section 1902(a)(8) of the 
Act, states must also provide individuals with access to a fair hearing 
if the state fails to act on a claim for medical assistance with 
reasonable promptness under section 1902(a)(3) of the Act. Therefore, 
for example, after January 1, 2023, the failure to render a prior 
authorization decision within the timeframe at proposed 42 CFR 
440.230(d)(1)(i) would be considered a failure to act with reasonable 
promptness and subject to fair hearing rights available to individuals 
under 42 CFR part 431, subpart E. Finally, existing regulations require 
that states grant Medicaid beneficiaries the opportunity for a fair 
hearing whenever a state takes an action as defined in 42 CFR 431.201. 
This definition includes ``a termination, suspension of, or reduction 
in covered benefits or services.'' Therefore, under the current 
definition of ``action'' at 42 CFR 431.201, any termination, suspension 
of, or reduction in benefits or services for which there is a current 
approved prior authorization is considered an action for which the 
state must afford a beneficiary the opportunity for a fair hearing in 
accordance with 42 CFR 431.220(a)(1).
    The proposed changes at 42 CFR 440.230(d)(1)(ii) are also intended 
to make it explicit in regulation text that existing Medicaid notice 
regulations apply to states' prior authorization

[[Page 82615]]

decisions. Under 42 CFR 435.917(a), a state must provide timely and 
adequate written notice of its prior authorization decisions, 
consistent with 42 CFR 431.206 through 431.214. This notice must 
include information about the beneficiary's fair hearing rights. Under 
our proposals, a state would be required to provide notice of a 
decision within the timeframes in 42 CFR 440.230(d)(1)(i) when the 
state approves or partially or totally denies a prior authorization 
request after January 1, 2023. However, whenever a state makes a prior 
authorization decision that is considered an action, including the 
termination, suspension of, or reduction in benefits or services for 
which there is a current approved prior authorization, the state must 
provide the individual at least 10 days advance notice consistent with 
42 CFR 431.211 prior to taking the action and afford the beneficiary 
the right to the continuation of services pending the resolution of the 
state fair hearing, in accordance with 42 CFR 431.230. Under 42 CFR 
431.206(c)(2), the state must inform the beneficiary in writing 
whenever a fair hearing is required per 42 CFR 431.220(a), which 
includes when a state has not acted upon a claim with reasonable 
promptness. For example, after January 1, 2023, this would mean that a 
state must also provide notice to the beneficiary when it fails to 
reach a decision on a prior authorization request within the timeframes 
in proposed 42 CFR 440.230(d)(1)(i).
    To enhance beneficiary notice, we are proposing to explicitly link 
the required notice content in 42 CFR 431.210 to denials of or changes 
in benefits or services for beneficiaries receiving medical assistance 
by proposing amendments to 42 CFR 435.917(b)(2) to include a reference 
to denials of or changes in benefits and services for beneficiaries 
receiving medical assistance. The notice content requirements at 42 CFR 
431.210 include a requirement that notices include a clear statement of 
the specific reasons supporting the intended action, so this proposed 
amendment would ensure that individuals receiving medical assistance 
who are denied benefits or services receive a notice clearly explaining 
the reasons for a denial. As we explained above, because a denial of a 
prior authorization request is a denial of a benefit or service, this 
change would also apply to notices for denials of prior authorization 
decisions.
    We note that the current application of existing notice and fair 
hearing requirements to Medicaid fee-for-service prior authorization 
decisions, which we propose to make explicit in regulation text, is 
consistent with current regulations for notice and appeal rights for 
managed care prior authorization decisions (sometimes referred to as 
service authorizations or adverse benefit determinations). See 42 CFR 
438.400 (definition of adverse benefit determination), 42 CFR 438.404 
(timely and adequate notice for adverse benefit determination), and 42 
CFR 438.420 (continuation of benefits while managed care plan appeal 
and the state fair hearing process are pending).
    As noted above, these proposed modifications generally apply 
existing regulations to prior authorization decisions and do not 
generally change Medicaid notice or fair hearing policy. As such, we 
propose that the revisions to 42 CFR 431.201, 431.220, 431.917, and 
440.230(d)(1)(ii) would be effective upon publication of the final 
rule, with the understanding that any notice or fair hearing rights 
based solely on new provisions proposed in this rulemaking would take 
effect in accordance with the proposed effective date for the proposed 
new provisions, including the proposed timeframes for notifications 
about prior authorization decisions. We seek comment both on how states 
apply these notice and fair hearing rights to prior authorization 
decisions currently and on our proposals. We also seek comment on 
whether we should change this policy through future rulemaking, and not 
require fair hearing rights for prior authorization denials.
    To implement the proposed authorization timeframes for Medicaid 
managed care, we also propose to revise 42 CFR 438.210(d)(1). Under our 
proposal, the new timeframes for Medicaid managed care plans to issue 
decisions on prior authorization requests would apply beginning with 
the rating period on or after January 1, 2023. Therefore, we propose to 
add at the end of the current regulation that, beginning with the 
rating period that starts on or after January 1, 2023, the state-
established timeframe that a decision may not exceed 7 calendar days 
following the plan's receipt of the request for service would go into 
effect. This effectively would limit the period of time that a Medicaid 
managed care plan must make and provide notice of an authorization 
decision to a maximum of 7 days (or fewer if the state establishes a 
shorter timeline) unless there is an extension. We propose that the 
authority to extend that timeframe by up to 14 additional calendar days 
would continue to apply. Our proposal would not change the current 
provisions for how failure to issue a decision within the required time 
frame constitutes an adverse benefit determination that can be appealed 
under 42 CFR 438.404(c)(5). Section 438.404 and the other regulations 
governing appeal rights in 42 CFR part 438, subpart F, would continue 
to apply. This is also consistent with how the definition of ``adverse 
benefit determination'' in 42 CFR 438.400(b) includes a failure of a 
Medicaid managed care plan to make an authorization decision within the 
regulatory timeframes. We also note that under current regulations at 
42 CFR 438.3(s)(1) and (s)(6) and 438.210(d)(3), Medicaid managed care 
plans must also comply with the requirements in section 1927 of the Act 
regarding coverage and prior authorization of covered outpatient drugs. 
Nothing in this proposed rule would change these requirements. We also 
note that Medicaid managed care plans that are applicable integrated 
plans as defined in 42 CFR 438.2 would continue to follow the decision 
timeframes defined in 42 CFR 422.631(d).
    We believe implementing these proposed prior authorization 
timeframes for Medicaid FFS and managed care programs would help states 
to ensure that they are furnishing medical assistance services with 
reasonable promptness as described in section 1902(a)(8) of the Act and 
with reasonable program safeguards to ensure that services would be 
provided in the best interests of the recipients, in accordance with 
section 1902(a)(19) of the Act. In addition, this proposal would 
implement section 1932(b)(4) of the Act, which provides that each 
Medicaid managed care organization must establish an internal grievance 
procedure under which an enrollee who is eligible for medical 
assistance may challenge the denial of coverage of or payment for such 
assistance. Reducing plan response time for prior authorizations should 
enable enrollees to file appeals timelier, when needed, and receive 
faster resolution. The prior authorization proposals in this rule, 
particularly the proposal to reduce the maximum amount of time for a 
managed care plan to make a standard prior authorization decision from 
14 days to 7 days, are consistent with how section 1932(c)(2)(A) of the 
Act indicates that timely access to care should be assured for 
enrollees. Currently, and under our proposal, 42 CFR 438.210 applies 
the same appeal and grievance requirements for PIHPs and PAHPs as for 
MCOs; for this proposal, we rely on our authority in section 1902(a)(4) 
to adopt these standards for PIHPs and PAHPs. This is consistent with 
our prior practice for adopting standards for Medicaid

[[Page 82616]]

managed care plans (81 FR 27507). We believe that the proposal to 
shorten the maximum amount of time for a plan to make a prior 
authorization decision from 14 days to 7 days would improve the 
efficient operation of the Medicaid program by facilitating faster 
receipt of services or filing of appeals.
    We are not proposing any changes to the required timeframes for 
expedited decisions at 42 CFR 438.210(d)(1) nor the authority for a 14-
day extension provided at 42 CFR 438.210(d)(1) and (2)(ii). This 
proposed requirement would be applicable to CHIP managed care through 
the cross reference to 42 CFR 438.210 in current 42 CFR 457.1230(d).
    To implement the proposed prior authorization timeframes for CHIP, 
we propose to revise 42 CFR 457.495, such that beginning January 1, 
2023, decisions related to prior authorization of health services would 
be required to be completed in accordance with the medical needs of the 
patient, but no later than 7 calendar days after the date of the 
receipt of the request for a standard determination and 72 hours 
following the receipt of the request for an expedited determination. We 
are retaining the authority for an extension of up to 14 days to be 
granted if the enrollee requests or the physician or health plan 
determines that additional information is needed. We propose to remove 
the option for states to follow existing state law regarding prior 
authorization of health services, requiring states to instead follow 
these updated timeframes. However, if state laws are more stringent, 
states are not prohibited from complying with enhanced decision 
timelines. We believe timely prior authorization decisions are an 
important beneficiary protection, and CHIP beneficiaries should be 
afforded the same decision timeframes as Medicaid beneficiaries. We 
seek comment on this proposal, and most specifically from states.
    Existing CHIP regulations at 42 CFR 457.1130(b) require a state to 
ensure that an enrollee has an opportunity for external review of 
health services matters, including a delay, denial, reduction, 
suspension, or termination of health services, in whole or in part, 
including a determination about the type or level of service. Under 
this regulation, CHIP enrollees must have an opportunity for external 
review of prior authorization decisions. We are not proposing any 
changes to this requirement, as it already applies to decisions related 
to the prior authorization of services.
    In the case of QHP issuers on the FFEs, regulations at 45 CFR 
147.136 establish internal claims and appeals processes, external 
review processes, and pre-service claims requirements for all non-
grandfathered group and individual market plans or coverage. 
Specifically, at 45 CFR 147.136(b)(3), individual health insurance 
issuers are required to meet minimum internal claims and appeals 
standards. To avoid adding to the burden that this proposal might 
impose by applying multiple, potentially inconsistent regulatory 
standards for individual and group market plans, we are considering, 
and solicit comments on, whether to extend the timeframes for 
processing of prior authorizations applicable to other payers, as 
discussed in this section, to QHP issuers on the FFEs. Specifically, we 
seek comment on whether having different processing timelines for prior 
authorizations for QHP issuers on the FFEs would be operationally 
feasible for issuers, or if such a requirement would have the 
unintended effect of increasing burden for issuers that are already 
subject to different requirements.\52\ Finally, we note that the 
alternative of making changes to regulations applicable to all non-
grandfathered group and individual market plans or coverage for 
consistency with our proposed approach here would be outside the scope 
of this regulation.
---------------------------------------------------------------------------

    \52\ We are not proposing in this proposed rule to impose on 
individual and group market plans generally timelines for processing 
of prior authorizations consistent with those we propose for other 
payers, as such requirements would require rulemaking by the 
Departments of Labor, the Treasury, and Health and Human Services.
---------------------------------------------------------------------------

    Overall, we believe that the decision timeframes proposed for the 
impacted payers in this rule would help ensure that prior authorization 
processes do not inappropriately delay patient access to necessary 
services. The introduction of decision timeframes that are the same 
across all impacted payers for items and services that require prior 
authorization would also help providers better organize and manage 
administrative resources and allow more time for providers to render 
patient-centered care. We believe these proposals would make 
substantive progress in improving the care experience for patients and 
lead to better health outcomes. In turn, better health outcomes would 
contribute to more efficient use of program resources.
    We request comment on these proposals, specifically those that 
include feedback on any unintended consequences of these proposed 
policies to reduce payer decision timeframes.
    In addition to comments on the proposals regarding timelines and 
notifications, we seek comment on several related topics. For example, 
are alternative timeframes feasible or appropriate for prior 
authorization for items and services?
    <bullet> Under what circumstances could payers approve an expedited 
prior authorization in less than the proposed 72 hours? Are there 
circumstances in which a payer should be required to approve an 
expedited prior authorization in 24 hours for items and services other 
than prescription or outpatient drugs? What are the operational and 
system requirements for a more streamlined scenario for prior 
authorization approvals?
    <bullet> Under what circumstances could an approval be provided in 
less than 7 calendar days for a complex case?
    <bullet> We also seek comment on process challenges with prior 
authorization. For example, are there scenarios that could be 
appropriate to support temporary coverage of services, such as, 
temporary access to DME, while the patient waits for an authorization 
during the 14-day review timeframe? What policy conditions might be 
necessary to include in such authorization determinations? Commenters 
are encouraged to provide examples of best-case and worst-case 
scenarios, and explain what changes in process, policy, or technology 
would be necessary.
7. Proposed Extensions, Exemptions and Exceptions for Medicaid and CHIP 
and QHP Issuers
a. Extensions and Exemptions for Medicaid and CHIP FFS Programs
    If our proposals regarding the DRLS and PAS APIs are finalized, we 
would strongly encourage state Medicaid and CHIP FFS programs to 
implement these APIs as soon as possible, in light of the many benefits 
of these APIs as discussed previously in this section. However, we also 
recognize that state Medicaid or CHIP FFS agencies could face certain 
unique circumstances that would not apply to other impacted payers, as 
discussed in more detail later in this section. As a result, a few 
states might need to seek an extension of the compliance deadline or an 
exemption from these requirements. To address this concern, we are 
proposing a process through which states may seek an extension of and, 
in specific circumstances, an exemption from, the DRLS and PAS API 
requirements if they are unable to implement these API requirements, 
consistent with the extension and exemption proposals for the Provider 
Access API in section II.B., and the Payer-to-Payer API in section 
II.D. of this proposed rule. Providing these flexibilities might allow 
these states to continue building technical

[[Page 82617]]

capacity in support of overall interoperability goals consistent with 
their needs. We therefore propose the following.
    Extension. At 42 CFR 431.80(b)(1) and 42 CFR 457.732(b)(1) 
respectively, we propose to provide states--for Medicaid FFS and CHIP 
FFS--the opportunity to request a one-time extension of up to one (1) 
year for the implementation of the PAS API specified at 42 CFR 
431.80(a)(1) and 42 CFR 457.732(a)(2) and DRLS API specified at 42 CFR 
431.80(a)(1) and 42 CFR 457.732(a)(1). Unique circumstances that might 
present a challenge to specific states to meet the proposed compliance 
date could include resource challenges, such as funding. Depending on 
when the final rule is published in relation to a state's budget 
process and timeline, some states may not be able to secure the needed 
funds in time to both develop and execute implementation of the API 
requirements by the proposed compliance data. A one-year extension 
could help mitigate this issue. And, some states may need to initiate a 
public procurement process to secure contractors with the necessary 
skills to support a state's implementation of these proposed API 
policies. The timeline for an open, competed procurement process, 
together with the time needed to onboard the contractor and develop the 
API, could require additional time as well. Finally, a state might need 
to hire new staff with the necessary skillset to implement this policy. 
Again, the time needed to initiate the public employee hiring process, 
vet, hire, and onboard the new staff may make meeting the proposed 
compliance timeline difficult, because, generally speaking, public 
employee hiring processes include stricter guidelines and longer time-
to-hire periods than other sectors.\53\ In all such situations, a state 
might need more time than other impacted payers to implement the 
requirements.
---------------------------------------------------------------------------

    \53\ State hiring processes are comparable with federal hiring 
processes. According to OMB, the average time-to-hire for federal 
employees was 98.3 days in 2018, significantly higher than the 
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

    If a state believes it can demonstrate the need for an extension, 
its request must be submitted and approved as a part of its annual 
Advance Planning Document (APD) for MMIS operations costs and must 
include the following: (1) A narrative justification describing the 
specific reasons why the state cannot reasonably satisfy the 
requirement(s) by the compliance date, and why those reasons result 
from circumstances that are unique to states operating Medicaid or CHIP 
FFS programs; (2) a report on completed and ongoing implementation 
activities to evidence a good faith effort toward compliance; and (3) a 
comprehensive plan to meet implementation requirements no later than 
one year after the initial compliance date.
    An extension would be granted if CMS determines based on the 
information provided in the APD that the request adequately establishes 
a need to delay implementation, a good faith effort to implement the 
proposed requirements as soon as possible, and a clear plan to 
implement no later than one year after the proposed compliance date. We 
would expect states to explain why the request for an extension results 
from circumstances that are unique to states operating Medicaid or CHIP 
FFS programs. We solicit comment on whether our proposal would 
adequately address the unique circumstances that affect states, and 
that might make timely compliance with the proposed API requirement 
sufficiently difficult for states, and thus justify an extension. In 
particular, we seek comment on whether we should require or use 
additional information on which to base the determination or whether we 
should establish different standards in the regulation text for 
evaluating and granting the request.
    Exemption. At 42 CFR 431.80(b)(2) and 42 CFR 457.732(b)(2), 
respectively, we propose two circumstances that would permit state 
requests for exemption; namely, (1) when at least 90 percent of all 
covered items and services are provided to Medicaid or CHIP 
beneficiaries through Medicaid or CHIP managed care contracts with 
MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or 
(2) when at least 90 percent of the state's Medicaid or CHIP 
beneficiaries are enrolled in Medicaid or CHIP managed care 
organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 
for CHIP. In both circumstances, the time and resources that the state 
would need to expend to implement the API requirements may outweigh the 
benefits of implementing and maintaining the API. As discussed in 
section II.B. of this proposed rule, unlike other impacted payers, 
state Medicaid and CHIP FFS programs do not have a diversity of plans 
to balance implementation costs for those plans with low enrollment. If 
there is low enrollment in a state Medicaid or CHIP FFS program, there 
is no potential for the technology in which they have invested to be 
leveraged for additional beneficiaries as states, unlike other payers, 
do not maintain additional lines of business.
    We acknowledge that the proposed exemption could mean that a few 
Medicaid or CHIP FFS systems would not receive the benefits of having 
these APIs available to facilitate health information exchange. To 
address this, we propose that states meeting the above thresholds would 
be expected to employ an alternative plan to enable the electronic 
exchange and accessibility of health information for those 
beneficiaries who are served under the FFS program.
    A state meeting the above criteria would be permitted to submit a 
request for an exemption to the requirements for the DRLS and PAS APIs 
once per calendar year for a one (1) year exemption. The state would be 
required to submit this annual request as part of a state's annual APD 
for MMIS operations costs. The state would be required to include in 
its request document that it meets the criteria for the exemption using 
data from any one of the three most recent and complete calendar years 
prior to the date the exemption request is made. We propose that this 
request be made annually as from year-to-year the nature of the FFS 
population could change and so it is important that the state provide 
the most current information for CMS's consideration.
    Exemptions would be granted for a one-year period if a state 
establishes to CMS's satisfaction that it meets the criteria for the 
exemption and has established a plan to ensure that providers would 
have efficient electronic access to the same information through 
alternative means.
    We request comment on the proposed extension and exemption.
    For Medicaid and CHIP managed care, we are not proposing an 
extension process at this time because we believe that managed care 
plans are actively working to develop the necessary IT infrastructure 
to be able to comply with the existing requirements in 42 CFR part 438 
and part 457, and also benefit from efficiencies resulting from their 
multiple lines of business impacted by these interoperability policies. 
Many managed care plans are part of parent organizations that maintain 
multiple lines of business, including plans on the Exchanges. As 
discussed in the CMS Interoperability and Patient Access final rule (85 
FR 25607, 25612, 25620), work done by these organizations can benefit 
all lines of business and, as such, we do not believe that the 
proposals in this rule impose undue burden or are unachievable by the 
compliance date. We are soliciting comment on whether

[[Page 82618]]

our belief concerning the scope of resources and ability of managed 
care parent organizations to achieve economies of scale is well-
founded. Further, we seek comment on whether an extension process is 
warranted for certain managed care plans to provide additional time for 
the plan to comply with requirements at proposed 42 CFR 431.80(a)(1) 
and 431.80(a)(2), which cross references 42 CFR 438.242(b)(5) for 
Medicaid managed care plans and at proposed 42 CFR 457.732(a)(1) and 
457.732(a)(2) which cross reference 42 CFR 457.1223(d)(2) for CHIP 
managed care entities. While we are not proposing such a process for 
managed care plans and entities and do not believe one is necessary for 
the reasons outlined here, we are open to considering one if necessary. 
If we adopt an extension process for these managed care plans and 
entities, what criteria would a managed care plan or entity have to 
meet to qualify for an extension? Should the process consider, for 
example, enrollment size, plan type, or some unique characteristic of 
certain plans that could hinder their implementation of the proposed 
requirements by the proposed compliance date? Also, we seek comment on 
whether, if we finalize such a process for Medicaid managed care plans 
or CHIP managed care entities, the state or CMS should manage the 
process and whether states could successfully adopt and implement the 
process on the timeline necessary to fulfill the goals and purpose of 
the process. Consistent with the exception process proposed for QHP 
issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension 
request to include, at a minimum, a narrative justification describing 
the reasons why a plan or entity cannot reasonably satisfy the 
requirements by the proposed compliance date, the impact of non-
compliance upon enrollees, the current or proposed means of providing 
electronic health information to providers, and a corrective action 
plan with a timeline to achieve compliance.
    We request comment on this proposal.
b. Exceptions for QHP Issuers
    For QHP issuers on the FFEs, we propose an exceptions process to 
the DRLS API requirements proposed at 45 CFR 156.223(a)(1) and the PAS 
API requirements at proposed at 45 CFR 156.223(a)(2). We propose that 
if an issuer applying for QHP certification to be offered through an 
FFE believes it cannot satisfy the requirements to establish one or 
both of these APIs, the QHP issuer would have to include, as part of 
its QHP application: (1) A narrative justification describing the 
reasons why the plan cannot reasonably satisfy the requirements for the 
applicable plan year; (2) the impact of non-compliance upon enrollees; 
(3) the current or proposed means of providing health information to 
providers; and (4) solutions and a timeline to achieve compliance with 
the requirements of this section. Further, we propose that the FFE may 
grant an exception if it determines that making a health plan available 
through the FFE is in the interests of qualified individuals in the 
state or states in which such FFE operates. This exceptions process is 
proposed at 45 CFR 156.223(b). As we noted in the Interoperability and 
Patient Access Final Rule at 45 CFR 156.221(h), we anticipate that the 
exception would be provided in limited situations. For example, we 
would consider providing an exception to small issuers, issuers who are 
only in the individual market, financially vulnerable issuers, or new 
entrants to the program who demonstrate that deploying standards based 
API technology would pose a significant barrier to the issuer's ability 
to provide coverage to consumers, however, not certifying the issuer's 
QHP or QHPs would result in consumers having few or no plan options in 
certain areas. We believe that having a QHP issuer offer QHPs through 
an FFE is in the best interests of consumers. We seek comment on other 
circumstances in which the FFE should consider granting an exception.
    We request comment on these proposed extensions, exemptions and 
exceptions for Medicaid and CHIP FFS, Medicaid and CHIP managed care, 
and the QHP issuers on the FFEs.
8. Public Reporting of Prior Authorization Metrics
    We are proposing to require impacted payers to publicly report 
certain prior authorization metrics on their websites at the state-
level for Medicaid and CHIP FFS, at the plan-level for Medicaid and 
CHIP managed care, and at the issuer-level for QHP issuers on the FFEs. 
As discussed in section II.C.11. of this proposed rule, publicly 
reporting these metrics would support efficient operations, timely 
service, and ensure prior authorization processes are executed in such 
a way as to be in the best interest of patients. Specifically, public 
reporting of this information would provide patients and providers with 
important information about Medicaid managed care plans, CHIP managed 
care entities, and QHP issuers when the patient is making a decision 
about a plan. When looking for a new plan, patients may compare a 
variety of factors including, but not limited to, access to care 
(authorizations), premiums, benefits, and cost sharing or coinsurance. 
We believe access to care is a critical factor for patients to consider 
when choosing a plan, and transparency regarding prior authorization 
processes could be an important consideration.
    Similarly, providers may find metrics about prior authorization 
approvals or appeals useful when selecting payer networks to join, and 
when considering whether to contract with a payer. Providers should be 
armed with information about how they will be able to treat their 
patients, and whether that will be in a manner they believe will 
support value-based care and services that are appropriate and 
necessary for each patient's health.
    Therefore, we are proposing to require state Medicaid and CHIP FFS 
programs at 42 CFR 440.230(d)(2) and 457.732(a)(3), respectively; 
Medicaid managed care plans at 42 CFR 438.210(f); CHIP managed care 
entities through operation of existing 42 CFR 457.1233(d)(2); and QHP 
issuers on the FFEs at 45 CFR 156.223(a)(3) to publicly report, at 
least annually, prior authorization metrics on their websites or via 
publicly accessible hyperlink(s). We propose that each metric would be 
reported separately for each item and service, not including 
prescription drugs and/or covered outpatient drugs, and that the data 
would be required to be publicly reported for each metric. We propose 
that these metrics would include, at a minimum, the following:
    <bullet> A list of all items and services that require prior 
authorization;
    <bullet> The percentage of standard prior authorization requests 
that were approved, reported separately for items and services;
    <bullet> The percentage of standard prior authorization requests 
that were denied, reported separately for items and services;
    <bullet> The percentage of standard prior authorization requests 
that were approved after appeal, reported separately for items and 
services;
    <bullet> The percentage of prior authorization requests for which 
the timeframe for review was extended, and the request was approved, 
reported separately for items and services;
    <bullet> The percentage of expedited prior authorization requests 
that were approved, reported separately for items and services;
    <bullet> The average and median time that elapsed between the 
submission of a request and a decision by the payer, plan or issuer, 
for standard prior

[[Page 82619]]

authorizations, reported separately for items and services.
    In this proposal, when we state ``reported separately for items and 
services,'' we mean each payer would report a percentage for all prior 
authorization requests in a given year that meet the specified criteria 
for requests that were for items and a percentage for all prior 
authorization requests that year for the same criteria that were for 
services. In this way, a payer's prior authorization requests would be 
separated into two distinct categories, and these metrics would, if 
this proposal is finalized, be reported for each of these categories.
    By sharing information about prior authorization requirements for 
items and services, and data about prior authorization decisions, 
patients and providers would have a better understanding of a payer's 
prior authorization review and approval processes. Such information may 
be helpful for making decisions at the time of open enrollment, special 
enrollment, or plan selection throughout the year. We are proposing 
that, beginning March 31, 2023, these data be publicly reported 
annually, by the end of the first calendar quarter each year for the 
prior year's data. For example, for all impacted payers, all available 
data for calendar year 2022 would be publicly reported by the end of 
the first calendar quarter of 2023, or by March 31, 2023.
    We acknowledge that the first set of publicly available data would 
reflect current practices, rather than payer behavior based on 
compliance with this proposed rule. However, should our proposals be 
finalized, we anticipate that, over time, data might show improvements. 
In addition, year-over-year comparisons could demonstrate positive (or 
negative) trends, which alone could be useful information for patients 
who are making enrollment decisions. Publicly available data would aid 
interested providers and patients in understanding payer performance 
with respect to prior authorization processes for decisions, approvals, 
denials, and appeals.
    We request comments on the proposed reporting of metrics on prior 
authorization requests, including comments on the proposal to report a 
separate percentage for all prior authorization requests in a given 
year that meet the criteria for items and a separate percentage for all 
prior authorization requests that year for the criteria that were for 
services, and comments on the proposed reporting dates.
    In order to more directly facilitate the incorporation of such data 
into a consumer-friendly comparison tool, we may consider proposing in 
future rulemaking to use these data to help develop quality measures to 
incorporate into quality star ratings across certain payer programs 
over time, specifically for QHP issuers on the FFEs.
    For Medicaid managed care, we propose to remove the text currently 
at 42 CFR 438.210(f), which addresses the applicability date for the 
provisions in that section. That text was added in 2016 to clarify that 
the prior requirements in that section would remain in effect until the 
new provisions begin starting with rating periods beginning on or after 
July 1, 2017. As several rating periods have passed since July 1, 2017, 
we do not believe this clarifying text is needed. We propose to replace 
the current text at 42 CFR 438.210(f) with the proposed public 
reporting of prior authorization metrics, as explained above.
9. Request for Comments on ``Gold-Carding'' Programs for Prior 
Authorization
    During the CMS listening sessions, we heard about the potential for 
additional efficiencies in the prior authorization process, through 
certain payer policies, including decisions about when to require prior 
authorization. For example, prior authorization is sometimes required 
for certain items and services that are almost always approved or for 
some providers who have demonstrated a history of complying with all 
payer requirements. Stakeholders stated that it could be more efficient 
and cost effective if prior authorization requirements were minimized 
or removed in these cases.
    Some payers have implemented what they term ``gold-carding'' or 
similar programs to relax or reduce prior authorization requirements 
for providers that have demonstrated a consistent pattern of 
compliance. For example, some payers have relieved certain providers 
from the requirement to request prior authorizations based on data 
indicating adherence to submission requirements, appropriate 
utilization of items or services, or other evidence-driven criteria 
that they deem relevant. CMS uses an approach similar to gold-carding 
in the Medicare FFS Review Choice Demonstration for Home Health 
Services, under which home health agencies in demonstration states that 
select certain review choice options and have a review affirmation rate 
or claim approval rate of 90 percent or greater over 6 months are given 
the option to continue in the pre-claim review program or choose a 
selective post-payment review or spot check review process.\54\
---------------------------------------------------------------------------

    \54\ Centers for Medicare and Medicaid Services. (2019, October 
7). Review Choice Demonstration for Home Health Services. Retrieved 
from https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/Review-Choice-Demonstration/Review-Choice-Demonstration-for-Home-Health-Services.html.
---------------------------------------------------------------------------

    We believe the use of gold-carding programs could help alleviate 
provider burden related to prior authorization and believe these 
programs could facilitate more efficient and prompt delivery of health 
care services to beneficiaries. We encourage payers to adopt gold-
carding approaches that would allow prior authorization exemptions or 
more streamlined reviews for certain providers who have demonstrated 
compliance with requirements. Gold-carding policies could reduce burden 
on providers and payers, while improving the patient experience. By 
taking this step, payers can join CMS in helping to build an 
infrastructure that would allow clinicians to deliver care in a timely 
and value-based manner. While we are not including any proposals here, 
and are not intending to be overly prescriptive in defining 
requirements in future rulemaking for gold-carding programs, we 
emphasize the importance of reducing provider burden and seek comment 
for consideration for future rulemaking on how best to measure whether 
and how these types of approaches and programs actually reduce provider 
and payer burden.
    To further encourage the adoption and establishment of gold-carding 
programs, we have considered including gold-carding as a factor in 
quality star ratings, where applicable, as a way for payers to raise 
their score in the quality star ratings for QHP issuers. We seek 
comment for potential future rulemaking on the incorporation of gold-
carding into star ratings for QHP issuers on the FFEs. We also 
considered proposing gold-carding as a requirement in payer's prior 
authorization policies and seek comment on how such programs could be 
structured to meet such a potential requirement.
10. Additional Requests for Comment
    We seek comment on additional topics pertaining to prior 
authorization, as feedback may be useful for future rulemaking.
    We understand from our listening sessions that there may be 
opportunities to improve the prior authorization process for 
individuals with chronic medical conditions. For example, when a 
patient has a chronic condition that

[[Page 82620]]

requires ongoing treatment, the provider is often required to resubmit 
repeated prior authorization requests for the same service, each time 
treatment is needed. One such condition described in listening sessions 
was macular degeneration. Patients shared their experience of needing 
monthly prior authorizations for their monthly injection treatments, 
despite the fact that those injections are required to avoid loss of 
vision, and despite the fact that there is no cure for their condition. 
Repeatedly submitting a prior authorization request for the same item 
or service, which is always approved, creates a burden on both the 
patient and the provider and adds costs to the overall health care 
system. We seek comment on whether there should be certain restrictions 
regarding requirements for repeat prior authorizations for items and 
services for chronic conditions, or whether there can be approvals for 
long term authorizations. What alternative programs are in place or 
could be considered to provide long-term authorizations for terminal or 
chronic conditions?
    Another topic identified in listening sessions was patient concerns 
about losing access to approved services after changing health plans. 
Patients expressed concern about being able to continue a specific 
course of care where, for example, they might be in the middle of an 
approved course of care requiring physical therapy, but then change 
health plans (payer). We seek comments on whether a prior authorization 
decision should follow a patient when they change from one qualified 
health plan on the Exchange to another, or to another health plan 
impacted by this proposed rule, and under what circumstances that prior 
authorization could follow a patient from payer to payer. We also seek 
comment for potential future rulemaking on other prior authorization 
topics, such as whether prior authorizations should be valid and 
accepted for a specified amount of time. We are interested in comments 
on who should determine how long an existing approved prior 
authorization from a previous payer should last and whether prior 
authorization should be regulated by amount of time and/or by 
condition.
    An additional topic from our listening sessions was the issue of 
the number of different forms used by payers for prior authorization 
requests, each with different information requirements (data elements) 
and methods for submission. The lack of standard forms and requirements 
from payers is considered burdensome and time consuming for both 
patients and providers. We request input on solutions to standardizing 
prior authorization forms, including the possibility of developing an 
HL7 FHIR based questionnaire for prior authorization requests. Input on 
requiring the use of a standardized questionnaire could inform future 
rulemaking.
    Finally, we request comments on how to potentially phase out the 
use of fax technology to request and send information for prior 
authorization decisions. As we described earlier in this section, we 
believe the standards-based API process should be the preferred and 
primary form of exchanging prior authorization communications. However, 
we acknowledge that providers could vary in their ability to develop 
and implement API-based prior authorization submission and receipt 
technology and that there must be a channel for prior authorization for 
providers whose systems are not API-capable. In particular, we 
anticipate that providers in rural areas, small providers, and certain 
types of service providers, such as home and community-based services 
providers in Medicaid, may be subject to prior authorization processes 
but may not have the technical expertise, access to high speed 
internet, infrastructure, or financial resources to implement 
connectivity with and use the DRLS and PAS APIs. Further, non-API 
mechanisms like fax, phone, and web portals may be needed in times when 
other technology is not available or other unexpected emergencies. We 
request comment on how payers and providers might begin to phase out 
the use of fax technology, and what barriers must still be overcome to 
accomplish this goal.
    As mentioned previously in this proposed rule, although Medicare 
FFS is not directly impacted by this rule, we do note that we are 
evaluating implementation of these provisions, if finalized. In this 
way, Medicare FFS implementations would conform to the same 
requirements that apply to the impacted payers under this rulemaking, 
as applicable, so that participating Medicare providers and 
beneficiaries would benefit from the APIs and process improvements.
11. Statutory Authorities To Require Prior Authorization Burden 
Reduction Proposals
a. Medicaid and CHIP
    For the reasons discussed below, our proposed requirements in this 
section for Medicaid managed care plans and Medicaid state agencies 
fall generally under our authority in section 1902(a)(4) of the Act, 
which requires that a state Medicaid plan provide such methods of 
administration as are found by the Secretary to be necessary for the 
proper and efficient operation of the state Medicaid plan. The 
proposals in this section are also authorized under section 1902(a)(8) 
of the Act, which requires states to ensure that Medicaid services are 
furnished with reasonable promptness to all eligible individuals. 
Additionally, they are authorized by section 1902(a)(19) of the Act, 
which requires states to ensure that care and services are provided in 
a manner consistent with simplicity of administration and the best 
interests of the recipients.
    The proposed requirement for the states and Medicaid managed care 
plans to implement the DRLS and PAS API (section II.C.3. and II.C.4. of 
this proposed rule; statutory authority for proposals to require 
specific IGs is discussed in section II.A.3. of this proposed rule) is 
expected to improve the efficiency and timeliness of the prior 
authorization process for Medicaid beneficiaries, providers, and state 
Medicaid agencies and Medicaid managed care plans by addressing 
inefficiencies that appear to exist in the process today. These 
proposals would ensure that all states and Medicaid managed care plans 
would provide easily accessible information about when a prior 
authorization is required, and what documentation requirements must be 
fulfilled to submit the request. The DRLS API would allow a provider to 
determine if a prior authorization is required, and what the 
documentation requirements are for that prior authorization request. 
When using the PAS API, the state or Medicaid managed care plan would 
send a real time response to a provider's request with the status of 
the request included. Use of these APIs by states (for FFS programs) 
and managed care plans could ensure that Medicaid providers are able to 
submit a request for a prior authorization with the correct and 
complete documentation, and avoid an incorrect submission which might 
result in an unnecessary denial. The PAS API would: (i) Enable 
providers to submit a prior authorization request faster and easier, 
(ii) support more timely notice to provider and beneficiary of the 
disposition of the prior authorization request sooner, and (iii) permit 
faster scheduling of services or filing appeals, depending on the 
decision. The DRLS API and the PAS API both have the potential to 
improve the prior

[[Page 82621]]

authorization process by making it more efficient, including by 
limiting the number of denials and appeals, or even by eliminating 
requests for additional documentation, as noted elsewhere. For the 
state, these requirements would thus align with section 1902(a)(4) of 
the Act, which requires that a state Medicaid plan provide such methods 
of administration as are found by the Secretary to be necessary for the 
proper and efficient operation of the state Medicaid plan. For the 
Medicaid managed care program, these requirements align with section 
1932(c)(1)(A)(i) of the Act, which requires that states using managed 
care organizations must develop and implement a quality assessment and 
improvement strategy that includes standards for evaluating access to 
care so that covered services are available within reasonable 
timeframes.
    The proposal would implement section 1932(b)(4) of the Act, which 
provides that each Medicaid managed care organization must establish an 
internal grievance procedure under which an enrollee who is eligible 
for medical assistance may challenge the denial of coverage of or 
payment for such assistance. This proposal would enable enrollees to 
file appeals, when needed, and support them in receiving resolution.
    Our proposal to clarify that current notice and fair hearing 
requirements apply to Medicaid fee-for-service prior authorization 
decisions is authorized under section 1902(a)(3) of the Act. Section 
1902(a)(3) of the Act requires that a Medicaid state plan provide for 
granting an opportunity for a fair hearing to any individual whose 
claim for medical assistance under the plan is denied or is not acted 
upon with reasonable promptness. These proposed clarifications are also 
supported by the 14th Amendment to the United States Constitution and 
case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254 
(1970). States must establish timely notice and fair hearing processes 
meeting due process standards under Golberg v. Kelly, as incorporated 
into existing Medicaid fair hearing regulations at 42 CFR part 431, 
subpart E; see 431.205(d).
    The proposed requirement that states and Medicaid managed care 
plans meet certain timeframes to provide notice of decisions for prior 
authorizations, including the requirements that expedited decisions be 
made and communicated in 72 hours and standard decisions be made and 
communicated in 7 calendar days, may provide an improvement from the 
current standards for decision timeframes for Medicaid managed care 
(section II.C.6. of this proposed rule). The proposal is intended to 
establish more certainty in the prior authorization process for 
Medicaid providers and enhance beneficiary access to timely and 
appropriate care, consistent with states' obligations to provide 
Medicaid services with reasonable promptness and in a manner consistent 
with beneficiaries' best interests. Improved decision timeframes could 
improve communication to providers and beneficiaries, as well as 
increase access to care. The proposal is consistent with, and might 
help states comply with, section 1902(a)(8) of the Act, which requires 
the provision of medical assistance with reasonable promptness. A 
uniform and consistent timeline for Medicaid program prior 
authorization decisions might improve beneficiaries' prompt access to 
Medicaid-covered services.
    Standardizing Medicaid prior authorization decision timeframes 
could also support process improvements for the state and Medicaid 
managed care plans, including the creation of standard operating 
procedures and internal metric reports for program operations. This is 
consistent with section 1902(a)(4) of the Act, which requires that a 
state Medicaid plan provide such methods of administration as are found 
by the Secretary to be necessary for the proper and efficient operation 
of the state Medicaid plan.
    The proposal is also authorized under section 1902(a)(17) of the 
Act, as implemented under the existing Medicaid regulations at 42 CFR 
440.230. This section of the Act requires state Medicaid programs to 
establish reasonable standards that are consistent with the objectives 
of title XIX of the Act to determine the extent of covered medical 
assistance. As set forth at 42 CFR 440.230, these standards could 
include appropriate limits on a service based on such criteria as 
medical necessity or on utilization control procedures, so long as each 
service is sufficient in amount, duration, and scope to reasonably 
achieve its purpose. Items and services covered under Title XIX benefit 
authorities are subject to 42 CFR 440.230, unless statute or regulation 
expressly provides for an exception or waiver. This would include 
covered items and services described in sections 1905(a), 1915(c), 
1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any 
other authorities as established by Congress.
    The proposal is also consistent with section 1902(a)(19) of the 
Act, which requires that care and services be provided in a manner 
consistent with simplicity of administration and the best interests of 
recipients, because it is expected to help make the prior authorization 
process less burdensome for the state, providers, and beneficiaries. 
The proposed requirements and standards could result in more prompt 
prior authorization decisions, improve delivery of covered services, 
and improve efficiency of operations for the program, thereby serving 
the best interest of Medicaid beneficiaries.
    Our proposal to require states and Medicaid managed care plans to 
publicly report prior authorization metrics (section II.C.8. of this 
proposed rule) would support CMS and state Medicaid agency oversight, 
and evaluation and administration of the state plan, as it would allow 
for an evaluation of the implementation of the policies proposed in 
this rule. The data may indicate that payers have implemented the APIs 
(by showing improvements in prior authorization numbers) or made other 
improvements in policies and processes that result in improved metrics 
in the areas that we propose to be reported. Section 1902(a)(6) of the 
Act authorizes us to request reports from state Medicaid agencies in 
such form and containing such information as the Secretary may require 
from time to time. By reporting metrics, states and Medicaid managed 
care plans could review data to identify areas for improvement. 
Requiring Medicaid managed care plans to publicly report their prior 
authorization metrics would hold them accountable and enable them to 
more easily monitor their own performance and identify process 
improvement opportunities which could be an integral part of 
implementing a quality assessment and improvement strategy, consistent 
with the requirements for quality strategies for managed care programs 
at section 1932(c)(1)(A)(i) of the Act.
    For CHIP, we propose these requirements under the authority in 
section 2101(a) of the Act, which sets forth that the purpose of title 
XXI is to provide funds to states to provide child health assistance to 
uninsured, low-income children in an effective and efficient manner 
that is coordinated with other sources of health benefits coverage. 
This provision authorizes us to adopt these requirements for CHIP 
because they would also provide access to program data, which can 
improve the efficacy of CHIP programs, and allow for more efficient 
administration of services.
    As discussed above, we propose to require implementation of the 
DRLS API and PAS API (section II.C.3. and II.C.4.

[[Page 82622]]

of this proposed rule; statutory authority for proposals to require 
specific IGs is discussed in section II.A.3. of this proposed rule) to 
improve the prior authorization process for patients, providers and 
payers by addressing deficiencies and inefficiencies that exist in the 
current process. Today, a payer's rules about when a prior 
authorization is required, and what documentation requirements must be 
fulfilled to submit the request are not easily accessible for 
providers, which requires phone calls, access to multiple websites, and 
use of hard copy manuals, etc. This takes time away from actual patient 
care. The DRLS API allows a provider to determine if a prior 
authorization is required, and what the documentation requirements are 
for that prior authorization request. While we expect providers to be 
the primary stakeholders that benefit from the DRLS API, making this 
information available in a standardized way and permitting access 
through an API also serves the requirements in section 2101(a) of the 
Act that CHIP ensure access to coverage and coordinate care.
    The proposed PAS API would be a mechanism for receiving and 
responding to requests for coverage determinations before the services 
are furnished; the PAS APIs would streamline the initial authorization 
process for the payer, by sharing this information in an easily 
accessible way; this also allows the provider to know what to do if a 
prior authorization is required for a certain service, which improves 
the providers ability to treat the patient timely. The proposed PAS API 
would enable the payer to send a real time response back to a provider, 
based on a request for authorization. This too would improve the 
efficiency of providing services to the patient, because the request 
and response would be automated, and in real time. Payer use of these 
APIs could ensure that a provider is able to submit a request for a 
prior authorization with the correct and complete documentation to 
avoid an incorrect submission which might result in an unnecessary 
denial. The PAS API would: (i) Enable providers to submit a prior 
authorization request faster and easier, (ii) support more timely 
notice to provider and enrollee of the disposition of the prior 
authorization request, and (iii) permit faster scheduling of services 
or filing appeals, depending on the decision. The DRLS API and the PAS 
API both have the potential to improve the prior authorization process 
by making it more efficient, including limiting the number of denials 
and appeals, or even eliminating requests for additional documentation, 
as noted elsewhere.
    The proposed requirement that CHIP FFS and managed care entities 
meet certain timeframes to provide decisions for prior authorizations, 
including the requirement that expedited decisions be given in 72 hours 
and standard decisions be given in 7 calendar days, is an improvement 
from the current state, when there is uncertainty about expectations 
for when a prior authorization might be approved (section II.C.6. of 
this proposed rule). The proposal is intended to establish more 
certainty in the prior authorization process for providers and enhance 
patient access to timely and appropriate care. As payers provide notice 
under a shorter timeframe, patients would have more timely access to 
care. This is often not the case today, as providers and patients could 
wait longer for the payer to respond to a request for certain services. 
This could have an impact on health, particularly for individuals with 
chronic conditions or who have health risks. Improving certainty around 
decision timeframes could also reduce administrative time and expense, 
because providers would not need to make repeat inquiries to payers for 
a status on the authorization request. The proposal to improve 
timeliness in responding to providers and patients could support 
process improvements for the state and managed care programs and is 
consistent with our authorities under section 2101(a) of the Act in 
that they improve the efficiency of the CHIP programs.
    Our proposal to require CHIP FFS and CHIP managed care entities to 
report prior authorization metrics also supports the states oversight, 
evaluation and administration responsibilities, as it would allow us to 
evaluate the impact of the prior authorization policies in this 
proposed rule (section II.C.8. of this proposed rule). The data may 
indicate use of the APIs (improvements in prior authorization numbers) 
or changes in total numbers, denials and appeals.
b. QHP Issuers on the FFEs
    For QHP issuers on the FFEs, we are proposing these new 
requirements pursuant to the authority of section 1311(e)(1)(B) of the 
Affordable Care Act, which affords the Exchanges the discretion to 
certify QHPs if the Exchange determines that making available such 
health plans through the Exchange is in the interests of qualified 
individuals in the state in which the Exchange operates.
    We believe that the policies included here would improve the 
efficiency of the issuers who are certified to participate in the QHP 
program and improve the quality of services they provide to providers 
and their patients. Qualified individuals in FFEs may receive covered 
services more quickly, and the information may be more accurate with 
the use of the APIs. These proposals could improve the quality of the 
patient experience with their providers by increasing the efficiency in 
the prior authorization submission and review process. Therefore, we 
believe generally, that certifying only health plans that implement 
FHIR based APIs and adhere to the other proposals herein, would be in 
the interests of qualified individuals in the state or states in which 
an FFE operates. We encourage SBEs to consider whether a similar 
requirement should be applicable to QHP issuers participating in their 
Exchanges.
    In sections II.C.3. and II.C.4. of this rule, we propose that QHPs 
implement two APIs for the prior authorization process (statutory 
authority for proposals to require specific IGs are discussed in 
section II.A.3. of this proposed rule). The DRLS API would allow 
providers to quickly and efficiently know if a prior authorization is 
needed and locate the documentation requirements easily. This would 
enable faster, more accurate submission of prior authorization requests 
and potentially more prompt delivery of services. We also propose that 
QHPs implement a PAS API, to allow providers to efficiently, and with 
greater simplicity submit prior authorization requests directly from 
within their workflow and would allow QHP issuers to respond to the 
prior authorization request quickly and efficiently, thus enabling more 
prompt delivery of services.
    We also include in our proposal that QHPs provide a denial reason 
when sending a response to a prior authorization request, to facilitate 
better communication and understanding between the provider and issuer. 
This could enable efficient resubmission of the prior authorization 
request with additional information or an appeal, which could more 
promptly facilitate the needed patient care.
    Finally, proposing to require QHP issuers to publicly report prior 
authorization metrics would hold issuers accountable to their providers 
and patients, which could help them improve their program 
administration (section II.C.8. of this proposed rule.). These data 
could help QHPs evaluate their processes and determine if there are 
better ways to leverage the APIs, including the quality and sufficiency 
of

[[Page 82623]]

the coverage and documentation information included in the APIs.

D. Payer-to-Payer Data Exchange on FHIR

1. Background
    Research shows that the more complete a patient's record is, and 
the more data there are at the point of care, the better patient 
outcomes can be.\55\ More data lead to better-coordinated care and more 
informed decision-making. Data sharing among payers is one powerful way 
to facilitate this critically valuable flow of information through the 
health care ecosystem. As a result, in the CMS Interoperability and 
Patient Access final rule, we finalized a requirement for certain 
impacted payers to exchange, at a minimum, clinical information as 
defined in the USCDI version 1 (85 FR 25568 through 25569). We did not 
specify an API standard for data sharing in that final rule, however, 
understanding at the time that there may be a variety of transmission 
solutions that payers could employ to meet this requirement. We did 
encourage impacted payers to consider the use of a FHIR-based API in 
line with the larger goal of leveraging FHIR-based APIs to support a 
number of interoperability use cases for improving patient, provider, 
and payer access to health care data in order to reduce burden, 
increase efficiency, and ultimately facilitate better patient care. In 
addition, we also signaled our intent to consider a future requirement 
to use FHIR-based APIs for payer-to-payer data sharing, envisioning the 
increasing implementation of FHIR-based APIs within the industry.
---------------------------------------------------------------------------

    \55\ Office of the National Coordinator. (2019, June 4). 
Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.
    \55\ See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
    \55\ HL7 International. (n.d.). Da Vinci Payer Coverage Decision 
Exchange (PCDE) FHIR IG. Retrieved from http://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
    \55\ State hiring processes are comparable with federal hiring 
processes. According to OMB, the average time-to-hire for federal 
employees was 98.3 days in 2018, significantly higher than the 
private sector average of 23.8 days. See https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

    In the time since we proposed the initial payer-to-payer data 
exchange requirements in the CMS Interoperability and Patient Access 
rule, we have begun to leverage new tools, most notably the HL7 FHIR 
Bulk Data Access (Flat FHIR) specification, as discussed in more detail 
in section II.B. of this proposed rule. We believe the HL7 FHIR Bulk 
Data Access (Flat FHIR) specification, in particular, provides an 
opportunity to continue to build upon the requirement for payer-to-
payer data sharing in a way that adds valuable efficiencies for payers, 
further simplifying administration and reducing burden. We believe that 
the suite of tools that the CMS Interoperability and Patient Access 
final rule (85 FR 25510) requires and that this proposed rule would 
require for payers would ultimately lead to payers having more complete 
information available to share with patients and providers. As a 
result, we are now proposing an enhanced set of payer-to-payer data-
sharing requirements that would build on the policy finalized in the 
CMS Interoperability and Patient Access final rule (85 FR 25568 through 
25569) by leveraging FHIR-based APIs to further support greater 
interoperability and information flow.
2. Payer-to-Payer Data Exchange on FHIR
    There are three primary proposals we are making regarding the 
payer-to-payer data exchange in this proposed rule. First, we propose 
to extend the payer-to-payer data exchange to state Medicaid and CHIP 
FFS programs at 42 CFR 431.61(b) and 457.731(b). We previously 
finalized in the CMS Interoperability and Patient Access final rule (85 
FR 25568 through 25569) that MA organizations, Medicaid managed care 
plans, CHIP managed care entities, and QHP issuers on the FFEs were 
required, at the patient's request, to share a specified subset of 
clinical data with another payer of the patient's choice.
    Second, we propose to enhance this payer-to-payer data exchange 
triggered by a patient's request beyond what was previously finalized 
(for MA organizations, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs) in the CMS Interoperability and 
Patient Access final rule. In the final rule, we required impacted 
payers to exchange, at the patient's request, clinical data as defined 
in the USCDI, but we did not finalize in what electronic form or how 
these data would be transmitted. In this rule, we are proposing to 
require a FHIR-based API for this data exchange. In addition, we 
propose that this standards-based API must be conformant with specific 
IGs. We also propose that this Payer-to-Payer API, at the patient's 
request, must make not just clinical data as defined in the USCDI 
available, but also claims and encounter data (not including cost 
information), and information about pending and active prior 
authorization decisions. We propose these enhancements to the required 
payer-to-payer exchanges for Medicaid managed care plans (other than 
NEMT PAHPs) at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 
CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 
156.221(f)(2). We are also proposing to include these enhancements as 
part of extending the payer-to-payer data exchange requirements to 
Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 
457.731(b). We believe these proposed enhancements would facilitate 
more efficient data sharing between payers. In addition, the proposed 
additions to the data the API must be able to share would be consistent 
with the proposals discussed in sections II.A. and II.B. of this 
proposed rule, which would require these payers to share the same types 
of data with patients and providers via FHIR-based APIs. This would add 
efficiencies for payers and maximize the value of the work being done 
to implement APIs, overall reducing burden for all impacted payers.
    Third, we propose a second payer-to-payer data exchange policy that 
would use this Payer-to-Payer API to facilitate data sharing between 
payers at enrollment. When a patient enrolls with a new payer or when a 
patient identifies concurrent coverage, we propose that the patient 
would have an opportunity to opt-in to this data sharing. Unlike the 
payer-to-payer exchange finalized previously, where the patient must 
make a request to initiate the data sharing, under this proposal the 
patient would be presented with data sharing as an option at 
enrollment. As more than one patient could be moving from one payer to 
another at enrollment, this new Payer-to-Payer API proposal to share 
data at enrollment would include a requirement for impacted payers to 
facilitate data sharing both for individual patients and for more than 
one patient using the HL7 FHIR Bulk Data Access (Flat FHIR) 
specification, discussed previously in section II.B. of this proposed 
rule. We are proposing to codify the requirement for this Payer-to-
Payer API, including use of the HL7 FHIR Bulk Data Access (Flat FHIR) 
specification, at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR 
438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c) for CHIP 
FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 
156.222(b) for QHP issuers on the FFEs.

[[Page 82624]]

3. Payer-to-Payer Data Sharing in Medicaid and CHIP
    In the CMS Interoperability and Patient Access final rule, we did 
not include Medicaid and CHIP FFS programs in the payer-to-payer data 
exchange policies. In that rule, we also did not specify how these data 
must be exchanged. As discussed in sections II.B.6.d. and II.C.7., and 
again later in this section of this proposed rule, Medicaid and CHIP 
FFS programs can face unique circumstances that might make it more 
challenging for them to meet new requirements within the same timeframe 
as other payers. As a result, in our first phase of interoperability 
policy, we chose to limit the burden on these programs so they could 
focus their attention and resources on implementing the Patient Access 
and Provider Directory APIs. Now that we are looking to transition the 
payer-to-payer data exchange to an API, and understanding the fact that 
this new API will be leveraging the same data and technical standards, 
and nearly all the same implementation guides as the Patient Access 
API, we believe that asking these programs to now implement this payer-
to-payer data exchange via a Payer-to-Payer API would not be as 
burdensome as it would have been had we required these FFS programs to 
implement a payer-to-payer data exchange that does not require an API 
in the CMS Interoperability and Patient Access final rule effective 
January 1, 2022. By the time these programs would need to start 
preparing to implement this new Payer-to-Payer API, they are expected 
to have implemented the Patient Access API, and they would thus be able 
to leverage the work done for that to make implementing this new API 
more manageable. As a result, we now propose to extend this requirement 
to Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 457.731(b), 
respectively.
    In the case of Medicaid and CHIP FFS programs, the state agency is 
the ``payer'' that can share patient data with other payers. As we 
discuss in more detail in section II.D.4. of this proposed rule, use of 
the Payer-to-Payer API could improve operational efficiencies for the 
state, thereby reducing burden for the state, and leading to better 
coordinated patient care and improved health outcomes. We thus expect 
the proposed Payer-to-Payer API requirement to lead to more effective 
administration of the state plan, and to better enable Medicaid and 
CHIP programs to ensure care and services are provided in a manner that 
is consistent with their beneficiaries' best interests. Ensuring that 
information can follow Medicaid and CHIP beneficiaries as they enter 
the programs could potentially lead to better care coordination for 
these patients, and better continuity of care. It could also reduce 
burden for patients and providers. Payers would have additional 
information to share via the Patient Access API and the Provider Access 
API. As a result, patients would have more readily available 
information to support informed decision making, and providers would 
have more information about the care their patients are receiving. This 
could potentially lead to fewer duplicate tests or less time taken 
collecting and recollecting information about the patient during a 
visit. Any opportunity a state takes to evaluate the data from a 
patient's previous payer could allow the state to avoid wasteful or 
unnecessary action that the previous payer may have already completed, 
such as an involved process or series of tests to support receipt of 
certain services. In this way, extending this Payer-to-Payer API to 
state Medicaid and CHIP programs could benefit them by helping them to 
operate more efficiently.
    Also, as discussed in the CMS Interoperability and Patient Access 
final rule (85 FR 255664 through 25569), we believe there are numerous 
benefits for payers to be able to maintain a cumulative record of their 
current patients' health information. If payers do so, they can make 
information available to patients and their providers and can help 
ensure that patient information follows patients as they move from 
provider to provider and payer to payer. We believe it is important to 
propose that Medicaid and CHIP FFS agencies facilitate this data access 
and sharing for their beneficiaries, so that the benefits of both the 
data sharing required in the final rule and the data sharing proposed 
in sections II.A. through the Patient Access API and II.B. through the 
Provider Access API of this proposed rule would extend to Medicaid and 
CHIP FFS beneficiaries in the same way across other impacted payers. In 
this way, as a patient moves in and out of Medicaid or CHIP FFS, they 
will not lose access to their health information--that information 
would continue to follow them to new payers and providers by virtue of 
payers being able to send and receive their data and make it available 
to the patient and providers through these APIs.
    States operating Medicaid and CHIP programs may be able to access 
federal matching funds to support their implementation of this Payer-
to-Payer API, because this API is expected to lead to more efficient 
administration of the Medicaid and CHIP state plans and improved care 
coordination and health outcomes for Medicaid beneficiaries consistent 
with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more 
detail in section II.D.8.a. of this proposed rule.
    Consistent with the discussion regarding funding and the Provider 
Access API proposal discussed in section II.B. of this proposed rule 
and the DRLS and API APIs in section II.C., we do not consider state 
expenditures for implementing this Payer-to-Payer API proposal to be 
attributable to any covered item or service within the definition of 
``medical assistance.'' Thus, we would not match these expenditures at 
the state's regular federal medical assistance percentage. However, 
federal Medicaid matching funds under section 1903(a)(7) of the Act, at 
a rate of 50 percent, for the proper and efficient administration of 
the Medicaid state plan, might be available for state expenditures 
related to implementing this proposal for their Medicaid programs, 
because use of the Payer-to-Payer API would help ensure that payers can 
access data that could improve their ability to render Medicaid 
services effectively, efficiently, and appropriately, and in the best 
interest of the patient.
    States' expenditures to implement these proposed requirements might 
also be eligible for enhanced 90 percent federal Medicaid matching 
funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can 
be attributed to the design, development, or installation of mechanized 
claims processing and information retrieval systems. Additionally, 75 
percent federal matching funds under section 1903(a)(3)(B) of the Act 
may be available for state expenditures to operate Medicaid mechanized 
claims processing and information retrieval systems to comply with this 
proposed requirement.
    States request Medicaid matching funds under section 
1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning 
Document (APD) process described in 45 CFR part 95, subpart F. States 
are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to 
ensure that any system for which they are receiving enhanced federal 
financial participation under section 1903(a)(3)(A)(i) or (B) of the 
Act aligns with and incorporates the ONC Health Information Technology 
standards adopted in accordance with 45 CFR part 170, subpart B. The 
Payer-to-Payer API, and all APIs proposed in this rule, complement this 
requirement

[[Page 82625]]

because these APIs further interoperability through the use of HL7 FHIR 
standards proposed for adoption by ONC for HHS use at 45 CFR 
170.215.\56\ And, states are reminded that 42 CFR 433.112(b)(10) 
explicitly supports exposed APIs as a condition of receiving enhanced 
federal financial participation under section 1903(a)(3)(A)(i) or (B) 
of the Act.
---------------------------------------------------------------------------

    \56\ See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

    Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of 
Medicaid technologies and systems as a condition of receiving enhanced 
federal financial participation under section 1903(a)(3)(A)(i) or (B) 
of the Act. As noted in section II.B. of this proposed rule, CMS would 
interpret that sharing and re-use requirement also to apply to 
technical documentation associated with a technology or system, such as 
technical documentation for connecting to a state's APIs. Making the 
needed technical documentation publicly available so that systems that 
need to connect to the APIs proposed in this rule can do so would be 
required as part of the technical requirements at 42 CFR 431.60(d) for 
all proposed APIs in this rule, including the Payer-to-Payer API.
    Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, 
limiting administrative costs to no more than 10 percent of CHIP 
payments to the state, would apply in developing the APIs proposed in 
this rule.
    Again, we note that the temporary federal medical assistance 
percentage (FMAP) increase available under section 6008 of the Families 
First Coronavirus Response Act (Pub. L. 116-127) does not apply to 
administrative expenditures.
    In the CMS Interoperability and Patient Access final rule, the 
payer-to-payer data exchange is required for Medicaid managed care 
plans with an applicability date of January 1, 2022 and codified at 42 
CFR 438.62(b)(1)(vi) and (vii). Because this rule proposes to require 
implementation and use of a Payer-to-Payer API for Medicaid FFS 
programs, and to be consistent with the other provisions of this rule, 
we propose to codify the requirement for states in connection with 
Medicaid FFS programs at 42 CFR 431.61(b), amend the requirement 
specific to Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii) to 
sunset the requirements at 438.61(b)(1)(vi) when the new requirements 
take effect with the rating period beginning on or after January 1, 
2023, and revise 42 CFR 438.242(b)(7) to add a requirement for Medicaid 
managed care plans to comply with the requirement imposed on Medicaid 
FFS program using a cross reference to 42 CFR 431.61. Codifying the 
requirement for Medicaid managed care plans this way would ensure that 
the same standards for payer-to-payer data exchange apply across the 
Medicaid program, regardless of it is through the FFS or managed care 
delivery system. Similarly, we are proposing revisions to the CHIP 
managed care regulations to require CHIP managed care entities to 
comply with the requirement for an API for payer-to-payer data 
exchanges that applies to CHIP FFS programs; the CHIP managed care 
entities would also have to comply by the rating period beginning on or 
after January 1, 2023. We propose to codify this policy for CHIP 
managed care entities at 42 CFR 457.1233(d)(4). Because CHIP managed 
care entities are required by current 42 CFR 457.1216 to comply with 42 
CFR 438.62, our proposed revisions to 42 CFR 438.62 (for Medicaid 
managed care plans) would also apply to CHIP managed care entities.
    We request comment on these proposals.
4. Enhancing the Payer-to-Payer Data Exchange--Payer-to-Payer API
    In the Interoperability and Patient Access final rule, we 
established a payer-to-payer data exchange that required certain 
impacted payers to share clinical data as defined in the USCDI version 
1 data set with the approval and at the direction of a current or 
former enrollee. We did not require that this data exchange take place 
using an API, though we encouraged payers to look at an API solution. 
We are now proposing to enhance this payer-to-payer data exchange in 
two ways. First, we are proposing to require that this payer-to-payer 
data exchange take place via an API. Second, we propose to require 
impacted payers to make available, at a minimum, not only the USCDI 
version 1 data, but also claims and encounter data (not including cost 
information) that the payer maintains with a date of service on or 
after January 1, 2016, conformant with the same IGs proposed for these 
data types in sections II.A. and II.B. of this rule, as well as 
information about pending and active prior authorization decisions, 
beginning January 1, 2023 (for Medicaid managed care plans and CHIP 
managed care entities, by the rating period beginning on or after 
January 1, 2023) via this standards-based Payer-to-Payer API. This 
Payer-to-Payer API is proposed to use the technical standards and the 
same base content and vocabulary standards used for the Patient Access 
API. These proposed requirements would be codified for Medicaid and 
CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 457.731(b), Medicaid 
managed care plans other than NEMT PAHPs at 42 CFR 438.242(b)(7), CHIP 
managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the 
FFEs at 45 CFR 156.221(f)(2). Ultimately, we believe sharing this 
information across payers can improve operational efficiencies, reduce 
unnecessary care, reduce care costs, and improve patient outcomes.
    Consistent with what was finalized in the CMS Interoperability and 
Patient Access final rule, impacted payers who receive these data would 
be required to incorporate the data into the payer's records about the 
enrollee, making these data part of the data maintained by the 
receiving payer. We note that unless expressly stated as part of a 
specific proposal, CMS is not proposing to require the receiving payer 
to specifically review or act on the data received from other payers. 
As explained in the CMS Interoperability and Patient Access final rule 
for the Payer-to-Payer Data Exchange, payers could choose to indicate 
the part of a data exchange that was received from a previous payer so 
a future receiving payer, provider, or even patient, would know where 
to direct questions (such as how to address contradictory or inaccurate 
information); and we propose that the same principle would apply to 
this enhancement. As noted in the CMS Interoperability and Patient 
Access final rule (85 FR 25566), impacted payers would be under no 
obligation under this proposal to review, utilize, update, validate, or 
correct data received from another payer. However, if a payer should 
choose to review or otherwise use received data, the payer would not be 
prohibited from doing so under any of the policies in this proposed 
rule.
    We believe a patient's current payer is in an optimal position to 
maintain a cumulative record for the patient and facilitate that record 
following the patient through their health care journey. Whereas 
patients may see many providers, patients' payers have a more holistic 
view of a patient's care across providers over time. It is important to 
note that, under these proposals, impacted payers would not be required 
to exchange any cost information, such as enrollee cost-sharing and 
provider remittances. While there could be some value to patients 
accessing this cost information via the Patient Access API, sharing 
this cost information between payers would have only limited beneficial 
impact on care

[[Page 82626]]

coordination. We believe that sharing claims and encounter information 
without the cost details, however, could complement the clinical data 
as defined in the USCDI by providing more information to support care 
coordination and efficient operation, including, for example, 
information about the patient's care history. As we discussed in the 
CMS Interoperability and Patient Access final rule, and in section 
II.B. of this proposed rule, claims and encounter data, used in 
conjunction with clinical data, can offer a broader and more holistic 
understanding of an individual's interactions with the health care 
system (85 FR 25523).
    In addition, we believe it would be highly valuable for payers to 
share pending and active prior authorization decisions generally, and 
particularly when a patient enrolls with a new payer. Currently, when a 
patient enrolls with a new payer, little to no information is sent from 
the previous payer to the new payer about the prior authorization 
decisions the previous payer made or was in the process of making 
relevant to the patient's ongoing care. While some previous payers will 
make this information available to the new payer upon request, most new 
payers do not request such information. Instead, most payers with a 
newly enrolling patient require the treating provider to request a new 
prior authorization, even for items or services for which a patient has 
a valid and current prior authorization approval. The burden of 
repeating the prior authorization process with the new payer falls on 
the provider and patient, which often impedes continuity of care, 
impacting patient outcomes and complicating care coordination. In 
addition, it adds burden to payers who must expend time and effort to 
review a potentially unnecessary and duplicative prior authorization 
request. While we do not propose to require the new payer that would 
receive the prior authorization information and documentation under 
this proposal to specifically consult this information, at the very 
least this information would now form part of the patient's cumulative 
record and thus be available to be shared by the payer with the patient 
and the patient's care team. Should a payer choose to consult this 
information, it could reduce payer, provider, and patient burden, and 
possibly cost, over time. If a new payer consulted this information, it 
could mean fewer prior authorization requests the provider needs to 
send and the payer needs to process. Patients would not have to wait 
for a new prior authorization for an item or service they have already 
demonstrated they need and would benefit from. This is especially true 
of patients with chronic conditions who are changing payers. As a 
result, sharing this information between payers could have a 
significant impact on payers, providers, and patients. Payers and 
providers could see reduced burden, and patients could experience 
better, continuous care.
    We discuss prior authorization and our proposals regarding prior 
authorization processes in more depth in section II.C. of this proposed 
rule. As part of this Payer-to-Payer API proposal, we propose at 42 CFR 
431.61(b) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid 
managed care, at 42 CFR 457.731(b) for CHIP FFS, at 42 CFR 
457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.221(f)(2) for 
QHP issuers on the FFEs to require all impacted payers make available 
pending and active prior authorization decisions (and related clinical 
documentation and forms) via the Payer-to-Payer API using the HL7 FHIR 
Da Vinci Payer Coverage Decision Exchange (PCDE) \57\ IG proposed at 45 
CFR 170.215(c)(4) and integrate this information into the patient's 
record for review and consideration. For purposes of this proposal, 
``active prior authorization decisions'' means prior authorizations 
that are currently open, and being used to facilitate current care, and 
are not expired or no longer valid. By ``pending prior authorization 
decision,'' we mean prior authorizations that are under review, either 
pending submission of documentation from the provider, or being 
evaluated by the payer's medical review staff, or for another reason 
have not yet had a determination made. As discussed in section II.A.2. 
of this proposed rule, when we say ``items and services,'' for purposes 
of this rule, we are talking about items and services excluding 
prescription drugs and/or covered outpatient drugs. ``Status'' of the 
prior authorization means information about whether the prior 
authorization is approved, denied, or if more information is needed to 
complete the request. We are proposing that impacted payers, consistent 
with the proposals for the Patient Access API in section II.A. and the 
Provider Access API in section II.B. of this proposed rule, limit 
sharing to pending and active authorizations to reduce the volume of 
outdated or irrelevant information shared between payers. We propose 
that this documentation would include the date the prior authorization 
was approved, the date the authorization ends, as well as the units and 
services approved and those used to date.
---------------------------------------------------------------------------

    \57\ HL7 International. (n.d.). Da Vinci Payer Coverage Decision 
Exchange (PCDE) FHIR IG. Retrieved from http://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
---------------------------------------------------------------------------

    We request comment on this proposal.
    In addition to these proposals, we also seek comment for possible 
future rulemaking on the extent to which we should consider explicitly 
requiring payers to demonstrate that they have reviewed and considered 
these previous prior authorization decisions and associated clinical 
documentation from a patient's previous payer before requiring patients 
to undergo a new prior authorization process. Such a requirement could 
minimize the possibility of duplicate testing for the purposes of 
reaffirming coverage or renewing a prior authorization for a covered 
benefit that is part of the patient's current care plan. As discussed 
in section II.C., providers experience burden when navigating through 
each payer's set of prior authorization policies or rules. It is a 
burden to payers to administer a prior authorization process. In 
addition, requiring a new prior authorization can also delay patient 
care. We also seek comment for possible future rulemaking on whether 
to, in the alternative, require payers to honor a previous payer's 
active prior authorization decisions at the time the enrollee moves 
from one payer to a new payer for some length of time, such as 30, 45, 
or 60 days, or if there are situations where this may not be possible 
or appropriate and why.
    This Patient Access API requirement was finalized at 42 CFR 
422.119(a) through (e) for MA organizations, 42 CFR 431.60(a) through 
(e) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid managed care, 
42 CFR 457.730(a) through (e) for CHIP FFS, 42 CFR 457.1233(d) for CHIP 
managed care, and at 45 CFR 156.221(a) through (e) for QHP issuers on 
the FFEs (85 FR 25558 through 25559). Further, we are proposing the 
same content and compliance with the same technical standards, the same 
documentation requirements, and the same discontinuation and denial of 
access requirements for the Patient Access API (discussed in section 
II.A. of this proposed rule) and the Provider Access API (discussed in 
section II.B. of this proposed rule) as we are proposing for this 
proposed Payer-to-Payer API. This degree of overlap and use of the same 
requirements should ease the burden for payers in developing and 
implementing these various APIs.

[[Page 82627]]

    In addition, all of these APIs would need to be conformant with the 
same IGs proposed for claims and encounter data as well as the USCDI 
version 1 data as discussed in section II.A. for the Patient Access API 
and section II.B. of this proposed rule for the Provider Access API. 
The Patient Access API, in particular, provides the foundation 
necessary to share claims, encounter, and clinical data. Because the 
same data elements would be exchanged through all three APIs, payers 
would have already formatted these data elements and prepared their 
systems to share these standardized data via a FHIR-based API, doing 
much of the work needed to implement this Payer-to-Payer API. As a 
result, we believe payers would have devoted the development resources 
needed to stand up a FHIR-based API infrastructure that could be 
adapted for expanded interoperability use cases after 2021, when they 
have implemented the Patient Access API.
    However, we are proposing that the Payer-to-Payer API and the 
Patient Access and Provider Access APIs be conformant with different 
IGs for sharing prior authorization decisions. In sections II.A. and 
II.B. of this proposed rule, we propose that the Patient Access and 
Provider Access APIs would need to be conformant with the PDex IG when 
sharing prior authorization decisions with patients and providers, 
respectively. We propose to require the Payer-to-Payer API be 
conformant with the PCDE IG instead, when sharing this information, as 
this IG addresses data sharing between payers more specifically. PDex 
would be better suited for an exchange from a payer to patients and 
providers. Given the shared FHIR resources across the two IGs, we do 
not believe requiring the use of both IGs--one for each appropriate 
recipient of the data--adds significant burden to payers.
5. Payer-to-Payer API--Sharing Data at Enrollment
    As finalized in the CMS Interoperability and Patient Access final 
rule, the payer-to-payer data exchange is initiated at the direction of 
the patient. We discussed proposed enhancements to this patient-
directed data sharing in the previous section where we noted this data 
exchange would now require the use of an API and include additional 
data to be shared. In addition to this case-by-case, patient-directed 
data sharing, however, we also propose a second, new Payer-to-Payer API 
data sharing opportunity that would be offered to all patients 
receiving coverage from a payer impacted by this proposed rule as an 
option at the time of enrollment with a new payer, if both the current 
payer and new payer would be subject to the requirements in this 
proposal. We propose to codify this new Payer-to-Payer API requirement 
at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR 438.242(b)(7) for 
Medicaid managed care, at 42 CFR 457.731(c) for CHIP FFS, at 42 CFR 
457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b) for QHP 
issuers on the FFEs. We are proposing that this exchange be offered to 
patients receiving coverage from payers impacted by this proposed rule 
as an option when they enroll with a new payer. The new payer, if an 
impacted payer under this proposed rule, could then request the data 
from the previous payer for patients who opt-in to this data sharing 
via the Payer-to-Payer API.
    We are proposing the following if a patient enrolls during a 
specified annual open enrollment period, or, for a payer that does not 
have such an enrollment period, during the first calendar quarter of 
each year. If such a patient opts-in to having their new payer obtain 
the applicable data from their previous payer at this specified time, 
we are proposing to require that impacted new payers request such data 
from the previous payers via the Payer-to-Payer API using the HL7 FHIR 
Bulk Data Access (Flat FHIR) specification within one week of the end 
of the enrollment period or the first calendar quarter of each year. 
The previous payer, if an impacted payer, would be required to respond 
to this request within one business day of receiving the request.
    We do recognize that not every impacted payer has a dedicated 
annual open enrollment period. For those payers, we are proposing that 
the opt-in Bulk data sharing occur at the end of the first calendar 
quarter of each year. We seek comment on whether this is the best time 
to require the data sharing for such payers. Based on our experience 
with Bulk data sharing discussed in section II.B.4. of this proposed 
rule, and based on discussions with payers and technology developers, 
we believe the efficiencies afforded by having at least one time per 
year where payers could facilitate this data sharing and employ the 
Bulk specification to leverage the opportunity to make data available 
for as many patients as possible at one time could be potentially 
significant because such an asynchronous data sharing option could 
limit drain on system resources and promote a dedicated and efficient 
opportunity each year to ensure patients have their health information 
follow them as they move from payer to payer, permitting better care 
coordination and potentially better health outcomes. Therefore, we seek 
comment on how best to operationalize this across impacted payers. We 
also see comment on whether the timeframes for the new payer requesting 
these data--within one week of this enrollment or other defined period 
ending--and the old payer sending these data--within one business day 
of receiving the request--are the optimal timeframes and what other 
timeframes payers may want us to consider. Would payers be able to 
accommodate a shorter request timeframe--such as one to three business 
days after the end of the defined enrollment period? Or, do payers need 
more than one business day to respond to a request? If so, would payers 
want to have a one week turnaround for data requests? We do think it is 
important for patient data to move to the new payer as soon as possible 
to facilitate care coordination, and to ensure the patient's data is 
available to their providers and to them, hence our current proposal. 
We also seek comment on whether we should consider any other factors 
regarding the process and timeline for this Payer-to-Payer API data 
sharing at enrollment.
    Efficient data sharing between payers would ensure that information 
that could support payer operations and benefit patient care is 
available to a new payer at the very start of the patient's care 
covered by a new payer. This could facilitate care coordination and 
continuity of care. This proposal would require the new payer to adopt 
a process to obtain the name of an enrollee's previous payer, or 
concurrent payer if the enrollee has coverage through more than one 
payer, as part of the enrollment process. Subsequently, the new payer 
would be required to receive the enrollee's clinical data as defined in 
the USCDI version 1 and adjudicated claims and encounter data, as well 
as pending and active prior authorization decisions, from the previous 
or concurrent payer, if that payer maintains such data for the relevant 
enrollee.
    Under this proposal, impacted payers would be required to maintain 
a process for capturing data about each patient's previous payer and 
concurrent payer (if there is one) at enrollment to facilitate this 
payer-to-payer data sharing. While we wish to leave it to each impacted 
payer how they choose to implement capturing this information, we seek 
comment on potential solutions to support payers in obtaining this 
previous and concurrent payer information in an effort to provide all 
impacted payers with options to consider. As to concurrent payers, we 
anticipate that many payers already

[[Page 82628]]

have a process in place to request and update information of this sort 
for coordination of benefits or to implement Medicare Secondary Payer 
requirements (if applicable), and we wish to allow payers to maintain 
their current processes if that is beneficial and feasible when 
incorporating the use of the Payer-to-Payer API into this process.
    We are proposing at 42 CFR 431.61(c)(5) for Medicaid FFS, at 42 CFR 
438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(5) for 
CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 
156.222(b)(5) for QHP issuers on the FFEs, that payers put a process in 
place to allow enrollees to opt-in to this payer-to-payer data sharing 
at enrollment, similar to the opt-in proposal under the Provider Access 
APIs detailed in section II.B. of this proposed rule. If enrollees do 
not actively opt-in, impacted payers would not be required to share 
their data through the Payer-to-Payer API as described under this 
proposal. This means that only at the defined enrollment period, or at 
the end of the first calendar quarter for payers that do not have a 
defined enrollment period, are impacted payers required under this 
proposal to have a process in place to capture a patient's preference 
to opt-in to this data sharing under this proposal. If a patient would 
like their data shared with another payer at another time throughout a 
given year, the patient could request that data exchange under the 
enhanced payer-to-payer data exchange proposal discussed in section 
II.D.4. of this proposed rule.
    We seek comment on these proposals.
    Some individuals may have concurrent coverage with two or more of 
the payers impacted by this proposal. We also propose at 42 CFR 
431.61(c)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid 
managed care, at 42 CFR 457.731(c)(4) for CHIP FFS, at 42 CFR 
457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(4) for 
QHP issuers on the FFEs that when an enrollee has concurrent coverage 
with two or more impacted payers, the impacted payers must make the 
patient's data available to the concurrent payer quarterly, in addition 
to when the enrollee obtains new coverage from a payer subject to these 
proposed requirements. We propose to require payers to provide 
enrollees the opportunity to opt-in to initiate this quarterly data 
sharing. This data exchange among concurrent payers is expected to 
support better care coordination and more efficient operations. We also 
considered whether to propose more frequent exchange (weekly or 
monthly), and less frequent exchange (semi-annually or annually); 
however, we believe a quarterly data exchange would strike the right 
balance in providing accurate, timely data with minimal payer burden.
    We request comment on this proposal, including the appropriate 
frequency for this payer-to-payer exchange for enrollees with 
concurrent coverage. We also seek comment on whether payers prefer the 
flexibility to define their own process for facilitating how patients 
opt-in to this quarterly data sharing and if there are additional 
considerations that we should take into account to facilitate data 
sharing using the Payer-to-Payer API between concurrent payers.
    We appreciate that a patient may be moving to or from a payer, or 
have concurrent coverage with a payer not subject to the requirements 
in this proposed rule, such as when a patient moves from a QHP on the 
FFE to an employer-based plan, as an employer-based plan is not 
impacted by this rulemaking. We encourage all payers to consider the 
value of implementing a Payer-to-Payer API so that all patients, 
providers, and payers in the U.S. health care system may ultimately 
experience the benefits of such data sharing. For instance, we are 
exploring best next steps for the Medicare FFS program to participate 
in a Payer-to-Payer API data exchange with all interested payers. That 
said, if an impacted payer learns that a previous or concurrent payer 
is not subject to this proposal, we encourage the new payer to evaluate 
if the other payer can accommodate an API data exchange and seek such 
exchange in accordance with applicable law. However, an impacted payer 
would not be required to try to send data to or receive data from a 
payer that is not required to exchange data through the Payer-to-Payer 
API under this proposal.
    As discussed in section II.B. of this proposed rule, and as further 
illustrated in the discussion in this section of this proposed rule, it 
may be valuable for a payer to share data with another payer for more 
than one patient at a time. It is likely that if payers are sharing 
data at enrollment, impacted payers would have many patients' data to 
share at one time. In such a situation, it can be burdensome to make an 
API call for each patient. This could require significant technological 
resources and time. To introduce additional efficiencies, we are 
proposing that this required Payer-to-Payer API must be able to share 
the specified data conformant with the HL7 FHIR Bulk Data Access (Flat 
FHIR) specification at 45 CFR 170.215(a)(4) to facilitate sharing 
information relevant to one or more patients at one time. We are 
proposing to codify this specific requirement at 42 CFR 431.61(c)(1) 
for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 
42 CFR 457.731(c)(1) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP 
managed care, and at 45 CFR 156.222(b)(1) for QHP issuers on the FFEs.
    We request comment on this proposal.
    As with the proposal for the Provider Access API, discussed in 
section II.B. of this proposed rule, we invite comment on the tradeoffs 
and benefits of having the Payer-to-Payer API available with and 
without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) 
specification. We believe both approaches would offer benefits to 
payers depending on the specifics of the situation in which they would 
need to share patient data. As we look to balance providing this 
flexibility with the burden of implementing and maintaining APIs, we 
invite public comment on the benefits of having the Payer-to-Payer API 
available with and without the use of the HL7 FHIR Bulk Data Access 
(Flat FHIR) specification, which can be leveraged to request the data 
for a single patient or multiple patients.
6. Extensions and Exemptions for Medicaid and CHIP
    If our proposals regarding the Payer-to-Payer API are finalized, we 
would encourage state Medicaid and CHIP FFS programs to implement the 
Payer-to-Payer API as soon as possible understanding the many benefits 
of the API as discussed previously in this section.
    However, we also recognize that state Medicaid or CHIP FFS agencies 
could face certain unique circumstances that would not apply to other 
impacted payers, as discussed in more detail later in this section. As 
a result, a few states might need to seek an extension of the 
compliance deadline or an exemption from these requirements. To address 
this concern, we are proposing a process through which states may seek 
an extension of and, in specific circumstances, an exemption from, the 
Payer-to-Payer API requirements if they are unable to implement these 
API requirements, consistent with the extension and exemption proposals 
for the Provider Access API in section II.B., and the DRLS and PAS APIs 
in section II.C. of this proposed rule. Providing these flexibilities 
might allow these states to continue building technical capacity in 
support of overall interoperability goals consistent with their needs. 
Therefore, we propose the following.

[[Page 82629]]

    Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1), 
respectively, we propose to provide states--for Medicaid FFS and CHIP 
FFS--the opportunity to request a one-time extension of up to one (1) 
year for the implementation of the Payer-to-Payer API specified at 42 
CFR 431.61(b) and (c) and 42 CFR 457.731(b) and (c). Unique 
circumstances that might present a challenge to specific states to meet 
the proposed compliance date could include resource challenges, such as 
funding. Depending on when the final rule is published in relation to a 
state's budget process and timeline, some states may not be able to 
secure the needed funds in time to both develop and execute 
implementation of the API requirements by the proposed compliance date. 
A one-year extension could help mitigate this issue. And, some states 
may need to initiate a public procurement process to secure contractors 
with the necessary skills to support a state's implementation of these 
proposed API policies. The timeline for an open, competed procurement 
process, together with the time needed to onboard the contractor and 
develop the API, could require additional time as well. Finally, a 
state might need to hire new staff with the necessary skillset to 
implement this policy. Again, the time needed to initiate the public 
employee hiring process, vet, hire, and onboard the new staff may make 
meeting the proposed compliance timeline difficult, because, generally 
speaking, public employee hiring processes include stricter guidelines 
and longer time-to-hire periods than other sectors.\58\ In all such 
situations, a state might need more time than other impacted payers to 
implement the requirements.
---------------------------------------------------------------------------

    \58\ State hiring processes are comparable with federal hiring 
processes. According to OMB, the average time-to-hire for federal 
employees was 98.3 days in 2018, significantly higher than the 
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

    If a state believes it can demonstrate the need for an extension, 
its request must be submitted and approved as a part of its annual 
Advance Planning Document (APD) for MMIS operations costs and must 
include the following: (1) A narrative justification describing the 
specific reasons why the state cannot reasonably satisfy the 
requirement(s) by the compliance date, and why those reasons result 
from circumstances that are unique to states operating Medicaid or CHIP 
FFS programs, (2) a report on completed and ongoing implementation 
activities to evidence a good faith effort toward compliance, and (3) a 
comprehensive plan to meet implementation requirements no later than 
one year after the initial compliance date.
    An extension would be granted if CMS determines based on the 
information provided in the APD that the request adequately establishes 
a need to delay implementation, a good faith effort to implement the 
proposed requirements as soon as possible, and a clear plan to 
implement no later than one year after the proposed compliance date. We 
would expect states to explain why the request for an extension results 
from circumstances that are unique to states operating Medicaid or CHIP 
FFS programs. We also solicit comment on whether our proposal would 
adequately address the unique circumstances that affect states, and 
that might make timely compliance with the proposed API requirement 
sufficiently difficult for states and thus justify an extension. In 
particular, we seek comment on whether we should require or use 
additional information on which to base the determination or whether we 
should establish different standards in the regulation text for 
evaluating and granting the request.
    Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457. 731(e)(2), 
respectively, we propose two circumstances that would permit state 
requests for exemption; namely, (1) when at least 90 percent of all 
covered items and services are provided to Medicaid or CHIP 
beneficiaries through Medicaid or CHIP managed care contracts with 
MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or 
(2) when at least 90 percent of the state's Medicaid or CHIP 
beneficiaries are enrolled in Medicaid or CHIP managed care 
organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 
for CHIP. In both circumstances, the time and resources that the state 
would need to expend to implement the API requirements may outweigh the 
benefits of implementing and maintaining the API. As discussed in 
section II.B. of this proposed rule, unlike other impacted payers, 
state Medicaid and CHIP FFS programs do not have a diversity of plans 
to balance implementation costs for those plans with low enrollment. If 
there is low enrollment in a state Medicaid or CHIP FFS program, there 
is no potential for the technology to be leveraged for additional 
beneficiaries as states, unlike other payers, do not maintain 
additional lines of business.
    We acknowledge that the proposed exemption could mean that a few 
Medicaid or CHIP FFS systems would not receive the benefits of having 
this API available to facilitate health information exchange. To 
address this, we propose that states meeting the above thresholds would 
be expected to employ an alternative plan to enable the electronic 
exchange and accessibility of health information for those 
beneficiaries who are served under the FFS program.
    A state meeting the above criteria would be permitted to submit a 
request for an exemption to the requirements for the Payer-to-Payer API 
once per calendar year for a one-year exemption. The state would be 
required to submit this annual request as part of a state's annual APD 
for MMIS operations costs. The state would be required to include in 
its request documentation that it meets the criteria for the exemption 
using data from any one of the three most recent and complete calendar 
years prior to the date the exemption request is made. We note we 
propose that this request be made annually as from year-to-year the 
nature of the FFS population could change and so it is important that 
the state provide the most current information for CMS's consideration.
    Exemptions would be granted for a one-year period if a state 
establishes to CMS's satisfaction that it meets the criteria for the 
exemption and has established a plan to ensure that all impacted payers 
would have efficient electronic access to the same information through 
alternative means.
    We request comment on the proposed extension and exemption.
    For Medicaid and CHIP managed care, we are not proposing an 
extension process at this time because we believe that managed care 
plans are actively working to develop the necessary IT infrastructure 
to be able to comply with the existing requirements in 42 CFR part 438 
and part 457 and also benefit from efficiencies resulting from their 
multiple lines of business impacted by these interoperability policies. 
Many managed care plans are part of parent organizations that maintain 
multiple lines of business, including Medicaid managed care plans and 
plans sold on the Exchanges. As discussed in the CMS Interoperability 
and Patient Access final rule (85 FR 25607, 25612, 25620), work done by 
these organizations can benefit all lines of business and, as such, we 
do not believe that the proposals in this rule impose undue burden or 
are unachievable by the compliance date. We are soliciting comment on 
whether our belief concerning the scope of resources and ability of 
managed care parent organizations to achieve economies of scale is 
well-founded. Further, we seek comment on whether an extension process 
is warranted for

[[Page 82630]]

certain managed care plans to provide additional time for the plan to 
comply with the requirement at proposed 42 CFR 438.242(b)(7) (which 
cross references 42 CFR 438.61(b) and (c)) for Medicaid managed care 
plans and at proposed 42 CFR 457.1233(d)(4) (which cross references 42 
CFR 457.731(b) and (c)) for CHIP managed care entities. While we are 
not proposing such a process for managed care plans and entities and do 
not believe one is necessary for the reasons outlined here, we are open 
to considering one if necessary. If we adopt an extension process for 
these managed care plans and entities, what criteria would a managed 
care plan or entity have to meet to qualify for an extension? Should 
the process consider, for example, enrollment size, plan type, or some 
unique characteristic of certain plans that could hinder their 
achievement of the proposed requirements by the proposed compliance 
date? Also, we seek comment on whether, if we finalize such a process 
for Medicaid managed care plans or CHIP managed care entities, the 
state or CMS should manage the process and whether states could 
successfully adopt and implement the process on the timeline necessary 
to fulfill the goals and purposes of the process. Consistent with the 
exception process proposed for QHP issuers on the FFEs at 45 CFR 
156.222(d), we would expect any extension request to include, at a 
minimum, a narrative justification describing the reasons why a plan or 
entity cannot reasonably satisfy the requirements by the proposed 
compliance date, the impact of non-compliance upon enrollees, the 
current or proposed means of providing electronic health information to 
providers, and a corrective action plan with a timeline to achieve 
compliance.
    We do propose, however, to exclude non-emergency transportation 
(NEMT) PAHPs from the Payer-to-Payer API proposals. In this rule, we 
propose to require MCOs, PIHPs, and PAHPs other than NEMT PAHPs (as 
defined at 42 CFR 438.9(a)) to implement and maintain the Payer-to-
Payer API. We believe that the unique nature and limited scope of the 
services provided by NEMT PAHPs is not consistent with the proposed 
purposes of the Payer-to-Payer API proposed at 42 CFR 431.61(b) and 
(c). Specifically, we do not believe that having all other Medicaid 
managed care plans, such as acute care or dental managed care plans, be 
required to request, receive, and incorporate into the plan's records 
NEMT data from an enrollee's prior or concurrent payer would help 
achieve the goals of the Payer-to-Payer API, namely to help avoid 
unnecessary care, ensure that providers are able to spend time with 
patients focusing on care versus collecting redundant information, or 
improve patient care through enhanced care coordination. Conversely, we 
do not believe having NEMT PAHPs be required to request, receive, and 
incorporate into its records enrollee data from other managed care 
plans contributes to achieving the goals of the Payer-to-Payer API 
given the unique nature and limited scope of the services they provide.
    We note that the HIPAA Privacy Rule, at 45 CFR 164.502, permits a 
covered entity to use or disclose PHI for certain treatment, payment, 
or health care operations without individual authorization. As such, we 
believe a health plan that needs NEMT PAHP utilization for treatment, 
payment, or the applicable health care operations for a current 
enrollee, would generally be permitted to under the applicable HIPAA 
provisions.
    As mentioned previously in this proposed rule, although Medicare 
FFS is not directly impacted by this rule, we do note that we are 
targeting to implement a Payer-to-Payer API for the Medicare FFS 
program, if finalized. In this way, the Medicare FFS Payer-to-Payer API 
would conform to the same requirements that apply to the impacted 
payers under this rulemaking, as applicable, so that Medicare FFS 
beneficiaries would also benefit from this data sharing.
7. Exception for QHP Issuers
    With regard to QHP issuers on the FFEs, similar to our exceptions 
process noted in the CMS Interoperability and Patient Access final rule 
for the Patient Access API (85 FR 25552 through 25553) and in section 
II.B.6.e. of this proposed rule for the Provider Access API, we are 
also proposing an exception for the Payer-to-Payer API at 45 CFR part 
156.222(d). As such, if a plan applying for QHP certification to be 
offered through a FFE believes it cannot satisfy the Payer-to-Payer API 
requirements, the issuer must include as part of its QHP application a 
narrative justification describing the reasons why the plan cannot 
reasonably satisfy the requirements for the applicable plan year, the 
impact of non-compliance upon enrollees, the current or proposed means 
of providing health information to payers, and solutions and a timeline 
to achieve compliance with the requirements of this section. Further, 
we propose that the FFE may grant an exception to these requirements if 
the Exchange determines that making such health plan available through 
such Exchange is in the interests of qualified individuals and 
qualified employers in the state or states in which such Exchange 
operates.
    We request comment on this proposal.
8. Statutory Authorities for Payer Exchange Proposals
a. Medicaid and CHIP
    For Medicaid managed care plans and Medicaid state agencies, we are 
proposing to require the implementation of a Payer-to-Payer API to 
exchange claims, encounter, clinical, and pending and active prior 
authorizations data between payers at a patient's request or any time a 
patient changes payers using a FHIR-based API. Our proposals in this 
section fall generally under our authority in the following provisions 
of the statute:
    <bullet> Section 1902(a)(4) of the Act, which requires that a state 
Medicaid plan provide such methods of administration as are found by 
the Secretary to be necessary for the proper and efficient operation of 
the state Medicaid plan.
    <bullet> Section 1902(a)(8) of the Act, which requires states to 
ensure that Medicaid services are furnished with reasonable promptness 
to all eligible individuals.
    <bullet> Section 1902(a)(19) of the Act, which requires states to 
ensure that care and services are provided in a manner consistent with 
simplicity of administration and the best interests of the recipients.
    We note statutory authority for proposals to require specific IGs 
for this and all APIs proposed in this rule is discussed in section 
II.A.3. of this proposed rule.
    We believe these proposals related to the Payer-to-Payer API are 
authorized by these provisions of the Act for the following reasons. 
First, because the Payer-to-Payer API is designed to enable efficient 
exchange of data between payers, it is anticipated to help state 
Medicaid programs improve the efficiencies and simplicity of their own 
operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. 
Use of the Payer-to-Payer API could introduce efficiencies in providing 
Medicaid services, by reducing duplicate prior authorization requests, 
referrals, or tests. In addition, as is discussed in section II.B. of 
this proposed rule, with respect to the Provider Access API and the 
Bulk specification, this Payer-to-Payer API, by allowing payers to 
share health information for one or more patients at once, could 
increase efficiency and simplicity of administration. It could give 
payers access to all of their enrollees' information with limited

[[Page 82631]]

effort and enable the state to then make that information available to 
providers and to patients through the Provider Access and Patient 
Access APIs. And, it could reduce the amount of time needed to evaluate 
a patient's current care plan and possible implications for care 
continuity, which could introduce efficiencies and improve care. Use of 
the proposed Bulk specification allows state Medicaid programs to 
receive information on a full panel of patients at once, thus 
expediting the data collection process. Sharing patient information for 
a full panel of patients at a specified time annually, such as at the 
end of the first calendar quarter, would help to ensure payers receive 
patient information in a timely manner when a beneficiary moves to a 
new payer, and therefore, could lead to more appropriate service 
utilization and higher beneficiary satisfaction by supporting efficient 
care coordination and continuity of care as beneficiaries move from 
payer to payer, which could lead to better health outcomes.
    Second, the proposals are expected to help states and managed care 
plans furnish Medicaid services with reasonable promptness and in a 
manner consistent with beneficiaries' best interests, consistent with 
section 1902(a)(8) and (a)(19) of the Act, for the following reasons. 
If states were to share information about Medicaid beneficiaries or 
former beneficiaries with other payers with whom these beneficiaries 
are enrolled, they could support opportunities for improved care 
coordination for Medicaid beneficiaries and former beneficiaries. 
Exchanging information about Medicaid beneficiaries and former 
beneficiaries between payers might also reduce the amount of time 
needed to evaluate a Medicaid beneficiary's current care plan, their 
health risks, and their health conditions at the time that beneficiary 
enrolls with the Medicaid program. Exchanging this information between 
payers could also better support care continuity for Medicaid 
beneficiaries. As discussed in section II.D.4. of this proposed rule, 
if a state Medicaid program has access to a previous payer's pending 
and active prior authorization decisions, the Medicaid program could 
choose to accept the existing decision and support continued patient 
care without requiring a new prior authorization or duplicate tests. 
This information exchange might be of particular value in improving 
care continuity for beneficiaries who might churn into and out of 
Medicaid coverage, or have concurrent coverage in addition to Medicaid. 
The proposal could also improve the provision of Medicaid services, by 
potentially helping to ensure that Medicaid beneficiaries who may 
require coordinated services with concurrent payers could be identified 
and provided case management services, as appropriate.
    For Medicaid managed care plans, the proposed exchange of claims, 
encounter, USCDI, and some prior authorization data would greatly 
enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations 
under 42 CFR 438.208(b) which require them to: Implement procedures to 
deliver care to and coordinate services including ensuring that each 
enrollee has an ongoing source of appropriate care; coordinate services 
between settings of care, among Medicaid programs, and with community 
and social support providers; make a best effort to conduct an initial 
screening of each enrollee's needs; and share with the state or other 
MCOs, PIHPs, and PAHPs serving the enrollee the results of any 
identification and assessment of that enrollee's needs to prevent 
duplication of those activities. The data provided via the Payer-to-
Payer API proposed in this rule would give managed care plans the 
information needed to much more easily perform these required 
functions, thus enhancing the effectiveness of the care coordination 
and helping enrollees receive the most appropriate care in an effective 
and timely manner.
    For CHIP, we are proposing these requirements under our authority 
in section 2101(a) of the Act, which states that the purpose of title 
XXI is to provide funds to states to provide child health assistance to 
uninsured, low-income children in an effective and efficient manner 
that is coordinated with other sources of health benefits coverage. We 
believe the provisions in this proposed rule could strengthen our 
ability to fulfill these statutory obligations in a way that recognizes 
and accommodates the use of electronic information exchange in the 
health care industry today and would facilitate a significant 
improvement in the delivery of quality health care to our 
beneficiaries.
    As with the Medicaid FFS and Medicaid managed care programs, the 
proposals in this section of the proposed rule for CHIP FFS and CHIP 
managed care require the use of a Payer-to-Payer API to exchange 
claims, encounter, clinical and pending and active prior authorization 
data at a beneficiary's request, or any time a beneficiary changes 
payers, using a FHIR-based API. The current payer could use data from 
the prior payer to more effectively or accurately respond to a request 
for a prior authorization, because under this proposal, a new payer 
would have historical claims or clinical data upon which they may 
review a request with more background data. Access to information about 
new patients could enable appropriate staff within the CHIP program to 
more effectively coordinate care and conduct the care management 
because they would have better data available to make decisions for 
planning. In many cases, patients do not remember what services they 
have had, what vaccines they have had, or other possibly relevant 
encounters that could help payers manage their care. This proposal is 
consistent with the goal of providing more informed and effective care 
coordination, which could help to ensure that CHIP services are 
provided in a way that supports quality care, which aligns with section 
2101(a).
b. QHP Issuers on the FFEs
    For QHP issuers on the FFEs, we are proposing these new 
requirements under our authority in section 1311(e)(1)(B) of the 
Affordable Care Act, which affords the Exchanges the discretion to 
certify QHPs if the Exchange determines that making available such 
health plans through the Exchange is in the interests of qualified 
individuals in the state in which the Exchange operates. Existing and 
emerging technologies provide a path to make information and resources 
for health and health care management universal, integrated, equitable, 
accessible to all, and personally relevant.
    Requiring QHP issuers on the FFEs to build and maintain a Payer-to-
Payer API would allow the seamless flow of claims and encounter data, 
the clinical data the payer maintains for a patient as defined in the 
USCDI version 1, as well as their pending and active prior 
authorization decisions, from payer to payer. We believe that ensuring 
a means for an enrollee's new issuer to electronically obtain the 
enrollee's claims, encounter, and clinical data, as well as prior 
authorization information with corresponding medical records, from the 
previous issuer will reduce administrative burden and result in more 
timely and efficient care coordination and responses to prior 
authorization requests.
    We believe it is necessary that QHP issuers on FFEs have systems in 
place to send information important to care coordination with departing 
enrollees, and that QHP issuers also have systems in place to receive 
such information from payer to payer on behalf of new and concurrent 
enrollees, as appropriate

[[Page 82632]]

and consistent with the proposals in this section. Therefore, we 
believe certifying only health plans that make enrollees' health 
information available to them and their providers, and as discussed in 
this section, other payers, in a convenient, timely, and portable way 
is in the interests of qualified individuals and qualified employers in 
the state in which an FFE operates. We encourage SBEs to consider 
whether a similar requirement should be applicable to QHP issuers 
participating in their Exchange.
    We previously finalized the Payer-to-Payer Data Exchange in the CMS 
Interoperability and Patient Access final rule, where, with the 
approval and at the direction of an enrollee, one payer would have to 
send clinical data as defined in the USCDI version 1 to another payer 
named by the enrollee. We are now requiring this to be done via an API 
and adding claims and encounter data, as well as pending and active 
prior authorization decisions.
    We also believe that requiring QHP issuers on the FFEs to use the 
Bulk Specification for the Payer-to-Payer API would improve the 
efficiency and simplicity of data transfers between issuers, by 
enabling the exchange of all data for all patients at once. We believe 
the opportunity to support an exchange of large volumes of patient 
data, rather than data for one patient at a time, may be cost effective 
for the issuers, and having patient care at the beginning of a new 
plan, could assist the new payer in identifying patients who need care 
management services, which could reduce the cost of care. Taking in 
volumes of data would also enable the QHPs to perform analysis on the 
types of new patients in their plan, if they choose to analyze data for 
existing patients as well.

E. Adoption of Health IT Standards and Implementation Specifications

    As first mentioned in section II.A. of this proposed rule, at 45 
CFR 170.215, ONC is proposing the specific IGs discussed in sections 
II.A., II.B., II.C., and II.D. of this proposed rule for HHS adoption 
in support of the API provisions included in this proposed rule. This 
section outlines ONC's authority to do so, and how this will support 
HHS generally, and CMS specifically, in continuing to advance standards 
and the use of FHIR to reduce burden, improve the prior authorization 
process, and support patient electronic access to health information.
1. Statutory Authority
    The Health Information Technology for Economic and Clinical Health 
(HITECH) Act, Title XIII of Division A and Title IV of Division B of 
the American Recovery and Reinvestment Act of 2009 (the Recovery Act) 
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act 
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve 
health care quality, safety, and efficiency through the promotion of 
health IT and exchange of electronic health information (EHI). 
Subsequently, Title IV of the 21st Century Cures Act (Pub. L. 114-255) 
(``Cures Act'') amended portions of the HITECH Act by modifying or 
adding certain provisions to the PHSA relating to health IT.
a. Adoption of Standards and Implementation Specifications
    Section 3001 of the PHSA directs the National Coordinator for 
Health Information Technology (National Coordinator) to perform duties 
in a manner consistent with the development of a nationwide health 
information technology infrastructure that allows for the electronic 
use and exchange of information. Section 3001(b) of the PHSA 
establishes a series of core goals for development of a nationwide 
health information technology infrastructure that:
    <bullet> Ensures that each patient's health information is secure 
and protected, in accordance with applicable law;
    <bullet> Improves health care quality, reduces medical errors, 
reduces health disparities, and advances the delivery of patient-
centered medical care;
    <bullet> Reduces health care costs resulting from inefficiency, 
medical errors, inappropriate care, duplicative care, and incomplete 
information;
    <bullet> Provides appropriate information to help guide medical 
decisions at the time and place of care;
    <bullet> Ensures the inclusion of meaningful public input in such 
development of such infrastructure;
    <bullet> Improves the coordination of care and information among 
hospitals, laboratories, physician offices, and other entities through 
an effective infrastructure for the secure and authorized exchange of 
health care information;
    <bullet> Improves public health activities and facilitates the 
early identification and rapid response to public health threats and 
emergencies, including bioterror events and infectious disease 
outbreaks;
    <bullet> Facilitates health and clinical research and health care 
quality;
    <bullet> Promotes early detection, prevention, and management of 
chronic diseases;
    <bullet> Promotes a more effective marketplace, greater 
competition, greater systems analysis, increased consumer choice, and 
improved outcomes in health care services; and
    <bullet> Improves efforts to reduce health disparities.
    Section 3004 of the PHSA identifies a process for the adoption of 
health IT standards, implementation specifications, and certification 
criteria, and authorizes the Secretary to adopt such standards, 
implementation specifications, and certification criteria. As specified 
in section 3004(a)(1) of the PHSA, the Secretary is required, in 
consultation with representatives of other relevant federal agencies, 
to jointly review standards, implementation specifications, and 
certification criteria endorsed by the National Coordinator under 
section 3001(c) of the PHSA and subsequently determine whether to 
propose the adoption of any grouping of such standards, implementation 
specifications, or certification criteria. The Secretary is required to 
publish all determinations in the Federal Register.
    Section 3004(b)(3) of the PHSA, which is titled ``Subsequent 
Standards Activity,'' provides that the Secretary shall adopt 
additional standards, implementation specifications, and certification 
criteria as necessary and consistent with the schedule published by the 
Health IT Advisory Committee (HITAC). As noted in the final rule, 
``2015 Edition Health Information Technology (Health IT) Certification 
Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, 
and ONC Health IT Certification Program Modifications'' (``ONC 2015 
Edition Final Rule''), published on October 16, 2015, we consider this 
provision in the broader context of the HITECH Act and the Cures Act to 
continue to grant the Secretary the authority and discretion to adopt 
standards, implementation specifications, and certification criteria 
that have been recommended by the HITAC and endorsed by the National 
Coordinator, as well as other appropriate and necessary health IT 
standards, implementation specifications, and certification criteria 
(80 FR 62606).
    Under the authority outlined in section 3004(b)(3) of the PHSA, the 
Secretary may adopt standards, implementation specifications, and 
certification criteria as necessary even if those standards have not 
been recommended and endorsed through the process established for the 
HITAC under section 3002(b)(2) and (3) of the PHSA. Moreover, while HHS 
has traditionally adopted standards and implementation

[[Page 82633]]

specifications at the same time as adopting certification criteria that 
reference those standards, the Secretary also has the authority to 
adopt standards or implementation specifications apart from the 
certification criteria adopted specifically for the voluntary 
certification of health IT under the ONC Health IT Certification 
Program.
    Finally, the Cures Act amended the PHSA to add section 3004(c) of 
the PHSA to specify that in adopting and implementing standards under 
this section, the Secretary shall give deference to standards published 
by standards development organizations and voluntary consensus-based 
standards bodies.
b. Coordination of Federal Activities With Adopted Standards and 
Implementation Specifications, and Application to Private Entities
    Section 13111 of the HITECH Act requires that when a federal agency 
implements, acquires, or upgrades health information technology systems 
used for the direct exchange of individually identifiable health 
information between agencies and with non-federal entities, it shall 
utilize, where available, health information technology systems and 
products that meet standards and implementation specifications adopted 
under section 3004 of the PHSA, as added by section 13101 of the HITECH 
Act. Similarly, section 13112 of the HITECH Act states that federal 
agencies shall require in its contracts and agreements with providers, 
plans, or issuers that as each provider, plan, or issuer implements, 
acquires, or upgrades health information technology systems, it shall 
utilize, where available, health information technology systems and 
products that meet standards and implementation specifications adopted 
under section 3004 of the PHSA.
2. Background
    Consistent with section 3004(b)(3) of the PHSA, we believe the 
standards and implementation specifications proposed at 45 CFR 170.215 
by ONC for HHS adoption are appropriate and necessary and would, if 
adopted, contribute to key health care priorities of a nationwide 
health IT infrastructure as described in section 3001(b) of the PHSA. 
The use of the identified implementation specifications across health 
IT systems would support more effective prior authorization 
transactions between providers and payers, and would help to reduce 
administrative burden and support medical decision-making. Use of the 
proposed payer data implementation specifications would help to bring 
together administrative and clinical data, and make such data 
accessible, which is an essential step to connecting cost and quality 
data to promote a more effective marketplace, greater competition, 
greater systems analysis, increased consumer choice, and improved 
outcomes in health care services. Finally, use of the additional 
implementation specifications for a Provider Directory API would 
support more robust care coordination and increased patient choice 
through improved availability of health care provider contact and 
exchange information. In support of these likely outcomes, we note that 
the CMS proposals in sections II.A., II.B., II.C., and II.D. of this 
rule detail further benefits that would result from the use of these 
implementation specifications for each of the relevant CMS payer API 
requirement proposals.
    In the following section, consistent with section 3004(b)(3) of the 
PHSA and on behalf of the Secretary, ONC proposes to adopt at 45 CFR 
170.215(c) implementation specifications for APIs based upon the 
HL7[supreg] FHIR[supreg] Release 4 base standard adopted by ONC on 
behalf of HHS at 45 CFR 170.215(a). The proposed implementation 
specifications were developed through a voluntary consensus-based 
standard organization, HL7[supreg], a non-profit standard development 
organization. In concert with CMS, ONC has led or participated in a 
variety of activities related to monitoring and evaluating the 
standards and implementation specifications identified in this proposed 
rule, utilizing available mechanisms for gathering input on these 
standards from stakeholders and experts. Based on these activities and 
input, it is appropriate to propose these specifications for adoption.
a. Standards Development Organization Activities
    Consistent with section 3004(c) of the PHSA, the implementation 
specifications proposed for adoption have been developed through an 
industry-led, consensus-based public process by a nationwide voluntary 
consensus-based standards body. HL7[supreg] is an American National 
Standards Institute (ANSI) accredited standards development 
organization. HL7[supreg] FHIR[supreg] standards are unique in their 
ability to allow disparate systems that otherwise represent data 
differently to exchange such data in a standardized way that all 
systems can share and consume via standards-based APIs. HL7[supreg] 
FHIR[supreg] IGs are also openly accessible, so any interested party 
can go to the HL7[supreg] website and access the IG. Once accessed, all 
public comments made during the balloting process as well as the IG 
version history are available for review.
    A number of the FHIR[supreg] IGs proposed for adoption have been 
developed by the Da Vinci project, an initiative established in 2018 to 
help payers and providers positively impact clinical, quality, cost, 
and care management outcomes.\59\ The Da Vinci project is part of the 
HL7[supreg] FHIR[supreg] Accelerator Program.\60\ Under the Da Vinci 
project, industry stakeholders have facilitated the definition, design, 
and creation of use-case-specific reference implementations of 
solutions based upon the HL7[supreg] FHIR[supreg] platform to address 
value-based care initiatives. Because the Da Vinci project is aligned 
with HL7[supreg], new and revised requirements can become open industry 
standards.
---------------------------------------------------------------------------

    \59\ See https://www.hl7.org/about/davinci/.
    \60\ See http://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20190211.pdf.
---------------------------------------------------------------------------

b. Interoperability Standards Advisory
    ONC's Interoperability Standards Advisory (ISA) supports the 
identification, assessment, and public awareness of interoperability 
standards and implementation specifications that can be used by the 
United States health care industry to address specific interoperability 
needs (see https://www.healthit.gov/isa). The ISA is updated on an 
annual basis based on recommendations received from public comments and 
subject matter expert feedback. This public comment process reflects 
ongoing dialogue, debate, and consensus among industry stakeholders 
when more than one standard or implementation specification could be 
used to address a specific interoperability need.
    ONC currently identifies the IGs referenced throughout this 
proposed rule within the ISA as available standards for a variety of 
potential use cases. For instance, the HL7[supreg] FHIR[supreg] Da 
Vinci PDex IG proposed for adoption at 45 CFR 170.215(c)(6) is 
currently identified under the ``Query for Documents Outside a Specific 
Health Information Exchange Domain'' within the ISA.\61\ We encourage 
stakeholders to review the ISA to better understand key applications 
for the IGs proposed for adoption in this proposed rule.
---------------------------------------------------------------------------

    \61\ See https://www.healthit.gov/isa/query-documents-outside-a-specific-health-information-exchange-domain.
---------------------------------------------------------------------------

c. Alignment With Federal Advisory Committee Activities
    The HITECH Act established two federal advisory committees, the HIT

[[Page 82634]]

Policy Committee (HITPC) and the HIT Standards Committee (HITSC). Each 
was responsible for advising the National Coordinator on different 
aspects of health IT policy, standards, implementation specifications, 
and certification criteria.
    Section 3002 of the PHSA, as amended by section 4003(e) of the 
Cures Act, replaced the HITPC and HITSC with one committee, the Health 
Information Technology Advisory Committee (HIT Advisory Committee or 
HITAC). After that change, section 3002(a) of the PHSA established that 
the HITAC would advise and recommend to the National Coordinator on 
different aspects of standards, implementation specifications, and 
certification criteria, relating to the implementation of a health IT 
infrastructure, nationally and locally, that advances the electronic 
access, exchange, and use of health information. The Cures Act 
specifically directed the HITAC to advise on two areas: (1) A policy 
framework to advance an interoperable health information technology 
infrastructure (section 3002(b)(1) of the PHSA); and (2) priority 
target areas for standards, implementation specifications, and 
certification criteria (section 3002(b)(2) and (3) of the PHSA).
    For the policy framework, as described in section 3002(b)(1)(A) of 
the PHSA, the Cures Act tasks the HITAC with providing recommendations 
to the National Coordinator on a policy framework for adoption by the 
Secretary consistent with the Federal Health IT Strategic Plan under 
section 3001(c)(3) of the PHSA. In February of 2018, the HITAC made 
recommendations to the National Coordinator for the initial policy 
framework \62\ and has subsequently published a schedule in the Federal 
Register, and an annual report on the work of the HITAC and ONC to 
implement and evolve that framework.\63\ For the priority target areas 
for standards, implementation specifications, and certification 
criteria, section 3002(b)(2)(A) of the PHSA identified that in general, 
the HITAC would recommend to the National Coordinator, for purposes of 
adoption under section 3004 of the PHSA, standards, implementation 
specifications, and certification criteria and an order of priority for 
the development, harmonization, and recognition of such standards, 
specifications, and certification criteria. In October of 2019, the 
HITAC finalized recommendations on priority target areas for standards, 
implementation specifications, and certification criteria.\64\
---------------------------------------------------------------------------

    \62\ HITAC Policy Framework Recommendations, February 21, 2018: 
https://www.healthit.gov/sites/default/files/page/2019-07/2018-02-21_HITAC_Policy-Framework_FINAL_508-signed.pdf.
    \63\ HITAC Annual Report CY 2019 published March 2, 2020: 
https://www.healthit.gov/sites/default/files/page/2020-03/HITAC%20Annual%20Report%20for%20FY19_508.pdf.
    \64\ HITAC recommendations on priority target areas, October 16, 
2019: https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf.
---------------------------------------------------------------------------

    As described above and in the ONC 2015 Edition final rule (80 FR 
62606), section 3004(b)(3) of the PHSA provides broad authority for the 
Secretary to adopt standards, implementation specifications, and 
certification criteria that have been recommended by the HITAC and 
endorsed by the National Coordinator, as well as other appropriate and 
necessary health IT standards, implementation specifications, and 
certification criteria. Under this authority, the Secretary may adopt 
standards, implementation specifications, and certification criteria as 
necessary even if those standards have not been recommended and 
endorsed through the process established for the HITAC under section 
3002(b)(2) and (3) of the PHSA. While the implementation specifications 
we are proposing to adopt have not been specifically recommended and 
endorsed through the HITAC process, the HITAC has recommended the 
adoption of interoperability standards for specific data flows 
addressed by the standards we propose to adopt in this proposed rule. 
In other instances, the HITAC has addressed issues related to 
interoperability standards for health care operations relevant to these 
proposed standards. In addition, our proposal to adopt the identified 
implementation specifications for health care operations under section 
3004(b)(3) of the PHSA is consistent with the HITAC policy framework 
schedule as well as with the priority target areas for standards and 
implementation specifications.
    In the October 16, 2019 recommendations from the HITAC establishing 
the Interoperability Standards Priority Target Areas, the HITAC 
recommendations identified a ``need for standards to support the 
integration of prior authorization (PA).'' The 2019 HITAC annual report 
(published March 2020) describes a hearing held by the HITAC related to 
prior authorization and administrative simplification. The report 
identifies continuing work in this area including highlighting the HL7 
standards development organization efforts to improve automation and 
interoperability of administrative and clinical data, and the Da Vinci 
Project use case supporting payers sending administrative data to 
providers using the HL7 FHIR standard.\65\
---------------------------------------------------------------------------

    \65\ HITAC Annual Report CY 2019 published March 2, 2020: 
https://www.healthit.gov/sites/default/files/page/2020-03/HITAC%20Annual%20Report%20for%20FY19_508.pdf.
---------------------------------------------------------------------------

    In CY 2020, ONC charged the HITAC to establish the Intersection of 
Clinical and Administrative Data (ICAD) Task Force to produce 
information and considerations related to the merging of clinical and 
administrative data. The ICAD Task Force explored a wide range of 
considerations including transport and exchange structures, areas for 
clinical and operations data alignment, and privacy and security rules 
and protections. The ICAD Task Force, which included members of the 
HITAC, NCVHS, industry, and the public, received input from a variety 
of experts and stakeholders in the field. In November 2020, the ICAD 
Task Force presented final recommendations \66\ to the HITAC, which 
were then approved by the full Committee. These included a 
recommendation to ``Establish Standards for Prior Authorization 
Workflows.'' Specifically, the final report recommends that ONC work 
with CMS, other federal actors, and standards development organizations 
to ``develop programmatic (API) specifications to create an 
authorization (digital prior authorization or related determinations 
such as Medical Necessity) such that the authorization and related 
documentation can be triggered in workflow in the relevant workflow 
system where the triggering event for the authorization is created.'' 
In addition, the final report identifies for consideration the 
potential use of HL7[supreg] FHIR[supreg] standards as part of this 
recommendation including discussion of: The HL7[supreg] FHIR[supreg] Da 
Vinci CRD and DTR IGs, and the HL7[supreg] FHIR[supreg] Da Vinci PAS 
IG. These implementation specifications, which ONC proposes to adopt on 
behalf of HHS in this proposed rule, are discussed extensively as part 
of the final report as examples of FHIR[supreg] specifications that can 
support prior authorization. ONC has considered these recommendations 
and considerations in our decision to propose to adopt these prior 
authorization implementation specifications for health care operations 
at 45 CFR 170.215(c)(1) through (3) as

[[Page 82635]]

described below in section II.E.3. of this proposed rule.
---------------------------------------------------------------------------

    \66\ Final Recommendations of the ICAD Task Force, November 
2020: https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_0.pdf.
---------------------------------------------------------------------------

    In addition to the recommendation regarding standards, the final 
report includes several additional recommendations to support the 
convergence of clinical and administrative data to improve data 
interoperability to support clinical care, reduce burden, and improve 
efficiency. We believe our proposal to adopt implementation 
specifications for health care operations relating to payer data 
exchange and provider directories at 45 CFR 170.215(c)(4) through (8) 
will help to advance these aims (see section II.E.3. of this proposed 
rule for further detail). These include recommendations relating to 
prioritizing administrative efficiency in relevant federal programs, 
focusing on convergence of health care standards, and developing 
patient-centered workflows and standards. We agree with the findings in 
the final report which state that these recommendations will help to 
form a solid basis on which to develop the future policies, standards, 
and enabling technologies that will truly put the patient at the center 
of an efficient health care information ecosystem.
d. Coordination of Federal Activities With Adopted Standards and 
Implementation Specifications
    Consistent with sections 13111 and 13112 of the HITECH Act, ONC has 
worked with CMS, HHS agencies, and other federal partners to ensure 
that federal activities involving the implementation, acquisition, and 
upgrade of systems that collect and process health information are 
consistent with the standards and implementation specifications adopted 
under section 3004 of the PHSA. Aligning the use of such standards and 
implementation specifications would ensure that the same health IT 
standards are utilized by federal government programs and federal 
partners in the health care industry and reduce the risk of competing 
or inconsistent regulatory requirements increasing stakeholder burden. 
In addition, alignment of standards and implementation guidance would 
be expected to reduce fragmentation between and among systems 
supporting interoperability across the health care continuum for a wide 
range of use cases.
    This includes specific efforts to align federal activities with the 
standards for APIs adopted in the ONC 21st Century Cures Act final rule 
as proposed in 2019 and finalized in 2020 (85 FR 25642). The ONC 21st 
Century Cures Act final rule implements provisions of the Cures Act, 
which prioritize the adoption of APIs across the health care industry. 
In the API requirements for payers finalized in the CMS 
Interoperability and Patient Access final rule (85 FR 25510), which 
serve as the basis for several additional proposals in this proposed 
rule, CMS specified alignment of their final policies with technical 
standards for APIs adopted in the ONC 21st Century Cures Act final rule 
at 45 CFR 170.215, as well as the USCDI version 1 standard vocabulary 
standard adopted at 45 CFR 170.213.
    In addition to the efforts described in this proposed rule, HHS 
agencies are exploring areas for alignment to these adopted standards 
to improve health information exchange for a wide range of use cases. 
Some examples include:
    <bullet> In fall 2019, NIH published a request for information on 
the use of FHIR-based APIs to support research use cases (https://grants.nih.gov/grants/guide/notice-files/NOT-OD-19-150.html).
    <bullet> In partnership with the CDC, ONC has worked with HL7 and 
other standards development process participants to develop an IG to 
provide developers and IT staff details on how to access prescription 
drug monitoring program (PDMP) data from clinical systems. This ongoing 
work includes aligning the IG with updates to existing standards and 
specifically FHIR Release 4 (http://hl7.org/fhir/us/meds/2018May/pdmp.html).
    <bullet> CMS is leading the PACIO Project for the development of 
post-acute care FHIR implementation specifications and reference 
implementations that will facilitate health data exchange through 
standards-based APIs (https://confluence.hl7.org/display/PC/PACIO+Project).
    As these efforts continue, ONC will continue to work with federal 
partners and monitor and analyze interoperability standards and 
implementation specifications for potential adoption on behalf of the 
Secretary and HHS. This ongoing process aims to support coordination 
and alignment of federal activities involving the broad collection and 
submission of health information, as well as the applicability to 
private entities engaged in health information exchange with federal 
partners. The overarching goal is to continue to support the 
advancement of a nationwide health information technology 
infrastructure that reduces burden and health care costs, and, most 
importantly, improves patient care.
3. Proposal To Adopt the Standards for Use by HHS
    Consistent with section 3004(b)(3) of the PHSA and the efforts 
described above to evaluate and identify standards for adoption, on 
behalf of the Secretary, we propose to adopt the implementation 
specifications for health care operations at 45 CFR 170.215 to support 
the continued development of a nationwide health information technology 
infrastructure as described under section 3001(b) of the PHSA and to 
support federal alignment of standards for interoperability and health 
information exchange. Specifically, we propose to adopt the latest 
versions of the following standards at 45 CFR 170.215 under a new 
paragraph (c), ``Standards and Implementation Specifications for Health 
Care Operations.'' We note that each IG is discussed in detail in 
relation to the specific API it will support in sections II.A., II.B., 
II.C., and II.D. of this proposed rule, as well as in section IV. of 
this proposed rule. The latest version of each standard may be accessed 
at the links provided:
    <bullet> HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD) 
Implementation Guide: Version STU 1.0.0. URL: http://hl7.org/fhir/us/davinci-crd/history.html.
    <bullet> HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR) 
Implementation Guide: Version STU 1.0.0. URL: http://hl7.org/fhir/us/davinci-dtr/history.html.
    <bullet> HL7 FHIR Da Vinci--Prior Authorization Support (PAS) 
Implementation Guide: Version STU 1.0.0. URL: http://hl7.org/fhir/us/davinci-pas/history.html.
    <bullet> HL7 FHIR Da Vinci--Payer Coverage Decision Exchange (PCDE) 
Implementation Guide: Version STU 1.0.0. URL: http://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
    <bullet> HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG 
for Blue Button[supreg]) Implementation Guide: Version STU 1.0.0. URL: 
http://hl7.org/fhir/us/carin-bb/history.html.
    <bullet> HL7 FHIR Da Vinci Payer Data Exchange (PDex) 
Implementation Guide: Version STU 1.0.0. URL: http://hl7.org/fhir/us/davinci-pdex/history.html.
    <bullet> HL7 FHIR Da Vinci--Payer Data Exchange (PDex) US Drug 
Formulary Implementation Guide: Version STU 1.0.1. URL: http://hl7.org/fhir/us/Davinci-drug-formulary/history.html.
    <bullet> HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net 
Implementation Guide: Version STU 1.0.0. URL: http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.

[[Page 82636]]

    The implementation specifications proposed for adoption in this 
rule would be important additions to the group of interoperability 
specifications adopted by HHS. We believe that by adopting these 
standards, as proposed at 45 CFR 170.215(c), we would support future 
alignment across health care system stakeholders and the development of 
a robust nationwide health IT infrastructure.
    Unlike other rulemakings in which ONC has engaged, we are not 
proposing new or revised certification criteria based on the proposed 
adoption of these standards, nor are we proposing to require testing 
and certification to these implementation specifications for any 
existing certification criteria in the ONC Health IT Certification 
Program. These proposals focus on the adoption of standards and 
implementation specifications for health information technology to 
support interoperability and health information exchange across a wide 
range of potential use cases. We expect that, as new models of care 
delivery continue to connect clinical and payment data in innovative 
ways to reduce burden and increase efficiency, the implementation 
specifications we are proposing to adopt at 45 CFR 170.215(c) will 
contribute to advancing the interoperability of data across clinical 
and administrative systems. We further believe this approach will 
support federal alignment and coordination of federal activities with 
adopted standards and implementation specifications for a wide range of 
systems, use cases, and data types within the broad scope of health 
information exchange. As noted above under section II.E.1.b. of this 
proposed rule, historically, state, federal, and local partners have 
leveraged the standards adopted by ONC on behalf of HHS (as well as 
those identified in the ISA) to inform program requirements, technical 
requirements for grants and funding opportunities, and systems 
implementation for health information exchange. We believe the adoption 
of these standards will support these HHS partners in setting technical 
requirements and exploring the use of innovative health IT solutions 
for health information exchange for health care operations.
    We additionally propose to make minor revisions to the regulation 
text at 45 CFR 170.215 to support clarity in the short descriptions of 
the standards and implementation specifications previously adopted at 
45 CFR 170.215(a) and (b). However, we are not proposing any changes to 
the standards and implementation specifications, or versions thereof, 
previously adopted in 45 CFR 170.215(a) or (b). For the implementation 
specifications proposed for adoption at 45 CFR 170.215(c) Standards and 
Implementation Specifications for Health Care Operations, we propose to 
incorporate by reference the specified version of each implementation 
specification at 45 CFR 170.299.

III. Requests for Information

A. Methods for Enabling Patients and Providers To Control Sharing of 
Health Information

    The CMS Interoperability and Patient Access final rule (85 FR 
25510) and this proposed rule are focused on unleashing data in order 
to empower patients to make informed decisions and empowering providers 
with the data they need at the moment they are caring for their 
patients. Stakeholders have shared that they believe part of empowering 
patients and providers is being sure both have a say in what specific 
data are shared, when, and with whom. We have started to address this 
issue within these two regulations. However, we received several 
comments on the CMS Interoperability and Patient Access proposed rule 
(84 FR 7610) indicating that patients and providers want more options 
for controlled sharing of health information beyond what is currently 
in place under current federal and state laws and regulations. 
Commenters indicated a preference for a framework that honors an 
individual's privacy rights, without constricting permissible uses of 
health information to improve the health and wellness of individuals 
and populations.
    Commenters indicated that some patients want the right to choose 
which data elements from their health record are shared with specified 
providers, payers, and third parties. Other patients want the ability 
to opt out of information exchanges between payers and other 
stakeholders, such as health care providers and health information 
exchanges. Some patients indicated that they want their preferences 
considered in the determination of what data should be shared, and they 
desire the ability to deem certain aspects of their health information 
as sensitive and not to be shared under pre-defined circumstances. 
These patient preferences could provide the opportunity to continue 
support for patient autonomy and encourage greater patient 
participation, as patients should have an understanding of how their 
health information is being shared and used, given this could have an 
impact on their care.
    We received comments indicating that providers want the right to 
choose if all or some of a patient's data should be shared with other 
providers and/or the patient themselves, especially if they believe 
sharing specific information could lead to negative outcomes. One 
example mentioned is where a provider may want to edit or remove a 
section of a patient's clinical notes before sharing the record with 
the patient and/or another provider if the notes indicate a possible 
diagnosis that may be misunderstood by the patient or lead to 
stigmatization by another provider who does not possess sufficient 
context prior to reading the notes.
    In regards to providers having the ability to choose which data are 
shared, we noted that the HIPAA Privacy Rule allows for certain limited 
circumstances for which a provider may deny a patient access to all or 
a portion of a patient's data under 45 CFR 164.524(a)(2) and 45 CFR 
164.524(a)(3). While there may also be relevant state laws, those that 
applied additional restrictions on individual access would be preempted 
by HIPAA, and we note that providing patients with easy access to their 
health information empowers them to be more in control of decisions 
regarding their health and well-being.
    We also note that in ONC's 21st Century Cures Act final rule (85 FR 
25642), ONC finalized certain exceptions to the practice of information 
blocking, which would allow health care providers, health IT 
developers, exchanges, and networks to withhold data from other health 
care providers, health IT developers, exchanges, and networks under 
certain circumstances. This allows organizations to respect an 
individual's request not to share information, where not required or 
prohibited by law.
    Additionally, we received comments about the maturity of existing 
processes that impact access controls of heath IT systems, such as data 
segmentation, or processes that enable more granular consent 
capabilities. Commenters indicated concerns that the current standards 
available are not well adopted or appropriately conformant with the 
FHIR version 4 (85 FR 25546).
    Taking into consideration applicable federal, state, local, and 
tribal law, we are interested in stakeholder feedback on different 
methods that enable patients and providers to have more granular 
control over the sharing of patient health information. Specifically, 
we are seeking stakeholder feedback on the following questions:
    <bullet> Patient Engagement and Provider Discretion. What role 
should patients and providers play in data segmentation

[[Page 82637]]

decisions? Should patients assume this responsibility and are there 
mechanisms currently in place or available that could support the 
documenting of these preferences? Would providing opportunities to 
express these preferences negatively impact patients who are unable or 
choose not to state their preferences? For instance, would a patient 
who did not fully understand how, or, or the pros and cons of, sharing 
some data but not other data be at a disadvantage in some way? How can 
patients be engaged in these decisions and acquire adequate 
understanding of how their data are being shared without burdening 
them? Are there specific situations, use cases, or considerations that 
should limit how the impacted entity responds to a data segmentation 
request to either restrict uses and disclosures of some of the data, or 
to obtain access to some of the data from a patient or provider? Are 
there unintended consequences of such data segmentation requests or 
options? If so, how can they be addressed?
    <bullet> Methods and Readiness. What are examples of effective 
tools and methods for patients and providers to control access to 
portions of patients' health data? What is the readiness and 
feasibility of implementing successful access control methods?
    <bullet> Resource Burden. Commenters raised concerns about the 
potential cost and burden of data segmentation at the data element 
level. Specifically, would requiring the ability to segment the data 
by, for instance, conducting data tagging, place additional burden on 
clinical providers? Please describe the nature of any additional 
burden. What are possible solutions to consider to address these 
concerns?
    <bullet> Current Patient Consent Practices. How do current consent 
practices inform patients of opportunities for patient engagement and 
provider discretion in responding to patient requests? What technology 
and policy gaps exist for achieving widespread successful segmentation 
practices?
    <bullet> FHIR Utility. What recommendations do stakeholders have to 
improve the data segmentation capabilities of existing FHIR standards? 
How would you describe the state of development projects or standards 
efforts planned or ongoing to address data segmentation (or 
segmentation of sensitive information) on FHIR or other standards? What 
are the key gaps or constraints that exist within ongoing and emerging 
efforts?
    <bullet> Technical Considerations. What general data segmentation 
strategies can we leverage for the programs described in this proposed 
rule from standards like the Substance Abuse and Mental Health Services 
Administration's (SAMSHA) Consent2Share \67\ and HL7 Data Segmentation 
for Privacy (DS4P)? \68\ What lessons can we learn from use of these 
existing standards?
---------------------------------------------------------------------------

    \67\ HL7 International Community-Based Care and Privacy. (n.d.). 
Consent2Share Implementation Guide. Retrieved from https://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=303.
    \68\ Office of the National Coordinator for Health Information 
Technology. (2020). Data Segmentation of Sensitive Information. 
Retrieved from https://www.healthit.gov/isa/data-segmentation-sensitive-information.
---------------------------------------------------------------------------

    <bullet> How can existing tools, resources, and approaches with 
data segmentation be used to help inform any approaches or strategies 
that CMS might consider proposing for impacted entities? \69\
---------------------------------------------------------------------------

    \69\ For selected resources on practices for privacy and data 
segmentation, see p. 61 of the Health IT Advisory Committee Notice 
of Proposed Rulemaking Task Force. (2019, June 3). Information 
Blocking Task Force Recommendations. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-07/2019-06-03_All%20FINAL%20HITAC%20NPRM%20Recs_508-signed.pdf.
---------------------------------------------------------------------------

    <bullet> Patient Options. Should preferences be something that data 
senders should try to honor but retain flexibility to deny in certain 
situations, when consistent with applicable regulations? For example, 
the HIPAA Privacy Rule requires a covered entity to permit an 
individual to request restrictions on the entity's uses and disclosures 
of PHI, but only requires the entity to agree to the request in limited 
circumstances (see 45 CFR 164.522(a)(1)(vi)).
    <bullet> Current Segmentation Efforts. Varied segmentation 
practices exist, and we are seeking stakeholder input from those who 
have implemented or piloted patient-controlled segmentation models, 
individual provider-controlled models, or other related models or 
tools. What prevents patients and/or providers from recording, 
maintaining, or using a patient's privacy preferences when exchanging 
health information? How can data segmentation decisions be automated? 
Are there particular processes or workflows related to patient privacy 
preferences, consent, or data segmentation that could be improved by 
automation and/or standardization?

B. Electronic Exchange of Behavioral Health Information

    Several factors have led to an EHR adoption rate that is 
significantly lower among behavioral health providers compared to other 
types of health care providers. One possible contributing factor was 
that the Health Information Technology for Economic and Clinical Health 
Act (Pub. L. 111-5, enacted February 17, 2009) (HITECH Act) made 
Medicare fee-for-service and Medicaid incentive payments for the 
adoption and meaningful use of certified EHR technology available only 
to eligible professionals, eligible hospitals, and critical access 
hospitals (CAH). Behavioral health providers that did not meet the 
criteria to be considered an eligible professional, eligible hospital, 
or CAH were not eligible for these incentive payments. For example, 
behavioral health providers who were physicians (eligible 
professionals) could receive the incentive payments, but other types of 
non-physician behavioral health providers may not have been eligible.
    Today, behavioral health providers lag behind their peers in the 
ability to electronically share health information across providers and 
with patients. ONC noted that, in 2017, only 12 percent of office-based 
physicians reported sending data to behavioral health providers, while 
14 percent of office-based physicians reported receiving data from 
behavioral health providers.\70\ Other technical and regulatory 
restrictions, such as 42 CFR part 2, which governs the confidentiality 
of substance use disorder patient records maintained by a covered 
substance use disorder treatment program can also inhibit the exchange 
of behavioral health information.
---------------------------------------------------------------------------

    \70\ Office of the National Coordinator. ``Interoperability 
among Office-Based Physicians in 2015 and 2017.'' ONC Data Brief No. 
47 (May 2019). Retrieved from https://www.healthit.gov/sites/default/files/page/2019-05/2015to2017PhysicianInteroperabilityDataBrief_0.pdf.
---------------------------------------------------------------------------

    Understanding the time and cost of implementing an EHR system, we 
are interested in evaluating whether using other applications that 
exchange data using FHIR-based APIs and do not require implementation 
of a full EHR system might be a way to help behavioral health providers 
leverage technology to exchange health data to improve care quality and 
coordination in a more agile fashion. Specifically, would small 
practices, community-based providers, and other non-traditional 
providers be able to more quickly adopt applications using API 
technology to exchange health information when the technology is not 
tied to an EHR? Would these providers be able to achieve the same care 
coordination goals using such applications as with a more extensive EHR 
implementation, or would the value be lower but still sufficient to 
improve care quality and care coordination?

[[Page 82638]]

    Over the past few years, HHS continued to highlight the importance 
of coordinated care and removing any unnecessary obstacles. In 2018, 
HHS launched the ``Regulatory Sprint to Coordinated Care'' prompting 
agencies within the Department to assess a variety of long-standing 
regulatory requirements to see whether they hinder innovative progress 
and how they can better incentivize coordination. We have also seen the 
Substance Abuse and Mental Health Services Administration (SAMHSA) 
publish regulations related to improved care coordination among 
providers that treat substance use disorders as well as protecting 
those patients' records (42 CFR part 2), and the enactment of the 
Substance Use-Disorder Prevention that Promotes Opioid Recovery and 
Treatment for Patients and Communities Act (SUPPORT for Patients and 
Communities Act) (Pub. L. 115-271, October 24, 2018), which encouraged 
us to consider ways to facilitate information sharing among behavioral 
health providers. In the spirit of the ``Regulatory Sprint to 
Coordinated Care'' and these policies, we are looking for innovative 
approaches to addressing the need to facilitate the electronic exchange 
of behavioral health information, as well as approaches to support the 
exchange of health information to behavioral health providers to inform 
care and provision of behavioral health services.
    Many behavioral health providers are in the community. As a result, 
when thinking about behavioral health specifically, it is valuable to 
think about community-based providers more broadly.
    We are interested in public comments on how we might best support 
electronic data exchange of behavioral health information between and 
among behavioral health providers, other health care providers, and 
patients, as well as how we might best inform and support the movement 
of health data (and its consistency) to behavioral health providers for 
their use to inform care and treatment of behavioral health services. 
Specifically, we are seeking public comments on the following 
questions:
    <bullet> Can applications using FHIR-based APIs facilitate 
electronic data exchange between behavioral health providers and with 
other health care providers, as well as their patients, without greater 
EHR adoption? Is EHR adoption needed first? What opportunities do FHIR-
based APIs provide to bridge the gap? What needs might not be addressed 
by the use of applications with more limited functionality than 
traditional EHRs?
    <bullet> What levers could CMS consider using to facilitate greater 
electronic health data exchange from and to behavioral health 
providers? What costs, resources, and/or burdens are associated with 
these options?
    <bullet> Are there particular considerations for electronic data 
exchange for behavioral health providers who practice independently, 
are community-based, or are non-traditional providers? What about 
rural-based behavioral health providers? How could an API-based 
solution help address these considerations?
    <bullet> Are there state or federal regulations or payment rules 
that are perceived as creating barriers to technical integration of 
systems within these practices? What additional policy issues, 
technical considerations, and operational realities should we consider 
when looking at ways to best facilitate the secure electronic exchange 
of health information that is maintained by behavioral health providers 
including sensitive health information?
    <bullet> What levers and approaches could CMS consider using and 
advancing to facilitate greater electronic health data exchange from 
and to community-based health providers including use of relevant 
health IT standards as feasible? What costs, resources, and/or burdens 
are associated with these options?
    We seek comments on these questions and issues for future 
consideration.

B. Electronic Exchange of Behavioral Health Information

    Several factors have led to an EHR adoption rate that is 
significantly lower among behavioral health providers compared to other 
types of health care providers. One possible contributing factor was 
that the Health Information Technology for Economic and Clinical Health 
Act (Pub. L. 111-5, enacted February 17, 2009) (HITECH Act) made 
Medicare fee-for-service and Medicaid incentive payments for the 
adoption and meaningful use of certified EHR technology available only 
to eligible professionals, eligible hospitals, and critical access 
hospitals (CAH). Behavioral health providers that did not meet the 
criteria to be considered an eligible professional, eligible hospital, 
or CAH were not eligible for these incentive payments. For example, 
behavioral health providers who were physicians (eligible 
professionals) could receive the incentive payments, but other types of 
non-physician behavioral health providers may not have been eligible.
    Today, behavioral health providers lag behind their peers in the 
ability to electronically share health information across providers and 
with patients. ONC noted that, in 2017, only 12 percent of office-based 
physicians reported sending data to behavioral health providers, while 
14 percent of office-based physicians reported receiving data from 
behavioral health providers.\71\ Other technical and regulatory 
restrictions, such as 42 CFR part 2, which governs the confidentiality 
of substance use disorder patient records maintained by a covered 
substance use disorder treatment program can also inhibit the exchange 
of behavioral health information.
---------------------------------------------------------------------------

    \71\ Office of the National Coordinator. ``Interoperability 
among Office-Based Physicians in 2015 and 2017.'' ONC Data Brief No. 
47 (May 2019). Retrieved from https://www.healthit.gov/sites/default/files/page/2019-05/2015to2017Physician 
InteroperabilityDataBrief_0.pdf.
---------------------------------------------------------------------------

    Understanding the time and cost of implementing an EHR system, we 
are interested in evaluating whether using other applications that 
exchange data using FHIR-based APIs and do not require implementation 
of a full EHR system might be a way to help behavioral health providers 
leverage technology to exchange health data to improve care quality and 
coordination in a more agile fashion. Specifically, would small 
practices, community-based providers, and other non-traditional 
providers be able to more quickly adopt applications using API 
technology to exchange health information when the technology is not 
tied to an EHR? Would these providers be able to achieve the same care 
coordination goals using such applications as with a more extensive EHR 
implementation, or would the value be lower but still sufficient to 
improve care quality and care coordination?
    Over the past few years, HHS continued to highlight the importance 
of coordinated care and removing any unnecessary obstacles. In 2018, 
HHS launched the ``Regulatory Sprint to Coordinated Care'' prompting 
agencies within the Department to assess a variety of long-standing 
regulatory requirements to see whether they hinder innovative progress 
and how they can better incentivize coordination. We have also seen the 
Substance Abuse and Mental Health Services Administration (SAMHSA) 
publish regulations related to improved care coordination among 
providers that treat substance use disorders as well as protecting 
those patients' records (42 CFR part 2), and the enactment of the 
Substance Use-Disorder Prevention that Promotes Opioid Recovery and 
Treatment for Patients and Communities Act (SUPPORT for Patients and

[[Page 82639]]

Communities Act) (Pub. L. 115-271, October 24, 2018), which encouraged 
us to consider ways to facilitate information sharing among behavioral 
health providers. In the spirit of the ``Regulatory Sprint to 
Coordinated Care'' and these policies, we are looking for innovative 
approaches to addressing the need to facilitate the electronic exchange 
of behavioral health information, as well as approaches to support the 
exchange of health information to behavioral health providers to inform 
care and provision of behavioral health services.
    Many behavioral health providers are in the community. As a result, 
when thinking about behavioral health specifically, it is valuable to 
think about community-based providers more broadly.
    We are interested in public comments on how we might best support 
electronic data exchange of behavioral health information between and 
among behavioral health providers, other health care providers, and 
patients, as well as how we might best inform and support the movement 
of health data (and its consistency) to behavioral health providers for 
their use to inform care and treatment of behavioral health services. 
Specifically, we are seeking public comments on the following 
questions:
    <bullet> Can applications using FHIR-based APIs facilitate 
electronic data exchange between behavioral health providers and with 
other health care providers, as well as their patients, without greater 
EHR adoption? Is EHR adoption needed first? What opportunities do FHIR-
based APIs provide to bridge the gap? What needs might not be addressed 
by the use of applications with more limited functionality than 
traditional EHRs?
    <bullet> What levers could CMS consider using to facilitate greater 
electronic health data exchange from and to behavioral health 
providers? What costs, resources, and/or burdens are associated with 
these options?
    <bullet> Are there particular considerations for electronic data 
exchange for behavioral health providers who practice independently, 
are community-based, or are non-traditional providers? What about 
rural-based behavioral health providers? How could an API-based 
solution help address these considerations?
    <bullet> Are there state or federal regulations or payment rules 
that are perceived as creating barriers to technical integration of 
systems within these practices? What additional policy issues, 
technical considerations, and operational realities should we consider 
when looking at ways to best facilitate the secure electronic exchange 
of health information that is maintained by behavioral health providers 
including sensitive health information?
    <bullet> What levers and approaches could CMS consider using and 
advancing to facilitate greater electronic health data exchange from 
and to community-based health providers including use of relevant 
health IT standards as feasible? What costs, resources, and/or burdens 
are associated with these options?
    We seek comments on these questions and issues for future 
consideration.

D. Reducing Burden and Improving Electronic Information Exchange of 
Prior Authorizations

    As discussed in section II.C. of this proposed rule, we believe 
there are many benefits to using electronic prior authorization 
solutions. Specifically, we propose to require impacted payers to 
implement, maintain, and use a Prior Authorization Support API. 
However, as we discuss in section VII. of this proposed rule, the 
health care system would gain maximum benefits if providers adopted use 
of the Prior Authorization Support API as well. As a result, we are 
requesting information for consideration in future rulemaking regarding 
how CMS can best incentivize providers to use electronic prior 
authorization solutions.
1. Electronic Prior Authorization for Medicare- and Medicaid-
Participating Providers and Suppliers
    We have been working with the provider community to ensure that the 
Conditions of Participation, Conditions for Certification, and 
Conditions for Coverage (CoPs and CfCs) reflect the latest advances in 
health information technology and interoperability to the greatest 
extent possible. For instance, the CMS Interoperability and Patient 
Access final rule (85 FR 25510, finalized on May 1, 2020) revised the 
CoPs for hospitals, psychiatric hospitals, and critical access 
hospitals (CAHs) by adding new standards that require a hospital, 
including a psychiatric hospital, or a CAH, which utilizes an 
electronic medical records system or other electronic administrative 
system that meets certain technical specifications, to demonstrate that 
it sends electronic patient event notifications to the patient's 
primary care practitioner, practice group, or other practitioner or 
practice group identified by the patient as being responsible for his 
or her primary care, when a patient is admitted to, and discharged 
(and/or transferred) from, the hospital or the CAH.
    The notifications must include, at a minimum, the patient's name, 
the name of the treating practitioner, and the name of the sending 
institution. These provisions were finalized at Sec.  482.24(d), 
``Electronic notifications,'' for hospitals; at Sec.  482.61(f), 
``Electronic notifications,'' for psychiatric hospitals; and at Sec.  
485.638(d), ``Electronic notifications,'' for CAHs. The CMS 
Interoperability and Patient Access final rule (85 FR 25510) requires 
hospitals, including psychiatric hospitals, and CAHs to implement the 
patient event notification provisions by April 30, 2021. As we 
explained in that final rule, there is growing evidence that health 
information exchange can lower cost and improve outcomes, particularly 
when the exchange of information, such as a patient event notification, 
is between providers. These exchanges are associated with better care 
coordination, a reduction in 30-day readmissions, and improved 
medication reconciliation, for instance (85 FR 25585).
    In reviewing other areas where the electronic exchange of patient 
information through interoperable systems offers significant 
opportunities for improvements for direct patient care, and also to 
overall health care system efficiency, we have identified electronic 
prior authorization as an area that might benefit from these 
technological advances. As we have discussed elsewhere in this proposed 
rule, we believe that the electronic prior authorization process is an 
opportunity to reduce burden and improve care. Prior authorization is 
the request and approval for payment of items and services (including 
prescription drugs) provided by Medicare- and Medicaid-participating 
providers and suppliers (including, but not limited to, hospitals, 
psychiatric hospitals, and CAHs) to beneficiaries. We recognize that 
there are gaps in the current prior authorization process, including:
    <bullet> Prior authorization requirements not residing within a 
provider's EHR or not being visible to the provider or staff members as 
part of the workflow;
    <bullet> Inability to rely on a consistent submission method for 
prior authorization requests. In many cases, only some of the process 
is automated, or electronic, making for a hybrid process that is 
partially computer-based through an EHR or practice management system, 
and partially manual, requiring phone calls, faxes, or emails, 
resulting in various workarounds that may or may not meld together;
    <bullet> Paper forms and portals require manual data reentry that 
may already reside electronically within an EHR; and
    <bullet> There are multiple routes to obtain a prior authorization 
depending on the

[[Page 82640]]

payer, item or service, and provider (such as a hospital).
    We are interested in learning what barriers exist for hospitals 
(and other providers and suppliers) to electronically transmit prior 
authorization requests and receive prior authorization decisions for 
patients receiving care and services by the applicable provider. We 
believe answers to the following questions would be beneficial in 
obtaining additional information on the overall electronic prior 
authorization process, the impact of this process on patient health and 
safety issues, and whether the hospital (and other providers and 
suppliers)CoP requirements are a good vehicle to achieve nearly 
universal adoption and use of electronic prior authorization requests 
and receipts:
    <bullet> What are the current barriers to transmitting prior 
authorization requests and receipts electronically? What actions could 
CMS and/or industry take to remove barriers?
    <bullet> Do the current methods for electronic transmission of 
prior authorization requests and receipts, including the adopted 
standard, and any that have been established and maintained by third-
party health care insurers (including Medicare) provide the efficient 
and timely request and receipt of prior authorization decisions? Please 
provide relevant detail in your response.
    <bullet> Would the CMS CoP/CfC requirements for hospitals and other 
providers and suppliers be the appropriate lever by which CMS should 
propose new or additional provisions that would require the electronic 
request and receipt of prior authorization decisions? If so, under 
which provisions would this best be accomplished?
    We intend to utilize this information as we evaluate opportunities 
to revise the hospital and CAH CoP requirements related to electronic 
prior authorization request and receipt.
2. Request for Information: Future Electronic Prior Authorization Use 
in the Merit-Based Incentive Payment System (MIPS)
    As discussed in section II.C. of this proposed rule, we believe the 
tools to support more efficient electronic prior authorization 
processes have the potential to greatly reduce the amount of time 
needed for submitting, reviewing, and making prior authorization 
decisions. We are considering ways to encourage clinicians to use 
electronic prior authorization solutions and are seeking input on the 
addition of an improvement activity for the Merit-Based Incentive 
Payment System (MIPS). The Medicare Access and CHIP Reauthorization Act 
of 2015 (Pub. L. 114-10) established MIPS for certain Medicare-
participating eligible clinicians, a system that will make payment 
adjustments based upon scores from four performance categories. We 
first established policies for MIPS in the CY 2017 Quality Payment 
Program final rule (81 FR 77008 through 77831) and annually thereafter.
    Section 1848(q)(2)(C)(v)(III) of the Act defines an improvement 
activity as an activity that relevant eligible clinician organizations 
and other relevant stakeholders identify as improving clinical practice 
or care delivery, and that the Secretary determines, when effectively 
executed, is likely to result in improved outcomes. For previous 
discussions on the background of the improvement activities performance 
category, we refer readers to the CY 2017 Quality Payment Program final 
rule (81 FR 77177 through 77178), the CY 2018 Quality Payment Program 
final rule (82 FR 53648 through 53661), the CY 2019 Physician Fee 
Schedule (PFS) final rule (83 FR 59776 through 59777), and the CY 2020 
PFS final rule (84 FR 62980 through 62990). We also refer readers to 42 
CFR 414.1305 for the definition of improvement activities and 
attestation, Sec.  414.1320 for the performance period, Sec.  414.1325 
for data submission requirements, Sec.  414.1355 for the improvement 
activity performance category generally, Sec.  414.1360 for data 
submission criteria, and Sec.  414.1380(b)(3) for improvement 
activities performance category scoring.
    In section II.C of this proposed rule, we note that prior 
authorization is the process through which a provider must obtain 
approval from a payer before providing care, and prior to receiving 
payment for delivering items or services. In that section, we propose 
that state Medicaid and CHIP FFS programs, Medicaid managed care plans, 
CHIP managed care entities, and QHP issuers on the FFEs implement and 
maintain a Prior Authorization Support (PAS) Application Programing 
Interface (API) conformant with the HL7 Fast Healthcare 
Interoperability Resources (FHIR) (PAS) IG beginning January 1, 2023 
(for Medicaid managed care plans and CHIP managed care entities, by the 
rating period beginning on or after January 1, 2023). We believe the 
PAS API would provide an opportunity to leverage the convenience and 
efficiency of API technology, while maintaining compliance with the 
mandated HIPAA transaction standard, to accelerate electronic prior 
authorization adoption and use by enabling the prior authorization 
process to be integrated into a provider's EHR or practice management 
system. Providers could leverage the PAS API to improve care 
coordination and patient and clinician shared decision making through 
improvements to the prior authorization process, particularly if the 
API is integrated into the provider workflow.
    We believe that MIPS eligible clinicians would also benefit from 
the PAS API, and we are seeking comment on whether we should add a MIPS 
improvement activity to our Inventory that would utilize this PAS API 
to facilitate submitting and receiving electronic prior authorization 
requests and decisions to reduce burden, improve efficiency, and 
ultimately ensure patients receive the items and services they need in 
a timely fashion. We believe this could fall under the care 
coordination subcategory (81 FR 77188) and section 1848(q)(2)(B)(iii) 
of the Act. We refer readers to Table H in the Appendix of the CY 2017 
Quality Payment Program final rule (81 FR 77177 through 77199), Tables 
F and G in the Appendix of the CY 2018 Quality Payment Program final 
rule (82 FR 54175 through 54229), Tables X and G in the Appendix 2 of 
the CY 2019 PFS final rule (83 FR 60286 through 60303), and Tables A, 
B, and C in the Appendix 2 of the CY 2020 PFS final rule (84 FR 63514 
through 63538) for our previously finalized improvement activities 
Inventory. We also refer readers to the Quality Payment Program website 
at https://qpp.cms.gov/ for a complete list of the most current 
improvement activities.
    We are interested in comments regarding the addition of a MIPS 
improvement activity, and if this area will be appropriate to encourage 
clinicians to make certain improvements.
    <bullet> Is this an activity that stakeholders identify as 
improving clinical practice or care delivery?
    <bullet> When effectively executed, is implementation of such 
technology and use of these standards likely to result in improved 
outcomes?
    <bullet> If yes, should this activity be assigned a medium-weight 
or high-weight?
    We refer readers to section III.I.3.h.(4)(d)(i)(C) of CY 2019 PFS 
final rule (83 FR 59776 through 59777) where we discussed that high-
weighting should be used for activities that directly address areas 
with the greatest impact on beneficiary care, safety, health, and well-
being and/or is of high intensity, requiring significant investment of 
time and resources. If the

[[Page 82641]]

addition of a MIPS improvement activity incorporating the use of a 
FHIR-based Prior Authorization Support API is not an incentive to 
encourage clinicians to use electronic prior authorization solutions, 
are there other ways that we could do so?
    In addition to the above questions, we are also seeking comment on 
the following questions regarding how best to encourage the use of 
electronic prior authorization:
    <bullet> Should CMS consider adding a measure to the Medicare 
Promoting Interoperability Program for eligible hospitals and critical 
access hospitals and the MIPS Promoting Interoperability performance 
category for clinicians and groups to encourage the use of electronic 
prior authorization through a payer's Prior Authorization Support API?
    <bullet> What are the primary considerations for developing such a 
measure?
    <bullet> How would the measure require the use of certified 
electronic health record technology?
    <bullet> Should the Prior Authorization Support IG be incorporated 
into potential future certification requirements for health IT under 
the ONC Health IT Certification Program?
    <bullet> Should CMS consider additional measures and activities 
under MIPS Quality, Cost, or Improvement Activities performance 
categories involving FHIR-based electronic prior authorization 
solutions?
    <bullet> If so, what are the primary considerations for developing 
such measures and activities?
    <bullet> What other approaches should CMS consider to help support 
clinician use of electronic prior authorization solutions such as the 
Prior Authorization Support API?

E. Reducing the Use of Fax Machines

    CMS is continually looking for ways to facilitate efficient, 
effective, and secure electronic data exchange to help ensure more 
timely, better quality, and highly coordinated care. Historically, we 
have relied on fax technology as a primary method for sharing 
information across the health care system, which can allow for easy 
sending and receiving of documents. However, the data in those 
documents are not easily integrated electronically into a patient's 
medical record or shared in an interoperable way with other payers and 
providers. Therefore, using fax technology limits our ability to reach 
true interoperability.
    Fax technology creates inefficiencies. It requires time spent 
manually pulling together clinical and administrative data from EHRs 
and practice management systems, transmitting data back and forth 
between health care providers and payers using a mechanism slower than 
the internet, and making frequent follow-up phone calls between health 
care providers and other providers and payers to clarify unclear 
transaction statuses in real-time. We discuss examples of these 
inefficiencies further in sections II.C. and V.C. of this proposed 
rule, to which we refer readers.
    To work toward true interoperability, we believe we must reduce or 
completely eliminate the use of fax technology in health care. To this 
end, we seek comment on how CMS can reduce or completely eliminate the 
use of fax technology across programs, including both hospitals and 
post-acute care facilities, so that information can be shared 
electronically in real time without extensive follow-up to determine if 
the information was received. At CMS, we are working to identify all 
programs and processes that currently require and/or encourage the use 
of fax technology for data exchange to determine whether the use of fax 
can be removed or significantly reduced in those programs. We 
acknowledge that there are instances where the use of fax may be 
necessary to send data, for example, where rural providers do not have 
sufficient internet access to exchange certain data electronically and 
must rely on fax technology, and also the impact of reduced fax use on 
preparedness and response to disasters. We note section 202(c) of the 
E-Government Act of 2002 (Pub. L. 107-347, December 17, 2002), requires 
CMS to avoid diminished access for those lacking internet access or 
computer access. We seek a balance and want to ensure that elimination 
of fax technology in CMS programs does not eliminate options for those 
without internet access.
    In an effort to reduce burden and increase efficiency, we are 
requesting feedback from the public on how electronic data exchange 
could replace fax technology. Specifically, we are seeking stakeholder 
feedback on the following questions:
    <bullet> What specific programs, processes, workflows, or cases are 
you currently using a fax machine to accomplish? In what ways would 
replacing this with an electronic data exchange, such as via a FHIR-
based API, add value, efficiencies, and/or improve patient care? Are 
there specific processes (such as prior authorization) that you would 
prioritize first to reduce the reliance on fax technology? Has your 
organization implemented an electronic data exchange in an effort to 
reduce the reliance on the fax machine?
    <bullet> What challenges might payers and providers face if use of 
the fax technology for health care data exchange is completely 
eliminated? Are there particular types of providers or health care 
settings that would be more negatively impacted than others? What 
solutions might mitigate these challenges?
    <bullet> What recommendations are there for balancing the goal of 
improving efficiencies in health care data exchange through reducing 
the use of fax while ensuring that health care providers without ready 
access to internet can still share information?
    <bullet> To what extent can electronic and cloud-based fax 
technology bridge the gap between electronic transmission and 
traditional fax technology?
    <bullet> What impact will the reduction of use of fax technology 
have on preparedness and response to disasters? How might organizations 
begin to reduce reliance on this technology, and mitigate these 
impacts?

F. Request for Information: Accelerating the Adoption of Standards 
Related to Social Risk Data

    CMS recognizes that social risk factors (for example, housing 
instability, food insecurity) impact beneficiary health and utilization 
outcomes. Providers in value-based payment arrangements rely on 
comprehensive, high-quality data to identify opportunities to improve 
patient care and drive value. When implemented effectively, value-based 
payment encourages clinicians to care for the whole person and address 
the social risk factors that are critical for beneficiaries' quality of 
life.
    As value-based payment has grown, so has provider interest in data 
on social risk factors. For example, a recent study \72\ found that 24 
percent of hospitals and 16 percent of physician practices were 
screening patients for all five health-related social needs (housing, 
food, transportation, utilities, and safety needs) included in the 
Accountable Health Communities model. Providers use these data to 
inform care and connect patients with the right community resources and 
supports.
---------------------------------------------------------------------------

    \72\ See https://www.ncbi.nlm.nih.gov/pubmed/31532515.
---------------------------------------------------------------------------

    Unfortunately, social risk data are often fragmented and 
duplicative due to a lack of clear standards for recording and 
exchanging these data. For example, multiple providers who cannot 
exchange these data with each other may ask the same beneficiary 
similar

[[Page 82642]]

questions, or hospitals within a single system may all collect varying 
food insecurity data in different formats. Additionally, relevant data 
collected by community-based organizations outside the health sector 
can be difficult to integrate and utilize. Siloed data increase the 
burden on beneficiaries, create inefficiencies in managing referrals 
for social services, create duplicative workflows in an already 
strained system, and impede opportunities to provide higher quality 
care.
    As providers assume greater accountability for costs and outcomes 
through value-based payment, they need tools to successfully identify 
and address social risk factors to improve care and health outcomes. 
Over the last several years, a variety of community led efforts are 
developing industry-wide standards \73\ to collect social risk data, 
electronically represent these data, and enable exchange of person-
centered data between medical providers and community-based 
organizations through health information technology platforms. CMS 
seeks input on barriers the health care industry faces to using 
industry standards and opportunities to accelerate adoption of 
standards related to social risk data. Specifically:
---------------------------------------------------------------------------

    \73\ See https://www.healthit.gov/buzz-blog/interoperability/advancing-interoperable-social-determinants-of-health-data.
---------------------------------------------------------------------------

    <bullet> What are the challenges in representing and exchanging 
social risk and social needs data from different commonly used 
screening tools? How do these challenges vary across screening tools or 
social needs (for example, housing, food)?
    <bullet> What are the barriers to the exchange of social risk and 
social needs data across providers? What are key challenges related to 
exchange of social risk and social needs data between providers and 
community-based organizations?
    <bullet> What mechanisms are currently used to exchange social risk 
and social needs data (EHRs, HIEs, software, cloud-based data 
platforms, etc.)? What challenges, if any, occur in translating social 
risk data collected in these platforms to Z-codes on claims?
    <bullet> How can health care payers promote exchange of social risk 
and social needs data? Are there promising practices used by public or 
private payers that can potentially be further leveraged in other 
settings?

IV. Incorporation by Reference

A. Standards, Implementation Guides, and Specifications

1. National Technology Transfer and Advancement Act
    The National Technology Transfer and Advancement Act (NTTAA) of 
1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget 
(OMB) Circular A-119 \74\ require the use of, wherever practical, 
technical standards that are developed or adopted by voluntary 
consensus standards bodies to carry out policy objectives or 
activities, with certain exceptions. The NTTAA and OMB Circular A-119 
provide exceptions to electing only standards developed or adopted by 
voluntary consensus standards bodies, namely when doing so would be 
inconsistent with applicable law or otherwise impractical. In these 
cases, agencies have the discretion to decline the use of existing 
voluntary consensus standards, and instead can use a government-unique 
standard or other standard. In addition to the consideration of 
voluntary consensus standards, the OMB Circular A-119 recognizes the 
contributions of standardization activities that take place outside of 
the voluntary consensus standards process. Therefore, as stated in OMB 
Circular A-119, in instances where use of voluntary consensus standards 
would be inconsistent with applicable law or otherwise impracticable, 
other standards should be considered that meet the agency's regulatory, 
procurement, or program needs; deliver favorable technical and economic 
outcomes; and, are widely utilized in the marketplace. In this proposed 
rule, we propose use of voluntary consensus standards, including 
implementation guides (IGs) and specifications.
---------------------------------------------------------------------------

    \74\ https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/revised_circular_a-119_as_of_1_22.pdf.
---------------------------------------------------------------------------

2. Compliance With Adopted Standards, Implementation Guides, and 
Specifications
    In accordance with the Office of the Federal Register (OFR) 
regulations related to ``incorporation by reference,'' 1 CFR part 51, 
which we follow when we adopt proposed standards, implementation 
guides, or specifications in any subsequent final rule, the entire 
standard, implementation guide, or specification document is deemed 
published in the Federal Register when incorporated by reference 
therein with the approval of the Director of the Federal Register. Once 
published, compliance with the standard, implementation guide, or 
specification includes the entire document unless specified otherwise 
in regulation. For example, if the Health Level 7[supreg] (HL7) Fast 
Healthcare Interoperability Resources[supreg] (FHIR) Da Vinci--Coverage 
Requirements Discovery (CRD) Implementation Guide: Version STU 1.0.0 
proposed in this rule is adopted (see section II.E. of this proposed 
rule), and API requirements for payers based on this IG are finalized 
(see section II.D. of this proposed rule, payers developing and 
implementing a Documentation Requirements Lookup Service (DRLS) 
application programming interface (API) would need to demonstrate 
compliance with all mandatory elements and requirements of the IG. If 
an element of the IG is optional or permissive in any way, it would 
remain that way for compliance unless we specified otherwise in 
regulation. In such cases, the regulatory text would preempt the 
permissiveness of the implementation guide. This also applies to 
standards and specifications.
3. ``Reasonably Available'' to Interested Parties
    The OFR has established requirements for materials (for example, 
standards, implementation guides, and specifications) that agencies 
propose to incorporate by reference in Federal Regulations (79 FR 
66267; 1 CFR 51.5(a)). To comply with these requirements, in this 
section we provide summaries of, and uniform resource locators (URLs) 
to the standards, implementation guides, and specifications we propose 
to adopt and subsequently incorporate by reference in the Code of 
Federal Regulations (CFR). To note, we also provide relevant 
information about these standards, implementation guides, and 
specifications throughout the relevant sections of the proposed rule.

B. Incorporation by Reference

    OFR has established requirements for materials (for example, 
standards, IGs, or specifications) that agencies propose to incorporate 
by reference in the CFR (79 FR 66267; 1 CFR 51.5(a)). Section 51.5(a) 
requires agencies to discuss, in the preamble of a proposed rule, the 
ways that the materials it proposes to incorporate by reference are 
reasonably available to interested parties or how it worked to make 
those materials reasonably available to interested parties, and 
summarize in the preamble of the proposed rule, the material it 
proposes to incorporate by reference.
    To make the materials we intend to incorporate by reference 
reasonably

[[Page 82643]]

available, we provide a URL for the IGs and specifications. In all 
cases, these IGs and specifications are accessible through the URLs 
provided by selecting the specific version number from the version 
history page the URL directly links to. In all instances, access to the 
IGs or specification can be gained at no-cost (monetary). There is also 
no requirement for participation, subscription, or membership with the 
applicable standards developing organization (SDO) or custodial 
organization to obtain these materials.
    As noted above, the NTTAA and OMB Circular A-119 require the use 
of, wherever practical, technical standards that are developed or 
adopted by voluntary consensus standards bodies to carry out policy 
objectives or activities, with certain exceptions. As discussed, HHS 
has followed the NTTAA and OMB Circular A-119 in proposing standards, 
IGs, and specifications for adoption. HHS has worked with HL7 to make 
the IGs and specifications being proposed for adoption and subsequently 
incorporated by reference in the Federal Register, available to 
interested stakeholders. As discussed in section II.B. of this proposed 
rule, all HL7 FHIR IGs are developed through an industry-led, 
consensus-based public process. HL7 is an American National Standards 
Institute (ANSI) accredited standards development organization. HL7 
FHIR standards are unique in their ability to allow disparate systems 
that otherwise represent data differently to exchange such data in a 
standardized way that all systems can share and consume via standards-
based APIs. HL7 FHIR IGs are also openly accessible, so any interested 
party can go to the HL7 website and access the IG. Once accessed, all 
public comments made during the balloting process as well as the 
version history of the IGs are available for review. In this way all 
stakeholders can fully understand the lifecycle of a given IG. Use of 
such guidance facilitates interoperability in a transparent and cost-
effective way that ensures the IGs are informed by, and approved by, 
industry leaders looking to use technology to improve patient care. As 
such, all of the standards we propose for HHS adoption and subsequent 
incorporation by reference are developed and/or adopted by voluntary 
consensus standards bodies.
    As required by Sec.  51.5(a), we provide summaries of the standards 
we propose to adopt and subsequently incorporate by reference in the 
Code of Federal Regulations. We also provide relevant information about 
these standards, implementation guides, and specifications throughout 
the relevant sections of the proposed rule.
Standards Including Implementation Guides and Specifications for Health 
Care Interoperability--45 CFR Part 170
    <bullet> HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD) 
Implementation Guide: Version STU 1.0.0.
    URL: http://hl7.org/fhir/us/davinci-crd/history.html.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: The purpose of this IG is to define a workflow whereby 
payers can share coverage requirements with clinical systems at the 
time treatment decisions are being made. This ensures that clinicians 
and administrative staff have the capability to make informed decisions 
and can meet the requirements of the patient's insurance coverage. We 
are specifically proposing this IG to support the DRLS API discussed by 
CMS in section II.C. of this proposed rule. The various CMS-regulated 
insurance and coverage products accepted by a given provider may have 
very different requirements for prior authorization documentation. 
Providers who fail to adhere to payer requirements may find that costs 
for a given service are not covered or not completely covered. The 
outcome of this failure to conform to payer requirements can be 
increased out of pocket costs for patients, additional visits and 
changes in the preferred care plan, and increased burden.
    The information that may be shared using this IG includes:

--Updated coverage information.
--Alternative preferred/first-line/lower-cost services/products.
--Documents and rules related to coverage.
--Forms and templates.
--Indications of whether prior authorization is required.

    <bullet> HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR) 
Implementation Guide: Version STU 1.0.0.
    URL: http://hl7.org/fhir/us/davinci-dtr/history.html.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: This IG specifies how payer rules can be executed in a 
provider context to ensure that documentation requirements are met. The 
DTR IG is a companion to the CRD IG, which uses Clinical Decision 
Support (CDS) Hooks \75\ to query payers to determine if there are 
documentation requirements for a proposed medication, procedure, or 
other service. When those requirements exist, CDS Hooks Cards will be 
returned with information about the requirements. This IG leverages the 
ability of CDS Hooks to link to a Substitutable Medical Applications, 
Reusable Technologies (SMART) on FHIR \76\ app to launch and execute 
payer rules. The IG describes the interactions between the SMART on 
FHIR app and the payer's IT system to retrieve the payer's 
documentation requirements, in the form of Clinical Quality Language 
(CQL) \77\ and a FHIR Questionnaire resource, for use by the provider.
---------------------------------------------------------------------------

    \75\ https://cds-hooks.org/.
    \76\ https://docs.smarthealthit.org/.
    \77\ https://cql.hl7.org/.
---------------------------------------------------------------------------

    The goal of DTR is to collect clinical documentation and/or to 
encourage the completion of documentation that demonstrates medical 
necessity for a proposed medication, procedure, or other service. To 
accomplish this, the IG details the use of a payer provided 
Questionnaire resource and results from CQL execution to generate a 
Questionnaire Response resource containing the necessary information. 
Essentially, the provider's EHR communicates to the payer's system, 
which informs the EHR of the documentation that needs to be completed--
this is the Questionnaire resource. To populate the Questionnaire 
response, this IG supports the provider's EHR in populating the 
response form with the relevant patient information from the patient's 
electronic record. As much as can be auto-populated by the system is 
completed. The IG then instructs the system to alert a provider to any 
gaps in information that may need to be manually filled before the 
Questionnaire response resource is sent back to the payer through the 
EHR via the SMART on FHIR app. This IG will also support the DRLS API 
discussed by CMS in section II.C. of this proposed rule.
    <bullet> HL7 FHIR Da Vinci--Prior Authorization Support (PAS) 
Implementation Guide: Version STU 1.0.0.
    URL: http://hl7.org/fhir/us/davinci-pas/history.html.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: The PAS IG uses the FHIR standard as the basis for 
assembling the information necessary to substantiate the need for a 
particular treatment and submitting that information and the

[[Page 82644]]

request for prior authorization to an intermediary end point. That 
endpoint is responsible for ensuring that any HIPAA requirements are 
met. The response from the payer is intended to come back to that 
intermediary endpoint and be available to the provider's EHR solution 
using the FHIR standard. The goal is to provide real time prior 
authorization, where possible, in the provider's clinical workflow.
    This IG, in this way, strives to enable direct submission of prior 
authorization requests initiating from a provider's EHR system or 
practice management system. To meet regulatory requirements, these FHIR 
interfaces will communicate with an intermediary that converts the FHIR 
requests to the corresponding X12 instances prior to passing the 
requests to the payer. Responses are handled by a reverse mechanism 
(payer to intermediary as X12, then converted to FHIR and passed to the 
provider's EHR). Direct submission of prior authorization requests from 
the provider's EHR will reduce costs for both providers and payers and 
result in faster prior authorization decisions resulting in improved 
patient care and experience.
    When combined with the Da Vinci CRD and DTR IGs, direct submission 
of prior authorization requests will further increase efficiency by 
ensuring that authorizations are always sent when (and only when) 
necessary, and that such requests will almost always contain all 
relevant information needed to make the authorization decision on 
initial submission.
    This IG also defines capabilities around the management of prior 
authorization requests, including checking the status of a previously 
submitted request, revising a previously submitted request, and 
cancelling a request. This IG will support the Prior Authorization 
Support API discussed by CMS in section II.C. of this proposed rule.
    <bullet> HL7 FHIR Da Vinci--Payer Coverage Decision Exchange (PCDE) 
Implementation Guide: Version STU 1.0.0.
    URL: http://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: The IG defines standardized mechanisms for a patient or 
payer to enable a transfer of ``current active treatments'' with other 
relevant metadata and coverage-related information from a prior payer 
to a new payer. It also defines a standardized structure for organizing 
and encoding that information to ease its consumption by the new payer 
organization.
    This IG addresses the need for continuity of treatment when 
patients move from one payer's health insurance or benefit plan to 
another. In the current situation, the patient and new payers often do 
not have the information needed to continue treatment in progress or to 
determine that the therapies are necessary or medically appropriate. As 
a result, patients can face a break in continuity of care, challenges 
to share additional information, and increased costs as tests are re-
run or prior therapies need to be re-tested in order to comply with the 
rules of the new payer. By enabling an authorized transfer of 
information from the original payer to the new payer, the new payer can 
have access to information about what therapies are currently in place 
and the rationale for them, as well as what precursor steps have been 
taken to demonstrate the medical necessity and appropriateness of the 
current therapy. By automating this exchange and maximizing the 
computability of the information shared, a process that frequently 
takes weeks or months can be reduced to a few days or even minutes 
reducing costs and improving patient safety, quality, and experience. 
This IG will support the Payer-to-Payer API discussed by CMS in section 
II.D. of this proposed rule.
    <bullet> HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG 
for Blue Button[supreg]) Implementation Guide: Version STU 1.0.0.
    URL: http://hl7.org/fhir/us/carin-bb/history.html.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: This IG describes the CARIN for Blue Button Framework, 
providing a set of resources that payers can exchange with third-
parties to display to consumers via a FHIR-based API. This IG will help 
impacted payers share adjudicated claims and encounter data via the 
Patient Access API discussed by CMS in section II.A. of this proposed 
rule. It includes data elements and coding instructions each impacted 
payer can use to prepare and share the specified data.
    <bullet> HL7 FHIR Da Vinci Payer Data Exchange (PDex) 
Implementation Guide: Version STU 1.0.0.
    URL: http://hl7.org/fhir/us/davinci-pdex/history.html.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: This IG enables payers to create a member's health history 
from clinical Resources based on FHIR Release 4 that can be exchanged 
with other payers, providers, and thirty-party applications. It 
supports patient-authorized exchange to a third-party application, such 
as the patient-requested prior authorization information via the 
Patient Access API as discussed in section II.A. of this proposed rule. 
It will also support exchanging active prior authorization decisions 
between payers and providers via the Provider Access API discussed by 
CMS in section II.B. of this proposed rule.
    <bullet> HL7 FHIR Da Vinci--Payer Data Exchange (PDex) US Drug 
Formulary Implementation Guide: Version STU 1.0.1.
    URL: http://hl7.org/fhir/us/Davinci-drug-formulary/history.html.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: This IG defines a FHIR interface to a health insurer's 
current drug formulary information for patient access. A drug formulary 
is a list of brand-name and generic prescription drugs a payer agrees 
to pay for, at least partially, as part of health insurance or benefit 
coverage. Drug formularies are developed based on the efficacy, safety, 
and cost of drugs. The primary use cases for this FHIR interface is to 
enable patients' ability to understand the costs and alternatives for 
drugs that have been or can be prescribed, and to enable the comparison 
of their drug costs across different insurance plans. This IG would 
support the inclusion of current formulary and preferred drug list 
information via the Patient Access API as discussed by CMS in section 
II.A. of this proposed rule.
    <bullet> HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net 
Implementation Guide: Version STU 1.0.0.
    URL: http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.
    This is a link to the version history. Select the specified version 
from the list on this page to access the IG and all related 
documentation.
    Summary: This IG is modeled off of the Validated Healthcare 
Directory Implementation Guide (VHDir), an international standard 
developed to support a conceptual, centralized, national source of 
health care data that would be accessible to local directories and used 
across multiple use cases. VHDir, as a basis for a centralized health 
care directory, is in development. This PlanNet IG leverages the 
lessons learned

[[Page 82645]]

and input provided throughout the extended VHDir development process, 
which has been informed by a large cross-section of stakeholders, and 
to address a more narrow scope of health care directory needs. This IG 
specifically allows payers to share basic information about their own, 
local networks via a publicly-accessible API. At a minimum, this IG 
will support impacted payers sharing their providers' names, addresses, 
phone numbers, and specialties, which is the information required to be 
shared via the Provider Directory API discussed by CMS in section II.A. 
of this proposed rule. Where the VHDir IG looks to create a central 
resource that a payer, for instance, could use to populate their local 
directory; the PlanNet IG allows the payer to make their local 
directory accessible to the public via an API.

V. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995, we are required to 
provide 30-day notice in the Federal Register and solicit public 
comment before a collection of information requirement is submitted to 
the Office of Management and Budget (OMB) for review and approval. To 
fairly evaluate whether an information collection should be approved by 
OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 
requires that we solicit comment on the following issues:
    <bullet> The need for the information collection and its usefulness 
in carrying out the proper functions of our agency.
    <bullet> The accuracy of our estimate of the information collection 
burden.
    <bullet> The quality, utility, and clarity of the information to be 
collected.
    <bullet> Recommendations to minimize the information collection 
burden on the affected public, including automated collection 
techniques.
    We are soliciting public comment on each of these issues for the 
following sections of this document that contain information collection 
requirements (ICRs):

A. Background

    Payers are in a unique position to offer patients and providers a 
holistic view of a patient's health care data that might otherwise be 
distributed across disparate IT systems. Payers should have the 
capability to exchange data with patients and providers for care and 
payment coordination or transitions, and to facilitate more efficient 
care.
    To advance our commitment to interoperability, we are proposing new 
requirements for various impacted CMS-regulated payers to implement a 
series of standards-based APIs. These standards-based APIs would permit 
patients and providers to have access to a defined set of standardized 
data. We believe that these proposals would help facilitate coordinated 
care by helping to ensure that patients can access their own health 
information, and that providers can access the health care data of 
their patients through the use of common technologies, without special 
effort and in an easily usable digital format.
    We additionally propose to reduce prior authorization burden on 
payers, providers, and patients, especially in terms of delays in 
patient care, through a number of proposals that would require impacted 
payers to implement standards-based APIs for prior authorization 
processes, reduce the amount of time to process prior authorization 
requests, and publicly report certain metrics about prior authorization 
processes for transparency, among other proposals.

B. Wage Estimates

    To derive average costs, we use data from the U.S. Bureau of Labor 
(BLS) Statistics' National Occupational Employment and Wage Estimates 
for Direct Health and Medical Insurance Carriers (NAICS Code 524114) 
(https://www.bls.gov/oes/current/oes_nat.htm). Table 1 presents the 
mean hourly wage, the cost of fringe benefits (calculated at 100 
percent of salary), and the adjusted hourly wage.
[GRAPHIC] [TIFF OMITTED] TP18DE20.000

    As indicated, we are adjusting the employee hourly wage estimates 
by a factor of 100 percent. This is necessarily a rough adjustment, 
both because fringe benefits and overhead costs vary significantly 
across employers, and because methods of estimating these costs vary 
widely across studies. Nonetheless, there is no practical alternative, 
and we believe that doubling the hourly wage to estimate

[[Page 82646]]

total cost is a reasonably accurate estimation method.

C. Information Collection Requirements (ICRs)

    Consistent with our approach in the CMS Interoperability and 
Patient Access final rule (85 FR 25622-25623), we determine ICRs by 
evaluating cost and burden at the parent organization level, as defined 
and discussed in detail in that rule. In that final rule, we provided a 
detailed rationale for how we determined the number of parent 
organizations (85 FR 25622). For this proposed rule, we used a similar 
approach to determine the number of parent organizations. We started by 
reviewing the parent organizations of health plans across Medicaid and 
CHIP managed care and QHP issuers on the FFEs to remove organizations 
that would not be subject to our proposed policies. We then de-
duplicated the list to accurately represent those parent organizations 
that have multiple lines of business across programs only once. 
Ultimately, we determined that there are 209 parent organizations 
across Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers on the FFEs. In addition, we again identified 56 states, 
territories, and U.S. commonwealths which operate FFS programs, as well 
as one state that operates its CHIP and Medicaid FFS programs 
separately, for a total of 266 parent organizations that together 
represent the possible plans, entities, issuers, and state programs 
impacted by these proposals. We are interested to hear from the public 
regarding this methodology and whether parent organizations can 
implement the following information collection requirements across 
their lines of business.
1. ICRs Regarding Patient Access API Proposal (42 CFR 431.60, 438.242, 
457.730, 457.1233, and 45 CFR 156.221)
    To improve patient access to their health information, as discussed 
in section II.A. of this proposed rule, we are proposing to expand the 
Patient Access API finalized in the CMS Interoperability and Patient 
Access final rule (85 FR 25510). Specifically, we are proposing that 
impacted payers implement the API conformant with a specific set of IGs 
at 45 CFR 170.215 to improve interoperability. We are also proposing to 
enhance the API by proposing to require information about pending and 
active prior authorization decisions be made available by all impacted 
payers.
    The cost of upgrading the Patient Access API to be conformant with 
the specified IGs is accounted for in the maintenance costs estimated 
in the CMS Interoperability and Patient Access final rule (85 FR 
25607). We note that those maintenance costs also include costs for MA 
organizations, which are still relevant to the CMS Interoperability and 
Patient Access final rule policies, and would not be directly regulated 
by these proposed policies. As discussed therein, the maintenance we 
estimated accounts for additional capability testing and long-term 
support of the APIs, increased data storage needs, such as additional 
servers, or cloud storage to store any additional patient health 
information, and allocation of resources to maintain the FHIR server. 
In the CMS Interoperability and Patient Access final rule (85 FR 
25510), we provided a link to additional information about the set of 
IGs that we are now proposing to require, and we encouraged, but did 
not require, the use of the these IGs. We understand that most payers 
are currently using these IGs to implement the API. We seek comment on 
our assumptions that use of these IGs is adequately accounted for in 
the maintenance costs of the Patient Access API in the CMS 
Interoperability and Patient Access final rule.
    We are also proposing to require the Privacy Policy Attestation 
provision that we had presented as an option in the CMS 
Interoperability and Patient Access final rule (85 FR 25549 through 
25550). Facilitating this attestation process is part of the regular 
work of keeping the API up to date and functioning.
2. ICRs Regarding Reporting Patient Access API Metrics to CMS Proposal 
(42 CFR 431.60, 438.242, 457.730, 457.1233, and 45 CFR 156.221)
    In order to assess whether our policy requirements concerning the 
Patient Access API finalized in the CMS Interoperability and Patient 
Access final rule (85 FR 25558) are providing patients information in a 
transparent and timely way, we are proposing at 42 CFR 431.60(h), 
438.242(b)(5), 457.730(h), 457.1233(d)(2), and 45 CFR 156.221(i) to 
require impacted payers to report quarterly to CMS certain metrics on 
use of the Patient Access API. We estimate that impacted payers would 
conduct two major work phases: 1) implementation, which includes 
defining requirements and system design (and updates) to generate and 
compile reports; and 2) maintenance, compiling and transmitting 
quarterly reporting to CMS. In the first phase (implementation), we 
believe impacted payers would need to define requirements concerning 
the types and sources of data that would need to be collected on the 
use of the Patient Access API and build the capability for a system to 
generate data that can be sent to CMS. In the second phase 
(maintenance), we believe impacted payers would need to prepare the 
quarterly data to be transmitted to CMS.
    The burden estimate related to the new proposed requirements 
reflects the time and effort needed to collect the information 
described above and to disclose the information. We estimate an initial 
set of one-time costs associated with implementing the reporting 
infrastructure, and an ongoing annual maintenance cost to report after 
the reporting infrastructure is set up.
    Table 2 presents our estimates for first year implementation and 
ongoing maintenance costs. For example, in the second row of Table 2, 
we estimate for first-year implementation that Business Operations 
Specialists would spend 60 hours at a wage of $72.62 an hour for a 
total cost of $4,357.20.
    As captured in the bottom two rows of Table 2:
    <bullet> First-year implementation would require, on average, a 
total of 160 hours per organization at an average cost of $14,645.20 
per organization.
    <bullet> Therefore, the aggregate burden of the first-year 
implementation across 266 parent organizations would be 42,560 hours 
(160 hours * 266 parent organizations) at a cost of $3,895,623 
($14,645.20 * 266 parent organizations).
    <bullet> Similarly, ongoing maintenance after the first year would 
require a total of 40 hours per organization per year at an average 
cost of $2,904.80 per organization.
    <bullet> Therefore, the aggregate burden of ongoing maintenance 
across 266 parent organizations would be 10,640 hours (40 hours * 266 
parent organizations) at a cost of $772,677 ($2,904.80 * 266 parent 
organizations).

[[Page 82647]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.001

    We solicit comment on our assumptions and approach.
3. ICRs Regarding Provider Directory API Proposal (42 CFR 431.70, 
438.242, 457.760, and 457.1233)
    As discussed in section II.A. of this proposed rule, we are 
proposing to require impacted payers implement and maintain the 
Provider Directory API conformant with the HL7 FHIR Da Vinci Payer Data 
Exchange Plan Net IG. The Provider Directory API was finalized in the 
CMS Interoperability and Patient Access final rule (85 FR 25564). We 
note that those maintenance costs also include costs to MA 
organizations, which are still relevant to the CMS Interoperability and 
Patient Access final rule policies, and would not be directly regulated 
by these proposed policies. In the CMS Interoperability and Patient 
Access final rule (85 FR 25562), we encouraged, but did not require the 
use of this IG. We seek comment on this assumption that use of the IG 
is fully accounted for in the maintenance costs from the CMS 
Interoperability and Patient Access final rule.
4. ICRs Regarding Provider Access API Proposal (42 CFR 431.61, 438.242, 
457.731, 457.1233, and 45 CFR 156.222)
    To promote our commitment to interoperability, we propose new 
requirements for APIs at 42 CFR 431.61(a), 438.242(b)(5), 457.731(a), 
457.1233(d)(2), and 45 CFR 156.222(a). This standards-based Provider 
Access API would permit providers to retrieve standardized patient data 
to facilitate coordinated care. To estimate costs to implement the new 
requirements for all new APIs proposed in this rule, we are using the 
same methodology that we used in the CMS Interoperability and Patient 
Access final rule (85 FR 25510).
    In the CMS Interoperability and Patient Access final rule (85 FR 
25510), we estimated that impacted payers would conduct three major 
work phases: Initial design; development and testing; and long-term 
support and maintenance. In this proposed rule, we assume the same 
major phases of work would be required, with a different level of 
effort during each work phase for each of the new proposed APIs. 
Consistent across all new proposed API provisions, we describe below 
the tasks associated with the first two phases. Where we believe 
additional effort associated with these tasks is necessary, we describe 
those as relevant in subsequent ICRs depending on how we believe they 
impact cost estimates. We discuss the costs for the third phase, long-
term support and maintenance, and our methodology for the development 
of those costs in aggregate for all proposed APIs below in this 
section.
    In the initial design phase, we believe tasks would include: 
Determining available resources (personnel, hardware, cloud storage 
space, etc.); assessing whether to use in-house resources to facilitate 
an API connection or contract the work to a third party; convening a 
team to scope, build, test, and maintain the API; performing a data 
availability scan to determine any gaps between internal data models 
and the data required for the necessary FHIR resources; and, mitigating 
any gaps discovered in the available data.
    During the development and testing phase, we believe impacted 
payers would need to conduct the following: Map existing data to the 
HL7 FHIR standards, which would constitute the bulk of the work 
required for implementation; allocate hardware for the necessary 
environments (development, testing, production); build a new FHIR-based 
server or leverage existing FHIR-based servers; determine the frequency 
and method by which internal data is populated on the FHIR-based 
server; build connections between the databases and the FHIR-based 
server; perform capability and security testing; and vet provider 
requests.
    The payers impacted by the proposed Provider Access API provision 
are required by the CMS Interoperability and Patient Access final rule 
by January 1, 2021 (beginning with plan years beginning on or after 
January 1, 2021 for QHP issuers on the FFEs) \78\ (85 FR 25510) to 
implement a FHIR-based Patient Access API using the same baseline 
standards. These include HL7 FHIR Release 4.0.1, and complementary 
security and app registration protocols, specifically the SMART 
Application Launch Implementation Guide (SMART IG) 1.0.0 (including 
mandatory support for the ``SMART on FHIR Core Capabilities''), which 
is a profile of the OAuth 2.0 specification. Therefore, we believe 
payers will be able to gain efficiencies and leverage efforts and 
knowledge of the staff required to build, implement, and maintain the 
Provider Access API (as well as the other APIs in this proposed rule) 
because part of the cost of training and staff necessary is built into 
the development of the APIs required in the CMS Interoperability and 
Patient Access final rule (85 FR 25510).
---------------------------------------------------------------------------

    \78\ In the CMS Interoperability and Patient Access final rule, 
we finalized that these provisions would be applicable to data with 
a date of service on or after January 1, 2016, beginning January 1, 
2021, and enforced beginning July 1, 2021 taking into account the 6 
months of enforcement discretion we are exercising as a result of 
the current public health emergency (PHE).
---------------------------------------------------------------------------

    One additional requirement new for both the Provider Access API and 
the Payer-to-Payer API is conformance with the HL7 FHIR Bulk Data 
Access (Flat FHIR) specification. We believe this is an additional 
package layer on top of the baseline standards that supports the 
exchange of health information for one or more patients at a time in a 
secure manner. We believe this would require additional development. We 
are also proposing that the Provider Access API include active and 
pending prior authorization decisions and related clinical 
documentation and forms, including the date the prior authorization was 
approved, the date the authorization ends, as well as the units and 
services approved and those used to-date. We factor in these proposed 
requirements in the estimated

[[Page 82648]]

costs for the Provider Access API in Table 3. We assume this cost 
accounted for here will absorb costs to include the same data in other 
proposed APIs. As a result, we account for these new costs once 
appreciating the efficiencies of using the same mapped data across more 
than one API. We seek comment on this assumption that the underlying 
content and exchange standards can be shared across the multiple APIs 
discussed in this proposed rule.
    Our estimates as summarized in Table 3 are based on feedback from 
industry experts on the anticipated burden to implement the HL7 FHIR 
Bulk Data Access (Flat FHIR) specification--including input based on 
CMS' experience with the DPC pilot discussed in section II.B. of this 
proposed rule. Therefore, we believe this to be a reasonable estimate 
of the implementation burden.
    The burden estimate related to the new requirements for APIs 
reflects the time and effort needed to collect the information 
described above and to disclose this information. We estimate an 
initial set of one-time costs associated with implementing the proposed 
Provider Access API requirements. Below we describe the burden 
estimates for the development and implementation phases for the 
Provider Access API.
    Table 3 presents the total activities, hours, and dollar burdens 
for the implementation of the Provider Access API (initial design phase 
and the development and testing phase). Based on the same assumptions 
as those included in the CMS Interoperability and Patient Access final 
rule (85 FR 25510), we have selected the medium estimate as the primary 
estimate. As can be seen from the bottom rows of Table 3:
    <bullet> One-time implementation efforts for the first two phases 
would (for the primary estimate) require on average a total of 2,800 
hours per organization at an average cost of $275,743 per organization.
    <bullet> The aggregate burden of the first-year implementation 
across 266 parent organizations would be 744,800 hours (2,800 hours * 
266) at a cost of $73.3 million ($275,743 * 266). This corresponds to 
the primary estimate; the primary and high estimates are obtained by 
multiplying the low estimate by a factor of two and three, 
respectively.
[GRAPHIC] [TIFF OMITTED] TP18DE20.002

    Although this provision would be first applicable January 1, 2023, 
we believe it is reasonable that the APIs will be under development 
prior to this date. Acknowledging that impacted payers will have 
varying technological and staffing capabilities, we estimate that 
development of the APIs will require six to 12 months of work. 
Expecting that this rule will be finalized in early 2021, we have 
distributed the cost estimates over approximately 2 calendar years of 
time to reflect payers being given flexibility regarding when they 
complete the work (see Table 10, summary table).
    We solicit comment on our approach and assumptions for the cost of 
the Provider Access API, including whether our estimates and ranges are 
reasonable or should be modified.

[[Page 82649]]

a. API Maintenance Costs
    We discuss the costs for the third phase, long-term support and 
maintenance, and our methodology for the development of those costs in 
aggregate for all four proposed APIs below.
    As relevant to the APIs discussed in sections V.C.4., 5., 6., and 
10., we estimate ongoing maintenance costs for the Provider Access API, 
DRLS API, PAS API, and Payer-to-Payer API in aggregate. This approach 
aligns with the approach taken in the CMS Interoperability and Patient 
Access final rule (85 FR 25606-25607) whereby the costs of API 
development are split into three phases: Initial design, development 
and testing, and long-term support and maintenance. However, unlike the 
CMS Interoperability and Patient Access final rule, this rule assumes 
that maintenance costs only account for cost associated with the 
technical requirements as outlined in this rule. Any changes to 
requirements would require additional burden which would be discussed 
in future rulemaking. Throughout this Collection of Information 
section, we discuss initial design and development, and testing costs 
per API. We now discuss a total maintenance cost for all four APIs.
    As discussed in the CMS Interoperability and Patient Access final 
rule (85 FR 25606), once the API is established, we believe that there 
would be an annual cost to maintain the FHIR server, which includes the 
cost of maintaining the necessary patient data, supporting the privacy 
policy attestation, and performing capability and security testing. We 
do believe there are efficiencies gained in implementation and 
maintenance due to the fact that these proposed APIs rely on several of 
the same underlying foundational technical and content. For example, 
the same baseline standards including the HL7 FHIR Release 4.0.1, and 
complementary security and app registration protocols--specifically the 
SMART Application Launch Implementation Guide (SMART IG) 1.0.0 
(including mandatory support for the ``SMART on FHIR Core 
Capabilities''), which is a profile of the OAuth 2.0 specification, as 
noted above. However, we do believe that maintenance costs will be 
higher than what we estimated for the CMS Interoperability and Patient 
Access final rule (85 FR 25510) for the new APIs proposed in this rule 
as our estimates also account for new data mapping needs, standards 
upgrades, additional data storage, system testing, initial bug fixes, 
fixed-cost license renewals, contracting costs, and ongoing staff 
education and training.
    In order to account for these maintenance costs, we based our 
estimates on input from industry experience piloting and demoing APIs 
for provider access, prior authorization, and payer-to-payer data 
exchange. We estimate an annual cost averaging approximately 25 percent 
of the primary estimate for one-time API costs, or $575,285 per parent 
organization ($275,743 (Provider Access API) + $984,181 (DRLS API) + 
$936,400 (PAS API) + $104,816 (Payer-to-Payer API) * 25 percent) (see 
V.C.4., 5., 6., and 10. for calculation of these estimates). Therefore, 
the aggregate maintenance burden across 266 parent organizations would 
be approximately $153,025,810 ($575,284 * 266). In Table 10 (summary 
table) we account for this maintenance cost separately for each API (at 
25 percent of the one-time API cost) but, as discussed previously, the 
overlap in IGs across the proposed APIs, for example, is a shared 
efficiency that we believe supports the assumption that maintenance 
should be accounted for in aggregate and is presented in this section 
as such.
    We solicit public comment on our approach and assumptions for the 
aggregate maintenance cost of the APIs, including whether our estimate 
is reasonable or should be modified.
5. ICRs Regarding Documentation Requirement Lookup Service (DRLS) API 
Proposal (42 CFR 431.80, 438.242, 457.732, 457.1233, and 45 CFR 
156.223)
    To promote our commitment to interoperability, we propose 
requirements for DRLS API at 42 CFR 431.80(a)(1), 438.242(b)(5), 
457.732(a)(1), 457.1233(d)(2), and 45 CFR 156.223(a)(1). This DRLS API, 
would permit providers to access data showing whether prior 
authorization is required by the payer for the requested item or 
service, and if so, the documentation requirements for submitting the 
prior authorization request. This API is proposed to be conformant with 
the CRD and DTR IGs, and would begin January 1, 2023 (for Medicaid and 
CHIP managed care plans, by the rating period beginning on or after 
January 1, 2023).
    As discussed above regarding the Provider Access API, to implement 
the new requirements for the DRLS API, we estimate that impacted payers 
would conduct three major work phases: Initial design, development and 
testing, and long-term support and maintenance. Additionally, for this 
proposed API, we believe additional tasks are necessary to accomplish 
the proposed requirements, which we describe below as they impact the 
cost estimates. As discussed previously, the costs for the third phase, 
long-term support and maintenance, and our methodology for the 
development of those costs in aggregate for all proposed APIs is 
presented in section V.C.4. of this proposed rule.
    We base our estimates on feedback from industry experts on the 
anticipated burden to implement the DRLS API, including input from our 
own experience working on the prototype as further discussed in section 
II.C. of this proposed rule. We base our estimates on our own 
experience because we believe many impacted payers will find the 
experience similar to that used to estimate the cost. Additionally, the 
necessary IGs are openly available as HL7 provides access to all IGs as 
open source materials. Thus, HL7 IGs and many reference implementations 
and test scripts are also available free of charge to the health care 
community. These shared resources help support our belief that other 
payers will incur similar costs. Lessons learned from this DRLS 
prototype experience to-date indicate the efforts may require clinical 
expertise and software and web developers. As such, we have accounted 
for the necessary engineers, subject matter experts, and health 
informaticists. These personnel resources would, for example, need to 
convert payer prior authorization documentation rules into computable 
formats, create provider questionnaires regarding whether a patient had 
a medical necessity for a medical item or service, create formats that 
could interface with the provider's EHR or practice management system, 
and integrate the DRLS API with the payer's system.
    Table 4 presents the total activities, hours, and dollar burdens 
for the implementation of the DRLS API (initial design phase and the 
development and testing phase). Based on the same assumptions as those 
included in the CMS Interoperability and Patient Access final rule (85 
FR 25510), we have selected the mid-range estimate as the primary 
estimate. As can be seen from the bottom rows of Table 4:
    <bullet> One-time implementation efforts for the first two phases 
would (for the primary estimate) require on average a total of 9,630 
hours per organization at an average cost of $984,181 per organization.
    <bullet> Aggregate burden of the one-time implementation costs 
across 266 parent organizations would be 2,561,580 hours (9,630 hours * 
266) at a cost of $261.8 million ($984,181 * 266). This

[[Page 82650]]

corresponds to the primary estimate; the primary and high are obtained 
by multiplying the low estimate by a factor of two and three, 
respectively.
[GRAPHIC] [TIFF OMITTED] TP18DE20.003

    As noted previously, although this provision would be first 
applicable January 1, 2023, we believe it is reasonable that the APIs 
will be under development prior to that date. Acknowledging that 
impacted payers will have varying technological and staffing 
capabilities, we estimate that development of the APIs will require six 
to 12 months of work. Expecting that this rule will be finalized in 
early 2021, we have distributed the cost over approximately two 
calendar years of time to give payers the flexibility to complete the 
work necessary (see Table 10, summary table).
    We solicit public comment on our approach and assumptions for the 
cost of the DRLS API, including whether our estimates and ranges are 
reasonable or should be modified.
6. ICRs Regarding Prior Authorization Support (PAS) API Proposal (42 
CFR 431.80, 438.242, 457.732, 457.1233, and 45 CFR 156.223)
    We are also proposing new requirements for a PAS API at 42 CFR 
431.80(a)(2), 438.242(b)(5), 457.732(a)(2), 457.1233(d)(2), and 45 CFR 
156.223(a)(2). Impacted payers would be required to implement the PAS 
API, and, when sending the response, include information regarding 
whether the organization approves (and for how long), denies, or 
requests more information for the prior authorization request. This API 
must be conformant with the HL7 FHIR Da Vinci Prior Authorization 
Support (PAS) IG beginning January 1, 2023 (for Medicaid and CHIP 
managed care plans, by the rating period beginning on or after January 
1, 2023).
    As discussed previously, to implement the new requirements for the 
PAS API, we estimate that impacted payers would conduct three major 
work phases: Initial design, development and testing, and long-term 
support and maintenance. Additionally, for this proposed PAS API, we 
believe additional tasks are necessary to accomplish the proposed 
requirements, which we describe below as they impact the cost 
estimates. As discussed previously, the costs for the third phase, 
long-term support and maintenance, and our methodology for the 
development of those costs in aggregate for all proposed APIs is 
presented in section V.C.4. of this proposed rule.
    Our estimates are based on feedback from industry experts on the 
anticipated burden to implement the PAS API. We believe this to be a 
reasonable estimate of the implementation burden. Payers would need to 
develop APIs that could receive providers' prior authorization 
requests, and associated documentation and send the payer's decision. 
In addition to implementing the PAS API, these payers would also be 
required to send a reason for denial for any prior authorization 
decisions that are denied. We note, as discussed in section II.C. of 
this proposed rule, while the PAS API will leverage the HL7 FHIR 
standard, the prior authorization transactions would remain conformant 
with the X12 278 standard and thus remain HIPAA-compliant. As such, 
given the added complexity of accounting for the HIPAA standards, we 
have accounted for the multiple skill sets required in developing the 
burden estimates.
    Table 5 presents the total activities, hours, and dollar burdens 
for the implementation of the PAS API (initial design phase and the 
development and testing phase). Based on the same assumptions as those 
included in the CMS Interoperability and Patient Access

[[Page 82651]]

final rule (85 FR 25510), we have selected the medium estimate as the 
primary estimate. As can be seen from the bottom rows of Table 5:
    <bullet> One-time implementation efforts for the first two phases 
would (for the primary estimate) require on average a total of 9,200 
hours per organization at an average cost of $936,400 per organization.
    <bullet> The aggregate burden of the one-time implementation costs 
across 266 parent organizations would be 2,447,200 hours (9,200 hours * 
266) at a cost of $249.1 million ($936,400 * 266). This corresponds to 
the primary estimate; the primary and high are obtained by multiplying 
the low estimate by a factor of two and three, respectively.
[GRAPHIC] [TIFF OMITTED] TP18DE20.004

    As noted previously, although compliance with this provision is 
required to begin January 1, 2023, the APIs will be under development 
prior to this date in order to be implemented and operational on 
January 1, 2023 (or the rating period that begins on or after January 
1, 2023 for Medicaid managed care plans and CHIP managed care 
entities). Acknowledging that impacted payers will have varying 
technological and staffing capabilities, we estimate that development 
of the APIs will require six to 12 months of work. Expecting that this 
rule will be finalized in early 2021, we have distributed the cost over 
approximately two calendar years of time to give payers the flexibility 
to complete the work necessary (see Table 10, summary table).
    We solicit public comment on our approach and assumptions for the 
one-time implementation cost of the PAS API, including whether our 
estimates and ranges are reasonable or should be modified. The burden 
of this provision will be included in OMB Control #0938-NEW.
7. ICRs Regarding Requirement To Send Prior Authorization Decisions 
Within Certain Timeframes Proposals (42 CFR 438.210, 440.230, 457.495, 
and 457.1230)
    To increase transparency and reduce burden, we are proposing to 
require that impacted payers, not including QHP issuers on the FFEs, 
send prior authorization decisions within 72 hours for urgent requests 
and 7 calendar days for non-urgent requests at 42 CFR 438.210(d)(1), 
440.230(d)(1), and 457.495(d)(1). We are proposing that the payers 
would have to comply with these provisions beginning January 1, 2023 
(for Medicaid and CHIP managed care plans, by the rating period 
beginning on or after January 1, 2023).
    Since this provision is only applicable to Medicaid and CHIP, only 
235 of the 266 Parent Organizations, those parent organizations that 
offer Medicaid or CHIP plans, would have to implement this provision.
    In order to implement this policy, there would be up-front costs 
for impacted payers to update their policies and procedures, the burden 
for which we now estimate. We anticipate this burden per payer is 8 
hours to update policies and procedures reflecting two half-days of 
work. We estimate a per entity cost of $946.40 (8 hours to develop * 
$118.30/hour, the hourly wage for General and Operations Managers). The 
total burden for all 235 payers is 1,880 hours (8 hours * 235), at an 
aggregate first year cost of $222,404 ($946.40 * 235).
    These calculations are summarized in Table 6.
    [GRAPHIC] [TIFF OMITTED] TP18DE20.005
    

[[Page 82652]]


    We solicit public comments on our assumptions and approach.
8. ICRs Regarding Public Reporting of Prior Authorization Metrics 
Proposal (42 CFR 438.210, 440.230, 457.732, 457.1233, and 45 CFR 
156.223)
    In order to support transparency for patients in choosing health 
coverage, and for providers when selecting payer networks to join, we 
are proposing to require at 42 CFR 438.210(g), 440.230(d)(2), 
457.732(a)(3), 457.1233(d)(2), and 45 CFR 156.223(a)(3) the applicable 
payers to publicly report, annually, certain plan-level prior 
authorization metrics on their websites or via publicly accessible 
hyperlink(s). Impacted payers would be required to report once, 
annually, by the end of the first calendar quarter each year for the 
prior year's data beginning March 31, 2023.
    We estimate that impacted payers would conduct two major work 
phases: (1) Implementation, which includes defining requirements and 
system design (and updates) to generate and compile reports; and (2) 
maintenance, including annual compilation of reports and public 
reporting of metrics on a website or through a publicly accessible 
hyperlink(s). In the first phase, we believe impacted payers would need 
to define requirements concerning the types and sources of data that 
would need to be compiled regarding prior authorization activities, 
build the capability for a system to generate reports, and update or 
create a public web page to post the data. In the second phase, we 
believe impacted payers would need to create the quarterly reports and 
post to a public web page on an annual basis.
    <bullet> First-year implementation would require on average a total 
of 320 hours per organization at an average cost of $28,685.20 per 
organization.
    <bullet> Therefore, the aggregate burden of the first-year 
implementation across 266 parent organizations would be 85,120 hours 
(320 hours * 266) at a cost of $7,630,263 ($28,685.20/organization * 
266).
    <bullet> Similarly, ongoing maintenance after the first year will 
require a total of 120 hours per organization at an average cost of 
$8,714.40 per organization.
    <bullet> Therefore, the aggregate burden of ongoing maintenance 
across 266 parent organizations would be 31,920 hours (120 hours * 266 
parent organizations) at a cost of $2,318,030 ($8,714.40 * 266).
[GRAPHIC] [TIFF OMITTED] TP18DE20.006

    We solicit comment on this approach and our assumptions.
9. ICRs for Implementing Third Party Application Attestation for 
Privacy Provisions (42 CFR 431.60(g), 438.242(b)(5), 457.70(g), 
457.1233(d)(2), and 45 CFR 156.221(h))
    We are proposing at 42 CFR 431.60(g) for state Medicaid FFS 
programs, at 42 CFR 438.242(b)(5) for Medicaid managed care plans, at 
42 CFR 457.730(g) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2) 
for CHIP managed care entities, and at 45 CFR 156.221(h) for QHP 
issuers on the FFEs that beginning January 1, 2023 (for Medicaid 
managed care plans and CHIP managed care entities, by the rating period 
beginning on or after January 1, 2023), that impacted payers must 
establish, implement, and maintain a process for requesting an 
attestation from a third-party app developer requesting to retrieve 
data via the Patient Access API that indicates the app adheres to 
certain privacy provisions.
    Since the two tasks of establishing, implementing, and maintaining 
a process for requesting an attestation from a third-party app 
developer and the task of informing patients of the privacy policy 
evaluation of the third-party app developer are connected, we estimate 
the cost together.
    We estimate the system work required is similar to the system work 
required for the public reporting requirements (Table 7) which involves 
both data lookup and data display. We therefore assume that first year 
development costs would involve 180 hours by a software developer 
working in collaboration with a business operations specialist for 140 
hours to develop these systems. After the first year, the business 
operations specialist would require 120 hours to maintain the system.

[[Page 82653]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.007

    The aggregate first year burden is therefore 85,120 hours (266 
parent organizations *(180 for development plus 140 for input from a 
business operations specialist)) at a cost of $7.6 million (266 
organizations * (180 hr * $102.88/hr for a software and web developer 
plus 140 hr * $72.62/hr for a business operations specialist). Second 
and later year burden would be 31,920 hours (266 parent organizations * 
120 hr) at a cost of $2.3 million (266 parent organizations * 120 hr * 
$72.62/hr).
10. ICRs Regarding Payer-to-Payer API Proposal (42 CFR 431.61, 438.242, 
457.731, 457.1233, and 45 CFR 156.222)
    To reduce payer, and ultimately, provider burden and improve 
patient access to their health information through care coordination 
between payers, as discussed in section II.D. of this proposed rule, we 
are proposing new requirements at 42 CFR 431.61(c), 438.242(b), 
457.731(c), 457.1233(d), and 45 CFR 156.222(b). These proposals would 
improve care coordination between payers by requiring payers to 
exchange, at a minimum, adjudicated claims and encounter data (not 
including remittances and enrollee cost-sharing information), clinical 
information as defined in the USCDI (version 1), and pending and active 
prior authorization decisions, using a FHIR-based Payer-to-Payer API by 
January 1, 2023 (for Medicaid and CHIP managed care plans, by the 
rating period beginning on or after January 1, 2023).
    As discussed for the other APIs being proposed in this rule, we 
estimate that impacted payers would conduct three major work phases: 
Initial design, development and testing, and long-term support and 
maintenance. Additionally, for this proposed API, we believe additional 
tasks are necessary to accomplish the proposed requirements, which we 
describe below as they impact the cost estimates. The costs for the 
third phase, long-term support and maintenance, and our methodology for 
the development of those costs in aggregate for all proposed APIs is 
presented in section V.C.4. of this proposed rule.
    Payers should be able to leverage the API infrastructure already 
accounted for in other requirements, including the Patient Access API 
finalized in the CMS Interoperability and Patient Access final rule (85 
FR 25510) and the Provider Access API proposal in this rule. As 
discussed in the CMS Interoperability and Patient Access final rule (85 
FR 25510) (as well as the companion ONC 21st Century Cures Act final 
rule (85 FR 25642)) and this proposed rule, payers would be using the 
same FHIR standards for content and transport; IGs to support 
interoperability of data sharing; as well as the same underlying 
standards for security, authentication, and authorization. In addition, 
impacted payers would be required to implement the HL7 FHIR Bulk Data 
Access (Flat FHIR) specification for the Provider Access API, the same 
specification proposed for this Payer-to-Payer API, to support the 
exchange of patient health information for one or more patients at a 
time. Taken together, these standards would also support the proposed 
Payer-to-Payer API. Thus, we believe there will be some reduced 
development costs to implement the Payer-to-Payer API because of 
efficiencies gained in implementing many of the same underlying 
standards and IGs for the Patient Access API and the other APIs 
proposed in this rule.
    We do believe there will be some costs for impacted payers to 
implement the proposed Payer-to-Payer API that are unique to this 
proposal. Even though there will be some efficiencies gained in using 
the same standards and IGs as other APIs, we believe based on input 
from industry experience in implementing APIs that there will be costs 
to test and integrate the Payer-to-Payer API with payer systems, albeit 
potentially lower costs than estimated for the Provider Access API. We 
estimate the one-time implementation costs at about one-third the cost 
of a full de novo Provider Access API implementation based on input 
from developers who have implemented and piloted prototype APIs using 
the proposed required standards and IGs. As such, we have accounted for 
the necessary staff required as we also believe there will be unique 
costs for implementing the HL7 FHIR Payer Coverage Decision Exchange IG 
so that payers can exchange active and pending prior authorization 
decisions and related clinical documentation and forms when an enrollee 
or beneficiary enrolls with a new impacted payer.
    Table 9 presents the total activities, hours, and dollar burdens 
for the implementation of the Payer-to-Payer API given our assumptions 
above (initial design phase and the development and testing phase). 
Based on the same assumptions as those published in the CMS 
Interoperability and Patient Access final rule (85 FR 25510), we have 
selected the medium estimate as the primary estimate. As can be seen 
from the bottom rows of Table 9:
    <bullet> One-time implementation efforts for the first two phases 
would (for the primary estimate) require on average a total of 1,012 
hours per organization at an average cost of $104,816 per organization.
    <bullet> Therefore, the aggregate burden of the one-time 
implementation costs across 266 parent organizations would be 269,192 
hours (1,012 hours * 266) at a cost of $27.9 million ($104,816 * 266). 
This corresponds to the primary estimate; the primary and high are 
obtained by multiplying the low estimate by a factor of two and three, 
respectively.

[[Page 82654]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.008

    As noted previously, although this provision would first be 
applicable January 1, 2023, we believe it is reasonable that the APIs 
will be under development prior to that date. Acknowledging that 
impacted payers will have varying technological and staffing 
capabilities, we estimate that development of the APIs will require six 
to twelve months of work. Expecting that this rule will be finalized in 
early 2021, we have distributed the cost estimates over approximately 
two calendar years of time to reflect impacted payers being given 
flexibility regarding when they complete the work (see Table 10).
    We solicit public comments on our approach and assumptions for the 
cost of the Payer-to-Payer API, including whether our estimates and 
ranges are reasonable or should be modified.
c. Summary of Information Collection Burdens
    The previous sections have detailed costs of individual provisions. 
Table 10 summarizes costs for the first, second, and subsequent years 
of these provisions (as described in detail above). Table 10 reflects 
an assumption of an early 2021 publication date for the final rule; the 
API provisions would be effective January 1, 2023. Table 10 reflects 
the primary estimates. Calculations of the high and low estimates for 
the APIs may be found in the tables and narrative of the relevant 
sections for each of the provisions as discussed in this Collection of 
Information section. Labor costs are either BLS wages when a single 
staff member is involved, or a weighted average representing a team 
effort obtained by dividing the aggregate cost (calculated in the 
tables above) by the aggregate hours; for example, in the first row the 
$91.53 equals the aggregate $3.9 million cost divided by the aggregate 
42,560 hours.
BILLING CODE 4120-01-P

[[Page 82655]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.009

BILLING CODE 4120-01-C

D. Conclusion

    The provisions of this proposed rule could greatly improve data 
sharing across stakeholders by facilitating access, receipt, and 
exchange of patient data. This could both increase access to patient 
data and decrease burden associated with gaining access to patient 
data. We are committed to providing patients, providers, and payers 
with timely access to patient health information. We welcome comments 
on our approaches for estimating cost burden and cost savings.
    The requirements of this proposed rule are extensions of the 
requirements of the CMS Interoperability and Patient Access final rule 
(85 FR 25510). Therefore, the information collection requirements will 
be submitted to OMB for review and approval.
    If you would like to provide feedback on these information 
collections, please submit your comments electronically as specified in 
the ADDRESSES section of this proposed rule.
    Comments must be received on/by January 4, 2021.

VI. Response to Comments

    Because of the large number of public comments we normally receive 
on Federal Register documents, we are not able to acknowledge or 
respond to them individually. We will consider all comments we receive 
by the date and time specified in the DATES section of this preamble, 
and, when we proceed with a subsequent document, we will respond to the 
comments in the preamble to that document.

VII. Regulatory Impact Analysis

A. Statement of Need

    As described in prior sections of this proposed rule, the proposed 
changes to 42 CFR parts 431, 435, 438, 440, and 457, and 45 CFR parts 
156 and 170 further support the agency's efforts to reduce burden on 
patients, providers, and payers, and to empower patients and providers 
by increasing electronic access to health care data, while keeping that 
information safe and secure. The proposals in this rule would largely 
build on the foundation we laid in the CMS Interoperability and Patient 
Access final rule (85 FR 25510). This proposed rule continues the 
efforts started with that final rule to move the health care system 
toward greater interoperability and reduce burden by proposing to 
increase the data sharing capabilities of impacted payers, encourage 
health care providers' use of new capabilities, and

[[Page 82656]]

make patient data more easily available to them through standards-based 
technology.
    The provisions in this proposed rule would allow providers and 
payers new means to receive their patient population's data from 
impacted payers through the Provider Access and Payer-to-Payer APIs. 
This would allow providers to improve their ability to deliver quality 
care and improve care coordination by ensuring that providers have 
access to patient data at the point of care. These proposals would also 
assist impacted payers by improving their ability to exchange claims 
and clinical data on enrollees who switch payers or have concurrent 
payers, which would reduce burden and improve continuity of care for 
patients, as well as ensure more efficient payer operations. Further, 
patients would have more timely access to their claims and other health 
care information from impacted payers, empowering them to more directly 
understand and manage their own care through enhancements to the 
Patient Access API.
    Additionally, we believe these proposals would reduce burden on 
patients, providers, and payers, as well as reduce interruptions or 
delays in patient care by improving some aspects of the prior 
authorization process. To accomplish this, we are proposing a number of 
requirements, including proposing to require impacted payers implement 
and maintain a FHIR-based API to support a documentation requirement 
lookup service (DRLS). The DRLS API would be able to integrate with a 
provider's EHR or practice management system to allow providers to 
discover the items and services that require prior authorization, as 
well as the documentation required to submit a prior authorization. 
Impacted payers would also be required to implement and maintain a 
Prior Authorization Support (PAS) API that would have the capability to 
accept and send prior authorization requests and decisions, and could 
be integrated directly in a provider's workflow, while maintaining 
alignment with, and facilitating the use of, the required HIPAA 
transaction standards.
    As noted below, we believe that the policies in this proposed rule, 
if finalized, would result in some financial burdens for impacted 
payers. We have weighed these potential burdens against the potential 
benefits, and believe the potential benefits justify potential costs.

B. Overall Impact

    We have examined the impacts of this proposed rule as required by 
Executive Order 12866 on Regulatory Planning and Review (September 30, 
1993), Executive Order 13563 on Improving Regulation and Regulatory 
Review (January 18, 2011), the Regulatory Flexibility Act (RFA) 
(September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social 
Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 
(March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism 
(August 4, 1999), and Executive Order 13771 on Reducing Regulation and 
Controlling Regulatory Costs (January 30, 2017).
    Executive Orders 12866 and 13563 direct agencies to assess all 
costs and benefits of available regulatory alternatives and, if 
regulation is necessary, to select regulatory approaches that maximize 
net benefits (including potential economic, environmental, public 
health and safety effects, distributive impacts, and equity). Section 
3(f) of Executive Order 12866 defines a ``significant regulatory 
action'' as an action that is likely to result in a rule: (1) Having an 
annual effect on the economy of $100 million or more in any one year, 
or adversely and materially affecting a sector of the economy, 
productivity, competition, jobs, the environment, public health or 
safety, or state, local or tribal governments or communities (also 
referred to as ``economically significant''); (2) creating a serious 
inconsistency or otherwise interfering with an action taken or planned 
by another agency; (3) materially altering the budgetary impacts of 
entitlement grants, user fees, or loan programs or the rights and 
obligations of recipients thereof; or (4) raising novel legal or policy 
issues arising out of legal mandates, the President's priorities, or 
the principles set forth in the Executive Order.
    A Regulatory Impact Analysis must be prepared for major rules with 
economically significant effects ($100 million or more in any one 
year). We estimate that this rulemaking is ``economically significant'' 
as measured by the $100 million threshold, and hence a major rule under 
the Congressional Review Act. Accordingly, we have prepared a 
Regulatory Impact Analysis that, to the best of our ability, presents 
the costs and benefits of this rulemaking.

C. Regulatory Flexibility Act

    Executive Order 13272 requires that HHS thoroughly review rules to 
assess and take appropriate account of their potential impact on small 
business, small governmental jurisdictions, and small organizations (as 
mandated by the Regulatory Flexibility Act (RFA)). If a proposed rule 
may have a significant economic impact on a substantial number of small 
entities, then the proposed rule must discuss steps taken, including 
alternatives considered, to minimize burden on small entities. The RFA 
does not define the terms ``significant economic impact'' or 
``substantial number.'' The Small Business Administration (SBA) advises 
that this absence of statutory specificity allows what is 
``significant'' or ``substantial'' to vary, depending on the problem 
that is to be addressed in rulemaking, the rule's requirements, and the 
preliminary assessment of the rule's impact. Nevertheless, HHS 
typically considers a ``significant'' impact to be three to five 
percent or more of the affected entities' costs or revenues.
    For purposes of the RFA, we estimate that many impacted payers are 
small entities as that term is used in the RFA, either by being 
nonprofit organizations or by meeting the SBA definition of a small 
business. For purposes of the RFA, small entities include small 
businesses, nonprofit organizations, and small governmental 
jurisdictions. The North American Industry Classification System 
(NAICS) is used in the U.S., Canada, and Mexico to classify businesses 
by industry. While there is no distinction between small and large 
businesses among the NAICS categories, the SBA develops size standards 
for each NAICS category.\79\ Note that the most recent update to the 
NAICS went into effect for the 2017 reference year.
---------------------------------------------------------------------------

    \79\ Office of Management and Budget. (2017). North American 
Industry Classification System. Retrieved from: https://www.census.gov/eos/www/naics/2017NAICS/2017_NAICS_Manual.pdf.
---------------------------------------------------------------------------

    We first review the provisions of this rule at a high level, and 
then discuss each of the impacted payer types, and through this 
discussion evaluate the impact on small entities.
1. Overview of Overall Impact
    The annual information collection burden estimates for the proposed 
requirements in this rule are summarized in Table 10 of the Collection 
of Information (section V. of this proposed rule). The specific 
information collection requirement (ICR) proposals, which we have 
calculated burden estimates for, include: (1) Provider Access API 
(Table 3); (2) DRLS API (Table 4); (3) PAS API (Table 5); (4) Proposed 
requirement to send prior authorization decisions within certain 
timeframes (Table 6); (5) Payer-to-Payer API (Table 9); (6) two metrics 
reporting requirements (specifically, Patient Access API and prior 
authorization metrics) (Tables 2

[[Page 82657]]

and 7) and (7) Requirements to comply with privacy policy attestations 
(Table 8).
    Additionally, this Regulatory Impact Analysis section provides an 
analysis about potential savings from voluntary provider compliance 
with the DRLS and PAS API proposed provisions (however, this savings is 
neither included in monetized tables nor in summary tables, as further 
discussed below). We have identified assumptions for these analyses, 
and we solicit public comment.
    In analyzing the impact of this proposed rule, we note that there 
would be a quantifiable impact for the proposed Provider Access, DRLS, 
and PAS APIs. The proposed requirements would apply to 266 parent 
organizations. Throughout this proposed rule we use the term ``parent 
organizations'' to refer to impacted payers. These parent organizations 
include the states that administer state Medicaid and CHIP FFS 
programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers on the FFEs.
    The NAICS category relevant to these proposed provisions is Direct 
Health and Medical Insurance Carriers, NAICS 524114, who have a $41.5 
million threshold for ``small size.'' Seventy-five percent of insurers 
in this category have under 500 employees, thereby meeting the 
definition of small business.
    We are certifying that, for impacted payers, this proposed rule 
does not have a significant economic impact on a substantial number of 
small entities with regard to the provisions noted above.
2. Health Coverage Groups
    If the proposals in this rule are finalized, the 266 parent 
organizations, including state Medicaid and CHIP agencies, would be 
responsible for implementing and maintaining four new APIs, updating 
policies and procedures regarding timeframes for making prior 
authorization decisions, and reporting certain metrics either to CMS or 
the public. Medicaid managed care plans, CHIP managed care entities, 
and QHP issuers on the FFEs are classified as NAICS code 524, direct 
health insurance carriers. We are assuming that a significant number of 
these entities are not small. And, we note that none of the state 
Medicaid and CHIP agencies are considered small.
    At a high level, state Medicaid managed care plans and CHIP managed 
care entities have many of their costs covered through capitation 
payments from the federal government or through state payments. 
Therefore, there is no significant burden, as detailed below. If 
finalized as proposed, QHP issuers on the FFEs and certain states 
operating Medicaid and CHIP FFS programs would be able to apply for an 
extension, exception or exemption under which they would not be 
required to meet the new API provisions of the proposed rule on the 
proposed compliance dates, provided certain conditions are met as 
discussed in sections II.B., II.C., and II.D. of this proposed rule. We 
therefore believe there is no significant burden to a significant 
number of entities from this proposed rule for these provisions as 
discussed.
a. Medicaid and CHIP
    Title XIX of the Act established the Medicaid program as a federal-
state partnership for the purpose of providing and financing medical 
assistance to specified groups of eligible individuals. States claim 
federal matching funds on a quarterly basis based on their program 
expenditures. Since states are not small entities under the Small 
Business Act we need not further discuss in this section the burden 
imposed on them by this rule.
    With regard to Medicaid managed care plans and CHIP managed care 
entities, since managed care plans receive 100 percent capitation 
payments from the state, we generally expect that the costs associated 
with the provisions of this proposed rule would be included in their 
capitation rates and may be reasonable, appropriate, and attainable 
costs whether they are a small business or not. Consequently, we can 
assert that there is no significant impact on a significant number of 
entities.
    As discussed in sections II.B., II.C., and II.D. for the new 
proposed API provisions, states operating Medicaid FFS and CHIP FFS 
programs could submit an application for an extension of up to one year 
to comply with the requirements of this rule. Additionally, we propose 
that states operating Medicaid and CHIP FFS programs with very low 
enrollment and high managed care penetration rates (at least 90 
percent), can apply for an exemption under which they would not be 
required to meet certain proposed requirements, provided certain 
conditions are met.
b. QHP Issuers on the FFEs
    Few, if any, QHP issuers on the FFEs are small enough to fall below 
the size thresholds for a small business established by the SBA. 
Consistent with previous CMS analyses, we estimate that any issuers 
that would be considered a small business are likely to be subsidiaries 
of larger issuers that are not small businesses (78 FR 33238) and thus 
do not share the same burdens as an independent small business. 
Therefore, even though QHP issuers do not receive federal reimbursement 
for the costs of providing care, we do not conclude that there would be 
a significant small entity burden for these issuers. In addition, we 
propose an exception process for QHP issuers on the FFEs from certain 
proposed requirements, which further helps to address burden that could 
otherwise prohibit a QHP issuer from participating in an FFE.
    Based on the above, we conclude that the requirements of the RFA 
have been met by this proposed rule.

D. UMRA and E.O. 13132 Requirements

    Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) 
requires that agencies assess anticipated costs and benefits before 
issuing any rule whose mandates require spending in any one year of 
$100 million in 1995 dollars, updated annually for inflation. In 2020, 
that threshold is approximately $156 million. This proposed rule would 
not impose an unfunded mandate that would result in the expenditure by 
state, local, and tribal governments, in the aggregate, or by the 
private sector, of more than $156 million in any one year.
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct requirement costs on state 
and local governments, preempts state law, or otherwise has federalism 
implications. As previously outlined, while the API provisions would be 
a requirement for state Medicaid and CHIP agencies under these 
proposals, the cost per enrollee for implementation is expected to be 
negligible when compared with the overall cost per enrollee. This 
analysis does not take into account federal matching funds provided to 
state Medicaid and CHIP agencies, but the conclusion is the same: There 
is not expected to be a significant cost impact on state entities.
    For Medicaid and CHIP, we do not believe that the proposals in this 
rule would conflict with state law, and therefore, do not anticipate 
any preemption of state law. However, we invite states to submit 
comments on this proposed rule if they believe any proposal in this 
rule would conflict with state law, so that we can fully evaluate any 
potential conflicts.
    If regulations impose administrative costs on private entities, 
such as the time needed to read and interpret this proposed or final 
rule, we should estimate the cost associated with

[[Page 82658]]

regulatory review. We model our estimates of review burden based on 
similar estimates presented in the CMS Interoperability and Patient 
Access final rule (85 FR 25510).
    The particular staff involved in such a review would vary from one 
parent organization to another. We believe that a good approximation 
for a range of staff would be a person such as a medical and health 
service manager or a lawyer. Using the wage information from the BLS 
for medical and health services managers (Code 11-9111) and lawyers 
(Code 23-1011) we estimate that the cost of reviewing this proposed 
rule is $125.23 per hour, including overhead and fringe.\80\ This 
number was obtained by taking the average wage of a medical manager and 
lawyer.
---------------------------------------------------------------------------

    \80\ U.S. Bureau of Labor Statistics. (2019, April 02). May 2018 
National Occupational Employment and Wage Estimates. Retrieved from 
https://www.bls.gov/oes/current/oes_nat.htm.
---------------------------------------------------------------------------

    In the CMS Interoperability and Patient Access final rule (85 FR 
25510), we estimated six hours of reading time. Therefore, we believe 
10 hours would be enough time for each parent organization to review 
relevant portions of this proposed rule.
    We believe the review would be done by parent organizations that 
would be required to implement the proposed provisions. There are 266 
parent organizations accounted for in our estimates. Thus, we estimate 
a one-time aggregated total review cost of $333,112 million ($125.23 * 
10 hours * 266 entities). We solicit comments on our estimate.

E. Impact of Individual Proposals

    The proposed provisions of this rule would have information 
collection-related burden. Consequently, the impact analysis may be 
found in Table 10 of the Collection of Information in section V. of 
this proposed rule. To facilitate review of the provisions and 
estimates made in the Collection of Information, we include Table 11, 
which provides the related ICRs in section V. of this proposed rule, 
the tables in section V. where impact is presented, as well as a title 
used for cross-reference in the remainder of this Regulatory Impact 
Analysis section.
    Table 19 of this section, using Table 10 as a basis, provides a 10-
year impact estimate. Table 19 includes impact by year, by type (parent 
organizations, including Medicaid and CHIP state agencies), as well as 
the cost burden to the federal government, allocations of cost by 
program, and payments by the federal government to Medicaid and CHIP, 
as well as the premium tax credits (PTC) paid to certain enrollees in 
the individual market.
[GRAPHIC] [TIFF OMITTED] TP18DE20.010

F. Alternatives Considered

    In this proposed rule, we continue to build on the efforts 
initiated with the CMS Interoperability and Patient Access final rule 
(85 FR 25510) and the work we have done to reduce burden in the health 
care system, to advance interoperability, improve care coordination, 
reduce burden, and empower patients with access to their health care 
data. This proposed rule covers a range of policies aimed at achieving 
these goals. We carefully considered alternatives to the policies we 
are proposing in this rule. We concluded that none of the alternatives 
would adequately or immediately begin to address the critical issues 
related to patient access and interoperability or help to address the 
processes that contribute to payer, provider, and patient burden.
    We now discuss the alternatives we considered to our proposed 
provisions and the reasons why we did not select them as proposed 
policies.
1. Alternatives Considered for the Proposed Patient Access API 
Enhancements
    We are proposing to require that payers make enhancements to the 
Patient Access API finalized in the CMS Interoperability and Patient 
Access final rule (85 FR 25510) including requiring the Patient Access 
API be conformant with the IGs specified in section II.A.2. of this 
proposed rule, proposing additional information be made available to 
patients through the Patient Access API, proposing a privacy 
attestation policy, and proposing certain metrics about patient use of 
the Patient Access API be reported directly to CMS quarterly. Before 
proposing to require these provisions, we considered several policy 
alternatives.
    As we discussed in the CMS Interoperability and Patient Access 
final rule (85 FR 25627), one alternative to the proposed updates to 
the Patient Access API we considered is allowing payers and providers 
to upload patient

[[Page 82659]]

data directly to a patient portal, operated by a provider. However, 
despite the availability of patient portals, ONC reported in 2017 that 
only 52 percent of individuals have been offered online access to their 
medical records by a health provider or payer. And of the 52 percent 
that were offered access, only half of those viewed their record.\81\ 
Therefore, we do not believe that patient portals are meeting patients' 
needs and would not be a suitable policy option to propose. We also 
believe that there would be additional burden associated with using 
portals, because providers and patients would need to utilize multiple 
portals and websites, requiring various log-ins, to access all of a 
patient's relevant data--one for each provider a patient is associated 
with--instead of a single app. Portals would require developers to link 
systems or ensure system-level compatibility to enable patients to see 
a more comprehensive picture of their care. Alternatively, FHIR-based 
APIs have the ability to make data available without the need to link 
multiple systems or portals and would provide a patient a single point 
of access to their data. APIs that make data available to third-party 
apps permit the patient to choose how they want to access their data 
and promote innovation in industry to find solutions to best help 
patients interact with their data in a way that is most meaningful and 
valuable to them. The nature of portals does not lend as well to such 
interoperability or innovation. Because business models and processes 
pertaining to patient portals are varied across the industry, and any 
one patient could be associated with a number of different portals, we 
believe it would be very difficult to evaluate the cost impacts of 
requiring individual portals versus the estimates for enhancing the 
Patient Access API.
---------------------------------------------------------------------------

    \81\ Patel, V. & Johnson, C. (2018, April). Individuals' Use of 
Online Medical Records and Technology for Health Needs (ONC Data 
Brief N. 40). Retrieved from https://www.healthit.gov/sites/default/files/page/2018-03/HINTS-2017-Consumer-Data-Brief-3.21.18.pdf.
---------------------------------------------------------------------------

    As explained in the CMS Interoperability and Patient Access final 
rule (85 FR 25627), another alternative considered was to allow Health 
Information Exchanges (HIEs) and Health Information Networks (HINs) to 
serve as a central source for patients to obtain aggregated data from 
across their providers and payers in a single location. HIEs and HINs 
could provide patients with information via an HIE portal that is 
managed by the patient. However, as described above, there are various 
reasons why patient portal access does not lend itself to 
interoperability or innovation, and not all patients might have access 
to an HIE or HIN. For these reasons, we ultimately decided to proceed 
with our proposed requirements versus this alternative.
    We had also considered alternative compliance dates for the 
proposed policies. For instance, we considered January 1, 2022, as a 
possible compliance date for the Patient Access API enhancements. 
However, due to the current public health emergency and the enforcement 
discretion we are exercising for the API policies finalized in the CMS 
Interoperability and Patient Access final rule, we believe it is more 
appropriate, and less burdensome to impacted payers to propose 
compliance dates for these policies beginning January 1, 2023 (for 
Medicaid managed care plans and CHIP managed care entities, by the 
rating period beginning on or after January 1, 2023).
2. Alternatives Considered for the Proposed Provider Access API
    In this proposed rule, to better facilitate the coordination of 
care across the care continuum, we are proposing to require impacted 
payers to implement and maintain a Provider Access API conformant with 
the specified HL7 FHIR IGs, as well as the HL7 FHIR Bulk Data Access 
(Flat FHIR) specification to support exchanging data for one or more 
patients at a time. This proposed API would require payers to make 
available to providers the same types of data they would make available 
to patients via the enhanced Patient Access API.
    Alternatively, we considered other data types that could be 
exchanged via the Provider Access API. We considered only requiring the 
exchange of clinical data, as defined in the USCDI. While this would be 
less data to exchange and, thus, potentially less burdensome for payers 
to implement, we believe that claims and encounter information can 
complement the USCDI data and offer a broader and more holistic 
understanding of a patient's interactions with the health care system. 
Furthermore, the data that we propose to be available through the 
proposed Provider Access API aligns with the data that we propose be 
available to individual patients through the Patient Access API. 
Therefore, we do not believe there is significant additional burden to 
include these data as once the data are mapped and prepared to share 
via one FHIR-based API, these data are available for all payer APIs to 
use.
    We did also consider only having payer claims and encounter data 
available to providers, understanding that providers are generally the 
source of clinical data. Again, this could potentially reduce burden on 
payers by potentially requiring less data to be made available. 
However, even if a provider is the source for the clinical data 
relevant to their patients' care, a provider may not have access to 
clinical data from other providers a patient is seeing. As a result, 
and understanding payers were already preparing these data for use in 
other APIs, we decided a more comprehensive approach would be most 
beneficial to both providers and patients and thus aligned the proposed 
Provider Access API data requirements with those proposed for the 
Patient Access API.
    We also considered including additional data elements in this 
proposal. We considered requiring the patient's complete medical 
record. However, we believe this would require additional resources and 
be overly burdensome for impacted payers at this time. The USCDI is a 
standardized set of health data classes and constituent data elements 
for nationwide, interoperable health information exchange.\82\ Because 
this limited set of data has been standardized, and corresponding HL7 
FHIR IGs have been developed, payers can map these data and make them 
more easily available via an API. Industry has not yet fully developed 
the needed IGs to facilitate sharing a patient's full medical record. 
Before this alternative would be feasible, more FHIR development work 
needs to be done, and important questions about data segmentation, and 
a patient's role in potentially specifying what parts of their medical 
record could or should be available to which providers, need to be 
considered.
---------------------------------------------------------------------------

    \82\ Interoperability Standards Advisory. (n.d.). U.S. Core Data 
for Interoperability. Retrieved from https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.
---------------------------------------------------------------------------

3. Alternatives Considered for the Proposed DRLS API and PAS API and 
Other Prior Authorization Proposals
    In this rule, we are also proposing several policies that would 
reduce burden associated with the prior authorization process. First, 
we are proposing to require all impacted payers implement and maintain 
a DRLS API conformant with the HL7 FHIR CRD and DTR IGs. We believe 
this would reduce burden for payers, providers, and patients by 
streamlining access to information about which items and services 
require a prior authorization and the associated documentation 
requirements, potentially reducing the number of incomplete and denied 
prior authorization requests. This would add efficiencies for both 
payers and

[[Page 82660]]

providers, and it would improve patient care by avoiding gaps and 
delays in care.
    As proposed, by January 1, 2023, (for Medicaid managed care plans 
and CHIP managed care entities, by the rating period beginning on or 
after January 1, 2023), impacted payers would be required to implement 
the DRLS API, populate the API with their list of items and services 
for which prior authorization is required, populate the API with their 
associated documentation rules, and ensure the DRLS API is functional. 
Alternatively, we considered proposing a phased approach to the DRLS 
API where payers would first upload a specified subset of documentation 
to the DRLS API, as opposed to all of the documentation for all 
applicable items and services at one time. For instance, we considered 
requiring that payers only prepare the DRLS for a specific set of 
services most commonly requiring prior authorization across payers. 
However, we believe this would be more burdensome in some ways. It 
would require payers to use different systems to find requirements for 
different services for a single payer, for instance. If the 
requirements for different services were in different places--such as 
some information in payer portals and some through the DRLS API--
providers would have to spend additional time searching for the 
information in multiple locations for one payer. Therefore, we believe 
it is ultimately less burdensome overall to require impacted payers to 
populate the prior authorization and documentation requirements for all 
items and services at the same time.
    We also considered whether we should propose to require that payers 
post, on a public-facing website, their list of items and services for 
which prior authorization is required, populate the website with their 
associated documentation rules as in interim step while they implement 
the DRLS. However, we are aware that payers already have this 
information publicly available, and determined that this would not 
provide any reduced burden on payers or providers at this time. We seek 
comment on whether a payer website to provide additional transparency 
to prior authorization requirements and documentation would be 
beneficial in reducing overall burden in this process.
    We are also proposing to require impacted payers implement and 
maintain a FHIR-based PAS API conformant with the HL7 FHIR Da Vinci PAS 
IG that would have the capability to accept and send prior 
authorization requests and decisions. This API would be accessible to 
providers to integrate directly into their workflow, while maintaining 
alignment with, and facilitating the use of, the required HIPAA 
transaction standards. This requirement is proposed to be effective at 
the same time as the DRLS API, January 1, 2023 (for Medicaid managed 
care plans and CHIP managed care entities, by the rating period 
beginning on or after January 1, 2023). We considered a phased timeline 
approach to implement both of these APIs. For instance, we considered 
first requiring implementation of the DRLS API in 2022 and then a year 
later requiring implementation of the PAS API. However, given the 
current situation with the public health emergency, and taking into 
account the enforcement discretion we are exercising as a result for 
the APIs finalized in the CMS Interoperability and Patient Access final 
rule (85 FR 25510), we believe it is more appropriate, and less 
burdensome to impacted payers, to propose compliance dates for both of 
these policies in 2023, providing payers with more time to potentially 
implement both policies. We further determined that because the DRLS 
API and the PAS API are steps in the same prior authorization workflow, 
the full benefits of both APIs are best realized when used 
concurrently.
    We are proposing other provisions to reduce prior authorization 
burden including requiring payers to ensure that prior authorization 
decisions are made within 72 hours of receiving an expedited request 
and no later than 7 days after receiving a standard requests, and 
proposing to require impacted payers to publicly report prior 
authorization metrics on their websites or via publicly accessible 
hyperlink(s) annually.
    We considered several alternative policies before deciding to 
propose these policies. We considered alternative timeframes such as 
whether payers could provide a decision in less than 72 hours (for 
expedited decisions) and 7 days (for standard decisions). For example, 
we considered requiring payers to provide a decision in 48 hours for 
expedited requests and 3 days for standard requests. Despite the 
importance of having providers and patients get decisions as quickly as 
possible, we believe that the timeframes we propose in this rule would 
help increase reliability in the prior authorization process and 
establish clear expectations without being overly burdensome for 
payers. These timeframes would allow payers to process the prior 
authorization decisions in a timely fashion and give providers and 
patients an expectation for when they can anticipate a decision, while 
at the same time encouraging a timelier decision-making process. We 
also considered whether more than 7 days would be necessary for complex 
cases. We did not propose this alternative, however, because we believe 
it is important for patients and providers to be able to receive a 
decision in a shorter timeframe. We believe 7 days is sufficient time 
for a payer to process prior authorization decisions.
    Regarding publicly reporting prior authorization metrics, we 
considered requiring impacted payers to publicly report these metrics 
more frequently than annually. For instance, we considered a quarterly 
requirement. While we considered this alternative, we believe that our 
proposal is sufficient to accomplish our goals without creating 
additional burden. Because patients typically shop for health coverage 
on an annual basis, we believe updating this information annually would 
be sufficient for supplying patients and providers with transparent and 
valuable information. We also considered reporting these metrics at the 
parent organization versus at the plan or issuer level for all impacted 
payers. After further consideration, we decided this may not be truly 
operational and may be too aggregated a level of reporting for some 
payer types to provide true transparency or useful information for 
patients and providers. As a result, we are proposing reporting at the 
state-level for Medicaid and CHIP FFS, plan-level for Medicaid and CHIP 
managed care, and at the issuer-level for QHP issuers on the FFEs.
4. Alternatives Considered for the Proposed Payer-to-Payer API
    We are proposing to require impacted payers to implement and 
maintain a Payer-to-Payer API that makes the same data available to 
other payers via a FHIR-based API as we propose payers make available 
to patients and providers, conformant with the same IGs as proposed for 
the Patient Access API discussed in section II.A. and the Provider 
Access API discussed in section II.B. of this proposed rule. Before 
proposing these policies, we considered several policy alternatives.
    We considered proposing to enhance the Payer-to-Payer Data Exchange 
finalized in the CMS Interoperability and Patient Access final rule 
without naming a specific standard. We considered maintaining a payer's 
ability to share data with another payer without requiring the use of 
an API, and instead only requiring the additional

[[Page 82661]]

types of data be made available to share. But, ultimately, there are 
numerous benefits to requiring the FHIR-based API conformant with the 
specified IGs for this data sharing. We have heard from several 
stakeholders that sharing these data in a standardized way is the only 
way to introduce valuable efficiencies and achieve true 
interoperability. Furthermore, for the Payer-to-Payer API, once an 
organization implements the other proposed APIs, there would be less 
additional investment necessary to implement the Payer-to-Payer API as 
payers would be able to leverage the infrastructure already established 
for the Patient Access API and Provider Access API. Given this 
available infrastructure, and the efficiencies of sharing standardized 
data via the API, we determined it was most advantageous for payers to 
again leverage an API for this enhanced data exchange.
    We also considered which data elements would be the most 
appropriate. Similar to the Provider Access API alternatives, we 
considered only requiring the exchange of clinical data as defined in 
the USCDI via an API. As we described above, we believe that claims and 
encounter information can complement the USCDI data and potentially 
allow for better care coordination, as well as more efficient payer 
operations. And, we do not believe there would be significant 
additional burden once the data are mapped to FHIR for the other 
proposed APIs.
    We also considered requiring payers to exchange all prior 
authorization decisions, including expired decisions, via the Payer-to-
Payer API. However, we recognize that much of this information may be 
outdated and may not have an effect on the new payer's prior 
authorization process. Therefore, in an effort to reduce the volume of 
outdated or irrelevant information shared among payers, we have decided 
to limit the proposal to only active and pending prior authorization 
decisions.

G. Analysis of Potential Impact for Savings by Voluntary Participation 
of Individual Providers in the Proposed Prior Authorization Provisions

    To support our commitment to promoting interoperability and 
reducing burden on payers, providers, and patients, as discussed in 
section II.C. of this proposed rule, we are proposing new requirements 
related to prior authorization for states operating Medicaid FFS 
programs at 42 CFR 431.80 and 440.230; states operating CHIP FFS 
programs at 42 CFR 457.495 and 457.732; Medicaid managed care plans at 
42 CFR 438.210 and 438.242; CHIP managed care entities at 42 CFR 
457.495, 457.1230, and 457.1233; and QHP issuers on the FFEs at 45 CFR 
156.223. While we discussed the ICRs regarding cost estimates of those 
proposals with anticipated impact in sections V.C.5. through V.C.8., 
here, we discuss the anticipated cost savings of these proposals to the 
health care industry.
    We have detailed in this section the cost impact of creating the 
proposal discussed in section II.C. of this rule, including the DRLS 
and PAS APIs, as well as a number of other policies focused on reducing 
burden associated with the prior authorization process. Potentially 
offsetting some of these costs are the savings that would result from 
reduced administrative work associated with existing prior 
authorization protocols.
    These savings would be true savings, not transfers, since they 
reflect savings in reducing the administrative costs required to 
process prior authorizations. However, these savings would be an 
indirect consequence of the proposed rule, not direct savings. To be 
clear, this proposed rule does not reduce the current paperwork 
required for prior authorization. Rather, a consequence of the 
efficiencies resulting from the prior authorization proposals would be 
significantly reduced time spent on the paperwork. In general, it is 
only appropriate to claim that a regulatory provision's benefits are in 
excess of its costs after a substantive, and preferably quantitative, 
assessment of the pre-existing market failure and the provision's 
suitability for addressing it. As a result of data limitations and 
other analytic challenges preventing such an assessment in this, the 
case illustrative savings estimates are neither included in the 
monetized table, nor the summary table of the Regulatory Impact 
Analysis in section VII. of this proposed rule, nor in the 2016-dollar 
calculation. Nevertheless, the savings could be significant and we 
believe should be a factor in the evaluation of this proposed rule.
    In calculating these potential savings, uncertainties arise in five 
areas, described below. The result of this illustrative analysis is 
that we find a potential savings impact of a billion dollars over 10 
years. In this section, we carefully explain each uncertainty, indicate 
how we approached estimation, and solicit public comment.
    The five areas of uncertainty we had to take into account include:
    (1) Assumptions on the number of providers voluntarily engaging 
with the provisions of this proposed rule: A major obstacle in 
estimating impact is the fact that these provisions, if finalized, 
would be mandatory for impacted payers but engagement by providers is 
voluntary. Before proposing this rule, we conducted conversations with 
stakeholders who indicated that more efficient prior authorization 
processes would ultimately reduce burden for all affected parties and 
would therefore likely be utilized by providers.
    To address the voluntary nature of provider utilization of the 
electronic prior authorization tools, we assume no provider 
participation in the first year, gradually increasing to 25 percent 
participation in 10 years. We believe this is a usefully illustrative 
assumption.\83\ We also believe that it is reasonable to assume that 
additional providers would participate as prior authorization 
capabilities become more widely available in EHRs, which are not 
regulated by this rule, and the benefits of having more efficient prior 
authorization processes become clear through burden reduction and 
improved patient care.
---------------------------------------------------------------------------

    \83\ This assumption may be supported by some states already 
adopting legislation around electronic prior authorization, and 
federal legislation such as provision 6062 in the SUPPORT Act (H.R. 
6) where electronic prior authorization is stipulated for drugs 
covered under Medicare Part D by January 1, 2021. However, reasons 
for electronic prior authorization tools to be used are not 
necessarily reasons why their use is attributable to this proposed 
rule; they might instead be reasons why use would occur even in the 
rule's absence. We request comment that would help with identifying 
impacts attributable to this proposal.
---------------------------------------------------------------------------

    In going from no providers leveraging the technology in the first 
year of implementation to 25 percent of providers using the technology 
in 10 years, we did not believe it appropriate to use a strict linear 
approach of a 2.5 percent increase of providers per year. We are aware 
that many providers do not yet have the necessary technical 
capabilities to facilitate interoperable exchange of data for prior 
authorization. Specifically, their EHR systems are not yet prepared to 
leverage the DRLS or PAS APIs. Absent that technology in the EHR, the 
DRLS and PAS APIs would provide minimal benefit to providers. We assume 
that providers in hospitals and providers in large health systems who 
already have such software would use it as soon as technologically 
feasible. Therefore, we modeled the growth of providers participating 
with a gradually increasing exponential model, since the exponential 
model is typically used to indicate slow growth in the beginning but 
faster growth later on. Our numerical assumptions of the percent of 
providers using DRLS and PAS APIs are presented in Table 12.

[[Page 82662]]

(Note, exponential models cannot start at 0; therefore, we started at 
0.01 percent.)
    We solicit public comments on all assumptions: The assumption of no 
providers in the first year; the assumption of 25 percent participation 
in the tenth year; and the use of an exponential model.
[GRAPHIC] [TIFF OMITTED] TP18DE20.011

    (2) Assumptions on the current workload hours for prior 
authorization: To estimate the savings impact, we first require 
estimates of the current amount of paperwork involved in prior 
authorization, the type and number of staff involved, the type of 
physician offices involved, and hours per week spent engaged in prior 
authorization processes. Our assumptions are based on a well-conducted 
survey presented in Casalino et al. (2009) \84\, which gives a detailed 
analysis based on a validated survey instrument employed in 2006.
---------------------------------------------------------------------------

    \84\ Casalino, L.P., Nicholson, S., Gans, D., Hammons, T., 
Morra, D., Karrison, T., & Levinson, W. (May 2009). What Does It 
Cost Physician Practices To Interact With Health Insurance Plans? 
Health Affairs, 28(4): w533-w543. doi: 10.1377/hlthaff.28.4.w533.
---------------------------------------------------------------------------

    This survey excluded certain physician practices, including health 
maintenance organizations (HMOs), but analyzed workload by staff type 
(doctor, nurse, clerical, administrator, lawyer, and accountant), 
office type (solo, three to 10 physicians, 10 or more physicians), and 
type of medical work involved (prior authorization, formulary, claims 
billing, quality, etc.). Consistent with our approach, we restricted 
ourselves to prior authorization activities, though formulary work 
could possibly add to burden related to prior authorization activities.
    Using the methods and data from Casalino et al. (2009), Table 13 
presents an estimate of the current average annual paperwork burden per 
physician office for prior authorization activities. Table 13 estimates 
an annual burden per physician office of 1,060.8 hours at a cost of 
$73,750.
[GRAPHIC] [TIFF OMITTED] TP18DE20.012

    Table 13 estimates are based on Casalino et al. (2009). Several 
other examples in the literature were reviewed 
<SUP>85 86 87 88 89</SUP> which, although reflecting more recent 
research, either did not show the basis for their calculations, showed 
a basis based on a very small number of people, or used a non-validated 
survey. For this reason, we used the Casalino et al. (2009) article for 
our calculations.
---------------------------------------------------------------------------

    \85\ Morley, C.P., Badolato, D.J., Hickner, J., Epling, J.W. 
(2013, January). The Impact of Prior Authorization Requirements on 
Primary Care Physicians' Offices: Report of Two Parallel Network 
Studies. The Journal of the American Board of Family Medicine, 
26(1), 93-95. doi: 10.3122/jabfm.2013.01.120062.
    \86\ Ward, V. (2018, April). The Shocking Truth About Prior 
Authorization in Healthcare. Retrieved from https://getreferralmd.com/2018/04/prior-authorization-problems-healthcare/.
    \87\ Center for Health Innovation & Implementation Science. 
(2018, July 26) The Prior Authorization Burden in Healthcare. 
Retrieved from http://www.hii.iu.edu/the-prior-authorization-burden-in-healthcare/.
    \88\ Robeznieks, A. (2018, November 16). Inside Cleveland 
Clinic's $10 million prior authorization price tag. Retrieved from 
https://www.ama-assn.org/practice-management/sustainability/inside-cleveland-clinic-s-10-million-prior-authorization-price.
    \89\ American Medical Association. (2019, June). Prior 
Authorization and Utilization Management Reform Principles. 
Retrieved from https://www.ama-assn.org/system/files/2019-06/principles-with-signatory-page-for-slsc.pdf.
---------------------------------------------------------------------------

    The wages in Table 13 have been updated from those used in the 
Casalino et al. (2009) work to the latest BLS wages. The hours should 
also be adjusted for 2021, to account for increased prior authorization 
requirements. However, we do not have a more recent reliable survey on 
which to base this. Table 16 in this section presents an alternate 
estimate assuming a 4 percent growth rate in hours per week spent on 
prior authorization, the 4 percent coming from the articles cited 
above. We solicit public comment on these assumptions on the hours per 
week spent on prior authorization paperwork.
    (3) Assumptions on the total number of physician practices: Table 
13 presents current hour and dollar burden per physician office. To 
obtain aggregate annual burden of prior authorization over all 
physician practices including those exclusively furnishing services to 
Fee For Service (FFS) enrollees, Casalino et al. (2009) multiplies the 
Table 13 burdens for physician office by the total number of physician 
practices. Thus, we need an estimate of total number of physician 
practices. Additionally, in this section, we need to

[[Page 82663]]

modify the total number of physician practices by a factor accounting 
for the fact that only a percentage of physician practices accept 
enrollees in the Medicaid, CHIP, and QHP programs.
    We first discuss the total number of physician practices. Casalino 
et al. (2009) cited that the AMA listed a figure of 560,000 physician 
offices in 2006. Casalino et al. (2009) criticized this 560,000 
(rounded from 560,118 physician offices exactly) based on available 
sources in 2006 and reduced it to 450,000 physician offices (rounded 
from 453,696 physician offices exactly). The sources cited in the 
article have not been updated. Furthermore, the CY 2012 PFS final rule 
redefined physician group practice to require at least 25 physicians. 
As of 2016, there are 230,187 physician practices (76 FR 73026). We 
note that this number is lower than the value used in the 2016 survey, 
which makes sense given the high rates of consolidation in the medical 
field. In Table 16 later in this section, we present an alternative 
analysis of savings with 450,000 practices. We solicit public comment 
on our assumptions of the number of physician offices.
    (4) Percent of providers accepting Medicaid, CHIP, or QHP: The 
230,187 physician practices just mentioned include providers who 
exclusively service Fee For Service enrollees. We must therefore adjust 
this number by the percent of providers furnishing services to 
Medicaid, CHIP, and QHP enrollees. According to the Medicaid and CHIP 
Payment and Access Commission (MACPAC),\90\ 71 percent of providers 
accept Medicaid, but only 36 percent of psychiatrists accept new 
Medicaid patients, and 62 percent accept private insurance. Therefore 
we estimate that 50 percent of provider groups treat patients in the 
Medicaid and QHP. Although we don't account for it, we note that these 
provisions, which reduce the amount of paperwork, might encourage a 
greater participation in the coming years of providers accepting 
Medicaid, CHIP, and QHPs in the FFEs.
---------------------------------------------------------------------------

    \90\ Kayla Holgash and Martha Heberlin, ``Physician Acceptance 
of New Medicaid Patients,'' January 24, 2019 https://www.macpac.gov/wp-content/uploads/2019/01/Physician-Acceptance-of-New-Medicaid-Patients.pdf
---------------------------------------------------------------------------

    (5) Assumptions on the reduction in hours spent on prior 
authorization as a result of the provisions of this proposed rule: 
Table 13 provides current hours spent on prior authorization; to 
calculate potential savings we must make an assumption on how much 
these hours are being reduced as a result of the provisions of this 
rule. Therefore, we review the specific provisions of this proposed 
rule.
    We believe two provisions in this proposed rule would reduce prior 
authorization burden:
    <bullet> Section II.C. of this proposed rule would require payers 
to implement a DRLS API. This service, if voluntarily used by 
providers, would allow them, at the point of care, to discover whether 
a requested item or service requires prior authorization and, if so, 
the relevant documentation requirements. All provider office staff 
types, including doctors, nurses, and clerical staff, would experience 
reductions in the time needed to locate prior authorization rules and 
documentation requirements, which are currently either not readily 
accessible or available in many different payer-specific locations and 
formats. We believe that our proposal would make it possible for 
provider staff to use one system (such as their EHR or practice 
management system) or software application to find the prior 
authorization rules and documentation requirements for all impacted 
payers. With these rules and requirements more consistently and easily 
accessible, we anticipate a reduction in the need for providers to make 
multiple attempts at submitting the full set of information necessary 
for the payer to approve or deny a prior authorization. As a 
consequence, a DRLS API could also reduce appeals and improper 
payments,\91\ but we are not addressing such savings here, as we have 
no real-world basis on which to make an estimate. (We also note that 
reduction in improper payments, though experienced as savings by 
certain entities, would be categorized as transfers from a society-wide 
perspective.)
---------------------------------------------------------------------------

    \91\ Centers for Medicare and Medicaid Services. (2019, November 
15). Simplifying Documentation Requirements. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/SimplifyingRequirements.html.
---------------------------------------------------------------------------

    Overall, once the APIs are in place and providers integrate with 
them, we assume providers and nurses could experience a 25 percent 
reduction in hours spent working to identify prior authorization rules 
and requirements. (Again, we are uncertain when providers may connect 
to the APIs.) The level annual 25 percent reduction reflects the belief 
that these provisions would accomplish savings through reduced 
administrative burden and therefore in the absence of additional data, 
the 25 percent reflects a midpoint between 0 percent and 50 percent 
indicating some savings (more than 0 percent but not more than 50 
percent). We solicit public comment on the estimated reduction in hours 
spent determining prior authorization rules and requirements due to the 
DRLS API proposal in this proposed rule. We are interested in 
understanding if there is burden reduction prior to the development of 
an EHR integration with the API. We also note that Table 16 in this 
section provides an alternative analysis using a 75 percent reduction 
for doctors and nurses. The intent in Table 16 is to provide a broad 
range inclusive of many possibilities (hence 25 percent to 75 percent 
for providers and nurses).
    <bullet> Section II.C. of this proposed rule would require that 
payers implement and maintain a PAS API that would, if voluntarily used 
by providers, allow them, through an existing EHR or practice 
management system that is capable of connecting to the API, to submit 
prior authorization requests along with any associated documentation 
needed, and receive an approval or denial decision from the payer, 
including any ongoing communications regarding additional information 
needed or other status updates. Currently, most prior authorization 
requests and decisions are conducted through one of several burdensome 
channels, including telephone, fax, or payer-specific web portals--each 
of which require taking actions and monitoring status across multiple 
and varying communication channels. Since submission support is 
predominantly done by clerical staff, not by doctors or nurses, we 
would estimate no savings to doctors and nurses, but a 50 percent 
reduction in hours spent by clerical staff. The 50 percent reduction 
represents a reasonable estimate of time spent in the absence of any 
experience or data. We solicit comments on this estimated 50 percent 
reduction in hours spent by clerical staff and whether our assumptions 
of the affected staff type are accurate.
    Having presented our assumptions on the number of providers 
voluntarily using the DRLS and PAS APIs for electronic prior 
authorization, the current hour and dollar burden per week spent on 
prior authorization, the number of physician practices, and the 
reduction in hours arising from the proposed provisions of this rule, 
Tables 14 and 15 present total hours and dollars saved. Table 14 
presents the savings per physician practice. Table 15 multiplies these 
per physician practice savings by 50 percent of the 230,187 provider 
practices to obtain aggregate savings The following illustrative 
calculations help explain the entries in Table 14 and 15:

[[Page 82664]]

    <bullet> In Table 14, the row on nurses cites Table 13, which shows 
that currently, annually, per physician practice, nurses spend 681.2 
hours per year on prior authorization. Multiplying this number of hours 
by our assumed savings for nurses of 25 percent, we obtain 170.3 hours 
per year saved. Multiplying these reduced hours by the hourly wage for 
nurses of $74.48, we obtain a savings of $12,684 per physician practice 
for nurses. This calculation is repeated for all staff and then summed 
to obtain the total hours and dollars saved per physician practice. We 
save 347.1 hours per physician practice per year and $21,648 per 
physician practice per year.
    <bullet> Table 15 now multiplies the 347.1 hours and $21,648 saved 
per physician practice by 50 percent (percent of providers furnishing 
enrollees in Medicaid, CHIP, and QHP), times 230,187 (total number of 
physician practices) times the percent of providers using these 
technologies by year as outlined in Table 12. For example, for the 1st 
year, 2023, we multiply, $21,648 * 50 percent * 230,187 * 0.01% to 
obtain a reduced dollar spending of $0.2 million. The other rows in 
Table 15 are similarly calculated. As can be seen, the total savings 
over 10 years is 17.2 million hours and $1.1 billion.
    The savings for the first three years, obtained by summing the 
first three rows, is 36,254 hours and $2.26 million. The method of 
calculating the hours and dollars in these rows was just illustrated. 
Because we assume a 10-year gradual increase in voluntary provider 
participation, we present a 10-year horizon in Table 15 in this 
section.
[GRAPHIC] [TIFF OMITTED] TP18DE20.013

[GRAPHIC] [TIFF OMITTED] TP18DE20.014

    The analysis in Table 15 represents our illustrative analysis for 
this proposed rule, which we put forward for stakeholder review and 
comment. In Table 16, we present some alternative analysis of the 
savings. Despite the wide range of alternatives, the resulting range of 
savings is estimated at about $1.1 billion to about $5.2 billion. As 
indicated earlier, we solicit comments from stakeholders on our 
assumptions and methodology. We provide four

[[Page 82665]]

alternative assumptions as follows to the assumptions made in Tables 12 
through 15:
    <bullet> We assumed in this section that the number of hours per 
week that providers spend on prior authorization has not changed since 
2006. In Table 16, we allow for an alternative with 4 percent annual 
growth. This number came from several papers cited in section V. of 
this proposed rule.
    <bullet> We assumed in this section that the reduction of hours per 
week that provider teams spend on prior authorization is a result of a 
25 percent reduction for doctors and nurses and a 50 percent reduction 
for clerical staff. In the Table 16, we provide an alternative analysis 
assuming a 75 percent reduction for doctors and nurses and a 50 percent 
reduction for clerical staff. These alternative numbers are not based 
on published articles or experience but rather meant to span a range of 
alternatives.
    <bullet> In this section, we assumed 230,187 physician practices. 
In Table 16, we also use an alternate assumption of 450,000 physician 
practices, also discussed in this section.. We modified these numbers 
by a factor of 50 percent to account for the fact that only half of 
provider groups accept Medicaid, CHIP, and QHP.
    <bullet> For purposes of comparison we present the 10-year savings 
assuming all providers participate as well as the 10-year savings from 
reduced paperwork assuming a gradual increase in participation from 0 
percent in the base year to 25 percent in the tenth year.
    In making these assumptions, the goal was to obtain a range of 
possible alternatives. We have no experience basis to justify any 
particular assumption and data vary widely in the literature. As can be 
seen from Table 16, the potential savings range from about $1 billion 
to about $5 billion. We believe the magnitude of such a number is 
important for stakeholders when evaluating and commenting on the 
provisions of this rule. We solicit public comment on the four 
assumptions and their impact in estimating these savings.
BILLING CODE 4120-01-P

[[Page 82666]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.015

BILLING CODE 4120-01-P

H. Summary of Costs

    In this section, we present a 10-year summary table of costs, an 
analysis for federal impacts, and the monetized table.
    To analyze the cost of this rule to the federal government, we 
utilize a method of allocating costs by program (Medicaid, CHIP, and 
QHP issuers on the FFEs). As the cost is shared by the 266 parent 
organizations, including Medicaid and CHIP state agencies, there is no 
readily available way to allocate costs per parent organization across 
programs since the percentage of each parent organization's 
expenditures on the different programs is not publicly available.
    To address this, we utilize the same method that was used in the 
CMS Interoperability and Patient Access final rule (85 FR 25612). In 
that final rule, we used the public CMS Medical Loss Ratio (MLR) files, 
which break out total premiums across the various programs. The 
advantages and disadvantages of such an approach are fully discussed in 
that rule, to which we refer readers. At the time this proposed rule is 
being written, 2019 is the latest available year with published data. 
Table 17 presents the 2019 MLR data of premiums by program and the 
resulting percentages by program. We use these percentages to allocate 
costs by programs. This allocation of cost by program forms a basis to 
calculate the federal government's cost for the proposed provisions of 
this rule.

[[Page 82667]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.016

    We can calculate the federal Medicaid payments using the 
percentages in Table 18.
[GRAPHIC] [TIFF OMITTED] TP18DE20.017

    In Table 18, the first row shows that 52 percent of federal 
government payments go to the states for expenditures related to their 
FFS programs and 48 percent go to states for their Medicaid managed 
care programs. For state expenditures on Medicaid mechanized claims 
processing and information retrieval systems, the federal government 
pays states 90 percent of their expenditures on the design, 
development, installation, or enhancement of such systems, and 75 
percent of their expenditures on the ongoing operation of such systems. 
States receive an average of 58.44 percent (FMAP) for their managed 
care program costs. Therefore, the percent of costs paid in the first 
year by the federal government is 74.85 percent (90 percent * 52 
percent + 58.44 percent * 48 percent). The percent of costs paid in 
later years is 67.05 percent (75 percent * 52 percent + 58.44 percent * 
48 percent). By applying these percentages to the total Medicaid costs, 
we obtain federal costs for the program. These percentages are used to 
calculate the total dollars going from the federal government to 
states.
    We can now calculate all impacts of this proposed rule by program, 
government, and QHP issuers. The numerical impacts are presented in 
Table 19.

[[Page 82668]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.018

    For Table 19:
    <bullet> Cost of Proposed Rule by Year column: The total cost for 
years 2021 to 2023 matches the costs in the Collection of Information 
(section V.) summary table (Table 10).
    The total 10-year cost (including payers but excluding PTC payments 
and savings from prior authorization) is, as shown in Table 19, $1.9 
billion. This number uses the primary estimates for the API provisions. 
The low and high 10-year total costs are $1.0 billion and $2.8 billion, 
respectively.
    <bullet> Cost of Proposed Rule to Payers by Program columns: We 
apply the percentages from Table 17 to obtain the cost of the rule to 
Payers by program (Medicaid, CHIP, and QHP issuers on the FFEs).
    <bullet> Cost of Proposed Rule to Government by Program columns: We 
apply the percentages of payment by the federal government discussed in 
Table 18 to obtain the cost by program.
    <bullet> PTC Payments: The government does not reimburse QHPs, 
neither partially nor totally, neither prospectively nor retroactively, 
for their expenses in furnishing benefits. However, the government does 
offer eligible QHP enrollees PTCs to help cover the cost of the plan. 
QHP issuers on selling on the Exchanges have the option to deal with 
increased costs of complying with the requirements as proposed in this 
rule by either temporarily absorbing them (for purposes of market 
competitiveness), increasing premiums to enrollees, or reducing non-
essential health benefits. To the extent that issuers increase premiums 
for individual market plans on the FFEs, there would be federal PTC 
impacts. The purpose of the PTC is to assist enrollees in paying 
premiums. Since PTCs are only available if an individual purchases an 
individual market plan on an Exchange and the individual has an income 
between 100 and 400 percent of the Federal Poverty Level, the PTC 
estimates apply only to Exchange plans. In the PTC estimate, we have 
accounted for the fact that some issuers have both Exchange and non-
Exchange plans, and some issuers have only non-Exchange plans. We 
reflected these assumptions with global adjustments, so we believe the 
estimates are reasonable in aggregate.
    The methodology to estimate the PTC impact of the of the projected 
expense burdens is consistent with the method used to estimate the PTC 
impact in the CMS Interoperability and Patient Access final rule (85 FR 
25612). Within the FFE states, the estimated expense burden would 
impact premium rates in the individual market and is spread across both 
Exchange and non-Exchange plans. PTCs are only paid in the Exchanges 
and are calculated as a function of the second lowest cost silver plan 
and the eligible individuals' income. The estimate of these impacts 
uses the assumption that the industry would increase the second lowest 
cost silver plan premium rate in the same amount as the overall premium 
rate increase as a result of the expense estimate. This assumption 
allows application of the overall rate increase to the projected PTC 
payments in the FFE states to estimate the impact to PTC payments.
    There are no increases in PTC payments included for 2021 since by 
the time this proposed rule is projected to be published these rates 
will already have been determined. The total cost to the government is 
the sum of payments related to each program. This payment is a transfer 
from the government to payers for Medicaid, CHIP, and to QHP enrollees.
    <bullet> Remaining Cost to Payers columns: For Medicaid and CHIP, 
the remaining costs are the difference between total cost to payers and 
what the federal government pays. For the individual markets, the 
remaining costs to payers would be the total cost absorbed by the 
payers and not passed on through premium increases. Since the PTC is 
paid on behalf of individuals and not the payers, it therefore does not 
reduce expenses of the payers.
    <bullet> Note: The $1.1 billion savings from reduced paperwork 
burden for use of

[[Page 82669]]

electronic prior authorization (Table 16) is not included in Table 19.
    We next explain how the various plans (and states) would bear the 
costs remaining after federal payments. We follow the same methodology 
and discussion presented in the CMS Interoperability and Patient Access 
final rule (85 FR 25612).
[GRAPHIC] [TIFF OMITTED] TP18DE20.019

    In Table 20, we explain possible ways payers may manage these extra 
costs. We emphasize that Table 20 lists possibilities. Payers will 
ultimately make decisions about how to defray these remaining costs 
based on market dynamics and internal business decisions, and we have 
no uniform way of predicting what these actual behaviors and responses 
will be.
    Individual Market Plans: Individual market plans have the option of 
absorbing costs or passing costs to enrollees either in the form of 
higher premiums or reduced benefits that are not essential health 
benefits (EHBs). The experience of the Office of the Actuary is that 
frequently, plans, for reasons of market competitiveness, will absorb 
costs rather than increase premiums or reduce benefits.
    Medicaid and CHIP: Assuming roughly 75 million enrollees 
nationally, including Medicaid and CHIP FFS programs, Medicaid managed 
care plans and CHIP managed care entities are adding a cost of under a 
dollar per beneficiary per year; this contrasts with a total cost per 
beneficiary per year for the Medicaid and CHIP programs of several 
thousand dollars.

I. Accounting Statement and Table

    As required by OMB Circular A-4 (available at https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A4/a-4.pdf), we have prepared an accounting statement in Table 21 showing 
the classification of annualized costs associated with the provisions 
of this proposed rule for the 10-year period 2021 through 2030. This 
accounting table is based on Table 19. It includes costs of this 
proposed rule to providers, Medicaid and CHIP state entities, and 
issuers offering QHPs on the FFEs. It does not include the potential 
savings (Tables 14 and 15) of at least $1.1 billion arising from 
reduced burden due to providers voluntarily complying with electronic 
prior authorization as discussed in the illustrative earlier in this 
section.

[[Page 82670]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.020

J. Regulatory Reform Analysis Under E.O. 13771

    Executive Order 13771, titled Reducing Regulation and Controlling 
Regulatory Costs, was issued on January 30, 2017 and requires that the 
costs associated with significant new regulations ``shall, to the 
extent permitted by law, be offset by the elimination of existing costs 
associated with at least two prior regulations.'' This proposed rule, 
if finalized, is considered an E.O. 13771 regulatory action. We 
estimate that the medium (primary) estimates of this proposed rule 
would generate annual costs of $136.3 million in 2016 dollars when 
calculated at a 7 percent discount over a perpetual time horizon. (The 
low estimates would generate $70.6 million in annualized costs, while 
the high estimates would generate $202.1 million in annualized costs, 
discounted at 7 percent relative to 2016, over a perpetual time 
horizon.) Details on the estimated costs of this proposed rule can be 
found in the preceding analyses.
    In accordance with the provisions of Executive Order 12866, this 
regulation was reviewed by the Office of Management and Budget (OMB).

List of Subjects

42 CFR Part 431

    Grant programs-health, Health facilities, Medicaid, Privacy, 
Reporting and recordkeeping requirements, State fair hearings.

42 CFR Part 435

    Aid to Families with Dependent Children, Grant programs-health, 
Medicaid, Notices, Reporting and recordkeeping requirements, 
Supplemental Security Income (SSI), Wages.

42 CFR Part 438

    Grant programs-health, Medicaid, Reporting and recordkeeping 
requirements.

42 CFR Part 440

    Grant programs-health, Medicaid.

42 CFR Part 457

    Administrative practice and procedure, Grant programs-health, 
Health insurance, Reporting and recordkeeping requirements.

45 CFR Part 156

    Administrative practice and procedure, Advertising, Brokers, 
Conflict of interests, Consumer protection, Grant programs-health, 
Grants administration, Health care, Health insurance, Health 
maintenance organizations (HMO), Health records, Hospitals, Indians, 
Individuals with disabilities, Intergovernmental relations, Loan 
programs-health, Medicaid, Organization and functions (Government 
agencies), Prescription drugs, Public assistance programs, Reporting 
and recordkeeping requirements, Technical assistance, Women, Youth.

45 CFR Part 170

    Computer technology, Health, Health care, Health insurance, Health 
records, Hospitals, Indians, Incorporation by reference, Laboratories, 
Medicaid, Medicare, Privacy, Public health, Reporting and recordkeeping 
requirements, Security measures.

    For the reasons set forth in the preamble, the Centers for Medicare 
& Medicaid Services (CMS) proposes to amend 42 CFR chapter IV as set 
forth below:

PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION

0
1. The authority citation for part 431 continues to read as follows:

    Authority: 42 U.S.C. 1302.

0
2. Section 431.60 is amended by--
0
a. Revising paragraph (b)(3);
0
b. Adding paragraph (b)(5);
0
c. Revising paragraph (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and 
(e)(2);
0
f. Redesignating paragraph (g) as paragraph (i); and
0
g. Adding new paragraphs (g) and (h).

[[Page 82671]]

    The revisions and addition read as follows:


Sec.  431.60  Beneficiary access to and exchange of data

* * * * *
    (b) * * *
    (3) Clinical data, as defined in the USCDI version 1, if the State 
maintains any such data, no later than 1 business day after the data 
are received by the State;
* * * * *
    (5) Beginning January 1, 2023, pending and active prior 
authorization decisions and related clinical documentation and forms 
for items and services, not including covered outpatient drugs, 
including the date the prior authorization was approved, the date the 
authorization ends, as well as the units and services approved and 
those used to date, no later than 1 business day after a provider 
initiates a prior authorization request for the beneficiary or there is 
a change of status for the prior authorization.
    (c) * * *
    (3) Must comply with the content and vocabulary standards 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable to the data type or data element, unless alternate standards 
are required by other applicable law, and be conformant with the 
requirements in paragraph (c)(3)(iii) of this section:
* * * * *
    (iii) Beginning January 1, 2023, be conformant with the 
implementation specifications at 45 CFR 170.215(c)(5) for data 
specified in paragraphs (b)(1) and (2), 45 CFR 170.215(a)(2) or 45 CFR 
170.215(c)(6) for data specified in paragraph (b)(3) of this section, 
45 CFR 170.215(c)(7) for data specified in paragraph (b)(4) of this 
section, and 45 CFR 170.215(c)(6) for data specified in paragraph 
(b)(5) of this section.
    (4) May use an updated version of any standard or all standards and 
any or all implementation guides or specifications required under 
paragraphs (b) or (c) of this section, and Sec. Sec.  431.61, 431.70, 
431.80, where:
* * * * *
    (ii) * * *
    (C) Use of the updated version of the standard, implementation 
guide, or specification does not disrupt an end user's ability to 
access the data described in paragraph (b) of this section or the data 
described in Sec. Sec.  431.61, 431.70, and 431.80 through the required 
API.
* * * * *
    (e) * * *
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which parties seek to access electronic health 
information, as defined at 45 CFR 171.102, including but not limited to 
criteria that may rely on automated monitoring and risk mitigation 
tools.
* * * * *
    (g) Privacy policy attestation. (1) Beginning January 1, 2023, the 
State must establish, implement, and maintain a process for requesting 
an attestation from a third-party app developer requesting to retrieve 
data via the Patient Access API that indicates the app adheres to 
certain privacy provisions. The State must:
    (i) Independently, or through the support of a third party, request 
a third-party app developer to attest whether:
    (A) The app has a privacy policy that is publicly available and 
accessible at all times, including updated versions, and that is 
written in plain language, and that the third-party app has 
affirmatively shared with the beneficiary prior to the beneficiary 
authorizing the app to access their health information. To 
``affirmatively share'' means that the beneficiary had to take an 
action to indicate they saw the privacy policy, such as click or check 
a box or boxes.
    (B) The app's privacy policy includes, at a minimum:
    (1) How a beneficiary's health information may be accessed, 
exchanged, or used by any person or other entity, including whether the 
beneficiary's health information may be shared or sold at any time 
(including in the future);
    (2) A requirement for express consent from a beneficiary before the 
beneficiary's health information is accessed, exchanged, or used, 
including receiving express consent before a beneficiary's health 
information is shared or sold (other than disclosures required by law 
or disclosures necessary in connection with the sale of the application 
or a similar transaction);
    (3) If an app will access any other information from a 
beneficiary's device; and
    (4) How a beneficiary can discontinue app access to their data and 
what the app's policy and process is for disposing of a beneficiary's 
data once the beneficiary has withdrawn consent.
    (ii) Include information in the beneficiary resources required in 
paragraph (f) of this section about the specific content of the State's 
privacy policy attestation required under this paragraph, and, at a 
minimum, the timeline for the attestation process, the method for 
informing the beneficiary about the app developer's response or non-
response to the State's request, and the beneficiary's role and rights 
in this process; and
    (iii) Request the attestation at the time the third-party app 
engages the API and notify the beneficiary as follows:
    (A) The State must inform the beneficiary within 24 hours of 
requesting the attestation from the third-party app developer regarding 
the status of the attestation--positive, negative, or no response, with 
a clear explanation of what each means;
    (B) If a beneficiary does not respond within 24 hours of when the 
State sends notice of the attestation status to the beneficiary, the 
State must proceed with making the beneficiary's data available to the 
third-party app consistent with the beneficiary's original request.
    (2) The State must not discriminate when implementing this 
requirement, including for the purposes of competitive advantage; the 
method employed to meet this requirement must be applied equitably 
across all apps requesting access the Patient Access API.
    (h) Reporting on the use of the Patient Access API. (1) Beginning 
March 31, 2023, a State must report to CMS, at the State agency level, 
by the end of each calendar quarter, based on the previous quarter's 
data as follows:
    (i) The total number of unique beneficiaries whose data are 
transferred via the Patient Access API to a beneficiary-designated 
third-party application; and
    (ii) The number of unique beneficiaries whose data are transferred 
via the Patient Access API to a beneficiary designated third-party 
application more than once.
    (2) [Reserved].
* * * * *
0
3. Section 431.61 is added to read as follows:


Sec.  431.61  Access to and exchange of health data to providers and 
payers.

    (a) Application Programming Interface to support data transfer from 
payers to providers--Provider Access API.--(1) Accessible content and 
API requirements. Beginning January 1, 2023, a state must implement and 
maintain a standards-based Application Programming Interface (API) 
compliant with Sec.  431.60(c), (d), and (e):
    (i) Individual beneficiary data. The Provider Access API must make 
available to providers, if requested by the provider, as permitted by 
the beneficiary per paragraph (a)(3) of this section, and as permitted 
by applicable law, at a minimum, data maintained by the State with a 
date of service on or

[[Page 82672]]

after January 1, 2016, within one (1) business day of receipt, 
conformant with the implementation specifications at 45 CFR 
170.215(c)(5) for data specified at Sec.  431.60(b)(1) and (2) not 
including remittances and enrollee cost sharing information, 45 CFR 
170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified at Sec.  
431.60(b)(3), 45 CFR 170.215(c)(7) for data specified at Sec.  
431.60(b)(4), and 45 CFR 170.215(c)(6) for data specified at Sec.  
431.60(b)(5); and
    (ii) Bulk data access. The Provider Access API must be able to 
share the data specified in paragraph (a)(1)(i) of this section 
conformant with the implementation specification at 45 CFR 
170.215(a)(4) to facilitate sharing the specified data relevant to one 
or more beneficiary at one time.
    (2) Attribution. A State must establish, implement, and maintain a 
process to facilitate generating each provider's current beneficiary 
roster to enable this payer-to-provider data sharing via the Provider 
Access API.
    (3) Opt-in. A State may put a process in place to allow a 
beneficiary or the beneficiary's personal representative to opt-in to 
permit the State's use of the Provider Access API for sharing with each 
of the beneficiary's provider(s) currently providing care, or planning 
to provide care, the data specified in paragraph (a)(1) of this 
section.
    (4) Provider resources regarding APIs. A State must provide on its 
website and through other appropriate mechanisms through which it 
ordinarily communicates with providers, educational resources in non-
technical, simple, and easy-to-understand language explaining general 
information concerning how a provider may make a request to the State 
for beneficiary data using the standards-based Provider Access API 
required under paragraph (a)(1) of this section, both for individual 
access and bulk data requests.
    (5) Out-of-network provider access. A State cannot deny use of, or 
access to, the Provider Access API based on a provider's contract 
status.
    (b) Coordination among payers--Payer-to-Payer Data Exchange. (1) 
Beginning January 1, 2023, a State must implement and maintain a 
standards-based API compliant with Sec.  431.60(c), (d), and (e) that 
makes available to another payer, at a minimum, the data maintained by 
the state with a date of service on or after January 1, 2016, within 
one (1) business day of receipt, conformant with the implementation 
specifications at 45 CFR 170.215(c)(5) for data specified at Sec.  
431.60(b)(1) and (2) not including remittances and enrollee cost 
sharing information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for 
data specified at Sec.  431.60(b)(3), 45 CFR 170.215(c)(7) for data 
specified at Sec.  431.60(b)(4), and 45 CFR 170.215(c)(6) for data 
specified at Sec.  431.60(b)(5). Such information received by a State 
must be incorporated into the State's records about the current 
beneficiary.
    (2) With the approval and at the direction of a current or former 
beneficiary or the beneficiary's personal representative, the State 
must:
    (i) Receive all such data for a current beneficiary from any other 
payer that has provided coverage to the beneficiary within the 
preceding 5 years;
    (ii) At any time a beneficiary is currently enrolled with the State 
and up to 5 years after disenrollment, send all such data to any other 
payer that currently covers the beneficiary or to a payer the 
beneficiary or the beneficiary's personal representative specifically 
requests receive the data; and
    (iii) Send data received from another payer under this paragraph in 
the electronic form and format it was received.
    (c) Coordination among payers at enrollment--Payer-to-Payer API. 
(1) Accessible content and API requirements. Beginning January 1, 2023, 
a State must make the standards-based API specified in paragraph (b)(1) 
of this section conformant with the implementation specification at 45 
CFR 170.215(a)(4) to facilitate sharing the data specified in paragraph 
(b)(1) of this section relevant to one or more beneficiaries at one 
time.
    (2) Requesting data exchange. (i) When a beneficiary enrolls in 
coverage with the State, the State may request the data from a previous 
payer through the standards-based API described in paragraph (c)(1) of 
this section, as permitted by the beneficiary per paragraph (c)(5) of 
this section, and as permitted by applicable law;
    (ii) For any beneficiaries who enroll with the State during the 
first calendar quarter of each year, the State must request the 
specified data within one (1) week of the end of the first calendar 
quarter from any previous payers through the standards-based API 
described in paragraph (c)(1) of this section, as permitted by the 
beneficiary per paragraph (c)(5) of this section, and as permitted by 
applicable law;
    (iii) If a State receives a request from another payer to make data 
available for one or more former beneficiaries who have enrolled with 
the new payer, the State must respond by making the required data 
available via the standards-based API described in paragraph (c)(1) of 
this section within one (1) business day of receiving the request.
    (3) Previous or concurrent payer. A State must adopt a process to 
obtain from a new beneficiary the name of the new beneficiary's 
previous payer as part of the enrollment process, and the name of the 
new beneficiary's concurrent payer or payers if the beneficiary has 
coverage through more than one payer, to facilitate data sharing using 
the Payer-to-Payer API described in paragraph (c)(1) of this section.
    (4) Concurrent payer exchange. When a beneficiary has concurrent 
coverage with another payer also subject to CMS regulations on the 
Payer-to-Payer API, the State must make available to the other payer 
the data described in paragraph (b)(1) of this section through the 
standards-based API described in paragraph (c)(1) of this section 
quarterly.
    (5) Opt-in. A State must put a process in place to allow a 
beneficiary or the beneficiary's personal representative to opt-in to 
permit the State's use of the Payer-to-Payer API data sharing specified 
in paragraph (c)(1) of this section.
    (d) Obligations. The requirements under this section do not in any 
way alter or change a State's obligation as a HIPAA covered entity to 
comply with regulations regarding standard transactions at 45 CFR part 
162.
    (e) Extensions and Exemptions. (1) Extension. (i) A State may 
submit a written application to request to delay implementation of the 
requirements in paragraphs (a) through (c) of this section one-time for 
up to one (1) year with respect to its Medicaid fee-for-service 
program. The written application must be submitted and approved as part 
of the State's annual Advance Planning Document for MMIS operations 
costs and must include:
    (A) A narrative justification describing the specific reasons why 
the State cannot reasonably satisfy the requirement(s) by the 
compliance date and explaining why those reasons result from 
circumstances that are unique to States operating Medicaid fee-for 
service programs;
    (B) A report on completed and ongoing State implementation 
activities that evidence a good faith effort towards compliance; and
    (C) A comprehensive plan to meet implementation requirements no 
later than 1 year after the initial compliance date.
    (ii) CMS will grant the State's request if it determines based on 
the information provided in the State's annual Advance Planning 
Document for MMIS operations costs that the request

[[Page 82673]]

adequately establishes a need to delay implementation, that this need 
results from circumstances that are unique to States operating Medicaid 
fee-for-service programs, that the State has made a good faith effort 
to implement the proposed requirements as soon as possible, and that 
the State has a clear plan to implement the requirements no later than 
one (1) year after the proposed compliance date.
    (2) Exemption. (i) A State operating a Medicaid program under which 
at least 90 percent of all covered items and services are provided to 
Medicaid beneficiaries through Medicaid managed care contracts with 
MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery 
system, or under which at least 90 percent of the State's Medicaid 
beneficiaries are enrolled in Medicaid managed care organizations as 
defined in Sec.  438.2, may request that its fee-for-service program be 
exempted from the requirement(s) in paragraphs (a) through (c) of this 
section.
    (A) A state may submit an exemption request once per calendar year 
for a one (1) year exemption.
    (B) The annual request must be submitted as part of a state's 
annual Advance Planning Document for MMIS operations costs.
    (C) The State's request must include documentation that the State 
meets the criteria for the exemption, using data from any one of the 
three most recent and complete calendar years prior to the date the 
exemption request is made.
    (ii) CMS will grant the exemption for a one-year period if the 
State establishes to CMS's satisfaction that the State meets the 
criteria for the exemption and has established a plan to ensure there 
will be efficient electronic access to the same information through 
alternative means.
0
4. Section 431.70 is amended by adding paragraph (d) to read as 
follows:


Sec.  431.70  Access to published provider directory information.

* * * * *
    (d) Beginning January 1, 2023, the Provider Directory API must be 
conformant with the implementation specification at 45 CFR 
170.215(c)(8).
0
5. Section 431.80 is added to subpart B to read as follows:


Sec.  431.80  Documentation and prior authorization.

    (a) Requirements to support provider documentation discovery and to 
support prior authorization. At a minimum:
    (1) Documentation Requirement Lookup Service (DRLS) Application 
Programming Interface (API). Beginning January 1, 2023, a State must 
implement and maintain a standards-based API compliant with Sec.  
431.60(c), (d), and (e):
    (i) That is populated with the State's list of covered items and 
services, not including covered outpatient drugs, for which prior 
authorization is required, and with the State's documentation 
requirements for submitting a prior authorization request, including a 
description of the required documentation; and
    (ii) That is conformant with the implementation specifications at 
45 CFR 170.215(c)(1) and (2).
    (2) Prior Authorization Support API. Beginning January 1, 2023, a 
State must implement and maintain a standards-based API compliant with 
Sec.  431.60(c), (d), and (e):
    (i) That facilitates a HIPAA-compliant prior authorization request 
and response, including any forms or medical record documentation 
required by the State for the items or services for which the provider 
is seeking prior authorization;
    (ii) That is conformant with the implementation specification at 45 
CFR 170.215(c)(3); and
    (iii) That includes in the response whether the State approves (and 
for how long), denies, or requests more information related to the 
prior authorization request, along with a standard denial reason code 
in the case of denial;
    (iv) A State must include a specific reason for a denial in the 
case of a denial with all prior authorization decisions, regardless of 
the method used to send the prior authorization decision.
    (b) Extensions and Exemptions. (1) Extension. (i) A State may 
submit a written application to request to delay implementation of the 
requirements in paragraphs (a)(1) and (2) of this section one-time for 
up to one (1) year with respect to its Medicaid fee-for-service 
program. The written application must be submitted and approved as part 
of the State's annual Advance Planning Document for MMIS operations 
costs and must include:
    (A) A narrative justification describing the specific reasons why 
the State cannot reasonably satisfy the requirement(s) by the 
compliance date and explaining why those reasons result from 
circumstances that are unique to States operating Medicaid fee-for 
service programs;
    (B) A report on completed and ongoing State implementation 
activities that evidence a good faith effort towards compliance; and
    (C) A comprehensive plan to meet implementation requirements no 
later than 1 year after the initial compliance date.
    (ii) CMS will grant the State's request if it determines based on 
the information provided in the State's annual Advance Planning 
Document for MMIS operations costs that the request adequately 
establishes a need to delay implementation, that this need results from 
circumstances that are unique to States operating Medicaid fee-for-
service programs, that the State has made a good faith effort to 
implement the proposed requirements as soon as possible, and that the 
State has a clear plan to implement the requirements no later than one 
(1) year after the proposed compliance date.
    (2) Exemption. (i) A State operating a Medicaid program under which 
at least 90 percent of all covered items and services are provided to 
Medicaid beneficiaries through Medicaid managed care contracts with 
MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery 
system, or under which at least 90 percent of the State's Medicaid 
beneficiaries are enrolled in Medicaid managed care organizations as 
defined in Sec.  438.2, may request that its fee-for-service program be 
exempted from the requirement(s) in paragraphs (a)(1) and (2) of this 
section.
    (A) A state may submit an exemption request once per calendar year 
for a one (1) year exemption.
    (B) The annual request must be submitted as part of a state's 
annual Advance Planning Document for MMIS operations costs.
    (C) The State's request must include documentation that the State 
meets the criteria for the exemption, using data from any one of the 
three most recent and complete calendar years prior to the date the 
exemption request is made.
    (ii) CMS will grant the exemption for a one-year period if the 
State establishes to CMS's satisfaction that the State meets the 
criteria for the exemption and has established a plan to ensure there 
will be efficient electronic access to the same information through 
alternative means.
0
6. Section 431.201 is amended by revising the definition of ``Action'' 
to read as follows:


Sec.  431.201  Definitions.

* * * * *
    Action means:
    (1) A termination, suspension of, or reduction in covered benefits 
or services, including benefits or services for which there is a 
current approved prior authorization;
    (2) A termination, suspension of, or reduction in Medicaid 
eligibility, or an increase in beneficiary liability, including a 
determination that a beneficiary must incur a greater amount

[[Page 82674]]

of medical expenses in order to establish income eligibility in 
accordance with Sec.  435.121(e)(4) or Sec.  435.831 of this chapter;
    (3) A determination that a beneficiary is subject to an increase in 
premiums or cost-sharing charges under subpart A of part 447 of this 
chapter; or
    (4) A determination by a skilled nursing facility or nursing 
facility to transfer or discharge a resident and an adverse 
determination by a State with regard to the preadmission screening and 
resident review requirements of section 1919(e)(7) of the Act.
* * * * *
0
7. Section 431.220 is amended--
0
a. In paragraph (a)(1)(iv) by removing the term ``or'' from the end of 
the paragraph;
0
b. In paragraph (a)(1)(v) by removing ``.'' from the end of the 
paragraph and adding in its place ``; or''; and
0
c. By adding paragraph (a)(1)(vi).
    The addition reads as follows:


Sec.  431.220  When a hearing is required.

    (a) * * *
    (1) * * *
    (vi) A prior authorization decision.
* * * * *

PART 435--STATE ORGANIZATION AND GENERAL ADMINISTRATION

0
8. The authority citation for part 435 is revised to read as follows:

    Authority: 42 U.S.C. 1302.

0
9. Section 435.917 is amended by:
0
a. Revising the paragraph headings of paragraphs (a) and (b); and
0
b. Revising paragraph (b)(2).
    The revisions read as follows:


Sec.  435.917  Notice of agency's decision concerning eligibility, 
benefits, or services.

    (a) Notice of determinations. * * *
* * * * *
    (b) Content of notice. * * *
* * * * *
    (2) Notice of adverse action including denial, termination or 
suspension of eligibility or change in benefits or services. Any notice 
of denial, termination or suspension of Medicaid eligibility or, in the 
case of beneficiaries receiving medical assistance, denial of or change 
in benefits or services must be consistent with Sec.  431.210 of this 
chapter.
* * * * *

PART 438--MANAGED CARE

0
10. The authority citation for part 438 continues to read as follows:

    Authority: 42 U.S.C. 1302.
0
11. Section 438.9 is amended by revising paragraph (b)(7) to read as 
follows:


Sec.  438.9  Provisions that apply to non-emergency medical 
transportation PAHPs.

* * * * *
    (b) * * *
    (7) The PAHP standards in Sec. Sec.  438.206(b)(1), 438.210, 
438.214, 438.224, 438.230, and 438.242, excluding the requirement in 
Sec.  438.242(b)(7) to comply with Sec.  431.61(a) and (c) of this 
chapter.
* * * * *
0
12. Section 438.62 is amended by revising paragraph (b)(1)(vii)(A) 
introductory text to read as follows:


Sec.  438.62  Continued services to enrollees.

* * * * *
    (b) * * *
    (1) * * *
    (vii) * * *
    (A) The MCO, PIHP, or PAHP must comply with the requirements in 
paragraph (b)(1)(vi) of this section beginning January 1, 2022 until 
the start of the rating period beginning on or after January 1, 2023 
with regard to data:
* * * * *
0
13. Section 438.210 is amended by--
0
a. Revising paragraph (d)(1); and
0
b. Adding paragraph (g).
    The addition and revision read as follows:


Sec.  438.210  Coverage and authorization of services.

* * * * *
    (d) * * *
    (1) Standard authorization decisions. For standard authorization 
decisions, provide notice as expeditiously as the enrollee's condition 
requires and within State-established timeframes that may not exceed 14 
calendar days following receipt of the request for service, with a 
possible extension of up to 14 additional calendar days, and for 
standard authorization decisions made beginning with the rating period 
on or after January 1, 2023, may not exceed 7 calendar days following 
receipt of the request for service, with a possible extension of up to 
14 additional calendar days if--
* * * * *
    (g) Public reporting of prior authorization metrics. Beginning 
March 31, 2023, the MCO, PIHP, or PAHP must make the following 
information about plan level prior authorization publicly accessible by 
posting directly on its website or via publicly accessible 
hyperlink(s), annually by the end of the first calendar quarter, data, 
for the prior rating period:
    (1) A list of all items and services, not including covered 
outpatient drugs, that require prior authorization;
    (2) The percentage of standard prior authorization requests that 
were approved, reported separately for items and services, not 
including covered outpatient drugs;
    (3) The percentage of standard prior authorization requests that 
were denied, reported separately for items and services, not including 
covered outpatient drugs;
    (4) The percentage of standard prior authorization requests that 
were approved after appeal, reported separately for items and services, 
not including covered outpatient drugs;
    (5) The percentage of prior authorization requests for which the 
timeframe for review was extended, and the request was approved, 
reported separately for items and services, not including covered 
outpatient drugs;
    (6) The percentage of expedited prior authorization requests that 
were approved, reported separately for items and services, not 
including covered outpatient drugs; and
    (7) The average and median time that elapsed between the submission 
of a request and a determination by the MA organization, for standard 
prior authorizations, reported separately for items and services, not 
including covered outpatient drugs.
0
14. Section 438.242 is amended by--
0
a. Revising paragraphs (b)(5) introductory text;
0
b. Adding paragraph (b)(5)(ii);
0
c. Revising paragraph (b)(6); and
0
b. Adding paragraphs (b)(7) and (8).
    The revisions and additions read as follows:


Sec.  438.242  Health information systems.

* * * * *
    (b) * * *
    (5) Subject to paragraph (b)(8) of this section, implement a 
Patient Access Application Programming Interface (API) as specified in 
Sec.  431.60 of this chapter as if such requirements applied directly 
to the MCO, PIHP, or PAHP and include:
* * * * *
    (ii) Reporting metrics specified at Sec.  431.60(h) of this chapter 
at the plan level.
    (6) Except for Sec.  431.70(d) of this chapter implement, by 
January 1, 2021, and maintain a publicly accessible standard-based 
Provider Directory API described at Sec.  431.70 of this chapter, which 
must include all information specified at Sec.  438.10(h)(1) and (2) of 
this chapter. The State must require, at a minimum, that each MCO, 
PIHP, and PAHP comply with Sec.  431.70(d) by the rating period 
beginning on or after January 1, 2023.
    (7) By the rating period beginning on or after January 1, 2023, 
comply with Sec.  431.61(a) through (d) and Sec.  431.80(a)

[[Page 82675]]

of this chapter as if such requirements applied directly to the MCO, 
PIHP, or PAHP.
    (8) The following timeframes apply to paragraph (b)(5) of this 
section:
    (i) Except for the requirements at Sec. Sec.  431.60(b)(5), 
431.60(c)(3)(iii), 431.60(g), and 431.60(h) of this chapter, comply 
with the by the requirements of Sec.  431.60 of this chapter by January 
1, 2021.
    (ii) Comply with the requirements at Sec. Sec.  431.60(b)(5), 
431.60(c)(3)(iii), and 431.60(g) of this chapter by the rating period 
beginning on or after January 1, 2023.
    (iii) Comply with the reporting requirements at Sec.  431.60(h) of 
this chapter beginning with the end of the first full quarter of the 
rating period beginning on or after January 1, 2023 based on the 
previous quarter's data.
* * * * *

PART 440--SERVICES: GENERAL PROVISIONS

0
15. The authority citation for part 440 continues to read as follows:

    Authority: 42 U.S.C. 1302.

0
16. Section 440.230 is amended by adding paragraphs (d)(1) and (2) to 
read as follows:


Sec.  440.230  Sufficiency of amount, duration, and scope.

* * * * *
    (d) * * *
    (1) Prior authorization decision timeframes. The State Medicaid 
agency must--
    (i) Beginning January 1, 2023, provide notice of prior 
authorization decisions for items and services, not including covered 
outpatient drugs, as expeditiously as a beneficiary's health condition 
requires and under any circumstances not later than 72 hours of 
receiving a request for an expedited determination and not later than 7 
calendar days for standard requests. The timeframe for authorization 
decisions could be extended by up to 14 calendar days for standard 
requests if the beneficiary or provider requests an extension, or if 
the state agency or its authorized representative determines that 
additional information from the provider is needed to make a decision.
    (ii) Provide the beneficiary with notice of the agency's prior 
authorization decision and fair hearing rights in accordance with Sec.  
435.917 and part 431, subpart E of this chapter.
    (2) Public reporting of prior authorization metrics. Beginning 
March 31, 2023, the State Medicaid agency must make the following 
information about State agency level prior authorization decisions 
publicly accessible by posting directly on its website or via publicly 
accessible hyperlink(s), annually by the end of the first calendar 
quarter, data for the prior calendar year:
    (i) A list of all items and services, not including covered 
outpatient drugs, that require prior authorization;
    (ii) The percentage of standard prior authorization requests that 
were approved, reported separately for items and services, not 
including covered outpatient drugs;
    (iii) The percentage of standard prior authorization requests that 
were denied, reported separately for items and services, not including 
covered outpatient drugs;
    (iv) The percentage of standard prior authorization requests that 
were approved after appeal, reported separately for items and services, 
not including covered outpatient drugs;
    (v) The percentage of prior authorization requests for which the 
timeframe for review was extended, and the request was approved, 
reported separately for items and services, not including covered 
outpatient drugs;
    (vi) The percentage of expedited prior authorization requests that 
were approved, reported separately for items and services, not 
including covered outpatient drugs; and
    (vii) The average and median time that elapsed between the 
submission of a request and a determination by the state Medicaid 
agency, for standard prior authorizations, reported separately for 
items and services, not including covered outpatient drugs.

PART 457--ALLOTMENTS AND GRANTS TO STATES

0
17. The authority citation for part 457 continues to read as follows:

    Authority: 42 U.S.C. 1302.
0
18. Section 457.495 is amended by revising paragraph (d) to read as 
follows:


Sec.  457.495  State assurance of access to care and procedures to 
assure quality and appropriateness of care.

* * * * *
    (d) Decisions related to the prior authorization of health 
services. (1) That decisions related to the prior authorization of 
health services are completed in accordance with the medical needs of 
the patient, but no later than 7 calendar days after the date of 
receipt of the request for a standard determination and by no later 
than 72 hours after the date of receipt of the request for an expedited 
determination. A possible extension of up to 14 days may be permitted 
if the enrollee requests the extension or if the physician or health 
plan determines the additional information is needed.
    (2) Reserved.
0
19. Section 457.700 is amended by revising paragraph (c) to read as 
follows:


Sec.  457.700  Basis, scope, and applicability.

* * * * *
    (c) Applicability. The requirements of this subpart apply to 
separate child health programs and Medicaid expansion programs, except 
that Sec. Sec.  457.730, 457.731, and 457.732 do not apply to Medicaid 
expansion programs. Separate child health programs that provide 
benefits exclusively through managed care organizations may meet the 
requirements of Sec. Sec.  457.730, 457.731, and 457.732 by requiring 
the managed care organizations to meet the requirements of Sec.  
457.1233(d)(2).
0
20. Section 457.730 is amended by--
0
a. Revising paragraphs (b)(3);
0
b. Adding paragraph (b)(5);
0
c. Revising paragraph (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and 
(e)(2);
0
f. Redesignating paragraph (g) as paragraph (i); and
0
g. Adding new paragraphs (g) and (h).
    The revisions and additions read as follows:


Sec.  457.730  Beneficiary access to and exchange of data.

* * * * *
    (b) * * *
    (3) Clinical data, as defined in the USCDI version 1, if the State 
maintains any such data, no later than 1 business day after the data 
are received by the State;
* * * * *
    (5) By January 1, 2023, pending and active prior authorization 
decisions and related clinical documentation and forms for items and 
services, not including covered outpatient drugs, including the date 
the prior authorization was approved, the date the authorization ends, 
as well as the units and services approved and those used to date, no 
later than 1 business day after a provider initiates a prior 
authorization for the beneficiary or there is a change of status for 
the prior authorization.
    (c) * * *
    (3) Must comply with the content and vocabulary standard 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable to the data type or data element, unless alternate standards 
are required by other applicable law, and be conformant with the

[[Page 82676]]

requirements in paragraphs (c)(3)(iii) of this section:
* * * * *
    (iii) Beginning January 1, 2023, be conformant with the 
implementation specifications at 45 CFR 170.215(c)(5) for data 
specified in paragraphs (b)(1) and (2) of this section, 45 CFR 
170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified in paragraph 
(b)(3), 45 CFR 170.215(c)(7) for data specified in (b)(4), and 45 CFR 
170.215(c)(6) for data specified in paragraph (b)(5) of this section.
    (4) May use an updated version of any standard or all standards and 
any or all implementation guides or specifications required under 
paragraphs (b) or (c) of this section, Sec. Sec.  457.731, 457.732, and 
457.760, where:
* * * * *
    (ii) * * *
    (C) Use of the updated version of the standard, implementation 
guide, or specification does not disrupt an end user's ability to 
access the data described in paragraph (b) of this section, or the data 
described in Sec. Sec.  457.731, 457.732, and 457.760 of this chapter 
through the required API.
* * * * *
    (e) * * *
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which parties seek to access electronic health 
information, as defined at 45 CFR 171.102, including but not limited to 
criteria that may rely on automated monitoring and risk mitigation 
tools.
* * * * *
    (g) Privacy policy attestation. (1) Beginning January 1, 2023, the 
State must establish, implement, and maintain a process for requesting 
an attestation from a third-party app developer requesting to retrieve 
data via the Patient Access API that indicates the app adheres to 
certain privacy provisions. The State must:
    (i) Independently, or through the support of a third party, request 
a third-party app developer to attest whether:
    (A) The app has a privacy policy that is publicly available and 
accessible at all times, including updated versions, and that is 
written in plain language, and that the third-party app has 
affirmatively shared with the beneficiary prior to the beneficiary 
authorizing app access to their health information. To ``affirmatively 
share'' means that the beneficiary had to take an action to indicate 
they saw the privacy policy, such as click or check a box or boxes.
    (B) The app's privacy policy includes, at a minimum:
    (1) How a beneficiary's health information may be accessed, 
exchanged, or used by any person or other entity, including whether the 
beneficiary's health information may be shared or sold at any time 
(including in the future);
    (2) A requirement for express consent from a beneficiary before the 
beneficiary's health information is accessed, exchanged, or used, 
including receiving express consent before a beneficiary's health 
information is shared or sold (other than disclosures required by law 
or disclosures necessary in connection with the sale of the application 
or a similar transaction);
    (3) If an app will access any other information from a 
beneficiary's device; and
    (4) How a beneficiary can discontinue app access to their data and 
what the app's policy and process is for disposing of a beneficiary's 
data once the beneficiary has withdrawn consent.
    (ii) Include information in the beneficiary resources required in 
paragraph (f) of this section about the specific content of the State's 
privacy policy attestation required under this paragraph, and, at a 
minimum, the timeline for the attestation process, the method for 
informing beneficiary about the app developer's response or non-
response to the State's request, and the beneficiary's role and rights 
in this process; and
    (iii) Request the attestation at the time the third-party app 
engages the API and notify the beneficiary as follows:
    (A) The State must inform the beneficiary within 24 hours of 
requesting the attestation from the third-party app developer regarding 
the status of the attestation--positive, negative, or no response, with 
a clear explanation of what each means;
    (B) If a beneficiary does not respond within 24 hours of when the 
State sends notice of the attestation status to the beneficiary, the 
State must proceed with making the beneficiary's data available to the 
third-party app consistent with the beneficiary's original request.
    (2) The State must not discriminate when implementing this 
requirement, including for the purposes of competitive advantage; the 
method employed to meet this requirement must be applied equitably 
across all apps requesting access to the Patient Access API.
    (h) Reporting on the use of the Patient Access API. (1) Beginning 
March 31, 2023, a State must report to CMS, at the State agency level, 
by the end of each calendar quarter, based on the previous quarter's 
data as follows:
    (i) The total number of unique beneficiaries whose data are 
transferred via the Patient Access API to a beneficiary-designated 
third-party application; and
    (ii) The number of unique beneficiaries whose data are transferred 
via the Patient Access API to a beneficiary-designated third-party 
application more than once.
    (2) [Reserved].
* * * * *
0
21. Section 457.731 is added to subpart G to read as follows:


Sec.  457.731  Access to and exchange of health data to providers and 
payers.

    (a) Application Programming Interface to support data transfer from 
payers to providers--Provider Access API.--(1) Accessible content and 
API requirements. Beginning January 1, 2023, a State must implement and 
maintain a standards-based Application Programming Interface (API) 
compliant with Sec.  457.730(c), (d), and (e):
    (i) Individual beneficiary data. The Provider Access API must make 
available to providers, if requested by the provider, as permitted by 
the beneficiary per paragraph (a)(3) of this section, and as permitted 
by applicable law, at a minimum, data maintained by the State with a 
date of service on or after January 1, 2016, within one (1) business 
day of receipt, conformant with the implementation specifications at 45 
CFR 170.215(c)(5) for data specified at Sec.  431.60(b)(1) and (2) of 
this chapter, not including remittances and enrollee cost sharing 
information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data 
specified at Sec.  431.60(b)(3) of this chapter, 45 CFR 170.215(c)(7) 
for data specified at Sec.  431.60(b)(4), and 45 CFR 170.215(c)(6) for 
data specified at Sec.  431.60(b)(5) of this chapter; and
    (ii) Bulk data access. The Provider Access API must be able to 
share the data specified in (a)(1)(i) of this section conformant with 
the implementation specification at 45 CFR 170.215(a)(4) to facilitate 
sharing the specified data relevant to one or more beneficiaries at one 
time.
    (2) Attribution. A State must establish, implement, and maintain a 
process to facilitate generating each provider's current beneficiary 
roster to enable this payer-to-provider data sharing via the Provider 
Access API;
    (3) Opt-in. A State may put a process in place to allow a 
beneficiary or the beneficiary's personal representatives to opt-in to 
permit the State's use of the Provider Access API for sharing with

[[Page 82677]]

the each of the beneficiary's provider(s) currently providing care, or 
planning to provide care, the data specified in paragraph (a)(1) of 
this section.
    (4) Provider resources regarding APIs. A State must provide on its 
website and through other appropriate mechanisms through which it 
ordinarily communicates with providers, educational resources in non-
technical, simple and easy-to-understand language explaining general 
information concerning how a provider may make a request to the State 
for beneficiary data using the standards-based Provider Access API 
required under paragraph (a)(1) of this section, both for individual 
access and bulk data requests.
    (5) Out-of-network provider access. A State cannot deny use of, or 
access to, the Provider Access API based on a provider's contract 
status.
    (b) Coordination among payers--Payer-to-Payer Data Exchange. (1) 
Beginning January 1, 2023, a State must implement and maintain a 
standards-based API compliant with Sec.  457.730(c), (d), and (e) that 
makes available to another payer, at a minimum, the data maintained by 
the State with a date of service on or after January 1, 2016, within 
one (1) business day of receipt, conformant with the implementation 
specifications at 45 CFR 170.215(c)(5) for data specified at Sec.  
431.60(b)(1) and (2) of this chapter not including remittances and 
enrollee cost sharing information, 45 CFR 170.215(a)(2) or 45 CFR 
170.215(c)(6) for data specified at Sec.  431.60(b)(3) of this chapter, 
45 CFR 170.215(c)(7) for data specified at Sec.  431.60(b)(4) of this 
chapter, and 45 CFR 170.215(c)(6) for data specified at Sec.  
431.60(b)(5) of this chapter. Such information received by a State must 
be incorporated into the State's records about the current beneficiary.
    (2) With the approval and at the direction of a current or former 
beneficiary or the beneficiary's personal representative, the State 
must:
    (i) Receive all such data for a current beneficiary from any other 
payer that has provided coverage to the beneficiary within the 
preceding 5 years;
    (ii) At any time a beneficiary is currently enrolled with the State 
and up to 5 years after disenrollment, send all such data to any other 
payer that currently covers the beneficiary or a payer the beneficiary 
or the beneficiary's personal representative specifically requests 
receive the data; and
    (iii) Send data received from another payer under this paragraph in 
the electronic form and format it was received.
    (c) Coordination among payers at enrollment--Payer-to-Payer API.--
(1) Accessible content and API requirements. Beginning January 1, 2023, 
a State must make the standards-based API specified in paragraph (b)(1) 
of this section conformant with the implementation specification at 45 
CFR 170.215(a)(4) to facilitate sharing the data specified in paragraph 
(b)(1) of this section relevant to one or more beneficiaries at one 
time.
    (2) Requesting data exchange. (i) When a beneficiary enrolls in 
coverage with the State, the State may request the data from a previous 
payer through the standards-based API described in paragraph (c)(1) of 
this section, as permitted by the enrollee per paragraph (c)(5) of this 
section, and as permitted by applicable law;
    (ii) For any beneficiaries who enroll with the State during the 
first calendar quarter of each year, the State must request the 
specified data within one (1) week of the end of the first calendar 
quarter from any previous payers through the standards-based API 
described in paragraph (c)(1) of this section, as permitted by the 
beneficiary per paragraph (c)(5) of this section, and as permitted by 
applicable law;
    (iii) If a State receives a request from another payer to make data 
available for one or more former beneficiaries who have enrolled with 
the new payer, the State must respond by making the required data 
available via the standards-based API described in paragraph (c)(1) of 
this section within one (1) business day of receiving the request.
    (3) Previous or concurrent payer. A State must maintain a process 
to obtain from a new beneficiary the name of the new beneficiary's 
previous payer as part of the enrollment process, and concurrent payer 
if the beneficiary has coverage through more than one payer, to 
facilitate data sharing using the Payer-to-Payer API described in 
paragraph (c)(1) of this section.
    (4) Concurrent payer exchange. When a beneficiary has concurrent 
coverage with another payer also subject to CMS regulations on the 
Payer-to-Payer API, the State must make available to the other payer 
the data described in paragraph (b)(1) of this section through the 
standards-based API described in paragraph (c)(1) of this section 
quarterly.
    (5) Opt-in. A State must put a process in place to allow a 
beneficiary or the beneficiary's personal representative to opt-in to 
permit the State's use of the Payer-to-Payer API data sharing specified 
in paragraph (c)(1) of this section.
    (d) Obligations. The requirements under this section do not in any 
way alter or change a State's obligation as a HIPAA covered entity to 
comply with regulations regarding standard transactions at 45 CFR part 
162.
    (e) Extensions and Exemptions--(1) Extension. (i) A State may 
submit a written application to request to delay implementation of the 
requirements in paragraphs (a) through (c) of this section one-time for 
up to one (1) year with respect to its Medicaid fee-for-service 
program. The written application must be submitted and approved as part 
of the State's annual Advance Planning Document for MMIS operations 
costs and must include:
    (A) A narrative justification describing the specific reasons why 
the State cannot reasonably satisfy the requirement(s) by the 
compliance date and explaining why those reasons result from 
circumstances that are unique to States operating CHIP fee-for service 
programs;
    (B) A report on completed and ongoing State implementation 
activities that evidence a good faith effort towards compliance; and
    (C) A comprehensive plan to meet implementation requirements no 
later than 1 year after the initial compliance date.
    (ii) CMS will grant the State's request if it determines based on 
the information provided in the State's annual Advance Planning 
Document for MMIS operations costs that the request adequately 
establishes a need to delay implementation, that this need results from 
circumstances that are unique to States operating CHIP fee-for-service 
programs, that the State has made a good faith effort to implement the 
proposed requirements as soon as possible, and that the State has a 
clear plan to implement the requirements no later than one (1) year 
after the proposed compliance date.
    (2) Exemption. (i) A State operating a CHIP program under which at 
least 90 percent of all covered items and services are provided to 
beneficiaries through managed care contracts with MCOs, PIHPs, or 
PAHPs, rather than through a fee-for-service delivery system, or under 
which at least 90 percent of the State's beneficiaries are enrolled in 
managed care organizations as defined in Sec.  457.10, may request that 
its fee-for-service program be exempted from the requirement(s) in 
paragraphs (a) through (c) of this section.
    (A) A state may submit an exemption request once per calendar year 
for a one (1) year exemption.
    (B) The annual request must be submitted as part of a state's 
annual

[[Page 82678]]

Advance Planning Document for MMIS operations costs.
    (C) The State's request must include documentation that the State 
meets the criteria for the exemption, using data from any one of the 
three most recent and complete calendar years prior to the date the 
exemption request is made.
    (ii) CMS will grant the exemption for a one-year period if the 
State establishes to CMS's satisfaction that the State meets the 
criteria for the exemption and has established a plan to ensure there 
will be efficient electronic access to the same information through 
alternative means.
    (f) Applicability. This section is applicable beginning January 1, 
2023.
0
22. Section 457.732 is added to subpart G to read as follows:


Sec.  457.732  Documentation and prior authorization.

    (a) Requirements to support provider documentation discovery and to 
support prior authorization. At a minimum:
    (1) Documentation Requirement Lookup Service (DRLS) Application 
Programming Interface (API). Beginning January 1, 2023, a State must 
implement and maintain a standards-based API compliant with Sec.  
457.730(c), (d), and (e) --
    (i) That is populated with the State's list of covered items and 
services, not including covered outpatient drugs, for which prior 
authorization is required, and with the State's documentation 
requirements for submitting a prior authorization request, including a 
description of the required documentation; and
    (ii) That is conformant with the implementation specifications at 
45 CFR 170.215(c)(1) and (2).
    (2) Prior Authorization Support API. Beginning January 1, 2023, a 
State must implement and maintain a standards-based API compliant with 
Sec.  457.730(c), (d), and (e) --
    (i) That facilitates a HIPAA-compliant prior authorization request 
and response, including any forms or medical record documentation 
required by the State for the items or services for which the provider 
is seeking prior authorization;
    (ii) That is conformant with the implementation specifications at 
45 CFR 170.215(c)(1) and (2).
    (iii) That includes in the response whether the State approves (and 
for how long), denies, or requests more information related to the 
prior authorization request, along with a denial reason code in the 
case of denial;
    (iv) A State must include a specific reason for a denial in the 
case of a denial with all prior authorization decisions, regardless of 
the method used to send the prior authorization decision.
    (b) Extensions and Exemptions.--(1) Extension. (i) A State may 
submit a written application to request to delay implementation of the 
requirements in paragraphs (a)(1) and (2) of this section one-time for 
up to one (1) year with respect to its Medicaid fee-for-service 
program. The written application must be submitted and approved as part 
of the State's annual Advance Planning Document for MMIS operations 
costs and must include:
    (A) A narrative justification describing the specific reasons why 
the State cannot reasonably satisfy the requirement(s) by the 
compliance date and explaining why those reasons result from 
circumstances that are unique to States operating CHIP fee-for service 
programs;
    (B) A report on completed and ongoing State implementation 
activities that evidence a good faith effort towards compliance; and
    (C) A comprehensive plan to meet implementation requirements no 
later than 1 year after the initial compliance date.
    (ii) CMS will grant the State's request if it determines based on 
the information provided in the State's annual Advance Planning 
Document for MMIS operations costs that the request adequately 
establishes a need to delay implementation, that this need results from 
circumstances that are unique to States operating CHIP fee-for-service 
programs, that the State has made a good faith effort to implement the 
proposed requirements as soon as possible, and that the State has a 
clear plan to implement the requirements no later than one (1) year 
after the proposed compliance date.
    (2) Exemption. (i) A State operating a CHIP program under which at 
least 90 percent of all covered items and services are provided to 
beneficiaries through managed care contracts with MCOs, PIHPs, or 
PAHPs, rather than through a fee-for-service delivery system, or under 
which at least 90 percent of the State's beneficiaries are enrolled in 
managed care organizations as defined in Sec.  457.10, may request that 
its fee-for-service program be exempted from the requirement(s) in 
paragraphs (a)(1) and (2) of this section.
    (A) A state may submit an exemption request once per calendar year 
for a one (1) year exemption.
    (B) The annual request must be submitted as part of a state's 
annual Advance Planning Document for MMIS operations costs.
    (C) The State's request must include documentation that the State 
meets the criteria for the exemption, using data from any one of the 
three most recent and complete calendar years prior to the date the 
exemption request is made.
    (ii) CMS will grant the exemption for a one-year period if the 
State establishes to CMS's satisfaction that the State meets the 
criteria for the exemption and has established a plan to ensure there 
will be efficient electronic access to the same information through 
alternative means.
    (3) Public reporting of prior authorization metrics. Beginning 
March 31, 2023, the State must make the following information about 
State agency level prior authorization decisions publicly accessible by 
posting directly on its website or via publicly accessible 
hyperlink(s), annually by the end of the first calendar quarter, data 
for the prior calendar year:
    (i) A list of all items and services, not including covered 
outpatient drugs, that require prior authorization;
    (ii) The percentage of standard prior authorization requests that 
were approved, reported separately for items and services, not 
including covered outpatient drugs;
    (iii) The percentage of standard prior authorization requests that 
were denied, reported separately for items and services, not including 
covered outpatient drugs;
    (iv) The percentage of standard prior authorization requests that 
were approved after appeal, reported separately for items and services, 
not including covered outpatient drugs;
    (v) The percentage of prior authorization requests for which the 
timeframe for review was extended, and the request was approved, 
reported separately for items and services, not including covered 
outpatient drugs;
    (vi) The percentage of expedited prior authorization requests that 
were approved, reported separately for items and services, not 
including covered outpatient drugs; and
    (vii) The average and median time that elapsed between the 
submission of a request and a determination by the State, for standard 
prior authorizations, reported separately for items and services, not 
including covered outpatient drugs.
0
23. Section 457.760 is amended by adding paragraph (d) to read as 
follows:


Sec.  457.760  Access to published provider directory information

* * * * *
    (d) Beginning January 1, 2023, the Provider Directory API must be 
conformant with the implementation specification at 45 CFR 
170.215(c)(8).
0
24. Section 457.1233 is amended by--

[[Page 82679]]

0
a. Revising paragraph (d)(2) introductory text;
0
b. Adding paragraph (d)(2)(ii);
0
c. Revising paragraph (d)(3); and
0
d. Adding paragraph (d)(4) and (5).
    The revisions and additions read as follows:


Sec.  457.1233  Structure and operations standards.

* * * * *
    (d) * * *
    (2) Subject to paragraph (d)(5) of this section, each MCO, PIHP, 
and PAHP must implement a Patient Access Application Programming 
Interfaces (APIs) as specified in Sec.  457.730 as if such requirements 
applied directly to the MCO, PIHP, or PAHP, and include:
* * * * *
    (ii) Reporting metrics specified at Sec.  457.730(h) at the plan 
level.
    (3) Except for Sec.  457.760(d), implement, by January 1, 2021, and 
maintain a publicly accessible standards-based Provider Directory API 
described at Sec.  457.760 of this chapter, which must include all 
information specified in Sec.  438.10(h)(1) and (2) of this chapter. 
The state must require, at a minimum, that each MCO, PIHP, and PAHP 
comply with Sec.  457.760(d) by the rating period beginning on or after 
January 1, 2023.
    (4) By the rating period beginning on or after January 1, 2023, 
comply with Sec. Sec.  457.731(a) through (d) and 457.732(a) as if such 
requirements applied directly to the MCO, PIHP, or PAHP.
    (5) The following timeframes apply to paragraph (d)(2) of this 
section:
    (i) Except for the requirement at Sec. Sec.  457.730(b)(5), 
457.730(c)(3)(iii), 457.730(g), and 457.730(h), comply with the by the 
requirements of Sec.  457.730 by January 1, 2021.
    (ii) Comply with the requirements at Sec. Sec.  457.730(b)(5), 
457.730(c)(3)(iii), and 457.730(g) by the rating period beginning on or 
after January 1, 2023.
    (iii) Comply with the reporting requirement at Sec.  457.730(h) 
beginning with the end of the first full quarter of the rating period 
beginning on or after January 1, 2023 based on the previous quarter's 
data.
* * * * *
    For the reasons set forth in the preamble, the Department of Health 
and Human Services (HHS) proposes to amend 45 CFR subtitle A, 
subchapter B as set forth below:

PART 156--HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE 
CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES

0
25. The authority citation for part 156 continues to read as follows:

    Authority: 42 U.S.C. 18021-18024, 18031-18032, 18041-18042, 
18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B.

0
26. Section 156.221 is amended by--
0
a. Revising paragraph (b)(1)(iii);
0
b. Adding paragraph (b)(1)(iv);
0
c. Revising paragraph (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraph (c)(4) introductory text, (c)(4)(ii)(C), (e)(2), 
and (f)(1) introductory text;
0
f. Adding paragraph (f)(2);
0
g. Redesignating paragraphs (h) and (i) as paragraphs (j) and (k);
0
h. Adding new paragraphs (h) and (i); and
0
i. Revising newly redesignated paragraph (j).
    The revisions and addition read as follows:


Sec.  156.221  Access to and exchange of health data and plan 
information.

* * * * *
    (b) * * *.
    (1) * * *
    (iii) Clinical data, as defined in the USCDI version 1, if the QHP 
issuer maintains any such data, no later than 1 business day after data 
are received by the QHP issuer; and
    (iv) Beginning January 1, 2023, pending and active prior 
authorization decisions and related clinical documentation and forms 
for items and services, not including prescription drugs, including the 
date the prior authorization was approved, the date the authorization 
ends, as well as the units and services approved and those used to 
date, no later than 1 business day after a provider initiates a prior 
authorization for the enrollee or there is a change of status for the 
prior authorization.
* * * * *
    (c) * * *
    (3) Must comply with the content and vocabulary standard 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable to the data type or data element, unless alternate standards 
are required by other applicable law, and be conformant with the 
requirements in paragraph (c)(3)(iii) of this section:
* * * * *
    (iii) Beginning January 1, 2023, be conformant with the 
implementation specifications at Sec.  170.215(c)(5) for data specified 
at Sec.  156.221(b)(1)(i) and (ii), Sec.  170.215(a)(2) or Sec.  
170.215(c)(6) of this subchapter for data specified at Sec. Sec.  
156.221(b)(1)(iii), and 170.215(c)(6) of this subchapter for data 
specified in paragraph (b)(1)(iv) of this section.
    (4) May use an updated version of any standard or all standards and 
any or all implementation guides or specifications required under 
paragraphs (b), (c), or (f) of this section, Sec. Sec.  156.222 or 
156.223, where:
* * * * *
    (ii) * * *
    (C) Use of the updated version of the standard, implementation 
guide, or specification does not disrupt an end user's ability to 
access the data described in paragraph (b) or (f) of this section or 
the data described in Sec. Sec.  156.222 or 156.223 of this chapter 
through the required API.
* * * * *
    (e) * * *
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which parties seek to access electronic health 
information, as defined at Sec.  171.102 of this subchapter, including 
but not limited to criteria that may rely on automated monitoring and 
risk mitigation tools.
    (f) * * *
    (1) From January 1, 2022 until December 31, 2022, a QHP issuer on a 
Federally-facilitated Exchange must maintain a process for the 
electronic exchange of, at a minimum, the data classes and elements 
included in the content standard adopted at Sec.  170.213 of this 
subchapter. Such information received by a QHP issuer on a Federally-
facilitated Exchange must be incorporated into the QHP issuer's records 
about the current enrollee. With the approval and at the direction of a 
current or former enrollee or the enrollee's personal representative, a 
QHP issuer on a Federally-facilitated Exchange must:
* * * * *
    (2) Beginning January 1, 2023, a QHP issuer on a Federally-
facilitated Exchange must implement and maintain an API compliant with 
Sec.  156.221(c)(1), (c)(2), (c)(3)(i), and (c)(3)(ii), (d), and (e), 
and that is conformant with the implementation specifications at Sec.  
170.215(c)(5) of this chapter for data specified at Sec.  
156.221(b)(1)(i) and (ii) not including remittances and enrollee cost 
sharing information, Sec.  170.215(a)(2) or 170.215(c)(6) of this 
subchapter for data specified at Sec.  156.221(b)(1)(iii), and Sec.  
170.215(c)(6) of this subchapter for

[[Page 82680]]

data specified in paragraph (b)(1)(iv). Such information received by a 
QHP issuer on a Federally-facilitated Exchange must be incorporated 
into the QHP issuer's records about the current enrollee.
    (i) With the approval and at the direction of a current or former 
enrollee or the enrollee's personal representative, a QHP issuer on a 
Federally-facilitated Exchange must:
    (A) Receive all such data for a current enrollee from any other 
payer that has provided coverage to the enrollee within the preceding 5 
years;
    (B) At any time an enrollee is currently enrolled in the plan and 
up to 5 years after disenrollment, send all such data to any other 
payer that currently covers the enrollee or a payer the enrollee or the 
enrollee's personal representative specifically requests receive the 
data; and
    (C) Send data received from another payer under this paragraph 
(f)(2) of this section in the electronic form and format it was 
received.
    (ii) [Reserved].
* * * * *
    (h) Privacy policy attestation. (1) Beginning January 1, 2023, a 
QHP issuer on a Federally-facilitated Exchange must establish, 
implement, and maintain a process for requesting an attestation from a 
third-party app developer requesting to retrieve data via the Patient 
Access API that indicates the app adheres to certain privacy 
provisions. The QHP issuer on a Federally-facilitated Exchange must:
    (i) Independently, or through the support of a third party, request 
a third-party app developer to attest whether:
    (A) The app has a privacy policy that is publicly available and 
accessible at all times, including updated versions, and that is 
written in plain language, and that the third-party app has 
affirmatively shared with the enrollee prior to the enrollee 
authorizing app access to their health information. To ``affirmatively 
share'' means that the enrollee had to take an action to indicate they 
saw the privacy policy, such as click or check a box or boxes.
    (B) The app's privacy policy includes, at a minimum:
    (1) How an enrollee's health information may be accessed, 
exchanged, or used by any person or other entity, including whether the 
enrollee's health information may be shared or sold at any time 
(including in the future);
    (2) A requirement for express consent from an enrollee before the 
enrollee's health information is accessed, exchanged, or used, 
including receiving express consent before an enrollee's health 
information is shared or sold (other than disclosures required by law 
or disclosures necessary in connection with the sale of the application 
or a similar transaction);
    (3) If an app will access any other information from an enrollee's 
device; and
    (4) How an enrollee can discontinue app access to their data and 
what the app's policy and process is for disposing of an enrollee's 
data once the enrollee has withdrawn consent.
    (ii) Include information in the enrollee resources required in 
paragraph (g) of this section about the specific content of the QHP 
issuer's privacy policy attestation required under this paragraph, and, 
at a minimum, the timeline for the attestation process, the method for 
informing enrollees about the app developer's response or non-response 
to the QHP issuer's request, and the enrollee's role and rights in this 
process; and
    (iii) Request the attestation at the time the third-party app 
engages the API and notify the enrollee as follows:
    (A) The QHP issuer on a Federally-facilitated Exchange must inform 
the enrollee within 24 hours of requesting the attestation from the 
third-party app developer regarding the status of the attestation--
positive, negative, or no response, with a clear explanation of what 
each means;
    (B) If an enrollee does not respond within 24 hours of when the QHP 
issuer send the notice of the attestation status to the enrollee, the 
QHP issuer must proceed with making the enrollee's data available to 
the third-party app consistent with the enrollee's original request.
    (2) A QHP issuer must not discriminate when implementing this 
requirement, including for the purposes of competitive advantage; the 
method employed to meet this requirement must be applied equitably 
across all apps requesting access the Patient Access API.
    (i) Reporting on the use of the Patient Access API. (1) Beginning 
March 31, 2023, a QHP issuer on a Federally-facilitated Exchange must 
report to HHS, at the issuer level, by the end of each calendar 
quarter, based on the previous quarter's data:
    (i) The total number of unique enrollees whose data are transferred 
via the Patient Access API to an enrollee designated third-party 
application; and
    (ii) The number of unique enrollees whose data are transferred via 
the Patient Access API to an enrollee designated third-party 
application more than once.
    (2) [Reserved].
    (j) Exception. (1) If a plan applying for QHP certification to be 
offered through a Federally-facilitated Exchange believes it cannot 
satisfy the requirements in paragraphs (a) through (i) of this section, 
the issuer must include as part of its QHP application a narrative 
justification describing the reasons why the plan cannot reasonably 
satisfy the requirements for the applicable plan year, the impact of 
non-compliance upon enrollees, the current or proposed means of 
providing health information to enrollees, and solutions and a timeline 
to achieve compliance with the requirements of this section.
    (2) The Federally-facilitated Exchange may grant an exception to 
the requirements in paragraphs (a) through (i) of this section if the 
Exchange determines that making such health plan available through such 
Exchange is in the interests of qualified individuals and qualified 
employers in the State or States in which such Exchange operates.
* * * * *
0
27. Section 156.222 is added to read as follows:


Sec.  156.222  Access to and exchange of health data and plan 
information to providers and payers.

    (a) Application Programming Interface to support data transfer from 
payers to providers--Provider Access API. Subject to paragraph (d) of 
this section:
    (1) Accessible content and API requirements. Beginning January 1, 
2023, a QHP issuer on a Federally-facilitated Exchange must implement 
and maintain a standards-based Application Programming Interface (API) 
compliant with Sec.  156.221(c), (d), and (e):
    (i) Individual enrollee data. The Provider Access API must make 
available to providers, if requested by the provider, as permitted by 
the enrollee per paragraph (a)(3) of this section, and as permitted by 
applicable law, at a minimum, data maintained by the QHP with a date of 
service on or after January 1, 2016, within one (1) business day of 
receipt, conformant with the implementation specifications at Sec.  
170.215(c)(5) of this subchapter for data specified at Sec.  
156.221(b)(1)(i) and (ii), not including remittances and enrollee cost 
sharing information, Sec.  170.215(a)(2) or (c)(6) of this subchapter 
for data specified at Sec.  156.221(b)(1)(iii), and Sec.  170.215(c)(6) 
of this subchapter for data specified in paragraph (b)(1)(iv) of this 
section; and
    (ii) Bulk data access. The Provider Access API must be able to 
share the data described in paragraph (a)(1)(i) of

[[Page 82681]]

this section conformant with the implementation specification at Sec.  
170.215(a)(4) to facilitate sharing the specified data relevant to one 
or more QHP enrollees at one time;
    (2) Attribution. A QHP issuer on a Federally-facilitated Exchange 
must establish, implement, and maintain a process to facilitate 
generating each provider's current enrollee rosters to enable payer-to-
provider data sharing via the Provider Access API.
    (3) Opt-in. A QHP issuer on a Federally-facilitated Exchange may 
put a process in place to allow an enrollee or the enrollee's personal 
representative to opt-in to permit the QHP's use of the Provider Access 
API for sharing with each of the enrollee's provider(s) currently 
providing care, or planning to provide care, the data specified in 
paragraph (a)(1) of this section.
    (4) Provider resources regarding APIs. A QHP issuer on a Federally-
facilitated Exchange must provide on its website and through other 
appropriate mechanisms through which it ordinarily communicates with 
providers, educational resources in non-technical, simple, and easy-to-
understand language explaining general information concerning how a 
provider may make a request to the QHP for QHP enrollee data using the 
standards-based Provider Access API, required under paragraph (a)(1) of 
this section, both for individual access and bulk data requests.
    (5) Out-of-network provider access. A QHP issuer on a Federally-
facilitated Exchange cannot deny use of, or access to, the Provider 
Access API based on a provider's contract status.
    (b) Coordination among payers at enrollment--Payer-to-Payer API. 
Subject to paragraph (d) of this section:
    (1) Accessible content and API requirements. Beginning January 1, 
2023 a QHP issuer on a Federally-facilitated Exchange must make the 
standards-based API specified at Sec.  156.221(f)(2) conformant with 
the implementation specification at Sec.  170.215(a)(4) of this 
subchapter to facilitate sharing the data specified at Sec.  
156.221(f)(2) relevant to one or more QHP enrollees at one time.
    (2) Requesting data exchange. (i) When an enrollee enrolls in a QHP 
on a Federally-facilitated Exchange, the QHP issuer may request the 
data from the previous payer through the standards-based API described 
in paragraph (b)(1) of this section, as permitted by the enrollee per 
paragraph (b)(5) of this section, and as permitted by applicable law.
    (ii) For any enrollees who enrolled in a QHP on a Federally-
facilitated Exchange during the annual open enrollment period 
applicable to the Federally-facilitated Exchange, the QHP issuer must 
request the specified data within one (1) week of the end of the 
enrollment period from any previous payers through the standards-based 
API described in paragraph (b)(1) of this section, as permitted by 
enrollees per paragraph (b)(5) of this section, and as permitted by 
applicable law;
    (iii) If a QHP issuer receives a request from another payer to make 
data available for one or more former enrollee who have enrolled with 
the new payer, the QHP issuer must respond by making the required data 
available via the standards-based API described in paragraph (b)(1) of 
this section within one (1) business day of receiving the request.
    (3) Previous or concurrent payer. A QHP issuer on a Federally-
facilitated Exchange must maintain a process to obtain from a new QHP 
enrollee the name of the new QHP enrollee's previous payer, and 
concurrent payer if the enrollee has coverage through more than one 
payer, to facilitate data sharing using the Payer-to-Payer API 
described in paragraph (b)(1) of this section.
    (4) Concurrent payer exchange. When a QHP enrollee has concurrent 
coverage with another payer also subject to HHS regulations on the 
Payer-to-Payer API, the QHP issuer on the Federally-facilitated 
Exchange must make available to the other payer the data described at 
Sec.  156.221(f)(2) through the standards-based API described in 
paragraph (b)(1) of this section quarterly.
    (5) Opt-in. A QHP issuer on a Federally-facilitated Exchange must 
put a process in place to allow an enrollee or the enrollee's personal 
representative to opt-in to permit the QHP issuer to use the Payer-to-
Payer API data sharing specified in paragraph (b)(1) of this section.
    (c) Obligations. The requirements under this section do not in any 
way alter or change a QHP issuer's obligation as a HIPAA covered entity 
to comply with regulations regarding standard transactions at 45 CFR 
part 162.
    (d) Exception. (1) If a plan applying for QHP certification to be 
offered through a Federally-facilitated Exchange believes it cannot 
satisfy the requirements in paragraphs (a) or (b) of this section, the 
issuer must include as part of its QHP application a narrative 
justification describing the reasons why the plan cannot reasonably 
satisfy the requirements for the applicable plan year, the impact of 
non-compliance upon enrollees, the current or proposed means of 
providing health information to providers and/or payers, and solutions 
and a timeline to achieve compliance with the requirements of this 
section.
    (2) The Federally-facilitated Exchange may grant an exception to 
the requirements in paragraphs (a) or (b) of this section if the 
Exchange determines that making such health plan available through such 
Exchange is in the interests of qualified individuals and qualified 
employers in the State or States in which such Exchange operates.
0
28. Section 156.223 is added to read as follows:


Sec.  156.223  Documentation and prior authorization.

    (a) Requirements to support provider documentation discovery and to 
support prior authorization. Subject to paragraph (b) of this section:
    (1) Documentation Requirement Lookup Service (DRLS) Application 
Programming Interface (API). Beginning January 1, 2023, a QHP issuer on 
a Federally-facilitated Exchange must implement and maintain a 
standards-based API compliant with Sec.  156.221(c), (d), and (e):
    (i) That is populated with the QHP issuer's list of covered items 
and services, not including prescription drugs, for which prior 
authorization is required, and with the QHP issuer's documentation 
requirements for submitting a prior authorization request, including a 
description of the required documentation; and
    (ii) That is conformant with the implementation specifications at 
Sec.  170.215(c)(1) and (2).
    (2) Prior Authorization Support API. Beginning January 1, 2023, a 
QHP issuer on a Federally-facilitated Exchange must implement and 
maintain a standards-based API compliant with Sec.  156.221(c), (d), 
and (e):
    (i) That facilitates a HIPAA-compliant prior authorization request 
and response, including any other forms or medical record documentation 
required by the QHP issuer for the items or services for which the 
provider is seeking prior authorization, conformant with the 
requirements at Sec.  172.110(a)(3) of this subchapter;
    (ii) That is conformant with the implementation specification at 
Sec.  170.215(c)(3) of this subchapter; and
    (iii) That includes in the response whether the QHP issuer approves 
(and for how long), denies, or requests more information related to the 
prior authorization request, along with a standard denial reason code 
in the case of denial;
    (iv) A QHP issuer on a Federally-facilitated Exchange must include 
a specific reason for a denial in the case of a denial with all prior 
authorization

[[Page 82682]]

decisions, regardless of the method used to send the prior 
authorization decision.
    (3) Public reporting of prior authorization metrics. Beginning 
March 31, 2023, a QHP issuer on a Federally-facilitated Exchange must 
make the following information about the issuer level prior 
authorization decisions specified, publicly accessible by posting 
directly on its website or via publicly accessible hyperlink(s), 
annually by the end of the first calendar quarter, data for the prior 
calendar year:
    (i) A list of all items and services, not including prescription 
drugs, that require prior authorization;
    (ii) The percentage of standard prior authorization requests that 
were approved, reported separately for items and services, not 
including prescription drugs;
    (iii) The percentage of standard prior authorization requests that 
were denied, reported separately for items and services, not including 
prescription drugs;
    (iv) The percentage of standard prior authorization requests that 
were approved after appeal, reported separately for items and services, 
not including prescription drugs;
    (v) The percentage of prior authorization requests for which the 
timeframe for review was extended, and the request was approved, 
reported separately for items and services, not including prescription 
drugs;
    (vi) The percentage of expedited prior authorization requests that 
were approved, reported separately for items and services, not 
including prescription drugs; and
    (vii) The average and median time that elapsed between the 
submission of a request and a determination by the issuer, for standard 
prior authorizations, reported separately for items and services, not 
including prescription drugs.
    (b) Exception. (1) If a plan applying for QHP certification to be 
offered through a Federally-facilitated Exchange believes it cannot 
satisfy the requirements in paragraph (a)(1) and/or (a)(2) of this 
section, the issuer must include as part of its QHP application a 
narrative justification describing the reasons why the plan cannot 
reasonably satisfy the requirements for the applicable plan year, the 
impact of non-compliance upon enrollees, the current or proposed means 
of providing health information to providers, and solutions and a 
timeline to achieve compliance with the requirements of this section.
    (2) The Federally-facilitated Exchange may grant an exception to 
the requirements in paragraph (a) of this section if the Exchange 
determines that making such health plan available through such Exchange 
is in the interests of qualified individuals and qualified employers in 
the State or States in which such Exchange operates.

PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION 
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION 
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

0
29. The authority citation for part 170 continues to read as follows:

    Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552.
0
30. Section 170.215 is amended--
0
a. By revising the section heading;
0
b. In paragraph (a), by adding a paragraph heading;
0
c. In paragraph (b), by revising the paragraph heading; and
0
d. By adding paragraph (c).
    The revisions and additions read as follows:


Sec.  170.215   Application Programming Interface Standards and 
Implementation Specifications.

* * * * *
    (a) Base Standard and Implementation Specifications. * * *
* * * * *
    (b) Security Standard. * * *
    (c) Standards and Implementation Specifications for Health Care 
Operations.
    (1) Prior authorization implementation specification. HL7 FHIR Da 
Vinci--Coverage Requirements Discovery (CRD) Implementation Guide: 
Version STU 1.0.0 (incorporated by reference in Sec.  170.299).
    (2) Prior authorization implementation specification. HL7 FHIR Da 
Vinci--Documentation Templates and Rules (DTR) Implementation Guide: 
Version STU 1.0.0 (incorporated by reference in Sec.  170.299).
    (3) Prior authorization implementation specification. HL7 FHIR Da 
Vinci--Prior Authorization Support (PAS) Implementation Guide: Version 
STU 1.0.0 (incorporated by reference in Sec.  170.299).
    (4) Payer data implementation specification. HL7 FHIR Da Vinci--
Payer Coverage Decision Exchange (PCDE) Implementation Guide: Version 
STU 1.0.0 (incorporated by reference in Sec.  170.299).
    (5) Payer data implementation specification. HL7 FHIR Consumer 
Directed Payer Data Exchange (CARIN IG for Blue Button[supreg]) 
Implementation Guide: Version STU 1.0.0 (incorporated by reference in 
Sec.  170.299).
    (6) Payer data implementation specification. HL7 FHIR Da Vinci 
Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0 
(incorporated by reference in Sec.  170.299).
    (7) Payer data implementation specification. HL7 FHIR Da Vinci--
Payer Data Exchange (PDex) US Drug Formulary Implementation Guide: 
Version STU 1.0.1 (incorporated by reference in Sec.  170.299).
    (8) Provider directory implementation specification. HL7 FHIR Da 
Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide: Version 
STU 1.0.0 (incorporated by reference in Sec.  170.299).
0
31. Section 170.299 is amended by adding paragraphs (f)(35) through 
(42) to read as follows:


Sec.  170.299  Incorporation by reference.

* * * * *
    (f) * * *
    (35) HL7 FHIR[supreg] Da Vinci--Coverage Requirements Discovery 
(CRD) Implementation Guide, Version STU 1.0.0, IBR approved for Sec.  
170.215(c).
    (36) HL7 FHIR[supreg] Da Vinci--Documentation Templates and Rules 
(DTR) Implementation Guide, Version STU 1.0.0, IBR approved for Sec.  
170.215(c).
    (37) HL7 FHIR[supreg] Da Vinci--Prior Authorization Support (PAS) 
Implementation Guide, Version STU 1.0.0, IBR approved for Sec.  
170.215(c).
    (38) HL7 FHIR[supreg] Da Vinci--Payer Coverage Decision Exchange 
(PCDE) Implementation Guide, Version STU 1.0.0, IBR approved for Sec.  
170.215(c).
    (39) HL7 FHIR[supreg] Consumer Directed Payer Data Exchange (CARIN 
IG for Blue Button[supreg]) Implementation Guide, Version STU 1.0.0, 
IBR approved for Sec.  170.215(c).
    (40) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) 
Implementation Guide, Version STU 1.0.0, IBR approved for Sec.  
170.215(c).
    (41) HL7 FHIR[supreg] Da Vinci--Payer Data Exchange (PDex) US Drug 
Formulary Implementation Guide, Version STU 1.0.1, IBR approved for 
Sec.  170.215(c).
    (42) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Plan Net 
Implementation Guide, Version STU 1.0.0, IBR approved for Sec.  
170.215(c).
* * * * *

    Dated: December 2, 2020.
Seema Verma,
Administrator, Centers for Medicare & Medicaid Services.
    Dated: December 10, 2020.
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2020-27593 Filed 12-14-20; 11:15 am]
BILLING CODE 4120-01-P