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

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 FederallyFacilitated 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 Federallyfacilitated 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 standalone dental plans (SADPs). Likewise, 

we are also excluding QHP issuers only 

offering QHPs in the Federallyfacilitated 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 disenrolls 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, 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82588 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

1See OCR guidance regarding personal 

representatives at https://www.hhs.gov/hipaa/forprofessionals/faq/2069/under-hipaa-when-can-afamily-member/index.html and https://

www.hhs.gov/hipaa/for-professionals/faq/personalrepresentatives-and-minors/index.html. 

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. 

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. 

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

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-toPayer 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® (HL7) Fast 

Healthcare Interoperability Resources®

(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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 Meritbased 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 valuebased 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82590 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

3HL7 International. (n.d.). Consumer Directed 

Payer Data Exchange (CARIN IG for Blue Button®) 

Implementation Guide Publication (Version) 

History. Retrieved from http://hl7.org/fhir/us/carinbb/history.html. 

4HL7 International. (n.d.). US Core 

Implementation Guide (FHIR IG) Publication 

(Version) History. Retrieved from http://hl7.org/ 

fhir/us/core/history.html. 

5HL7 International. (n.d.). Da Vinci Payer Data 

Exchange (FHIR IG) Publication (Version) History. 

Retrieved from http://hl7.org/fhir/us/davinci-pdex/ 

history.html. 

6HL7 International. (n.d.). US Drug Formulary 

(FHIR IG) Publication (Version) History. Retrieved 

from http://hl7.org/fhir/us/Davinci-drug-formulary/ 

history.html. 

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: 

• HL7 Consumer Directed Payer Data 

Exchange (CARIN IG for Blue Button®) 

IG: Version STU 1.0.0 to facilitate the 

exchange of the claims and encounter 

data; 3

• 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; 4 5

and 

• 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

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 subregulatory 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 thirdparty 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 thirdparty 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 crossreferences 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-andGuidance/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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82592 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

7HL7 International. (n.d.). Da Vinci Payer Data 

Exchange (FHIR IG) Publication (Version) History. 

Retrieved from http://hl7.org/fhir/us/davinci-pdex/ 

history.html. 

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

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82593 

8See Example 1 in ONC’s 21st Century Cures at 

final rule (85 FR 25816). 

9Plain Language Action and Information 

Network. (2011, May). Federal Plain Language 

Guidelines. Retrieved from https://

www.plainlanguage.gov/media/ 

FederalPLGuidelines.pdf. 

10See https://www.carinalliance.com/our-work/ 

trust-framework-and-code-of-conduct/. 

11See https://www.healthit.gov/topic/privacysecurity-and-hipaa/model-privacy-notice-mpn. 

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. 

At a minimum, we propose that the 

requested attestation include whether: 

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

• 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.10 11 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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82594 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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

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

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 thirdparty app. 

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 thirdparty 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). 

Specifically, we propose that these 

payers report quarterly: 

• The total number of unique patients 

whose data are transferred via the 

Patient Access API to a patient 

designated third-party app; and 

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82595 

14We 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. 

15https://bluebutton.cms.gov/blog/FHIR-R4- 

coming-to-the-blue-button-api.html. 

16HL7 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. 

17Available at http://cmsgov.github.io/QHPprovider-formulary-APIs/developer/index.html. 

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. 

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. 

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, machinereadable format, the Provider Directory 

API proposal does not include QHP 

issuers.17

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82596 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 Medicaidcovered 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, lowincome 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 thirdparty 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82598 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

18See, 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/ 

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82599 

privacy/guidance/disclosures-treatment-paymenthealth-care-operations/index.html. 

19See 45 CFR 162.923(a). 20See 45 CFR 164.506. 

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: 

• Health care claims or equivalent 

encounter information. 

• Health care electronic funds 

transfers (EFT) and remittance advice. 

• Health care claim status. 

• Eligibility for a health plan. 

• Enrollment and disenrollment in a 

health plan. 

• Referrals certification and 

authorization. 

• Coordination of benefits. 

• Health plan premium payments. 

• 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

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

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82600 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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

22Centers for Medicare and Medicaid Services. 

(n.d.). Beneficiary Claims Data API. Retrieved from 

https://bcda.cms.gov/. 

23HL 7 International. (n.d.). FHIR Bulk Data 

Access (Flat FHIR). Retrieved from https://hl7.org/ 

fhir/uv/bulkdata/history.html. 

24 Data at the Point of Care. (n.d.). Retrieved from 

https://dpc.cms.gov/. 

25Office 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-forhealthcare/meetings/bulk-data-export-meeting-andreport/. 

26A ‘call’ is an interaction with a server using an 

API to deliver a request and receive a response in 

return. 

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

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 § 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 patientlevel 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. 

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. 

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. 

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82601 

