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

Federal RegisterDec 18, 2020

Ask Donna

What actually matters in this document.

Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

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

Office of the Secretary

45 CFR Parts 156 and 170

[CMS-9123-P]

RIN 0938-AT99

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

AGENCY:

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

ACTION:

Proposed rule.

SUMMARY:

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

DATES:

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

ADDRESSES:

In commenting, please refer to file code CMS-9123-P.

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

Electronically.

You may submit electronic comments on this regulation to

http://www.regulations.gov.

Follow the “Submit a comment” instructions.

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.

By express or overnight mail.

You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-9123-P, Mail Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.

For information on viewing public comments, see the beginning of the

SUPPLEMENTARY INFORMATION

section.

FOR FURTHER INFORMATION CONTACT:

Alexandra Mugge, (410) 786-4457, for general issues related to this rule and CMS interoperability initiatives.

Denise St. Clair, (410) 786-4599, for the API policies, implementation guides (IGs), general issues related to this rule, and CMS interoperability initiatives.

Lorraine Doo, (443) 615-1309, for prior authorization process policies and CMS interoperability initiatives.

Amy Gentile, (410) 786-3499, for issues related to Medicaid managed care.

Kirsten Jensen, (410) 786-8146, for issues related to Medicaid fee for service (FFS).

Cassandra Lagorio, (410) 786-4554, for issues related to the Children's Health Insurance Program (CHIP).

Russell Hendel, (410) 786-0329, for issues related to the Collection of Information and Regulatory Impact Analysis.

Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified Health Plans (QHPs).

SUPPLEMENTARY INFORMATION:

Inspection of Public Comments:

All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. We post all comments received before the close of the comment period on the following website as soon as possible after they have been received:

http://www.regulations.gov.

Follow the search instructions on that website to view public comments. CMS will not post on

Regulations.gov

public comments that make threats to individuals or institutions or suggest that the individual will take actions to harm the individual. CMS continues to encourage individuals not to submit duplicative comments. We will post acceptable comments from multiple unique commenters even if the content is identical or nearly identical to other comments.

Table of Contents

I. Background and Summary of Provisions

A. Purpose

B. Summary of Major Proposals

II. Provisions of the Proposed Rule

A. Patient Access API

B. Provider Access APIs

C. Documentation and Prior Authorization Burden Reduction Through APIs

D. Payer-to Payer Data Exchange on FHIR

E. Adoption of Health IT Standards and Implementation Specifications

III. Requests for Information

A. Request for Information: Methods for Enabling Patients and Providers to Control Sharing of Health Information

B. Request for Information: Electronic Exchange of Behavioral Health Information

C. Request for Information: Reducing Burden and Improving Electronic Information Exchange of Prior Authorization

D. Request for Information: Reducing the Use of Fax Machines

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

IV. Incorporation by Reference

V. Collection of Information

VI. Response to Comments

VII. Regulatory Impact Analysis

Regulations Text

I. Background and Summary of Provisions

A. Purpose

In the May 1, 2020

Federal Register

, we published the first phase of CMS interoperability rulemaking in the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, state Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges and Health Care Providers” final rule (85 FR 25510) (hereinafter referred to as the “CMS Interoperability and Patient Access final rule”).

This proposed rule emphasizes improving health information exchange

and achieving appropriate and necessary access to complete health records for patients, providers, and payers, while simultaneously reducing payer, provider, and patient burden by improving prior authorization processes, and helping to ensure that patients remain at the center of their own care. In this rule, we are proposing to enhance certain policies from the CMS Interoperability and Patient Access final rule, as described below, and add several new proposals to increase data sharing and reduce overall payer, provider, and patient burden through proposed changes to prior authorization practices. “Prior authorization” refers to the process through which a provider must obtain approval from a payer before providing care and prior to receiving payment for delivering items or services. In some programs, this may be referred to as “pre-authorization” or “pre-claim review.” Prior authorization requirements are established by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided rather than undertaking that review for the first time when a post-service request for payment is made.

We are taking an active approach to move participants in the health care market toward interoperability and reduced burden by proposing policies for the Medicaid program; the Children's Health Insurance Program (CHIP); and qualified health plan (QHP) issuers on the individual market Federally-facilitated Exchanges (FFEs).

For purposes of this proposed rule, references to QHP issuers on the FFEs exclude issuers offering only stand-alone dental plans (SADPs). Likewise, we are also excluding QHP issuers only offering QHPs in the Federally-facilitated Small Business Health Options Program Exchanges (FF-SHOPs) from the proposed provisions of this rule. We believe that the proposed standards would be overly burdensome to both SADP and SHOP issuers, as their current enrollment numbers and premium intake from QHP enrollment are unlikely to support the costs of the requirements that this proposed rule would impose, and could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. We note that, in this proposed rule, FFEs include those Exchanges in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though consumers in these states enroll in coverage through

HealthCare.gov

, and QHP issuers in SBE-FPs would not be subject to the requirements in this proposed rule. We encourage states operating Exchanges to consider adopting similar requirements for QHPs on the State-based Exchanges (SBEs).

In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized policies impacting Medicare Advantage organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. The policies finalized in that rule requiring those impacted payers to build and maintain application programing interfaces (APIs) were critical and foundational policies, increasing patient access and data exchange and improving interoperability in health care. In this proposed rule, we are proposing certain policies to expand upon those foundational policies for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. As further addressed later in this section of the preamble, starting with this payer population is a critical first step for these new proposals. For instance, state Medicaid and CHIP FFS programs were excluded from the payer-to-payer data exchange policies finalized in the CMS Interoperability and Patient Access final rule (85 FR 25564 through 25569). In our first phase of interoperability policy, we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs. This proposed rule is a critical step in proposing to require state Medicaid and CHIP FFS programs to similarly exchange patient health information in a more efficient and interoperable way, as discussed in section II.D. of this proposed rule, leveraging the technology and experience gained from implementing the initial set of API policies to these new proposed policies.

“Churn” in health care refers to the movement of patients between payers and in and out of health care coverage. Churn occurs when a patient moves between payer types and plans or dis-enrolls from coverage (voluntarily or involuntarily) for a period of time. Patients enrolled in Medicaid, CHIP, and QHPs in particular may move between and among these payers due to a change in their eligibility status, or a change in the availability of subsidies in the case of QHP enrollees. Medicaid beneficiaries who churn in and out of Medicaid tend to have higher utilization of emergency services. Overall, these patients face more coverage instability than those enrolled in Medicare. Several of the API proposals outlined in this proposed rule would particularly benefit patients enrolled in Medicaid, CHIP, and QHPs by allowing them to retain their health information in an electronic form, and have their health information move with them from payer to payer and provider to provider.

Our authority to regulate Medicaid and CHIP FFS, Medicaid and CHIP managed care, and QHP issuers on the FFEs puts us in a unique position to be able to align policies across these programs to the benefit of patients across the nation. Patients enrolled in these programs may churn from payer to payer within a given program, as well as from program to program. For example, a Medicaid enrollee may change eligibility status for Medicaid and enroll with a QHP issuer and back in a given year. For this reason, our API proposals discussed in the following sections are particularly valuable because they allow patients to maintain an electronic copy of their health information (Patient Access API discussed in section II.A.), share data directly with their providers (Provider Access API discussed in section II.B. of this proposed rule), and to bring their health information with them as they move from one payer to another (Payer-to-Payer API discussed in section II.D.), which is especially valuable to patients covered by Medicaid and QHPs who experience churn both within and between programs, and may also experience churn in and out of coverage.