27See SHO #20–003, https://www.medicaid.gov/ 

federal-policy-guidance/downloads/sho20003.pdf. 

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-toprovider 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 standardsbased 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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82602 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

28 Data at the Point of Care. (n.d.). Terms of 

Service. Retrieved from https://dpc.cms.gov/termsof-service. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82603 

29State 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-issuesupdated-time-to-hire-guidance/. 

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 optout 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 nontechnical, simple, and easy-tounderstand 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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82604 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 noncompliance 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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. 

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

• Section 1902(a)(8) of the Act, which 

requires states to ensure that Medicaid 

services are furnished with reasonable 

promptness to all eligible individuals. 

• 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, lowincome 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82606 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

30ONC Strategy to reduce provider burden. 

Report required under the 21st Century Cures Act: 

https://www.healthit.gov/topic/usability-andprovider-burden/strategy-reducing-burden-relatinguse-health-it-and-ehrs. 

31American Medical Association. (2019, 

February). 2018 AMA Prior Authorization (PA) 

Physician Survey. Retrieved from https://www.amaassn.org/system/files/2019-02/prior-auth-2018.pdf. 

32Office 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. 

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

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 timeconsuming trying to determine whether 

prior authorization requirements exist 

for a given patient, diagnosis, insurance 

plan, or state.’’ 32

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82607 

33American 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/priorauthorization-consensus-statement.pdf. 

34Office 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. 

35National 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. 

36America’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/newfast-path-initiative-aims-to-improve-priorauthorization-for-patients-and-doctors/. 

37See https://www.healthit.gov/hitac/ 

committees/intersection-clinical-andadministrative-data-task-force. 

38Final 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. 

39American 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-healthplan-prior-authorization-11-4-19.pdf. 

40American Medical Association. (2019, 

February). 2018 AMA Prior Authorization (PA) 

Physician Survey. Retrieved from https://www.amaassn.org/system/files/2019-02/prior-auth-2018.pdf. 

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. 

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

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82608 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

41CAQH. (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-caqhindex.pdf?token=SP6YxT4u. 

42Consensus Statement for Improving Prior 

Authorization: https://www.ama-assn.org/sites/ 

ama-assn.org/files/corp/media-browser/public/arcpublic/prior-authorization-consensusstatement.pdf. 

43AMA website link with resources regarding the 

prior authorization challenges: https://

fixpriorauth.org/resources. 

44HL7 International. (n.d.). Da Vinci Coverage 

Requirements Discovery (CRD) FHIR 

Implementation Guide. Retrieved from http://

hl7.org/fhir/us/davinci-crd/history.html. 

45HL7 International. (n.d.). Da Vinci 

Documentation Templates and Rules. Retrieved 

from http://hl7.org/fhir/us/davinci-dtr/history.html. 

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: 

• NCPDP Version D.0 for retail 

pharmacy drugs; and 

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

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 nongovernmental 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82609 

46For more information, visit: https://

www.cms.gov/Regulations-and-Guidance/ 

Guidance/Interoperability/index. 

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. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82610 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82611 

47See SHO # 20–003, https://www.medicaid.gov/ 

federal-policy-guidance/downloads/sho20003.pdf. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82612 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

48CHIP managed care entities are required to 

comply with these standards by 42 CFR 57.1230(d). 

49American 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. 

50American 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. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 laborintensive 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. 

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 nonurgent 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82614 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

51See 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). 

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 decisionmaking 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

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82616 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

52We 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. 

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. 

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? 

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

• Under what circumstances could an 

approval be provided in less than 7 

calendar days for a complex case? 

• 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 bestcase 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82617 

53State 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-issuesupdated-time-to-hire-guidance/. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82618 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 noncompliance 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 issuerlevel 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: 

• A list of all items and services that 

require prior authorization; 

• The percentage of standard prior 

authorization requests that were 

approved, reported separately for items 

and services; 

• The percentage of standard prior 

authorization requests that were denied, 

reported separately for items and 

services; 

• The percentage of standard prior 

authorization requests that were 

approved after appeal, reported 

separately for items and services; 

• 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; 

• The percentage of expedited prior 

authorization requests that were 

approved, reported separately for items 

and services; 

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82619 

54Centers for Medicare and Medicaid Services. 

(2019, October 7). Review Choice Demonstration for 

Home Health Services. Retrieved from https://

www.cms.gov/Research-Statistics-Data-andSystems/Monitoring-Programs/Medicare-FFSCompliance-Programs/Review-ChoiceDemonstration/Review-Choice-Demonstration-forHome-Health-Services.html. 

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-overyear 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 ‘‘GoldCarding’’ 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 evidencedriven criteria that they deem relevant. 

CMS uses an approach similar to goldcarding 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 postpayment review or spot check review 

process.54

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82620 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 standardsbased 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 APIcapable. 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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, lowincome 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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82622 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82623 

55Office of the National Coordinator. (2019, June 

4). Improved Diagnostics & Patient Outcomes. 

Retrieved from https://www.healthit.gov/topic/ 

health-it-basics/improved-diagnostics-patientoutcomes. 

55See SHO # 20–003, https://www.medicaid.gov/ 

federal-policy-guidance/downloads/sho20003.pdf. 

55HL7 International. (n.d.). Da Vinci Payer 

Coverage Decision Exchange (PCDE) FHIR IG. 

Retrieved from http://www.hl7.org/fhir/us/davincipcde/history.cfml. 

55State 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-issuesupdated-time-to-hire-guidance/. 

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

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 payerto-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-topayer 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-toPayer 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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82624 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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-topayer 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 Payerto-Payer API, and all APIs proposed in 

this rule, complement this requirement 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82625 

56See SHO # 20–003, https://www.medicaid.gov/ 

federal-policy-guidance/downloads/sho20003.pdf. 

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. 

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-topayer 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-topayer 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 costsharing 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82626 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

57HL7 International. (n.d.). Da Vinci Payer 

Coverage Decision Exchange (PCDE) FHIR IG. 

Retrieved from http://www.hl7.org/fhir/us/davincipcde/history.cfml. 

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. 

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 FHIRbased API, doing much of the work 

needed to implement this Payer-toPayer 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 optin to this data sharing via the Payer-toPayer 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-toPayer 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82628 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 optin 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 employerbased 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 Payerto-Payer API are finalized, we would 

encourage state Medicaid and CHIP FFS 

programs to implement the Payer-toPayer 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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82629 

58State 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-issuesupdated-time-to-hire-guidance/. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82630 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 noncompliance 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-toPayer 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-toPayer 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: 

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

• Section 1902(a)(8) of the Act, which 

requires states to ensure that Medicaid 

services are furnished with reasonable 

promptness to all eligible individuals. 

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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, lowincome 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82632 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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-toPayer 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: 

• Ensures that each patient’s health 

information is secure and protected, in 

accordance with applicable law; 

• Improves health care quality, 

reduces medical errors, reduces health 

disparities, and advances the delivery of 

patient-centered medical care; 

• Reduces health care costs resulting 

from inefficiency, medical errors, 

inappropriate care, duplicative care, and 

incomplete information; 

• Provides appropriate information to 

help guide medical decisions at the time 

and place of care; 

• Ensures the inclusion of meaningful 

public input in such development of 

such infrastructure; 

• 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; 

• 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; 

• Facilitates health and clinical 

research and health care quality; 

• Promotes early detection, 

prevention, and management of chronic 

diseases; 

• Promotes a more effective 

marketplace, greater competition, 

greater systems analysis, increased 

consumer choice, and improved 

outcomes in health care services; and 

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82633 

59See https://www.hl7.org/about/davinci/. 

60See http://www.hl7.org/documentcenter/ 

public/pressreleases/HL7_PRESS_20190211.pdf. 

61See https://www.healthit.gov/isa/querydocuments-outside-a-specific-health-informationexchange-domain. 

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® FHIR® 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®, 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®

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 IG version history are available for 

review. 

A number of the FHIR® 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® FHIR® 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® FHIR® platform to 

address value-based care initiatives. 

Because the Da Vinci project is aligned 

with HL7®, new and revised 

requirements can become open industry 

standards. 

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® FHIR® 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. 

c. Alignment With Federal Advisory 

Committee Activities 

The HITECH Act established two 

federal advisory committees, the HIT 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82634 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

62HITAC 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. 

63HITAC 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. 

64HITAC 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. 

65HITAC 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. 

66Final 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. 

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

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

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®

FHIR® standards as part of this 

recommendation including discussion 

of: The HL7® FHIR® Da Vinci CRD and 

DTR IGs, and the HL7® FHIR® 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®

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82635 

described below in section II.E.3. of this 

proposed rule. 

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 patientcentered 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: 

• 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). 

• 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). 

• 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: 

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

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

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

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

• HL7 FHIR Consumer Directed Payer 

Data Exchange (CARIN IG for Blue 

Button®) Implementation Guide: 

Version STU 1.0.0. URL: http://hl7.org/ 

fhir/us/carin-bb/history.html. 

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

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

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82636 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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: 

• Patient Engagement and Provider 

Discretion. What role should patients 

and providers play in data segmentation 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82637 

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

68Office of the National Coordinator for Health 

Information Technology. (2020). Data Segmentation 

of Sensitive Information. Retrieved from https://

www.healthit.gov/isa/data-segmentation-sensitiveinformation. 