While we are not making any proposals for MA organizations at this time, we acknowledge that payers with multiple lines of business may choose to implement these polices for their MA lines of business to support better internal alignment as well as to create more efficiencies and transparency for their patients. Neither the provisions in the CMS Interoperability and Patient Access final rule nor the proposed provisions here would preclude any payer from implementing these proposed policies regardless of whether the payer is directly impacted by the rule. We believe aligning these policies across all payers would benefit all payers alike. However, we do not believe our approach to start with state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs will have a negative impact on patients. We believe these policies would provide a net benefit to these patients, bringing these programs closer in alignment with one another. We are aware that these proposals, if finalized,

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

A patient's personal representative could address policies in this proposed rule that require a patient's action.

See OCR guidance regarding personal representatives at

https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html

and

https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html.

We also use terms such as “payer”, “plan”, and “issuer” in this proposed rule. Certain portions of this proposed rule are applicable to state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans (managed care organizations (MCOs)), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. We use the term “payer” in the preamble of this proposed rule as an inclusive term for all these programs and (in the case of plans) plan types, but we also use specific terms as applicable in sections of this proposed rule.

We reference “items and services” when discussing prior authorization. Throughout this proposed rule, when we discuss “items and services,” this does not include prescription drugs and/or covered outpatient drugs. We did not include information about prescription drugs and/or covered outpatient drugs in any of the proposals in this rule.

Finally, we use the terms “provider” and “supplier” too, as inclusive terms comprising individuals, organizations, and institutions that provide health services, such as clinicians, hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment (such as portable X-ray services), community based organizations, etc., as appropriate in the context used.

B. Summary of Major Proposals

To drive interoperability, improve care coordination, reduce burden on providers and payers, and empower patients, we are proposing several initiatives that would impact state Medicaid FFS programs, Medicaid managed care plans, state CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs. We are also including several Requests for Information (RFIs) to gather information that may support future rulemaking or other initiatives. As with the CMS Interoperability and Patient Access rulemaking, our proposals provide for program requirements to cross-reference technical specifications in HHS regulations codified at 45 CFR part 170; in this rule, ONC is proposing the adoption of certain specified implementation guides (IGs) needed to support the proposed new API policies we are proposing here for impacted payers.

In the CMS Interoperability and Patient Access final rule, we required certain payers to implement and maintain standards-based Patient Access and Provider Directory application programming interfaces (APIs).

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

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

In this proposed rule, we are proposing to enhance the Patient Access API for impacted payers by requiring the use of specific IGs, proposed for adoption by ONC on behalf of HHS, and by proposing payers include information about pending and active prior authorization decisions. In addition, we are proposing to require that impacted payers establish, implement, and maintain a process to facilitate requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. We are also proposing to require these impacted payers to report certain metrics about patient data requests via the Patient Access API quarterly to CMS. In addition, we are proposing to require use of a specific IG for the Provider Directory API. And, we are proposing to extend the patient-initiated Payer-to-Payer Data Exchange requirements to state Medicaid and CHIP FFS programs.