69For 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. 

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

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? 

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

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

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

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

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

• 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

• 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)). 

• 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 officebased 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. 

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, communitybased providers, and other nontraditional 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? 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82638 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

71Office 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. 

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 UseDisorder 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: 

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

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

• Are there particular considerations 

for electronic data exchange for 

behavioral health providers who 

practice independently, are communitybased, or are non-traditional providers? 

What about rural-based behavioral 

health providers? How could an APIbased solution help address these 

considerations? 

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

• 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 officebased 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. 

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, communitybased providers, and other nontraditional 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 UseDisorder Prevention that Promotes 

Opioid Recovery and Treatment for 

Patients and Communities Act 

(SUPPORT for Patients and 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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: 

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

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

• Are there particular considerations 

for electronic data exchange for 

behavioral health providers who 

practice independently, are communitybased, or are non-traditional providers? 

What about rural-based behavioral 

health providers? How could an APIbased solution help address these 

considerations? 

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

• 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 § 482.24(d), 

‘‘Electronic notifications,’’ for hospitals; 

at § 482.61(f), ‘‘Electronic notifications,’’ 

for psychiatric hospitals; and at 

§ 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 Medicaidparticipating 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: 

• 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; 

• 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; 

• Paper forms and portals require 

manual data reentry that may already 

reside electronically within an EHR; and 

• There are multiple routes to obtain 

a prior authorization depending on the 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82640 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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: 

• What are the current barriers to 

transmitting prior authorization requests 

and receipts electronically? What 

actions could CMS and/or industry take 

to remove barriers? 

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

• 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 MeritBased 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, § 414.1320 for the 

performance period, § 414.1325 for data 

submission requirements, § 414.1355 for 

the improvement activity performance 

category generally, § 414.1360 for data 

submission criteria, and § 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. 

• Is this an activity that stakeholders 

identify as improving clinical practice 

or care delivery? 

• When effectively executed, is 

implementation of such technology and 

use of these standards likely to result in 

improved outcomes? 

• If yes, should this activity be 

assigned a medium-weight or highweight? 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82641 

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

31532515. 

addition of a MIPS improvement 

activity incorporating the use of a FHIRbased 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: 

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

• What are the primary 

considerations for developing such a 

measure? 

• How would the measure require the 

use of certified electronic health record 

technology? 

• Should the Prior Authorization 

Support IG be incorporated into 

potential future certification 

requirements for health IT under the 

ONC Health IT Certification Program? 

• Should CMS consider additional 

measures and activities under MIPS 

Quality, Cost, or Improvement Activities 

performance categories involving FHIRbased electronic prior authorization 

solutions? 

• If so, what are the primary 

considerations for developing such 

measures and activities? 

• 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 EGovernment 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: 

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

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

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

• To what extent can electronic and 

cloud-based fax technology bridge the 

gap between electronic transmission 

and traditional fax technology? 

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

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82642 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

73See https://www.healthit.gov/buzz-blog/ 

interoperability/advancing-interoperable-socialdeterminants-of-health-data. 

74https://www.whitehouse.gov/sites/ 

whitehouse.gov/files/omb/circulars/A119/revised_

circular_a-119_as_of_1_22.pdf. 

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: 

• 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)? 

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

• What mechanisms are currently 

used to exchange social risk and social 

needs data (EHRs, HIEs, software, cloudbased data platforms, etc.)? What 

challenges, if any, occur in translating 

social risk data collected in these 

platforms to Z-codes on claims? 

• 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 governmentunique 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. 

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® (HL7) Fast Healthcare 

Interoperability Resources® (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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82643 

75https://cds-hooks.org/. 

76https://docs.smarthealthit.org/. 

77https://cql.hl7.org/. 

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 nocost (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 industryled, 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 § 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 

• HL7 FHIR Da Vinci—Coverage 

Requirements Discovery (CRD) 

Implementation Guide: Version STU 

1.0.0. 

URL: http://hl7.org/fhir/us/davincicrd/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 CMSregulated 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/lowercost services/products. 

—Documents and rules related to 

coverage. 

—Forms and templates. 

—Indications of whether prior 

authorization is required. 

• HL7 FHIR Da Vinci— 

Documentation Templates and Rules 

(DTR) Implementation Guide: Version 

STU 1.0.0. 

URL: http://hl7.org/fhir/us/davincidtr/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 

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

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. 

• HL7 FHIR Da Vinci—Prior 

Authorization Support (PAS) 

Implementation Guide: Version STU 

1.0.0. 

URL: http://hl7.org/fhir/us/davincipas/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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82644 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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. 

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

• HL7 FHIR Consumer Directed Payer 

Data Exchange (CARIN IG for Blue 

Button®) 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. 

• HL7 FHIR Da Vinci Payer Data 

Exchange (PDex) Implementation Guide: 

Version STU 1.0.0. 

URL: http://hl7.org/fhir/us/davincipdex/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 patientauthorized exchange to a third-party 

application, such as the patientrequested 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. 

• HL7 FHIR Da Vinci—Payer Data 

Exchange (PDex) US Drug Formulary 

Implementation Guide: Version STU 

1.0.1. 

URL: http://hl7.org/fhir/us/Davincidrug-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. 

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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: 

• The need for the information 

collection and its usefulness in carrying 

out the proper functions of our agency. 

• The accuracy of our estimate of the 

information collection burden. 

• The quality, utility, and clarity of 

the information to be collected. 

• 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 CMSregulated 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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.000</GPH>
82646 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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: 

• First-year implementation would 

require, on average, a total of 160 hours 

per organization at an average cost of 

$14,645.20 per organization. 

• 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). 

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

• 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). 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82647 

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

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 FHIRbased 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). 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.001</GPH>
82648 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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: 

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