We also propose to enhance and expand the Payer-to-Payer Data Exchange, and to require this exchange be conducted via a specified Health Level Seven International® (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

FHIR Bulk Data Access (Flat FHIR) specification, to support exchanging patient data including but not limited to: Adjudicated claims and encounter data (not including cost information), clinical data as defined in the USCDI, and information related to pending and active prior authorization decisions.

To better facilitate the coordination of care across the care continuum and in support of a move to value-based care, we are proposing to require that impacted payers implement and maintain a Provider Access API that, consistent with the APIs finalized in the Interoperability and Patient Access final rule (85 FR 25510), utilizes HL7 FHIR version 4.0.1 to facilitate the exchange of current patient data from payers to providers, including adjudicated claims and encounter data (not including cost information), clinical data as defined in the USCDI, and information related to pending and active prior authorization decisions.

In an effort to improve patient experience and access to care, we are proposing several policies associated with the prior authorization process that may ultimately reduce burden on patients, providers, and payers. As described in the CMS Interoperability and Patient Access proposed rule published on March 4, 2019 (84 FR 7610, 7613), we partnered with industry stakeholders to build a FHIR-based web service that would enable providers to search documentation and prior authorization requirements for Medicare FFS directly from their electronic health records (EHRs). This has significant potential to decrease the burden associated with providers determining which items and services need a prior authorization and what documentation is needed to submit the prior authorization request. And, this could reduce burden on payers who would receive fewer incomplete prior authorization requests and fewer denied and appealed requests simply as the result of missing or incorrect documentation. In this second phase of interoperability proposals, we are proposing to require impacted payers to implement and maintain a similar prior authorization Documentation Requirement Lookup Service (DRLS) API. To further streamline the process of submitting a prior authorization request, and reduce processing burden on both providers and payers, we are also proposing to require impacted payers to implement and maintain a FHIR-based Prior Authorization Support (PAS) API that would have the capability to accept and send prior authorization requests and decisions, and could be integrated within a provider's workflow, while maintaining alignment with, and facilitating the use of, HIPAA transaction standards. Provider use of the PAS API would be voluntary and payers may maintain their existing methods for processing prior authorization requests.

We are also proposing several policies that would require impacted payers, with the exception of QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. And, we are proposing that impacted payers publicly report certain metrics about prior authorization processes for transparency.

Finally, on behalf of HHS, the Office of the National Coordinator for Health IT (ONC) is proposing to adopt the implementation specifications described in this regulation at 45 CFR 170.215—Application Programming Interfaces—Standards and Implementation Specifications as standards and implementation specifications for health care operations. ONC is proposing these implementation specifications for adoption by HHS as part of a nationwide health information technology infrastructure that supports reducing burden and health care costs and improving patient care. By ONC proposing these implementation specifications in this way, CMS and ONC are together working to ensure a unified approach to advancing standards in HHS that adopts all interoperability standards in a consistent manner, in one location, for HHS use. Once adopted for HHS use, these specifications would facilitate implementation of the proposed API policies in this rule if finalized.

Although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement these proposed provisions, if finalized. In this way, the Medicare implementations would conform to the same requirements that apply to the impacted payers under this rulemaking, as applicable, so that Medicare FFS beneficiaries would also benefit. And, we encourage other payers not directly impacted by this rule to join us in moving toward reduced burden and greater interoperability.

We are also including several RFIs to gather information that may support future rulemaking or other initiatives. Specifically, we are seeking input for potential future rulemaking on whether patients and providers should have the ability to selectively control the sharing of data in an interoperable landscape. We request comment on whether patients and/or providers should be able to dictate which data elements from a medical record are shared when and with whom.

We are additionally seeking comment on how CMS might leverage APIs (or other solutions) to facilitate electronic data exchange between and with behavioral health care providers, and also community based organizations, who have lagged behind other provider types in adoption of EHRs.

We are also seeking comment on how to reduce barriers, and actively encourage and enable greater use of electronic prior authorization, particularly among providers who could benefit most by being able to engage in the prior authorization process directly from their workflows. And, we request comment specifically on including an Improvement Activity under the Merit-based Incentive Payment System (MIPS) to support the use of the Prior Authorization Support (PAS) API.

We are continually looking for ways to facilitate efficient, effective, and secure electronic data exchange to help ensure timely, better quality, and highly coordinated care. We believe one way to do this is to generally reduce or eliminate the use of facsimile (fax) technology across CMS programs, as possible and appropriate. The use of fax technology limits the ability of the health care sector to reach true interoperability. To work toward this goal and enable electronic data exchange, we request information on how CMS can reduce or eliminate the use of fax technology across programs where fax technology is still in use.

Finally, we request information on barriers to adopting standards, and opportunities to accelerate adoption of standards, related to social risk data. We recognize that social risk factors (for example, housing instability and food insecurity) influence patient health and health care utilization. In addition, we understand that providers in value-based arrangements rely on comprehensive, high-quality social risk data. Given the importance of these data, we look to understand how to better standardize and liberate these data.

II. Provisions of the Proposed Rule

A. Patient Access API

1. Background

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

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;

HL7 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/carin-bb/history.html.

• 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 International. (n.d.). US Core Implementation Guide (FHIR IG) Publication (Version) History. Retrieved from

http://hl7.org/fhir/us/core/history.html.

HL7 International. (n.d.). Da Vinci Payer Data Exchange (FHIR IG) Publication (Version) History. Retrieved from

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

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

HL7 International. (n.d.). US Drug Formulary (FHIR IG) Publication (Version) History. Retrieved from

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

On this website, we explain how these IGs can help payers meet the requirements of the final rule efficiently and effectively in a way that reduces burden on them and ensures patients are getting timely access to their health information in a way that they can best make use of these data so that they can make informed decisions about their health. Although these IGs were available for payers and third-party app vendors, we did not require payers to use these IGs in the CMS Interoperability and Patient Access final rule. We did not specifically propose these IGs for possible finalizing in the final rule as general practice had been to include such information in sub-regulatory guidance. However, the June 3, 2019

Azar

Allina Health Services,

139 S. Ct. 1804 (2019) decision held that under section 1871 of the Act, CMS must undertake notice-and-comment rulemaking for any rule, requirement, or other statement of policy that establishes or changes a “substantive legal standard” for the Medicare Program. IGs are considered a “substantive legal standard” per this decision. As such, we are now officially proposing to finalize these IGs through notice-and-comment rulemaking to ensure that all impacted payers are using these IGs in order to support true interoperability. If these IGs remain optional, there is a chance that the required APIs could be built in such a way that creates misalignment between and among payer APIs and with third-party apps. For example, where there is optionality in the technical build of the API, if that optionality is interpreted differently by the payer and a third-party app, that app may be unable to access and use the data as needed. By removing this optionality in the technical implementation, we better ensure that the APIs can support true interoperability and facilitate the desired data exchange. Additionally, as these same IGs are proposed for use for other APIs proposed in this rule, it would mean that providers (see section II.B. of this proposed rule) and payers (see section II.D. of this proposed rule) would also not be able to access and use the data as needed if misalignment is introduced during implementation. Proposing these IGs be required removes the current optionality resulting from only suggested use of the IGs, which could be a barrier to interoperability.

We are proposing to require these specific IGs for the Patient Access API, by amending 42 CFR 431.60(c)(3)(iii) for state Medicaid FFS programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS programs, and 45 CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs. These requirements would be equally applicable to Medicaid managed care plans and CHIP managed care entities based on cross-references to the state Medicaid and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. If finalized, beginning January 1, 2023, impacted payers would be required to ensure their APIs are

conformant with these IGs (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). The CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary IG are proposed for HHS use at 45 CFR 170.215(c). The US Core IG was adopted by HHS at 45 CFR 170.215(a)(2) in the ONC 21st Century Cures Act final rule.

We recognize that while we have proposed to require compliance with the specific IGs noted above, the need for continually evolving IGs typically outpaces our ability to amend regulatory text. Therefore, we propose to amend 431.60(c)(4), 438.242(b)(5), 457.730(c)(4), 457.1233(d)(2), and 45 CFR 156.221(c)(4) to provide that, if finalized, regulated entities would be permitted to use an updated version of any or all IGs proposed for adoption in this rule if use of the updated IG does not disrupt an end user's ability to access the data through any of the specified APIs discussed in this rule. This would then amend the process to allow payers to use new standards as they are available, as we finalized in the CMS Interoperability and Patient Access final rule to these proposed IGs.

In making these proposals, we note that these IGs are publicly available at no cost to a user (see section IV. of this proposed rule for more information). All HL7 FHIR IGs are developed through an industry-led, consensus-based public process. HL7 is an American National Standards Institute (ANSI)-accredited standards development organization. HL7 FHIR standards are unique in their ability to allow disparate systems that otherwise represent data differently and speak different languages to exchange such information in a standardized way that all systems can share and consume via standards-based APIs. HL7 FHIR IGs are also open source, so any interested party can go to the HL7 website and access the IG. Once accessed, all public comments made during the balloting process as well as the IG version history are available for review. In this way, all stakeholders can fully understand the lifecycle of a given IG. Use of IGs developed through such a public process would facilitate a transparent and cost-effective path to interoperability that ensures the IGs are informed by, and approved by, industry leaders looking to use technology to improve patient care.

We request comment on these proposals.

We finalized in the CMS Interoperability and Patient Access final rule that the Patient Access API at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) must make available clinical data, including laboratory results. We specified at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and 457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i) that such clinical data must comply with the content and vocabulary standards at 45 CFR 170.213, which is the USCDI version 1. Through a cross-reference to 45 CFR 170.215(a)(2) and (c)(6), at 42 CFR 431.60(c)(3)(iii) for state Medicaid FFS programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS programs, and 45 CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs, we propose that payers would be allowed to conform with either the US Core IG or the PDex IG to facilitate making the required USCDI data available via the Patient Access API. In section II.E. of this proposed rule, ONC, on behalf of HHS, proposes to adopt the PDex IG at 45 CFR 170.215(c)(6); currently, the US Core IG is adopted at 45 CFR 170.215(a)(2). These proposed new requirements to conform with either IG would be equally applicable to Medicaid managed care plans and CHIP managed care entities based on cross-references to the state Medicaid and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. When we first finalized the CMS Interoperability and Patient Access final rule and suggested IGs payers could use to implement the APIs, we only suggested the US Core IG; however, some payers informed us that they preferred to leverage the PDex IG because it offered additional resources for payer-specific use cases and was compatible with the US Core IG ensuring interoperable data regardless of which IG was used (see

https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index

for additional information). We seek comment on the pros and cons of requiring the use of either one of these IGs or if only one of the two proposed IGs should ultimately be required and why.

b. Additional Information

In addition to enhancing the Patient Access API by proposing to require that the API be conformant with the specified IGs, we are also proposing to require that information about prior authorization decisions be made available to patients through the Patient Access API in addition to the accessible content finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559). The primary goal of the Patient Access API is to give patients access to and use of their health information. By ensuring patient access to this additional information, we intend to help patients be more informed decision makers and true partners in their health care.

In section II.C. of this proposed rule, we advance a number of proposals focused on making the prior authorization process less burdensome for payers and providers, and in turn, avoiding care delays for patients, which we anticipate would also improve patient outcomes. Patients can only truly be informed if they understand all aspects of their care. We believe that more transparency would help ensure that patients better understand the prior authorization process. By having access to their pending and active prior authorization decisions via the Patient Access API, a patient could see, for instance, that a prior authorization is needed and has been submitted for a particular item or service, and might better understand the timeline for the process and plan accordingly. If a patient can see the supporting documentation shared with their payer they might better understand what is being evaluated and even potentially help providers get the best and most accurate information to payers to facilitate a successful prior authorization request, thus potentially avoiding unnecessary delays in care and reducing burden on providers and payers. As a result, we are proposing to require impacted payers to provide patients access to information about the prior authorization requests made on their behalf through the Patient Access API. Specifically, we are proposing at 431.60(b)(5) for state Medicaid FFS programs, at 438.242(b)(5) for Medicaid managed care plans, at 457.730(b)(5) for state CHIP FFS programs, at 457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(b)(1)(iv) for QHP issuers on the FFEs to require these payers to make available to patients information about any pending and active prior authorization decisions (and related clinical documentation and forms) for items and services via the Patient Access API conformant with the HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG no later than one (1) business day after a provider initiates a prior authorization request or there is a change of status for the prior authorization. We believe one (1) business day is appropriate because in order for patients to have true transparency into the process, they need to see the information timely. As discussed more in section II.C. of this proposed rule, we are proposing expedited prior authorization

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