• The aggregate burden of the firstyear 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. 

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.002</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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: 

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

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82650 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

corresponds to the primary estimate; the 

primary and high are obtained by 

multiplying the low estimate by a factor 

of two and three, respectively. 

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.003</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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: 

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

• The aggregate burden of the onetime 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. 

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.004</GPH> EP18DE20.005</GPH>
82652 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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

• First-year implementation would 

require on average a total of 320 hours 

per organization at an average cost of 

$28,685.20 per organization. 

• 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). 

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

• 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). 

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.006</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82653 

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 costsharing 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 Payerto-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-toPayer 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: 

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

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


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.007</GPH>
82654 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.008</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82655 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.009</GPH>
82656 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

79Office of Management and Budget. (2017). 

North American Industry Classification System. 

Retrieved from: https://www.census.gov/eos/www/ 

naics/2017NAICS/2017_NAICS_Manual.pdf. 

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

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82658 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

80U.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. 

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. 

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

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.010</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82659 

81Patel, 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-ConsumerData-Brief-3.21.18.pdf. 

82 Interoperability Standards Advisory. (n.d.). 

U.S. Core Data for Interoperability. Retrieved from 

https://www.healthit.gov/isa/united-states-coredata-interoperability-uscdi. 

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. 

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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82660 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82661 

83This 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. 

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

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82662 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

84Casalino, 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. 

85Morley, 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. 

86Ward, V. (2018, April). The Shocking Truth 

About Prior Authorization in Healthcare. Retrieved 

from https://getreferralmd.com/2018/04/priorauthorization-problems-healthcare/. 

87Center 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-inhealthcare/. 

88Robeznieks, A. (2018, November 16). Inside 

Cleveland Clinic’s $10 million prior authorization 

price tag. Retrieved from https://www.amaassn.org/practice-management/sustainability/ 

inside-cleveland-clinic-s-10-million-priorauthorization-price. 

89American Medical Association. (2019, June). 

Prior Authorization and Utilization Management 

Reform Principles. Retrieved from https://

www.ama-assn.org/system/files/2019-06/principleswith-signatory-page-for-slsc.pdf. 

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

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

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. 

Table 13 estimates are based on 

Casalino et al. (2009). Several other 

examples in the literature were 

reviewed 85 86 87 88 89 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. 

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.011</GPH> EP18DE20.012</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82663 

90 Kayla Holgash and Martha Heberlin, 

‘‘Physician Acceptance of New Medicaid Patients,’’ 

January 24, 2019 https://www.macpac.gov/wpcontent/uploads/2019/01/Physician-Acceptance-ofNew-Medicaid-Patients.pdf 

91Centers for Medicare and Medicaid Services. 

(2019, November 15). Simplifying Documentation 

Requirements. Retrieved from https://

www.cms.gov/Research-Statistics-Data-andSystems/Monitoring-Programs/Medicare-FFSCompliance-Programs/ 

SimplifyingRequirements.html. 

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. 

(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: 

• 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 realworld 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 societywide perspective.) 

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

• 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: 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82664 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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

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

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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.013</GPH> EP18DE20.014</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82665 

alternative assumptions as follows to 

the assumptions made in Tables 12 

through 15: 

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

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

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

• 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82666 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.015</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82667 

We can calculate the federal Medicaid 

payments using the percentages in Table 

18. 

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.016</GPH> EP18DE20.017</GPH>
82668 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

For Table 19: 

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

• 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). 

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

• 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 nonExchange 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. 

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

• Note: The $1.1 billion savings from 

reduced paperwork burden for use of 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.018</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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). 

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. 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.019</GPH>
82670 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 

■ 1. The authority citation for part 431 

continues to read as follows: 

Authority: 42 U.S.C. 1302. 