HL7 International. (n.d.). Da Vinci Payer Data Exchange (FHIR IG) Publication (Version) History. Retrieved from

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

By “active prior authorization decisions,” we mean prior authorizations that are currently open and being used to facilitate current care and are not expired or no longer valid. By “pending prior authorization decisions,” we mean prior authorizations that are under review, either pending submission of documentation from the provider, or being evaluated by the payer's medical review staff, or for another reason have not yet had a determination made. As discussed in section I.B. of this proposed rule, for the purposes of this rule, when we say “items and services,” we are talking about items and services excluding prescription drugs and/or covered outpatient drugs. And, “status” of the prior authorization means information about whether the prior authorization is approved, denied, or if more information is needed to complete the request. We also note that the required information and documentation through the API would include the date the prior authorization was approved, the date the authorization ends, the units and services approved, and those used to date.

Similarly, as further discussed in section II.B. of this proposed rule, we are proposing to require impacted payers to share the same information about prior authorization decisions with a patient's provider via the Provider Access API upon a provider's request, and, in section II.D. of this rule, we are proposing that the same information about prior authorization decisions be made available via the Payer-to-Payer API. In this way, if a patient authorizes their new payer to access data from their old payer, this data exchange would include information about pending and active prior authorizations, if such information is applicable.

We did not include information about denied or expired prior authorization decisions in this proposed requirement because this could result in a significant amount of information being shared that may or may not be clinically relevant at the moment in time the data are exchanged. Pending and active prior authorizations are much more likely to be clinically relevant and important for patients, providers, and payers to know in order to support treatment and care coordination, as well as efficient and effective payer operation that can lead to the best possible outcomes for patients. We do note that if a prior authorizations is “pending,” and the status changes to “denied,” that information would be shared as a “change in status.” As a result, a patient would have access to that information via the API per this proposal.

We anticipate that requiring payers to share prior authorization information through the Patient Access API, with their patient's approval and at their direction, might help patients better understand the items and services that require prior authorization, the information being considered and specific clinical criteria being reviewed to determine the outcome of that prior authorization, and the lifecycle of a prior authorization request. This proposed requirement could provide patients with an opportunity to better follow the prior authorization process and help their provider and payer by producing missing documentation or information when needed. The proposed requirement might also help to reduce the need for patients to make repeated calls to the provider and payer to understand the status of a request, or to inquire why there is a delay in care. We therefore believe this proposal would help give patients more agency in their health care journey and reduce burden on both the providers and the payers working through prior authorization requests, allowing them to more simply and efficiently administer the prior authorization process. As with all information being made available via the Patient Access API, we believe industry is in the best position to develop applications, or apps, that patients can use to most effectively use this information, and we look to innovators in industry to produce apps that would help patients understand this information and access it in a way that is useful to them.

In addition, we believe it would be highly valuable for payers to share pending and active prior authorization decisions with providers, as proposed in section II.B. of this proposed rule, and other payers, as proposed in section II.D. of this proposed rule. Currently, providers know which prior authorizations they have initiated for a patient, but they may not be able to see pending and active prior authorizations other providers have outstanding or in place for the patient. Having this information could support care coordination and more informed decision making. Additionally, if a new payer has information from a previous payer about pending and active prior authorization decisions, it could support improved care coordination and continuity of care, also potentially improving patient outcomes.

We request comment on this proposal.

We also request comment for possible future consideration on whether or not impacted payers should be required to include information about prescription drug and/or covered outpatient drug pending and active prior authorization decisions with the other items or services proposed via the Patient Access API, the Provider Access API, or the Payer-to-Payer API. We did not include information about prescription drugs and/or covered outpatient drugs in any of the proposals in this rule. However, we are interested in better understanding the benefits and challenges of potentially including drug information in future rulemaking. For example, what specific considerations should we take into account? Are there unique considerations related to the role Pharmacy Benefit Managers (PBMs) play in this process? Overall, we do think it would be very valuable to payers, providers, and patients to have information about a patient's prescription drug and/or covered outpatient drug pending and active prior authorization decisions, and we would like to better understand how to most efficiently and effectively consider including this information in these API provisions in the future.

c. Privacy Policy Attestation

As we discussed in detail throughout the CMS Interoperability and Patient Access final rule, one of the most important aspects of unleashing patient data is protecting the privacy and security of patient health information, especially appreciating that once a patient's data is received by a third-party app, it is no longer protected under HIPAA. Throughout the final rule, we noted the limitations to our authority to directly regulate third-party applications. We previously finalized a provision that payers could deny Patient Access API access to a third-party app that a patient wished to use only if the payer determined that such access would pose a risk to the PHI on their system. See 42 CFR 422.119(e) for Medicare Advantage organizations, 431.60(e) for state Medicaid FFS programs, 438.242(b)(5) for Medicaid managed care plans, 457.730(e) for state CHIP FFS programs, and 45 CFR 156.221(e) for QHP issuers on the FFEs.

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.

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.

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

At a minimum, we propose that the requested attestation include whether:

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

Plain Language Action and Information Network. (2011, May). Federal Plain Language Guidelines. Retrieved from

https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf.

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

See

https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.

See

https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.

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

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,

would help patients be as informed as possible. Therefore, we propose that the payer must include information about the specific content of their privacy policy provisions included in the attestation in the required enrollee resources. The enrollee resources must also include, at a minimum, the timeline for the attestation process, the method for informing enrollees about the app developer's attestation response or non-response. The enrollee resources would also have to include the enrollee's role and rights in this process, such as what actions the enrollee may take when a payer informs the enrollee about the status of the attestation, and information about an enrollee's right to access their data via a third-party app of their choice no matter what the status of the attestation request is. Together, this privacy policy attestation framework and the requirement for payers to provide patients with educational resources would help ensure a more secure data exchange environment and more informed patients. And, this would help build patient trust in apps, therefore encouraging them to take advantage of this opportunity to access their health information through a third-party app.

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

Privacy and security remain a critical focus for CMS, and we look forward to continuing to work with stakeholders to keep patient privacy and data security a top priority. Accordingly, we request comment on additional content requirements for the attestation that impacted payers must request and additional required enrollee resources that impacted payers must make available related to the attestation in this proposal. We are particularly interested in hearing feedback on how best to engage available industry-led initiatives, as well as the level of flexibility payers think is appropriate for defining the process for requesting, obtaining, and informing patients about the attestation. For instance, would payers prefer that CMS require the specific types of communication methods payers can use to inform patients about the attestation result, such as via email or text or other electronic communication only? How should CMS account for third-party solutions that present a list of apps that have already attested? In this situation a payer would not need to take action for these apps, but would need to have a process in place for apps not included on such a list.

We also request comment on whether the request for the app developer to attest to certain privacy provisions should be an attestation that all provisions are in place, as it is currently proposed, or if the app developer should have to attest to each provision independently. We wish to understand the operational considerations of an “all or nothing” versus “line-item” approach to the attestation for both the app developers and the payers who would have to communicate this information to patients. And, we wish to understand the value to patients of the two possible approaches.

We request comment on the proposal to require impacted payers to request a privacy policy attestation from third-party app developers.

d. Patient Access API Metrics

We are proposing to require impacted payers to report metrics about patient use of the Patient Access API to CMS.

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

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

Specifically, we propose that these payers report quarterly:

• 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

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.

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.

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

e. Patient Access API Revisions

We note that to accommodate the proposed requirements regarding the use of the Patient Access API, we are proposing two minor changes to the requirements finalized in the CMS Interoperability and Patient access final rule.

First, we are proposing to revise language about the clinical data to be made available via the Patient Access API 42 CFR 431.60(b)(3) for state Medicaid FFS programs, 42 CFR 457.730(b)(3) for state CHIP FFS programs, and 45 CFR 156.221(b)(1)(iii) for QHP issuers on the FFEs. In the CMS Interoperability and Patient Access final rule, these specific provisions require payers to make available “clinical data, including laboratory results.” We are proposing to revise these paragraphs to read, “clinical data, as defined in the USCDI version 1.” Lab results are part of the USCDI, and clinical data were operationalized as the USCDI version 1 under the “technical requirements” where the content standard at 45 CFR 170.213 is adopted. Specifically calling out the USCDI here would help avoid unnecessary confusion, as it would be explicitly noted that the clinical data that must be available through the Patient Access API is the USCDI version 1 data elements.

Second, we are proposing to revise the language previously finalized for denial or discontinuation of access to the API to require that the payer make such a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which

parties

seek EHI. We are proposing to change the terms “enrollees” and “beneficiaries” to “parties” as we are proposing to apply this provision to the Provider Access API, Payer-to-Payer API, and the prior authorization APIs discussed further in sections II.B., II.C., and II.D. of this proposed rule. As other parties may be accessing these APIs, such as providers and payers, we believe it is more accurate to use the term “parties” rather than “enrollees” or “beneficiaries.” We are proposing these revisions 431.60(e)(2), 457.730(e)(2), and 45 CFR 156.221(e)(2).

We request comment on these proposals.

Although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement the provisions, if finalized. In this way, the Medicare FFS implementation would conform to the same requirements that apply to the impacted payers under this rulemaking, so that Medicare FFS beneficiaries would also benefit from this data sharing. CMS started to liberate patients' data with Blue Button 2.0, which made Parts A, B, and D claims data available via an API to Medicare beneficiaries. In an effort to align with the API provisions included in the CMS Interoperability and Patient Access final rule, we are updating the Blue Button 2.0 API to FHIR R4, and will begin use of the CARIN IG for Blue Button.

If the provisions in this rule are finalized, we will work to align and enhance Blue Button accordingly, as possible.

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

f. Provider Directory API Implementation Guide

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

Currently, because QHP issuers on the FFEs are already required to make provider directory information available in a specified, machine-readable format, the Provider Directory API proposal does not include QHP issuers.

HL7 International. (n.d.). Da Vinci Payer Data Exchange PlanNet (FHIR IG) Publication (Version) History. Retrieved from

http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.

Available at

http://cmsgov.github.io/QHP-provider-formulary-APIs/developer/index.html.

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

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

or Medicaid managed care plan to a third-party app at their request. This attestation process is expected to help a beneficiary or enrollee better understand how their data would be used, and what they can do to further control how and when their data is shared by other entities associated with the app. Taking additional steps to protect patient privacy and security would help to ensure that the Medicaid program, whether through FFS or managed care, is providing Medicaid-covered care and services in a manner consistent with the best interests of beneficiaries and enrollees. In this way, it is within our authority under section 1902(a)(19) of the Act to propose to require this privacy policy attestation.

We are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS quarterly. We believe that having these metrics would support CMS' oversight, evaluation, and administration of the Medicaid program, as it would allow us to evaluate beneficiary and enrollee access to the Patient Access API. Use of the API could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended. Section 1902(a)(6) of the Act authorizes CMS to request reports in such form and containing such information as the Secretary from time to time may require. These metrics would serve as a report to evaluate the implementation and execution of the Patient Access API.

For CHIP, we propose these requirements under the authority in section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the proposed requirements increase access to patient data, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination across different sources of health benefits coverage.

As discussed above for Medicaid programs, requiring that the APIs finalized in the CMS Interoperability and Patient Access final rule, as well as those APIs proposed in this rule, be conformant with specific IGs would support program efficiency. By ensuring that these APIs are implemented in a consistent, standardized way, use of the IGs is expected to help support patient, provider, and payer access to data they can best use to make informed decisions, support care coordination, and for the state, support efficient operations.

We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP enrollees' prior authorization data and other standardized data available through standards-based APIs would ultimately lead to these enrollees accessing that information in a convenient, timely, and portable way. This improved access would help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a). We believe making patient data available in this format would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including CHIP. Allowing beneficiaries or enrollees easy and simple access to certain standardized data can also facilitate their ability to detect and report fraud, waste, and abuse—a critical component of an effective program.

These proposals align with section 2101(a) in that they also improve the efficiency of CHIP programs. For example, adding information about pending and active prior authorization decisions to the Patient Access API allows beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This allows patients to make scheduling decisions, and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, ultimately streamlining the prior authorization process.

Additionally, proposing to require the CHIP programs (FFS and managed care) to put a process in place to ask third-party app developers to attest to whether they have certain privacy provisions in place would allow CHIP to provide services in a way that is in the beneficiary's best interest by providing additional information to them about how they can best protect the privacy and security of their health information.

Finally, proposing to require state CHIP agencies and CHIP managed care plans report Patient Access API metrics to CMS quarterly would help states and CMS understand how this API can be used to continuously improve the effectiveness and efficiency of state CHIP operations by providing information about its use, which is an indication of the effectiveness of the API. The more we understand about the use of the Patient Access API, the better we can assess that the API is leading to improved operational efficiencies and providing information to beneficiaries in a way that supports their best interests.

Regarding the requiring the use of the PlanNet IG for the Provider Directory API under CHIP, we note that 42 CFR 457.1207 requires CHIP managed care entities to comply with the provider directory (and other information disclosure) requirements that apply to Medicaid managed care plans under 42 CFR 438.10.

b. QHP Issuers on the FFEs

For QHP issuers on the FFEs, we propose these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates.

Existing and emerging technologies provide a path to make information and resources for health care and health care management universal, integrated, equitable, more accessible, and personally relevant. Requiring the APIs discussed in this rule, including the Patient Access API, the Provider Access API, the DRLS API, the PAS API, and the Payer-to-Payer API be conformant with specific IGs would permit QHP issuers on the FFEs to meet the proposed requirements of this rulemaking efficiently by simplifying the process of implementing and maintaining each API, including preparing the needed information to be shared via each specific API, and ensuring data, and ultimately services, are provided to enrollees as quickly as possible. These IGs, by further ensuring that each API is built and implemented in a consistent and standardized way, transmitting data that are mapped and standardized as expected by both the sending and receiving parties, would further increase the efficiency of the APIs. It would help ensure that the data sent and received are usable and valuable to the end user, whether that is the patient looking to have timely access to their records or the provider or payer looking to ensure efficient care and increased care coordination to support the timely administration of services. This could add significant operational efficiencies for QHP issuers on the FFEs. This would help each proposed policy be most effective, the API solutions to be truly interoperable, and for QHP issuers on the FFEs to meet

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

See, Office for Civil Rights. (2013, July 26). Uses and Disclosures for Treatment, Payment, and Health Care Operations (45 CFR 164.506). Retrieved from

https://www.hhs.gov/hipaa/for-professionals/

privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html.

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.

See 45 CFR 162.923(a).

In this section, we propose to require that certain payers implement a standards-based Provider Access API that makes patient data available to providers both on an individual patient basis and for one or more patients at once using a bulk specification, as permitted by applicable law, so that providers could use data on their patients for such purposes as facilitating treatment and ensuring their patients receive better, more coordinated care. As noted, the HIPAA Privacy Rule generally permits HIPAA covered entities to use and disclose PHI for these purposes without need of an individual's authorization.

However, under other federal, state, local, or tribal laws (for example, the “part 2” regulations addressing substance use disorder data at 42 CFR part 2), payers and providers may need to obtain some specified form of patient consent to request or disclose behavioral health, certain substance use disorder treatment, or other sensitive health-related information, or they may have to use specified transactions to carry out certain defined data transfers between certain parties for specific purposes. We note these proposals do not in any way alter a payer's or a provider's obligations under all existing federal, state, local, or tribal laws.

See 45 CFR 164.506.