■ 2. Section 431.60 is amended by— 

■ a. Revising paragraph (b)(3); 

■ b. Adding paragraph (b)(5); 

■ c. Revising paragraph (c)(3) 

introductory text; 

■ d. Adding paragraph (c)(3)(iii); 

■ e. Revising paragraphs (c)(4) 

introductory text, (c)(4)(ii)(C), and (e)(2); 

■ f. Redesignating paragraph (g) as 

paragraph (i); and 

■ g. Adding new paragraphs (g) and (h). 


khammond on DSKJM1Z7X2PROD with PROPOSALS2EP18DE20.020</GPH>
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82671 

The revisions and addition read as 

follows: 

§ 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 §§ 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 

§§ 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 thirdparty 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 thirdparty 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]. 

* * * * * 

■ 3. Section 431.61 is added to read as 

follows: 

§ 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 § 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82672 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 § 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 § 431.60(b)(3), 45 CFR 

170.215(c)(7) for data specified at 

§ 431.60(b)(4), and 45 CFR 170.215(c)(6) 

for data specified at § 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 standardsbased API compliant with § 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 § 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 

§ 431.60(b)(3), 45 CFR 170.215(c)(7) for 

data specified at § 431.60(b)(4), and 45 

CFR 170.215(c)(6) for data specified at 

§ 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 standardsbased 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82673 

adequately establishes a need to delay 

implementation, that this need results 

from circumstances that are unique to 

States operating Medicaid fee-forservice 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 § 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. 

■ 4. Section 431.70 is amended by 

adding paragraph (d) to read as follows: 

§ 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). 

■ 5. Section 431.80 is added to subpart 

B to read as follows: 

§ 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 § 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 standardsbased API compliant with § 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-forservice 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 § 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. 

■ 6. Section 431.201 is amended by 

revising the definition of ‘‘Action’’ to 

read as follows: 

§ 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82674 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

of medical expenses in order to 

establish income eligibility in 

accordance with § 435.121(e)(4) or 

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

* * * * * 

■ 7. Section 431.220 is amended— 

■ a. In paragraph (a)(1)(iv) by removing 

the term ‘‘or’’ from the end of the 

paragraph; 

■ b. In paragraph (a)(1)(v) by removing 

‘‘.’’ from the end of the paragraph and 

adding in its place ‘‘; or’’; and 

■ c. By adding paragraph (a)(1)(vi). 

The addition reads as follows: 

§ 431.220 When a hearing is required. 

(a) * * * 

(1) * * * 

(vi) A prior authorization decision. 

* * * * * 

PART 435—STATE ORGANIZATION 

AND GENERAL ADMINISTRATION 

■ 8. The authority citation for part 435 

is revised to read as follows: 

Authority: 42 U.S.C. 1302. 

■ 9. Section 435.917 is amended by: 

■ a. Revising the paragraph headings of 

paragraphs (a) and (b); and 

■ b. Revising paragraph (b)(2). 

The revisions read as follows: 

§ 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 § 431.210 of this 

chapter. 

* * * * * 

PART 438—MANAGED CARE 

■ 10. The authority citation for part 438 

continues to read as follows: 

Authority: 42 U.S.C. 1302. 

■ 11. Section 438.9 is amended by 

revising paragraph (b)(7) to read as 

follows: 

§ 438.9 Provisions that apply to nonemergency medical transportation PAHPs. 

* * * * * 

(b) * * * 

(7) The PAHP standards in 

§§ 438.206(b)(1), 438.210, 438.214, 

438.224, 438.230, and 438.242, 

excluding the requirement in 

§ 438.242(b)(7) to comply with 

§ 431.61(a) and (c) of this chapter. 

* * * * * 

■ 12. Section 438.62 is amended by 

revising paragraph (b)(1)(vii)(A) 

introductory text to read as follows: 

§ 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: 

* * * * * 

■ 13. Section 438.210 is amended by— 

■ a. Revising paragraph (d)(1); and 

■ b. Adding paragraph (g). 

The addition and revision read as 

follows: 

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

■ 14. Section 438.242 is amended by— 

■ a. Revising paragraphs (b)(5) 

introductory text; 

■ b. Adding paragraph (b)(5)(ii); 

■ c. Revising paragraph (b)(6); and 

■ b. Adding paragraphs (b)(7) and (8). 

The revisions and additions read as 

follows: 

§ 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 § 431.60 of this 

chapter as if such requirements applied 

directly to the MCO, PIHP, or PAHP and 

include: 

* * * * * 

(ii) Reporting metrics specified at 

§ 431.60(h) of this chapter at the plan 

level. 

(6) Except for § 431.70(d) of this 

chapter implement, by January 1, 2021, 

and maintain a publicly accessible 

standard-based Provider Directory API 