3. Proposed Requirements for Payers: Provider Access API for Individual Patient Information Access

In the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559), we required impacted payers to make certain health information available to third-party apps with the approval and at the direction of a patient though the Patient Access API for patient use. We believe there would be value to providers having access to the same patient data through a FHIR-based API that allows the provider to request data for a single patient as needed. And, we recognize that the impacted payers under this proposed rule will have largely prepared the necessary infrastructure and implemented the FHIR standards to support the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) by January 1, 2021 (for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2021). As a result, we are now proposing to require impacted payers to implement a Provider Access API.

Both this proposed Provider Access API and the Patient Access API would facilitate the FHIR-based exchange of claims and encounter data, as well as the same set of clinical data as defined in the USCDI version 1, where such clinical data are maintained by the payer, and formulary data or preferred drug list data, where applicable. Both APIs also require the sharing of pending and active prior authorization decisions (and related clinical documentation and forms) for items and services. One difference is that the Provider Access API would not include remittances and beneficiary cost-sharing information. Another key difference is that in the case of the Provider Access API proposals, the provider, not the patient, requests and ultimately receives the patient's information, and would typically make such a request for treatment or care coordination purposes. Where a patient would receive this data via a third-party app for use on a mobile device, in the case of the Provider Access API, the provider would receive the data directly from the payer and incorporate it into their EHR or other practice management system.

Through a proposed cross-reference to the Patient Access API requirements, the Provider Access API also requires adherence to the same technical standards, API documentation requirements, and discontinuation and denial of access requirements. For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526 through 25550) and to section II.A. of this proposed rule.

We are proposing two approaches to the Provider Access API. First, we are proposing a Provider Access API that allows providers to have access to an individual patient's information. Second, we are proposing that the Provider Access API allow access to multiple patients' information at the same time; this is discussed in section II.B.5. of this proposed rule. The individual request approach may be better suited for situations such as, but not limited to, when the provider needs “real-time” access to a patient's data prior to or even during a patient visit or for small practices with limited server bandwidth. In these situations, providers may wish to gain access to patient data through an API that yields the data through an individual patient request.

To support this individual patient use case, we are proposing to require state Medicaid and CHIP FFS programs at 42 CFR 431.61(a)(1)(i) and 457.731(a)(1)(i) respectively; and QHP issuers on the FFEs at 45 CFR 156.222(a)(1)(i), to implement and maintain a Provider Access API conformant with the requirements at 45 CFR 170.215, as detailed in section II.A.2. of this proposed rule for the Patient Access API. This proposed Provider Access API would leverage the same IGs in the same way as proposed for the Patient Access API. These requirements would be equally applicable to Medicaid managed care plans and CHIP managed care

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

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

See 42 CFR 438.9(b)(7).

In the context of Medicaid managed care, we are proposing that NEMT PAHPs, as defined at 42 CFR 438.9(a), would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, and non-NEMT PAHPs are subject to this proposed rule. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs is not consistent with the proposed purposes of the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we do not believe that providers have any routine need for NEMT data nor that having NEMT PAHPs implement and maintain a Provider Access API would help achieve the goals of the proposal, namely to help avoid patients needing to recall prior services, ensure that providers are able to spend time with patients focusing on care versus collecting redundant information, or improve patient care through enhanced care coordination. However, we include NEMT PAHPs in the scope of some of our other requirements that apply to all other Medicaid managed care plans under proposed 42 CFR 438.242(b)(5) through (8). Currently, NEMT PAHPs are exempt from compliance with requirements in 42 CFR part 438 unless the provision is listed in § 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.

To better facilitate the coordination of care across the care continuum and in support of a move to value-based care, the BCDA utilizes the HL7 FHIR Bulk Data Access (Flat FHIR) specification to allow us to respond to requests for large amounts of patient-level Medicare FFS claims data on behalf of ACO participating practices.

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.

Centers for Medicare and Medicaid Services. (n.d.). Beneficiary Claims Data API. Retrieved from

https://bcda.cms.gov/.

HL 7 International. (n.d.). FHIR Bulk Data Access (Flat FHIR). Retrieved from

https://hl7.org/fhir/uv/bulkdata/history.html.

In addition, in July 2019, we announced a pilot program called “Data at the Point of Care” (DPC)

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.

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

https://dpc.cms.gov/.

Both BCDA and DPC have started to demonstrate the value of exchanging data on multiple patients at once via FHIR. The HL7 FHIR Bulk Data Access (Flat FHIR) specification can reduce the number of API requests and support a secure connection for third-party application access to specified data stored in EHRs and data warehouse environments.

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.

Office of the National Coordinator, Computational Health Informatics Program, & Boston Children's Hospital. (2017, December 15). The Intersection of Technology and Policy: EHR Population Level Data Exports to Support Population Health and Value. Retrieved from

https://smarthealthit.org/an-app-platform-for-healthcare/meetings/bulk-data-export-meeting-and-report/.

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

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.

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

5. Proposed Requirements for Payers: Bulk Data Provider Access API

We believe that the benefits of data sharing would be greatly enhanced if other payers were sharing health information about their patients with health care providers for multiple patients at once, as CMS is now beginning to do under BCDA and as we are also further testing through the DPC pilot, for instance. As a result, we are proposing a second approach to require impacted payers to implement payer-to-provider data sharing using the HL7 FHIR Bulk Data Access (Flat FHIR) specification—a Bulk Data Provider Access API.

Given the many benefits of giving providers efficient access to their patients' data, and the relative ease of doing so by leveraging the HL7 FHIR Bulk Data Access (Flat FHIR) specification, we are proposing to require that all Medicaid and CHIP FFS programs at 42 CFR 431.61(a)(1)(ii) and 457.731(a)(1)(ii), Medicaid managed care plans at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.222(a)(1)(ii) implement and maintain a standards-based Provider Access API using the HL7 FHIR Bulk Data Access (Flat FHIR) specification at 45 CFR 170.215(a)(4) to allow providers to receive the same information as indicated above for the individual patient request Provider Access API—their patients' claims and encounter data (not including cost information such as provider remittances and enrollee cost-sharing); clinical data as defined in the USCDI version 1, where such clinical data are maintained; and formulary data or preferred drug list data, where applicable; as well as information on pending and active prior authorization decisions. The regulations for Medicaid managed care plans and CHIP managed care entities are cross-referenced and incorporate the regulations we propose for state Medicaid and CHIP FFS programs.

We are proposing that payers would be required to implement this Bulk Data Provider Access API approach for data maintained by the payer with a date of service on or after January 1, 2016, by January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We request public comment on whether this timeline is feasible and whether the benefits would out weight the costs of this Bulk Data Provider Access API proposal.

We understand and acknowledge that payers and developers may view these proposed requirements as burdensome, as they could involve building multiple APIs to share data between payers and providers. We invite public comment on the benefits of having the Provider Access API available with and without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification. As we look to balance providing this flexibility with the burden of potentially implementing and maintaining multiple APIs, we invite input on whether we should require payers to implement just one API that leverages the HL7 FHIR Bulk Data Access (Flat FHIR) specification for when they are requesting data for just one patient, or for more than one patient, or should we finalize as we are proposing here to have payers implement one API solution that does not leverage the Bulk specification for a single patient request (as discussed in section II.B.3. above in this proposed rule), and a second solution that uses the Bulk specification for requests for more than one patient. We believe both proposed functionalities offer necessary benefits to providers depending on the specifics of the situations in which they would need patient data. For example, a large health system or large group practice may benefit from using the bulk specification if it is updating records annually. We also believe that requiring payers to have both API approaches available gives providers flexibility. For example, a provider practicing within a large health system, such as in the example above, may want quick access to a specific patient's information right before that patient's scheduled appointment.

We request comment on this proposal.

States operating Medicaid and CHIP programs may be able to access federal matching funds to support their implementation of this Provider Access API, because the API is expected to help the state administer its Medicaid and CHIP state plans properly and efficiently, consistent with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more detail in section II.B.7.a. of this proposed rule.

We do not consider state expenditures for implementing this proposal to be attributable to any covered item or service within the definition of “medical assistance.” Thus, we would not match these expenditures at the state's regular federal medical assistance percentage. However, federal Medicaid matching funds under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs, because use of the Provider Access API would help ensure that providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately, and in the best interest of the patient, and thus help the state more efficiently administer its Medicaid program.

States' expenditures to implement these proposed requirements might also be eligible for enhanced 90 percent federal Medicaid matching funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent federal matching funds under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement.

States request Medicaid matching funds under section 1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning Document (APD) process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to ensure that any system for which they are receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and incorporates the ONC Health Information Technology standards adopted in accordance with 45 CFR part 170, subpart B. The Provider Access API, and all APIs proposed in this rule, complement this requirement because these APIs further interoperability through the use of HL7 FHIR standards proposed for adoption by ONC for HHS use at 45 CFR 170.215.

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.

See SHO #20-003,

https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.

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

technical documentation publicly available so that systems that need to connect to the APIs proposed in this rule can do so would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the 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.

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.

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

https://dpc.cms.gov/terms-of-service.

We recognize that the payers impacted by this proposed rule have a variety of provider relationships to consider. We are therefore proposing that each payer establish, implement, and maintain for itself, a process to facilitate generating each provider's current patient roster to enable this proposed payer-to-provider data sharing via the Provider Access API.

We are proposing this at 42 CFR 431.61(a)(2) for state Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.61(a)) for Medicaid managed care plans other than non-emergency transportation (NEMT) PAHPs, at 42 CFR 457.731(a) for state CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.731(a)) for CHIP managed care, and at 45 CFR 156.222(a)(2) for QHP issuers on the FFEs. To facilitate this data sharing, it is necessary that providers give payers a list of the patients whose data they are requesting. We do not wish to be overly prescriptive about how to generate this list for all payers. But, we note that it would be necessary for payers to put a process in place that is compliant with existing HIPAA Privacy and Security Rules and provides the information they need to complete their payer-specific compliance processes.

We request comments on this proposal. And, we also seek comment on whether payers would like to maintain the option to define their own process or if they would prefer us to require a process across payers, such as the one we plan to test as part of the DPC pilot.

b. Opt-In

We are proposing that impacted payers would be permitted to put a process in place for patients to opt-in to use of the Provider Access API for data sharing between their payer and their providers. As with the attribution process discussed above, we did not want to be overly prescriptive regarding how this opt-in process might be implemented. However, we are considering whether to suggest a specific process for all payers who choose to implement this opt-in. One possible approach might be for CMS to have all payers engaging in an opt-in approach to include information about the ability to opt-in to this data sharing as part of their annual notice or regular communication with patients—such as when they communicate with patients about claims, and to permit opt-in via a variety of options, including by phone, via a website, or using an app, for instance.

Currently the HIPAA Privacy Rule does not require health plans to obtain patient consent to share data with health care providers for treatment purposes or care coordination, for instance. However, we believe it is important to honor patient privacy preferences, and thus see value in possibly providing patients with options regarding which providers have access to their information as it relates to this proposed policy. We do note, as discussed above, that all existing applicable laws and regulations apply. This opt-in option is only specific to using the Provider Access API as the means to share data that the payer otherwise has authority to share with the provider. Therefore, we are specifically proposing at 42 CFR

431.61(a)(3) for state Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.61(a)(3)) for Medicaid managed care, at 42 CFR 457.731(a)(3) for state CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.731(a)(3)) for CHIP managed care, and at 45 CFR 156.222(a)(3) for QHP issuers on the FFEs that payers may put a process in place to allow a patient to opt-in to the Provider Access API data exchange for each provider from whom they are currently receiving care or are planning to receive care.

We request comment on this proposal. In addition, we seek comment on whether payers would like to maintain the option to define their own process or if they would prefer CMS to suggest a process, such as the examples provided above, for all payers who would be required to implement and maintain the Provider Access API. We do note that we also considered the following alternatives: (1) Permit an opt-out process, (2) default to data sharing without patient engagement in the process consistent with the HIPAA Privacy Rule, and require an opt-out process. We seek comment on whether stakeholders would prefer we finalize an opt-out versus an opt-in approach, and whether either opt-out, or as currently proposed—opt-in, be permitted but not required. We request comment on the associated benefits and burdens with these different approaches, and any other considerations we should take into consideration as we consider a final policy.

c. Provider Resources

We are proposing that payers make educational resources available to providers that describe how a provider can request patient data using the payer's Provider Access APIs in non-technical, simple, and easy-to-understand language. This requirement would be codified at 42 CFR 431.61(a)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.61(a)) for Medicaid managed care other than NEMT PAHPs as defined at 42 CFR 438.2, at 42 CFR 457.731(a)(4) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.731(a)) for CHIP managed care, and at 45 CFR 156.222(a)(4) for QHP issuers on the FFEs. As proposed, this would include information on using both the individual patient request function as well as the bulk data request function. We are proposing that these resources be made available on the payer's website and through other appropriate mechanisms through which the payer ordinarily communicates with providers. We believe these resources would help providers understand how they can leverage the available APIs to access patient data, thus helping to ensure that the full value of the proposed APIs is realized and that providers gain access to needed patient data for use at the moment of care.

We request comment on this proposal.

d. Extensions and Exemptions for Medicaid and CHIP FFS Programs

If our proposals regarding the Provider Access API are finalized, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Provider Access API as soon as possible understanding the many benefits of the API as discussed previously in this section.

However, we also recognize that state Medicaid or CHIP FFS agencies could face certain unique circumstances that would not apply to other impacted payers, as discussed in more detail later in this section. As a result, a few states might need to seek an extension of the compliance deadline or an exemption from these requirements. To address this concern, we are proposing a process through which states may seek an extension of and, in specific circumstances, an exemption from, the Provider Access API requirements if they are unable to implement these API requirements. Providing for these flexibilities might allow these states to continue building technical capacity in support of overall interoperability goals consistent with their needs. We therefore propose the following.

Extension.

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

In all such situations, a state might need more time than other impacted payers to implement the requirements.

State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See:

https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.

If a state believes it can demonstrate the need for an extension, its request must be submitted and approved as a part of its annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations costs and must include the following: (1) A narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to states operating Medicaid or CHIP FFS programs, (2) a report on completed and ongoing implementation activities to evidence a good faith effort toward compliance, and (3) a comprehensive plan to meet implementation requirements no later than one year after the initial compliance date.

An extension would be granted if CMS determines based on the information provided in the APD that the request adequately establishes a need to delay implementation, a good faith effort to implement the proposed requirements as soon as possible, and a clear plan to implement no later than one year after the proposed compliance date. We would expect states to explain why the request for an extension results from circumstances that are unique to states operating Medicaid or CHIP FFS programs. We also solicit comment on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement sufficiently difficult for states and thus justify an extension. In particular, we seek comment on

whether we should require or use additional information on which to base the determination or whether we should establish different standards in the regulation text for evaluating and granting the request.

Exemption.

At 42 CFR 431.61(e)(2) and 42 CFR 457.731(e)(2), respectively, we propose two circumstances that would permit state requests for exemption; namely, (1) when at least 90 percent of all covered items and services are provided to Medicaid or CHIP beneficiaries through Medicaid or CHIP managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or (2) when at least 90 percent of the state's Medicaid or CHIP beneficiaries are enrolled in Medicaid or CHIP managed care organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 for CHIP. In both circumstances, the time and resources that the state would need to expend to implement the API requirements may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries as states, unlike other payers, do not maintain additional lines of business.