described at § 431.70 of this chapter, 

which must include all information 

specified at § 438.10(h)(1) and (2) of this 

chapter. The State must require, at a 

minimum, that each MCO, PIHP, and 

PAHP comply with § 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 

§ 431.61(a) through (d) and § 431.80(a) 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 

§§ 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 

§ 431.60 of this chapter by January 1, 

2021. 

(ii) Comply with the requirements at 

§§ 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 § 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 

■ 15. The authority citation for part 440 

continues to read as follows: 

Authority: 42 U.S.C. 1302. 

■ 16. Section 440.230 is amended by 

adding paragraphs (d)(1) and (2) to read 

as follows: 

§ 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 § 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 

■ 17. The authority citation for part 457 

continues to read as follows: 

Authority: 42 U.S.C. 1302. 

■ 18. Section 457.495 is amended by 

revising paragraph (d) to read as 

follows: 

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

■ 19. Section 457.700 is amended by 

revising paragraph (c) to read as follows: 

§ 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 

§§ 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 §§ 457.730, 457.731, 

and 457.732 by requiring the managed 

care organizations to meet the 

requirements of § 457.1233(d)(2). 

■ 20. Section 457.730 is amended by— 

■ a. Revising paragraphs (b)(3); 

■ b. Adding paragraph (b)(5); 

■ c. Revising paragraph (c)(3) 

introductory text; 

■ d. Adding paragraph (c)(3)(iii); 

■ e. Revising paragraphs (c)(4) 

introductory text, (c)(4)(ii)(C), and (e)(2); 

■ f. Redesignating paragraph (g) as 

paragraph (i); and 

■ g. Adding new paragraphs (g) and (h). 

The revisions and additions read as 

follows: 

§ 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82676 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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, §§ 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 

§§ 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 thirdparty 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 nonresponse 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 thirdparty 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]. 

* * * * * 

■ 21. Section 457.731 is added to 

subpart G to read as follows: 

§ 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 § 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 § 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 

§ 431.60(b)(3) of this chapter, 45 CFR 

170.215(c)(7) for data specified at 

§ 431.60(b)(4), and 45 CFR 170.215(c)(6) 

for data specified at § 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 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 standardsbased API compliant with § 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 § 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 

§ 431.60(b)(3) of this chapter, 45 CFR 

170.215(c)(7) for data specified at 

§ 431.60(b)(4) of this chapter, and 45 

CFR 170.215(c)(6) for data specified at 

§ 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 standardsbased 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 

§ 457.10, may request that its fee-forservice 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82678 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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. 

■ 22. Section 457.732 is added to 

subpart G to read as follows: 

§ 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 § 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 standardsbased API compliant with § 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 

§ 457.10, may request that its fee-forservice 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. 

■ 23. Section 457.760 is amended by 

adding paragraph (d) to read as follows: 

§ 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). 

■ 24. Section 457.1233 is amended by— 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82679 

■ a. Revising paragraph (d)(2) 

introductory text; 

■ b. Adding paragraph (d)(2)(ii); 

■ c. Revising paragraph (d)(3); and 

■ d. Adding paragraph (d)(4) and (5). 

The revisions and additions read as 

follows: 

§ 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 § 457.730 as if 

such requirements applied directly to 

the MCO, PIHP, or PAHP, and include: 

* * * * * 

(ii) Reporting metrics specified at 

§ 457.730(h) at the plan level. 

(3) Except for § 457.760(d), 

implement, by January 1, 2021, and 

maintain a publicly accessible 

standards-based Provider Directory API 

described at § 457.760 of this chapter, 

which must include all information 

specified in § 438.10(h)(1) and (2) of this 

chapter. The state must require, at a 

minimum, that each MCO, PIHP, and 

PAHP comply with § 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 

§§ 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 

§§ 457.730(b)(5), 457.730(c)(3)(iii), 

457.730(g), and 457.730(h), comply with 

the by the requirements of § 457.730 by 

January 1, 2021. 

(ii) Comply with the requirements at 

§§ 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 § 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 

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

■ 26. Section 156.221 is amended by— 

■ a. Revising paragraph (b)(1)(iii); 

■ b. Adding paragraph (b)(1)(iv); 

■ c. Revising paragraph (c)(3) 

introductory text; 

■ d. Adding paragraph (c)(3)(iii); 

■ e. Revising paragraph (c)(4) 

introductory text, (c)(4)(ii)(C), (e)(2), and 

(f)(1) introductory text; 

■ f. Adding paragraph (f)(2); 

■ g. Redesignating paragraphs (h) and (i) 

as paragraphs (j) and (k); 

■ h. Adding new paragraphs (h) and (i); 

and 

■ i. Revising newly redesignated 

paragraph (j). 

The revisions and addition read as 