We acknowledge that the proposed exemption could mean that a few Medicaid or CHIP FFS systems would not receive the benefits of having this API available to facilitate health information exchange. To address this, we propose that states meeting the above thresholds would be expected to employ an alternative plan to enable the electronic exchange and accessibility of health information for those beneficiaries who are served under the FFS program.

A state meeting the above criteria would be permitted to submit a request for an exemption to the requirements for the Provider Access API once per calendar year for a one (1) year exemption. The state would be required to submit this annual request as part of a state's annual APD for MMIS operations costs. The state would be required to include in its request documentation that it meets the criteria for the exemption using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. We note we propose that this request be made annually as from year-to-year the nature of the FFS population could change and so it is important that the state provide the most current information for CMS' consideration.

Exemptions would be granted for a one-year period if a state establishes to CMS' satisfaction that it meets the criteria for the exemption and has established a plan to ensure that providers will have efficient electronic access to the same information through alternative means.

We request comment on the proposed extension and exemption.

For Medicaid and CHIP managed care, we are not proposing an extension process at this time because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements in 42 CFR part 438 and part 457 and also benefit from efficiencies resulting from their multiple lines of business impacted by these interoperability policies. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or are unachievable by the compliance date. We are soliciting comment on whether our belief concerning the scope of resources and ability of managed care parent organizations to achieve economies of scale is well-founded. Further, we seek comment on whether an extension process is warranted for certain managed care plans to provide additional time for the plan to comply with the requirement at 42 CFR 438.61(a) (which cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans and at proposed 42 CFR 457.731(a) (which cross references 42 CFR 457.1223(d)(4)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary for the reasons outlined here, we are open to considering one if necessary. If we adopt an extension process for these managed care plans and entities, what criteria would a managed care plan or entity have to meet to qualify for an extension? Should the process consider, for example, enrollment size, plan type, or some unique characteristic of certain plans that could hinder their achievement of the proposed requirements by the proposed compliance date? Also, we seek comment on whether, if finalized such a process for Medicaid managed care plans or CHIP managed care entities, the state or CMS should manage the process and whether states could successfully adopt and implement the process on the timeline necessary to fulfill the goals and purposes of the process. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension request to include, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, the impact of non-compliance upon enrollees, the current or proposed means of providing electronic health information to providers, and a corrective action plan with a timeline to achieve compliance.

e. Exception for QHP issuers

For QHP issuers on the FFEs, we propose an exception at 45 CFR 156.222(d) to these Provider Access API proposals. We propose that if an issuer applying for QHP certification to be offered through a FFE believes it cannot satisfy the proposed requirements in 45 CFR 156.222(a) for the Provider Access APIs, the issuer must include as part of its QHP application a narrative justification describing the reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements in 45 CFR 156.222(a) for the Provider Access APIs if it determines that making such health plan available through such FFE is in the interests of qualified individuals in the state or states in which such FFE operates. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the Interoperability and Patient Access final rule (85 FR 25552 through 25553). For instance, as noted in that final rule, that exception could apply to small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standards based API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to consumers, and not certifying the issuer's QHP or QHPs would result in consumers having few

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, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this proposed rule could strengthen states' ability to fulfill these title XXI statutory obligations in a way that recognizes and accommodates the use of electronic information exchange in the health care industry today and would facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries.

When providers have access to patient utilization and authorization information directly from their EHRs or other health IT systems, they can provide higher quality care. Improving the quality of care aligns with section 2101(a), which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient's care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers can be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient versus on their need to collect information. And, the information they do collect will not be based solely on patient recall. As noted above for Medicaid, this could save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider's EHR or practice management system, they can be leveraged as needed at the point of care by the provider, but also be used to support coordination across

providers and payers. This is inherently more efficient, and ultimately, more cost effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API proposals also align with section 2101(a) in that these proposals could improve coordination between CHIP and other health coverage. For these reasons, we believe this proposal is in the best interest of the beneficiaries and within our authorities.

b. QHP Issuers on the FFEs

For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We note statutory authority for proposals to require specific IGs for this and all APIs proposed in this rule are discussed in section II.A.3. of this proposed rule.

We believe that certifying only health plans that make enrollees' health information available to their providers via the Provider Access API is in the interests of enrollees. Giving providers access to their patients' information supplied by QHP issuers on the FFEs would ensure that providers are better positioned to provide enrollees with seamless and coordinated care, and helps to ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patients' more complete medical information may also maximize the efficiency of an enrollee's office visits. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges.

We also believe that requiring QHP issuers on the FFEs to use the Bulk specification for the Provider Access API would improve the efficiency and simplicity of data transfers by allowing the provider to get all the info for a full panel of patients at once.

C. Reducing the Burden of Prior Authorization Through APIs

1. Background

Improving the prior authorization process is an opportunity to reduce burden for payers, providers, and patients. The proposals in this rule build on the foundation set out in the CMS Interoperability and Patient Access final rule to improve health information exchange and increase interoperability in the health care system. Proposals in this section were developed based on industry input from CMS sponsored listening sessions, stakeholder meetings, and reports.

We use the term “prior authorization” to refer to the process through which a provider must obtain approval from a payer before providing care and prior to receiving payment for delivering items or services. In some programs, this may be referred to as “pre-authorization” or “pre-claim review.” Prior authorization requirements are established by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided rather than undertaking that review for the first time when a post-service request for payment is made. However, stakeholders have stated that diverse payer policies, provider workflow challenges, and technical barriers have created an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and a health risk for patients when it causes their care to be delayed.

The policies in this proposed rule would apply to any formal decision-making process by which impacted payers render an approval or disapproval determination, or decision, regarding payment for clinical care based on the payer's coverage guidelines and policies before services are rendered or items provided.

We have been studying prior authorization and its associated burden to identify the primary issues that stakeholders believe need to be addressed to alleviate that burden. To advance the priorities of the 21st Century Cures Act,

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.

ONC Strategy to reduce provider burden. Report required under the 21st Century Cures Act:

https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.

In 2018, the American Medical Association (AMA) conducted a physician survey that indicated a weekly per-physician average of 31 prior authorization requests, consuming an average of 14.9 hours of practice time per workweek for physicians and their staff. Additionally, 36 percent of physicians have staff that work exclusively on prior authorizations.

In 2019, CMS conducted a number of listening sessions with payers, providers, patients, and other industry representatives to gain insight into issues with prior authorization processes and to identify potential areas for improvement. While both providers and payers agreed that prior authorization provides value to the health care system through cost control, utilization management, and program integrity measures, some stakeholders expressed concerns that certain steps in the prior authorization processes are burdensome. For example, the information required from payers to receive prior authorization can be inconsistent from payer to payer, and it can be difficult for providers to determine the rules for items or services that require prior authorization or what documentation is needed to obtain approval. Furthermore, the documentation requirements are not centralized because the rules vary for each payer, and access to those requirements may require the use of proprietary portals. These challenges were described in the ONC 2020 report on reducing electronic health record burdens, which stated, “Each payer has different requirements and different submission methods, and clinicians report finding it burdensome and time-consuming trying to determine whether prior authorization requirements exist for a given patient, diagnosis, insurance plan, or state.”

American Medical Association. (2019, February). 2018 AMA Prior Authorization (PA) Physician Survey. Retrieved from

https://www.ama-assn.org/system/files/2019-02/prior-auth-2018.pdf.

Office of the National Coordinator for Health Information Technology. (n.d.) Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. Retrieved from

https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.

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

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.

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.

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.

American Medical Association. (2018). Consensus Statement on Improving the Prior Authorization Process. Retrieved from

https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc-public/prior-authorization-consensus-statement.pdf.

Office of the National Coordinator for Heal

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.