follows: 

§ 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 § 170.215(c)(5) for data 

specified at § 156.221(b)(1)(i) and (ii), 

§ 170.215(a)(2) or § 170.215(c)(6) of this 

subchapter for data specified at 

§§ 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, §§ 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 

§§ 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 

§ 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 § 170.213 of 

this subchapter. Such information 

received by a QHP issuer on a Federallyfacilitated 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 § 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 

§ 170.215(c)(5) of this chapter for data 

specified at § 156.221(b)(1)(i) and (ii) 

not including remittances and enrollee 

cost sharing information, § 170.215(a)(2) 

or 170.215(c)(6) of this subchapter for 

data specified at § 156.221(b)(1)(iii), and 

§ 170.215(c)(6) of this subchapter for 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82680 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 thirdparty 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 nonresponse 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 Federallyfacilitated 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 Federallyfacilitated 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 noncompliance 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. 

* * * * * 

■ 27. Section 156.222 is added to read 

as follows: 

§ 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 Federallyfacilitated Exchange must implement 

and maintain a standards-based 

Application Programming Interface 

(API) compliant with § 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 § 170.215(c)(5) of this subchapter for 

data specified at § 156.221(b)(1)(i) and 

(ii), not including remittances and 

enrollee cost sharing information, 

§ 170.215(a)(2) or (c)(6) of this 

subchapter for data specified at 

§ 156.221(b)(1)(iii), and § 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82681 

this section conformant with the 

implementation specification at 

§ 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 standardsbased API specified at § 156.221(f)(2) 

conformant with the implementation 

specification at § 170.215(a)(4) of this 

subchapter to facilitate sharing the data 

specified at § 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 Federallyfacilitated Exchange must make 

available to the other payer the data 

described at § 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. 

■ 28. Section 156.223 is added to read 

as follows: 

§ 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 standardsbased API compliant with § 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 

§ 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 

§ 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 § 172.110(a)(3) 

of this subchapter; 

(ii) That is conformant with the 

implementation specification at 

§ 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 Federallyfacilitated Exchange must include a 

specific reason for a denial in the case 

of a denial with all prior authorization 


khammond on DSKJM1Z7X2PROD with PROPOSALS2
82682 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 

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 Federallyfacilitated 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 noncompliance 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 

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

■ 30. Section 170.215 is amended— 

■ a. By revising the section heading; 

■ b. In paragraph (a), by adding a 

paragraph heading; 

■ c. In paragraph (b), by revising the 

paragraph heading; and 

■ d. By adding paragraph (c). 

The revisions and additions read as 

follows: 

§ 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 § 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 § 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 

§ 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 

§ 170.299). 

(5) Payer data implementation 

specification. HL7 FHIR Consumer 

Directed Payer Data Exchange (CARIN 

IG for Blue Button®) Implementation 

Guide: Version STU 1.0.0 (incorporated 

by reference in § 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 § 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 § 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 

§ 170.299). 

■ 31. Section 170.299 is amended by 

adding paragraphs (f)(35) through (42) to 

read as follows: 

§ 170.299 Incorporation by reference. 

* * * * * 

(f) * * * 

(35) HL7 FHIR® Da Vinci—Coverage 

Requirements Discovery (CRD) 

Implementation Guide, Version STU 

1.0.0, IBR approved for § 170.215(c). 

(36) HL7 FHIR® Da Vinci— 

Documentation Templates and Rules 

(DTR) Implementation Guide, Version 

STU 1.0.0, IBR approved for 

§ 170.215(c). 

(37) HL7 FHIR® Da Vinci—Prior 

Authorization Support (PAS) 

Implementation Guide, Version STU 

1.0.0, IBR approved for § 170.215(c). 

(38) HL7 FHIR® Da Vinci—Payer 

Coverage Decision Exchange (PCDE) 

Implementation Guide, Version STU 

1.0.0, IBR approved for § 170.215(c). 

(39) HL7 FHIR® Consumer Directed 

Payer Data Exchange (CARIN IG for Blue 

Button®) Implementation Guide, 

Version STU 1.0.0, IBR approved for 

§ 170.215(c). 

(40) HL7 FHIR® Da Vinci Payer Data 

Exchange (PDex) Implementation Guide, 

Version STU 1.0.0, IBR approved for 

§ 170.215(c). 

(41) HL7 FHIR® Da Vinci—Payer Data 

Exchange (PDex) US Drug Formulary 

Implementation Guide, Version STU 

1.0.1, IBR approved for § 170.215(c). 

(42) HL7 FHIR® Da Vinci Payer Data 

Exchange (PDex) Plan Net 

Implementation Guide, Version STU 

1.0.0, IBR approved for § 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 


khammond on DSKJM1Z7X2PROD with PROPOSALS2