# Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/fr%3A2022-26479

## Record

- **Collection:** Federal Register
- **Document type:** Proposed Rule
- **Published:** December 13, 2022
- **Citation:** 87 FR 76238

## Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 422, 431, 435, 438, 440, and 457
Office of the Secretary
45 CFR Part 156
[CMS-0057-P]
RIN 0938-AU87
Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program

AGENCY:

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

ACTION:

Proposed rule.

SUMMARY:

This proposed rule would place new requirements on Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) 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 healthcare data and streamline processes related to prior authorization, while continuing CMS' drive toward interoperability in the healthcare market. This proposed rule would also add a new measure for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program and for Merit-based Incentive Payment System (MIPS) eligible clinicians under the Promoting Interoperability performance category of MIPS. These policies taken together would play 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 March 13, 2023.

ADDRESSES:

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

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

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

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

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

3.
By express or overnight mail.
You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0057-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 questions related to any of the policies in this proposed rule, or questions related to CMS interoperability initiatives.

Lorraine Doo, (443) 615-1309, for issues related to the prior authorization process policies, or the Prior Authorization Requirements, Documentation, and Decision (PARDD) Application Programming Interface (API).

Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-Payer API, the Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance category and Medicare Promoting Interoperability Program, or any of the API standards and implementation guides (IGs) included in this proposed rule.

David Koppel, (303) 844-2883, for issues related to the Patient Access API policies, or patient privacy.

Scott Weinberg, (410) 786-6017, for issues related to the Provider Access API policies, or the Requests for Information.

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

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

Joshua Bougie, (410) 786-8117, for issues related to CHIP.

Natalie Albright, (410) 786-1671, for issues related to MA organizations.

Ariel Novick, (301) 492-4309, for issues related to QHPs.

Elizabeth Holland, (410) 786-1309, for issues related to MIPS and the Medicare Promoting Interoperability Program.

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

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:
https://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 and Background

B. Summary of Major Proposals

II. Provisions of the Proposed Rule

A. Patient Access API

B. Provider Access API

C. Payer to Payer Data Exchange on FHIR

D. Improving Prior Authorization Processes

E. Electronic Prior Authorization for the Merit-Based Incentive Payment System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program

F. Interoperability Standards for APIs

III. Requests for Information

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

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

C. Request for Information: Improving the Electronic Exchange of Information in Medicare Fee-for-Service

D. Request for Information: Advancing Interoperability and Improving Prior Authorization Processes for Maternal Health

E. Request for Information: Advancing the Trusted Exchange Framework and Common Agreement (TEFCA)

IV. Collection of Information Requirements

V. Response to Comments

VI. Regulatory Impact Analysis

Regulations Text

I. Background and Summary of Provisions

A. Purpose and Background

In the May 1, 2020,
Federal Register
, we published a final rule implementing the first phase of CMS interoperability rulemaking in the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for MA 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”).

On December 18, 2020, we published a proposed rule (85 FR 82586) (hereinafter referred to as the “December 2020 CMS Interoperability proposed rule”) in which we proposed new requirements for state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS' drive toward interoperability and reducing burden in the healthcare market. In addition, on behalf of the Department of Health and Human Services (HHS), the Office of the National Coordinator for Health Information Technology (ONC) proposed the adoption of certain specified implementation guides (IGs) needed to support the proposed Application Programming Interface (API) policies in that proposed rule.

We received approximately 251 individual comments on the December 2020 CMS Interoperability proposed rule by the close of the comment period on January 4, 2021. While commenters largely supported the intent of the proposals and the proposals themselves, many noted and emphasized that MA organizations were not included among the impacted payers. The National Association of Medicaid Directors and state Medicaid programs expressed concerns about the implementation timeframes, states' constraints to secure the funding necessary to implement the requirements of the rule in a timely manner, and states' ability to recruit staff with necessary technical expertise. Commenters also raised concerns that the relatively short comment period inhibited more thorough analyses of the proposals and, for membership organizations, the ability to receive input from and gain consensus among their members. The December 2020 CMS Interoperability proposed rule will not be finalized; we considered whether to issue a final rule based on that proposed rule, but considering the concerns raised by the commenters, we have opted not to do so. Instead, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. This approach will allow us to incorporate the feedback we have already received and provide additional time for public comment.

Some of the changes we have incorporated in this proposed rule were influenced by the comments we received on the December 2020 CMS Interoperability proposed rule. For example, unlike in that proposed rule, we now propose to require impacted payers to use those health information technology (IT) standards at 45 CFR 170.215 that are applicable to each set of API requirements proposed in this rule, including the HL7 Fast Healthcare Interoperability Resources (FHIR) standard, the HL7 FHIR US Core Implementation Guide, and the HL7 SMART Application Launch Framework Implementation Guide. Also, in this proposed rule, we include MA organizations as impacted payers and propose that the policies included herein would have a longer implementation timeline.

Most of the implementation dates for the proposals included in this proposed rule would begin in 2026, including those for the API proposals, prior authorization decision timeframes for certain impacted payers, and certain reporting proposals. We believe a three-year timeline to recruit and train staff, update or build the APIs, and update operational procedures would be sufficient for these proposals, particularly based on the information we have from some payers and providers regarding similar initiatives already in progress. In addition to the proposed three-year implementation timeframe, we propose to give state Medicaid and CHIP FFS programs an opportunity to seek an extension of proposed implementation deadlines, or an exemption from meeting certain proposed requirements, in certain circumstances. Additionally, we include a proposal to provide an exceptions process for issuers of QHPs on the FFEs. We believe the three-year timeframe would offer sufficient time for these impacted payers to evaluate their qualifications to participate in the API proposals in this proposed rule and to prepare the necessary documentation to request an extension, exemption, or exception.

We are proposing some clarifications to existing Medicaid beneficiary notice and fair hearing regulations which apply to Medicaid prior authorization decisions. Because these are clarifications and improvements to existing regulations, these policies would become effective upon the effective date of a final rule if these proposals are finalized as proposed. We are also proposing terminology changes in section II.A.2.e related to the Patient Access API that would take effect with the effective date of the final rule, should these proposals be finalized as proposed.

We are proposing a new Electronic Prior Authorization measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, which is in direct response to comments we received on the December 2020 CMS Interoperability proposed rule.

We are re-issuing two requests for information (RFIs) that were included in the December 2020 CMS Interoperability proposed rule. We are also issuing three new RFIs: one to solicit information related to opportunities for improving the electronic exchange of medical documentation between providers to support prior authorization programs for Medicare FFS, a second to gather public feedback regarding data standardization and use of prior authorization to improve maternal health care, and a third to solicit comment regarding enabling exchange under the Trusted Exchange Framework and Common Agreement (TEFCA).

With this new proposed rule, we are taking an active approach to move certain participants in the healthcare market toward interoperability by proposing policies for the MA program, Medicaid, CHIP, and QHP issuers on the FFEs, as well as eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS.

Our proposals emphasize improving health information exchange and facilitating appropriate and necessary

patient, provider, and payer access to information in health records. We also include several proposals intended to reduce payer, provider, and patient burden by improving prior authorization processes and helping patients remain at the center of their own care. Prior authorization refers to the process through which a healthcare provider, such as an individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval from a payer before providing care. 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.

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 offering only 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 for both SADP and SHOP issuers. Requiring issuers offering only SADPs and QHPs in the FF-SHOPs, which have relatively lower enrollment and premium intake compared to individual market QHPs, to comply with the proposals in this rule could result in those issuers no longer participating in the FFEs, which would not be in the best interest of the enrollees. The categorical exclusion of these issuers is consistent with CMS' approach to some other QHP requirements. We also propose offering an exceptions process for QHP issuers on the FFEs for the API requirements proposed in this rule, that would be conditioned upon approval of a narrative justification that meets CMS requirements. The proposed exceptions processes could apply to small issuers, financially vulnerable issuers, or new entrants to the FFEs that demonstrate that deploying standards-based API technology consistent with the proposed policies would pose a significant barrier to the issuers' ability to provide coverage or service to patients and that not certifying the issuers QHP or QHPs would result in patients having few or no plan options in certain areas. This approach is consistent with the exceptions process finalized for the Patient Access API in the CMS Interoperability and Patient Access final rule. Were we to apply the proposed standards to such issuers, we believe it 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 FFEs in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though patients in those states enroll in coverage through
HealthCare.gov.
Hence, QHP issuers in SBE-FPs would not be subject to the requirements in this proposed rule. We encourage SBE-FPs and State-based Exchanges operating their own platforms (SBEs) to consider adopting similar requirements for QHPs on their Exchanges.

Throughout this proposed rule, we use terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” Every reader of this proposed rule is a patient and has received, or will receive, medical care at some point in their life. In this proposed rule, we use the term “patient” as an inclusive term. We understand that, historically, we have referred in our regulations to patients using the other terms previously noted. However, for the proposals herein, we will use additional, specific terms applicable to individuals covered under the healthcare programs that we administer and regulate. We also note that when we discuss patients, the term includes, where applicable, a patient's personal representative. For example, a patient or their personal representative may consent to certain types of information exchange under our proposals. But when we refer to a patient's medical needs or health records, we are not including the medical needs or health records of the patient's personal representative. Per the Privacy, Security, and Breach Notification Rules (HIPAA Rules)
1

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), and related guidance thereof, a personal representative, generally and for purposes of access to protected health information (PHI), defined at 45 CFR 160.103, is someone authorized under state or other applicable law to act on behalf of an individual in making healthcare-related decisions (such as a parent, guardian, or person with a medical power of attorney).
2

As permitted by the HIPAA Rules, a patient's personal representative could act on a patient's behalf using the processes within this proposed rule.

1
See 45 CFR parts 160 and 164.

2
See HHS Office of Civil Rights (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 MA organizations, 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. Where certain proposed provisions may not be applicable to specific plan or provider types, we have identified them separately from the aforementioned categories. 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 various sections of this proposed rule. We are proposing at 42 CFR 457.700(c) that states that have a Medicaid expansion CHIP (a program under which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meets the requirements of section 2103 of the Social Security Act), the proposals in this rule for Medicaid would apply to those programs rather than our proposals for a separate CHIP. Functionally, our proposals are the same; however, for clarity, we are making explicit that the Medicaid requirements at §§ 431.60, 431.61, and 431.80 would apply to those programs rather than the separate CHIP requirements at §§ 457.730, 457.731, and 457.732.

We use the term “items and services” when discussing prior authorization in this proposed rule, and note that, unless otherwise stated, the proposals for prior authorization APIs and processes do not apply to drugs of any type, meaning any drugs that could be covered by the impacted payers in this proposed rule (for example, this would include outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy or hospital), because the processes and standards for prior authorization applicable to drugs differ from the other “items and services” for which we propose regulation. In the CMS Interoperability and Patient Access final rule, we finalized policies that would require payers to send claims data

related to prescription and other drug claims via an API, and we make several proposals related to claims data in this proposed rule. For example, Medicare Advantage Prescription Drug (MA-PD) plans that cover Part A, Part B, and Part D benefits, as well as supplemental benefits, are required to provide access to information about all those covered benefits through the Patient Access API at 42 CFR 422.119(b). Prescription and other drug information is part of a patient's longitudinal record and giving patients, providers, and payers access to claims data for prescription and other drugs can offer valuable insights into a patient's healthcare, provide benefits for care coordination, and help avoid potentially harmful drug interactions. We acknowledge that there are existing laws and regulations that may apply to prior authorization for drugs for the impacted payers in this proposed rule. Thus, while the claims data included in our proposed and previously finalized policies did include prescription and other drug claims, our proposals related to prior authorization in this proposed rule do not include standards or policies for any drugs (as previously described), including covered outpatient drugs under Medicaid, and Medicare Part B or Part D drugs.

Additionally, we use the terms “provider” and “supplier” as inclusive terms composed of individuals, organizations, and institutions that provide health services, such as clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS), community-based organizations, as appropriate in the context used. When specifically discussing policies related to the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS, we refer to MIPS eligible clinicians, eligible hospitals, and CAHs.

Throughout this proposed rule we make several API-related proposals in which we refer to the functionality as a singular API, or API gateway, though we acknowledge that this functionality may be made up of one or multiple APIs. For example, while we refer to the Patient Access API (discussed in section II.A. of this proposed rule) as a single API for the purpose of describing the functionality, the same functionality may be achieved with one or multiple APIs, depending on the implementation approach chosen by the applicable payer.

An API is a set of commands, functions, protocols, or tools published by one software developer (“A”) that enables other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software, while maintaining data security and patient privacy, if properly implemented. This is how API technology enables the seamless user experiences associated with applications, which are familiar in other aspects of patients' daily lives, such as travel and personal finance. Standardized, secure, transparent, and pro-competitive API technology can enable similar benefits for patients of healthcare services.
3

3
ONC released an overview of APIs in context of consumers' access to their own medical information across multiple providers' electronic health record (EHR) systems, which is available at the
HealthIT.gov
website at
https://www.healthit.gov/api-education-module/story_html5.html.

Health Level 7 (HL7®) is the standards development organization which develops the Fast Healthcare for Interoperability Resources (FHIR®) standard and IGs referenced throughout this proposed rule. HL7 requires the registered trademark with the first use of its name in a document, for which policies are available on its website at
www.HL7.org.
4

4
CMS does not use the trademark symbol elsewhere in the preamble unless necessary when naming specific IGs. For HL7 Trademark policy,
see http://www.hl7.org/legal/trademarks.cfm?ref=nav.

Finally, we note that throughout this proposed rule we discuss the APIs in relation to the proposed programmatic requirements to share data between payers, between payers and providers, and between payers and patients under specific rules. However, these APIs could be used for a multitude of transactions, aside from those currently described by section 1173(a)(1) of the Social Security Act, beyond those proposed in this rule. For instance, a patient could request data outside the scope of this proposed rule, or program integrity entities could request data from payers or providers (such as under the Inspector General Act of 1978). Nothing in this proposed rule would prevent the requested data from being shared via the APIs discussed in this proposed rule, if technologically feasible, for appropriate purposes. In fact, we encourage the use of these standards-based APIs for purposes beyond the proposed requirements to improve the interoperability of health data regardless of the use case.

B. Summary of Major Proposals

To drive interoperability, improve care coordination, reduce burden on providers and payers, and empower patients, we are proposing several requirements for MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, as well as MIPS eligible clinicians participating in the MIPS Promoting Interoperability performance category, and eligible hospitals and CAHs in the Medicare Promoting Interoperability Program. We are also including RFIs to gather information that may support future rulemaking or other initiatives.

Executive Order (E.O.) 13985 of January 20, 2021, entitled “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,” set Administration policy that the “Federal Government should pursue a comprehensive approach to advancing equity for all.”
5

CMS is committed to pursuing a comprehensive approach to advancing health equity for all, and we believe the proposals in this rule are aligned with this E.O. because they represent efforts to mitigate existing inefficiencies in policies, processes, and technology which affect many patient populations. Some patient populations are more negatively affected by existing processes than others and thus might realize greater benefits through the improvements we propose. One of the main components of this proposed rule is continued support for the individual's ability to select an app of their choice when accessing their health information. We want to ensure that members of all communities can access their health information and benefit from this technology. However, we are interested in the best ways to ensure that apps are available and accessible for individuals with disabilities, individuals with limited English proficiency, individuals with low literacy or low health literacy, and individuals with geographic, economic, or other social risk factors that may create barriers to accessing or using technology and apps. We are soliciting comments from the public, particularly individuals who have knowledge about how underserved populations use healthcare apps and technology, such as researchers, policy advocates, social service agency staff, providers who serve underserved populations, and others who may be able to provide insight about accessibility, readability, and other relevant factors for consideration. Our goal is to ensure that these proposed policies do not

exacerbate current disparities or create unintended inequities that leave some communities or populations unable to benefit from this information sharing. Further, we seek to ensure that patient privacy considerations are built into the implementation of these proposed policies through the use of secure technologies, such as OAuth 2.0 and OpenID Connect for authentication, and as further discussed in the CMS Interoperability and Patient Access final rule (85 FR 25516). While we have proposed policies that we believe would address some healthcare inequities, we are soliciting comment about how to help ensure that individuals from all communities and populations can actively benefit from our healthcare interoperability proposals.

5
E.O. 13985, sec. 1, 86 FR 7009 (January 20, 2021).

In the CMS Interoperability and Patient Access final rule, we required impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to implement and maintain a standards-based Patient Access API. The Patient Access API must allow patients, through the health applications of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer, (85 FR 25558). In this proposed rule, we are proposing to require that impacted payers (MA organizations, state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) include information about prior authorizations in the data that are available through the Patient Access API. In addition, we are proposing to require these impacted payers to annually report to CMS certain metrics about patient data requests via the Patient Access API.

To improve coordination across the care continuum and movement toward value-based care, we are proposing to require that impacted payers implement and maintain a Provider Access API that, consistent with the technical standards finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558), utilizes HL7 FHIR version 4.0.1. That API can be used to exchange current patient data from payers to providers, including all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient's prior authorization decisions.

In the CMS Interoperability and Patient Access final rule, CMS required certain payers (MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to exchange a patient's health data with other payers at the patient's request, beginning on January 1, 2022, or plan years beginning on or after January 1, 2022, as applicable (85 FR 25568). We also required those payers to incorporate the data they receive through this payer to payer data exchange into patient records, with the goal of creating longitudinal records that would follow patients as they move from payer to payer throughout their healthcare journey. However, we did not require a standards-based API for the payer to payer data exchange.

Since the rule was finalized in May 2020, multiple impacted payers reported to CMS that the lack of technical specifications for the payer to payer data exchange requirement in the CMS Interoperability and Patient Access final rule was creating challenges for implementation, which, they stated, could lead to incompatible implementations across the industry, poor data quality, operational challenges, and increased administrative burdens. They were concerned that different implementation approaches could create gaps in patient health information, which would directly conflict with the intended goal of interoperable payer to payer data exchange.

After considering stakeholder concerns about implementing the payer to payer data exchange requirement finalized in the CMS Interoperability and Patient Access final rule, we announced in a December 10, 2021
Federal Register
notification (86 FR 70412) that we would not enforce the payer to payer data exchange requirements until further rules are finalized.
6

In this proposed rule, we are proposing to rescind our previous payer to payer data exchange requirements and replace them with a new policy. The CMS Interoperability and Patient Access final rule also did not apply the payer to payer data exchange requirements to Medicaid and CHIP FFS programs. We are now proposing to apply our newly proposed Payer-to-Payer API requirements to Medicaid and CHIP FFS programs, in addition to other impacted payers as discussed further in section II.C.4.a. The new proposed policy would require impacted payers to build a Payer-to-Payer API to facilitate the exchange of patient information between payers, both at a patient's request and at the start of coverage with a new payer. Specifically, that data exchange would include all data classes and data elements included in a standard adopted at 45 CFR 170.213 (currently USCDI version 1), adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information), and the patient's prior authorization decisions.

6
Centers for Medicare & Medicaid Services (2021, December 10). CMS-9115-N2. Notification of Enforcement Discretion.
https://www.govinfo.gov/content/pkg/FR-2021-12-10/pdf/2021-26764.pdf.

To improve the patient experience and access to care, we are also proposing several new requirements for prior authorization processes that we believe would ultimately reduce burden on patients, providers, and payers. To streamline the prior authorization process, we are proposing to require all impacted payers to implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision API (PARDD API). The API would streamline the prior authorization process by automating the process to determine whether a prior authorization is required for an item or service, thereby eliminating one of the major pain points of the existing prior authorization process. The API would then be able to query the payer's prior authorization documentation requirements and make those requirements available within the provider's workflow as well as support the automated compilation of certain information from the provider's system. Finally, the API would support an automated approach to compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions and enable payers to compile specific responses regarding the status of the prior authorization, including information about the reason for a denial. For the exchange of the prior authorization transaction, covered entities would continue to use the HIPAA-mandated transaction standards. Use of the FHIR API integrates identification of prior authorization and documentation requirements as well as information about prior authorization requests and decisions into a provider's workflow while maintaining compliance with the adopted HIPAA standard.

We are proposing to require that impacted payers send information to providers regarding the specific reason for denial when a prior authorization request is denied, regardless of the mechanism used to submit the prior authorization request. We are proposing

to require impacted payers, except for QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. In addition, we are proposing to require impacted payers to publicly report certain metrics about their prior authorization processes for transparency.

We are proposing a new measure for electronic prior authorization for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To promote PARDD API adoption, implementation, and use among MIPS eligible clinicians, eligible hospitals, and CAHs, we are proposing to add a new measure titled “Electronic Prior Authorization” under the Health Information Exchange (HIE) objective in the MIPS Promoting Interoperability performance category and the Medicare Promoting Interoperability Program, beginning with the performance period/EHR reporting period in calendar year (CY) 2026. For this measure, we are proposing that a MIPS eligible clinician, eligible hospital, or CAH must report a numerator and denominator or (if applicable) an exclusion.

Although these proposals do not directly pertain to Medicare FFS, we want to ensure that people with Medicare can benefit from the policies we are proposing, regardless of their coverage or delivery system. We intend for the Medicare FFS program to be a market leader on data exchange, including through the Provider Access, Payer-to-Payer, and Prior Authorization APIs. and therefore, seek comment throughout on how these proposals could apply to Medicare FFS. Similarly, we encourage other payers not directly impacted by this proposed rule to evaluate our proposals for voluntary adoption to reduce burden and support greater interoperability. Further information about CMS initiatives to achieve the desired level of data exchange with patients, providers and other payers can be found in those sections in this proposed rule.

We are also including five RFIs to gather information that may support future rulemaking or other initiatives. Specifically, we request information on barriers to adopting standards, and opportunities to accelerate the adoption of standards, for social risk data. We recognize that social risk factors (for example, housing instability and food insecurity) influence patient health and healthcare utilization. In addition, we understand that providers in value-based payment arrangements rely on comprehensive, high-quality social risk data. Given the importance of these data, we want to understand how we can better standardize and promote the exchange of these data in accordance with the law.

Additionally, we are seeking comment on how CMS could leverage APIs (or other technology) to facilitate electronic data exchange between and with behavioral healthcare providers, which generally have lower rates of EHR adoption than other provider types.

Furthermore, in the Medicare FFS program, the ordering provider can be different than the rendering provider of items or services, which creates unique obstacles to the coordination of patient care and exchange of medical information needed to ensure an accurate and timely payment. We are interested in public comments regarding how Medicare FFS could support improved medical documentation exchange between and among providers, suppliers, and patients as we believe it could enable better care for beneficiaries if covered services are not delayed by inefficiencies.

We also seek comment on how using data standards and electronic health records can improve maternal health outcomes. Additionally, we include questions related to how prior authorization can be improved and what special considerations should be given to support data sharing in maternal health care.

Finally, we seek comment on how to encourage providers and payers to enable exchange under TEFCA to make patient information more readily available for access and exchange in a variety of circumstances. We wish to understand how CMS can support enabling exchange under TEFCA and what concerns commenters have about potential requirements related to enabling exchange under TEFCA.

II. Provisions of the Proposed Rule

A. Patient Access API

1. Background

In the CMS Interoperability and Patient Access final rule (85 FR 25558), in order to give patients access to their own health information in a way most meaningful and useful to them, we required impacted payers to share, via FHIR APIs, certain information including patient claims, encounter data, and a subset of clinical data that patients can access via health apps. Claims and encounter data, used in conjunction with clinical data, can offer a broad picture of an individual's healthcare experience. In the CMS Interoperability and Patient Access final rule (85 FR 25523), we gave examples of how claims data can be used to benefit patients and 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 payer that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance.

Patients tend to receive care from multiple providers, leading to fragmented patient health records where various pieces of an individual's longitudinal record are locked in disparate, siloed data systems. With patient data scattered across these disconnected 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. This lack of comprehensive patient data can impede care coordination efforts and access to appropriate care.

As stated in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates feedback we received from stakeholders. We understand that many readers may be familiar with that proposed rule, and, in an effort to distinguish the differences between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule outlining the overarching differences between them. In this proposed rule, we are again proposing to require impacted payers to report Patient Access API metrics to CMS. However, we have changed the proposal to require reporting annually, as opposed to quarterly. In addition, we are no longer proposing that impacted payers maintain a process for requesting an attestation from health app developers when the developers register their app with the payer's Patient Access API. Instead, we are seeking comment on a variety of privacy considerations. Finally, we propose to extend the compliance date for our proposed policies to January 1, 2026.

As mentioned in section I.A. of this proposed rule, the proposals in this rule do not directly pertain to Medicare FFS. However, if our proposals are finalized, we plan to implement these provisions for Medicare FFS so that people with Medicare FFS could also benefit from their data availability. Through Blue

Button 2.0,
7

CMS makes Parts A, B, and D claims data available electronically via an API to people with Medicare FFS and those enrolled in Part D. To align with the API provisions included in the CMS Interoperability and Patient Access final rule, we have updated the Blue Button 2.0 API to FHIR Release 4, and begun using the CARIN Consumer Directed Payer Data Exchange IG for Blue Button 2.0. If we finalize our proposals, we plan to further align and enhance Blue Button 2.0 accordingly, as feasible. We seek comment on any considerations for applying these requirements to apply to Medicare FFS, if we finalize these proposals.

7
Blue Button 2.0 allows Medicare beneficiaries to download claims data to their computer or device to print it or share it with others. They can also easily link health apps to their account to share their data with providers, pharmacies, caregivers, or others. See Centers for Medicare & Medicaid Services. Share your Medicare claims (Medicare's Blue Button). Retrieved from
https://www.medicare.gov/manage-your-health/share-your-medicare-claims-medicares-blue-button.

2. Enhancing the Patient Access API

In the CMS Interoperability and Patient Access final rule (85 FR 25558-25559), we adopted regulations that require 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, to implement and maintain APIs that permit enrollees to use health apps to access data specified at 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221, respectively. The Patient Access API must make available, at a minimum, adjudicated claims (including provider remittances and enrollee cost-sharing), encounters with capitated providers, and clinical data, including laboratory results, with a date of service on or after January 1, 2016, as maintained by the payer. We finalized a policy that payers must make those data available via the Patient Access API no later than 1 business day after a claim is adjudicated or encounter or clinical data are received.

a. Prior Authorization Information

To enhance our policy by improving the usefulness of the information available to patients, we are proposing to add information about prior authorizations to the categories of data required to be made available to patients through the Patient Access API. In this section, we refer to the provider's workflow and associated information and documentation as the “prior authorization request” and the payer's processes and associated information and documentation as the “prior authorization decision.” This proposal would apply to all prior authorization requests and decisions for items and services (excluding drugs) for which the payer has data, whether the decision is still pending, active, denied, expired, or is in another status, as discussed further in this section. The primary goal of the Patient Access API is to give patients access to their health information. By expanding patient access to prior authorization information, we intend to help patients be more informed decision makers and true partners in their healthcare.

As discussed in section I.A. of this proposed rule, our proposals for prior authorization APIs and processes do not apply to drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, or drugs that may be administered in a pharmacy or hospital. In section II.D. of this proposed rule, we propose several provisions focused on making the prior authorization process less burdensome for providers and payers, which we anticipate would reduce care delays and improve patient outcomes. We believe that giving patients access to information about prior authorization requests and decisions would enable patients to take a more active role in their own healthcare. As a result, we are proposing to require impacted payers to provide patients with access to information about the prior authorization requests made for their care through the Patient Access API.

We propose to require that via the Patient Access API, impacted payers make information about prior authorization requests and decisions (and related administrative and clinical documentation) for items and services (excluding drugs) available to patients no later than 1 business day after the payer receives the prior authorization request or there is another type of status change for the prior authorization. Examples of status changes include: a payer approves or denies a pending prior authorization request, a provider or patient updates a denied prior authorization request with additional information for reconsideration, or the count of the items or services used under the prior authorization decision is updated. We expect that impacted payers use a variety of terminology, but, generally, any meaningful change to the payer's record of the prior authorization request or decision would require an update to the information available to the patient. For the requirement to include prior authorization information in the data available via the Patient Access API, we propose a January 1, 2026 compliance date (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026).

The required information available through the API would include the prior authorization status, the date the prior authorization was approved or denied, the date or circumstance under which the authorization ends, the items and services approved, and the quantity used to date under the authorization. The documentation required to be shared includes any materials that the provider sends to the payer to support a decision, for example, structured or unstructured clinical data including laboratory results, scores or assessments, past medications or procedures, progress notes, or diagnostic reports. In section II.D.4.a. of this proposed rule, we propose that in the case of a prior authorization denial, the payer must provide a specific reason for the denial. We propose that impacted payers would have to make that specific reason for denying a prior authorization request available to the patient via the Patient Access API as well. This information can help patients understand both why a payer denied a prior authorization request and/or what items and services were authorized for the patient's recent care.

As further discussed in sections II.B. and II.C. of this proposed rule, we are proposing to require impacted payers to share the same information about prior authorization requests and decisions with a patient's provider via the Provider Access API and via the Payer-to-Payer API. In this way, these prior authorization data can potentially be available to all relevant parties. We note that the requirement to share information about prior authorization via the API is in addition to any notice requirement that applies to prior authorization requests and decisions, such as the proposals to require notice of a decision within certain timeframes discussed in section II.D.5.b. of this proposed rule.

We believe that 1 business day is appropriate, as patients need timely access to the information to understand prior authorization processes and their available care options. As discussed further in section II.D. of this proposed rule, we are proposing to require payers to make much of the same information about prior authorization requests and decisions available via the PARDD API during the decision-making process. In

addition, because impacted payers would be required to exchange prior authorization information electronically, we believe it would be reasonable for them to share prior authorization information and documentation with patients within 1 business day of any update to the prior authorization request or decision.

We are also proposing to require that information about prior authorizations (and related administrative and clinical documentation) be available via the Patient Access API for as long as the authorization is active and at least 1 year after the last status change. We note that we are formulating our proposal for at least 1 year after any status change, but this provision would be particularly relevant to denied and expired prior authorizations, to ensure that they would be available for at least a year after expiring or being denied. We do not propose to require that payers share a patient's full prior authorization history because that could comprise a significant amount of information that may no longer be clinically relevant. Claims, encounter, and/or clinical data can provide important information about a patient's health history. With those data available through the Patient Access API, we believe that process-related information about long-expired or denied prior authorizations would be redundant. Also, as prior authorization rules may change over time, we believe that this information has a limited lifespan of usefulness to a patient's current care. At the same time, the API should include information about all active authorizations for as long as they are active and therefore may be related to ongoing care.

We anticipate that requiring payers to make prior authorization information accessible through the Patient Access API would help patients better understand the lifecycle of a prior authorization request, the items and services that require prior authorization, the information being considered, and specific clinical criteria their payer uses to make a determination. We believe that more transparency would better equip patients to engage with their payer(s) and/or provider(s). For example, by having access to certain prior authorization information via the Patient Access API, a patient could see that prior authorization is needed and has been submitted for a particular item or service, which could help them better understand the timeline for the process and plan accordingly. Supporting documentation could give patients better visibility into what the payer is evaluating so they could help providers get the best and most accurate information to payers to facilitate a successful request, thus potentially avoiding unnecessary care delays and reducing burden on providers and payers. The proposed requirement could also reduce the need for patients to make repeated calls to their providers and payers to understand the status of requests, or to inquire why there are delays in care.

We believe that this proposal would enable patients to participate in their care more and reduce burden on both providers and payers to allow them to more efficiently navigate the prior authorization process. The proposal may also add an additional layer of accountability for payers to make timely prior authorization decisions, as patients would be able to follow the prior authorization process from initiation to conclusion. As with all information made available via the Patient Access API, we believe industry is in the best position to develop apps for patients to effectively use this information, and to make sure that the apps are accessible to people with disabilities. We look to industry innovators to produce apps that will help patients understand their health information and access it in a manner that is useful to them.

In summary, we propose that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers would be required to make information available to patients via the Patient Access API about prior authorization requests and decisions (and related administrative and clinical documentations), including, as applicable, the status of the prior authorization; the date the prior authorization was approved or denied; the date or circumstance under which the authorization ends; the items and services approved; the quantity used to date; and, if the prior authorization was denied, a specific reason why the request was denied, no later than 1 business day after the payer receives a prior authorization request for items and services (excluding drugs) or there is another type of status change for the prior authorization. We are also proposing that, beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), impacted payers must make prior authorization information (and related administrative and clinical documentation), available to patients via the Patient Access API for the duration it is active and at least 1 year after the last status change. These proposals would apply to MA organizations, state Medicaid FFS and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1.

The requirements for a Patient Access API imposed on Medicaid managed care plans and CHIP managed care entities are set forth at 42 CFR 438.242(b)(5) and 457.1233(d), respectively. Through an amendment to paragraph (b)(5) and by adding a new paragraph (b)(8) at 42 CFR 438.242, we are proposing to require Medicaid managed care plans (and through § 457.1233(d), CHIP managed care entities) to include information about prior authorization requests and decisions and related administrative and clinical documentation in the data available via to the Patient Access API by the rating period beginning on or after January 1, 2026. We request comment on this proposal.

We request comment on how we could or should apply these requirements to Medicare FFS and its existing prior authorization requirements and standards.

As stated earlier in this preamble, the proposals in this proposed rule do not apply to any drugs. However, we also request comments on whether we should consider policies to require impacted payers to include information about prior authorizations for drugs, when the payer covers drugs, via the Patient Access API, the Provider Access API, and the Payer-to-Payer API. We request comments on how future rulemaking to make information about prior authorizations for drugs available through these APIs might interact with existing prior authorization requirements and standards.

b. Interaction With HIPAA Right of Access Provisions

Previous proposals have elicited numerous comments regarding the interaction between the Patient Access API and HIPAA Privacy Rule requirements for individual access.
8

Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a copy of protected health information (PHI) about themselves in a designated record set for as long as the PHI is maintained in the designated record set by a covered entity. This includes the right to inspect or obtain a

copy, or both, of the PHI. Our Patient Access API proposals would complement that right by requiring payers to make the PHI that patients already have a right to access available through a standards-based and interoperable Patient Access API. It is critical that individuals have access to their information and the ability to share it with others who are involved in their care, particularly when it could involve care coordination between providers and prior authorization for certain items and services.

8
See CMS Interoperability and Patient Access final rule (85 FR 25516-19) and December 2020 CMS Interoperability proposed rule (85 FR 82586).

When an individual requests an electronic copy of PHI that a covered entity maintains electronically (ePHI), per 45 CFR 164.524(c)(2)(ii), the covered entity must provide the individual with access to the information in the requested electronic form and format, if it is readily producible in that form and format. When the ePHI is not readily producible in the electronic form and format requested, then the covered entity must provide access to an agreed upon alternative readable electronic format.
9

As health apps become more common, we believe that it behooves us to require that all impacted payers be able to provide individuals' ePHI via an industry standard FHIR API, as demonstrated by both our current requirements and our proposals in this section. We believe that, in addition to the other benefits described in this proposed rule, ensuring that patients can receive their ePHI in a standard, interoperable format that they can use with the latest technologies would reduce instances of an individual requesting ePHI in an electronic format that is not readily producible.

9
See 45 CFR 164.524(c)(2)(ii) and U.S. Department of Health and Human Services. Individuals' Right under HIPAA to Access their Health Information 45 CFR 164.524. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.

Individuals have the right under the HIPAA Privacy Rule to request access to PHI in the form and format requested by the individual, if it is readily producible in the manner requested.
10

For example, the covered entity must transfer or transmit the PHI to the individual even where the requested mode of transfer or transmission is unsecure as long as the PHI is “readily producible” in such manner, the covered entity is capable of transmitting the PHI in the manner the individual requests, and the manner of transmission would not present an unacceptable level of security risk to the PHI on the covered entity's systems.
11

In the CMS Interoperability and Patient Access final rule, we specifically cited this security risk exception as the only reason payers could deny API access to a health app that a patient wishes to use. These risks include, for example, insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which patients seek to access their electronic health information. See 42 CFR 422.119(e) for MA organizations; 42 CFR 431.60(e) for state Medicaid FFS programs, through the existing cross reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42 CFR 457.730(e) for state CHIP FFS programs, through the existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45 CFR 156.221(e) for QHP issuers on the FFEs.

10
See 45 CFR 164.524(c)(2).

11
U.S. Department of Health and Human Services. Individuals' Right under HIPAA to Access their Health Information 45 CFR 164.524. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.

Disagreement with the individual about the worthiness of a health app as a recipient of PHI, or even concerns about what the app might do with the requested PHI, would not be acceptable reasons to deny an individual's request.
12

Therefore, as we also noted in the CMS Interoperability and Patient Access final rule, covered entities and business associates would be free to offer advice to patients on the potential risks involved with requesting data transfers to an app or entity not covered by HIPAA, but such efforts generally must stop at education and awareness or advice related to a specific app. For instance, if a payer noted that the app a patient was using to access their data did not explain in its privacy policy specifically how the patient's personal data would be used or sold (a possibility for apps not covered by HIPAA), the payer could choose to inform the patient that they may not want to share their data with that app without a clear understanding of how the app may use the data, including details about the app's secondary data use policy. If the patient still wants their data to be shared, or does not respond to the payer's warning, the payer would need to share their data via the API, absent an unacceptable security risk to the payer's own system. For more information on this ability to inform patients, see the CMS Interoperability and Patient Access final rule at 85 FR 25550. The requirements we are proposing do not affect or alter any obligations under the HIPAA Privacy and Security Rules.

12
Office for Civil Rights (OCR) (2019, April 18). Can a covered entity refuse to disclose ePHI to an app chosen by an individual because of concerns about how the app will use or disclose the ePHI it receives? Retrieved from
https://www.hhs.gov/hipaa/for-professionals/faq/3012/can-a-covered-entity-refuse-to-disclose-ephi.html.

We discussed privacy and safety concerns in the context of APIs in the CMS Interoperability and Patient Access final rule (85 FR 25516). We note that while the FHIR standard itself does not define security-related functions, when used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented and maintained to comply with the HIPAA Security Rule for secure data exchange.
13

Furthermore, the covered entity is not liable for what happens to the PHI once the designated third party receives the information as directed by the individual.
14

13
HL7 International (2022, May 28). HL7 FHIR Release 4. 6.1.0 FHIR Security. Retrieved from
http://www.hl7.org/Fhir/security.html.

14
Office for Civil Rights (OCR) (2020, January 31).
What is the liability of a covered entity in responding to an individual's access request to send the individual's PHI to a third party?
Retrieved from
https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html.

Our proposals in this section address how a payer must make patients' data available to them; however, we do not have the authority to regulate health apps that individuals may wish to use, or what those apps do with PHI. As discussed, per the CMS Interoperability and Patient Access final rule, impacted payers may only deny or discontinue an app's connection to their APIs if an impacted payer makes a determination using objective, verifiable criteria that the specific health app would present a danger to the impacted payer's own systems, such as increasing the risk of cyber-attack.

Regardless of whether HIPAA applies to a health app, other Federal laws may apply, even where HIPAA does not apply, such as the Federal Trade Commission (FTC) Act. Under section 5 of the FTC Act (15 U.S.C. 45(a)), the FTC has authority to challenge unfair or deceptive trade practices, including those related to the privacy and security of personal health information that apps collect, use, maintain, or share. For example, if an app discloses an individual's health information in a manner inconsistent with the app's privacy policy, terms of use, or an individual's reasonable expectations, or fails to take reasonable measures to assess and address privacy or data security risks, the developer of that app may be violating the FTC Act. The FTC has applied its section 5 authority to a

wide variety of entities, including health apps.
15

For more information about what laws may apply to health apps, see
https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.

15
See, for example, Federal Trade Commission (2021, June 22). Flo Health, Inc. Retrieved from
https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc.

The FTC also enforces the FTC Health Breach Notification Rule, which covers most health apps and similar technologies that are not covered by HIPAA, and therefore, not subject to the HIPAA Breach Notification Rule.
16

The FTC's Health Breach Notification Rule sets forth steps entities covered by that rule must follow when there has been a breach of unsecured personal health information. Any violation of the FTC's Health Breach Notification Rule is treated as an unfair or deceptive act or practice under section 18 of the FTC Act and subject to civil penalties of up to $46,517 per violation per day.

16
Federal Trade Commission (January 2022). Complying with FTC's Health Breach Notification Rule. Retrieved from
https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule.
See also Federal Trade Commission (2021, September 15). Statement of the Commission on Breaches by Health Apps and Other Connected Devices. Retrieved from
https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf.

c. Privacy Policy

As we discussed earlier in this proposed rule and in detail throughout the CMS Interoperability and Patient Access final rule (85 FR 25550), one of the most important aspects of making health data accessible to patients is to protect the privacy and security of patient health information, especially because once a patient's data are received by a health app, their data may no longer be protected by the HIPAA Rules.
17

Also as discussed earlier, we do not have the authority to directly regulate health apps. Yet, we take the privacy and security of PHI seriously and understand that patients may not know the implications of giving a health app access to their health information. We are continually working to find ways to further protect patient data.

17
Office for Civil Rights (OCR) (2021, January 6).
The access right, health apps & APIs.
Retrieved from
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access-right-health-apps-apis/index.html.

In the CMS Interoperability and Patient Access final rule, we required that impacted payers make educational resources available to their current and former patients with information to help protect the privacy and security of their health information. That includes factors to consider in selecting an app, including potential secondary uses of data, and the importance of understanding the security and privacy practices of any app to which they will entrust their health information. Furthermore, impacted payers must provide an overview of which types of organizations or individuals are and are not likely to be HIPAA-covered entities, and the oversight responsibilities of the Office for Civil Rights (OCR) and the FTC, and how to submit a complaint to those entities. See 42 CFR 422.119(g) for MA organizations, 42 CFR 431.60(f) for Medicaid FFS programs, through existing cross-reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing cross reference at 42 CFR 457.1233(d) for CHIP managed care entities, and at 45 CFR 156.221(g) for QHP issuers on the FFEs. We continue to believe these resources are important to provide to patients, but seek comments on how we can improve this policy so patients can make educated decisions about sharing their personal health information.

In the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program final rule (21st Century Cures Act final rule) (85 FR 25642, 25814 through 25815), ONC noted that providing information that is factually accurate, objective, unbiased, not unfair or deceptive, and provided in a non-discriminatory manner to inform a patient about the advantages, disadvantages and any risks of sharing their health information with a health app, would be unlikely to interfere (as defined in that rule) with the access, exchange, or use of electronic health information (EHI) for purposes of the information blocking regulations at 45 CFR part 171.
18

18
See 45 CFR 171.102: Electronic health information (EHI) is electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, regardless of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103. EHI shall not include: (1) Psychotherapy notes as defined in 45 CFR 164.501; or (2) Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.

In response to comments on the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we noted in the final rule (85 FR 25549-25550) commenters' observations that many patients were unlikely to understand the potential risk of disclosure when their data are transmitted to a health app and are thus no longer protected by the HIPAA Rules. Commenters were specifically concerned about secondary uses of data, such as whether developers would sell their data to third parties for marketing or other purposes. In the CMS Interoperability and Patient Access final rule (85 FR 25549), we noted that a clear, plain language privacy policy is the best vehicle to inform patients about how their information will be protected and how it will be used once shared with the health app.

In the December 2020 CMS Interoperability proposed rule (85 FR 82592 through 82594), we proposed to require impacted payers to request a privacy policy attestation from health app developers when their app requests to connect to the payer's Patient Access API. We proposed that the attestation would include, at a minimum, statements that the app has a plain language privacy policy that is always publicly available and accessible, and has been affirmatively shared with the patient prior to the patient authorizing the app to access their health information. In addition, the attestation we proposed included yes/no elements as to whether the privacy policy specifically communicates how the patient's health information could be accessed, exchanged, or used.

While we still believe that certain aspects of our previously proposed attestation policy could support enhanced patient education about health apps' privacy policies, based on public comments and feedback, we are concerned that this type of attestation would not serve to benefit patients in ways that would outweigh the burden on impacted payers. We are also concerned that such a policy could have unintended consequences for patients. Under the proposal in the December 2020 CMS Interoperability proposed rule, a health app developer would only be attesting to the format and inclusion of certain information. There would be no attestation that the substance of the privacy policy meets specific minimum requirements or best practices. We believe that having payers inform patients that an app developer has attested to the form and format of a privacy policy could easily be misinterpreted as assurance that the substance of the privacy policy has been reviewed and found acceptable by the payer (or CMS). We believe this is especially true in the case of patients with low health or technology literacy, who are least likely to be able to find and interpret an app's privacy policy to make well-informed decisions about their health data. We are concerned that requiring such an attestation would only give the appearance of privacy and

security for patients' health data, without providing additional benefit.

Because CMS does not have the statutory authority to regulate health apps, we cannot require developers to respond to that attestation. Furthermore, as discussed, even if a health app developer does not respond to the attestation (or responds in the negative), a payer would be required to allow that app to connect (unless it would create a security risk to the payer's own system) and provide a patient's health information through the app selected by the patient.

Commenters also responded that the proposed process would put an undue burden on payers to manage an attestation process for app developers with whom they may have no legal or contractual relationship. Furthermore, commenters expressed concerns about payers' lack of adherence mechanisms and payer liability due to the HIPAA right of access requirements discussed previously.

We still believe it is important for patients to have a clear understanding of how their health information may be used by a person or entity not covered by the HIPAA Rules, such as a health app, whether their data would be sold or marketed, and how to stop sharing their health information with such entities if they so choose. In particular, explaining certain privacy and security practices in a patient-friendly, easy-to-read privacy policy would help patients understand those elements and how they can be an active participant in the protection of their information. We also encourage app developers to follow industry best practices, including the CARIN Alliance's Code of Conduct and the ONC Model Privacy Notice (MPN).
19 20

We note that the developer attestation discussed in the December 2020 CMS Interoperability proposed rule (85 FR 82593) included some of the elements of the 2018 ONC MPN, such as explaining 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.
21

As discussed, if an app has a written privacy policy and the app or developer operates contrary to that policy, the FTC has authority to act.

19
CARIN. The CARIN Alliance Code of Conduct (May 2020). Retrieved from
https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.

20
Office of the National Coordinator. Model Privacy Notice (MPN). Retrieved from
https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.

21
Office of the National Coordinator. Model Privacy Notice (MPN). Retrieved from
https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.

We request comments on how we can help give patients the tools they need to understand the privacy and security implications of using a health app within the scope of our regulatory authority. We seek ideas on how we can balance our desire to both educate patients and respect their rights under the HIPAA Privacy Rule. For example, should there be a process at the time a developer registers an app with a payer for access to the API to submit information about its privacy policy? Should payers be required to provide that information in an easy-to-understand format the first time a patient requests access via an app? We encourage comments about how we can leverage the MPN (most recent version from 2018). While we cannot require health app developers to utilize the MPN, should payers notify patients, the first time the patients request data through an app, whether the app utilizes the MPN or not? To encourage visibility for apps that use the MPN versus those that do not, should payers be required to list apps that have established access to their API on their websites that comply with the MPN's transparency requirements? We note that payers would have to treat apps identically based on the substance of their privacy policies and could not favor certain apps over others, such as for competitive advantage. Again, we (and payers) cannot prohibit patients from using health apps that do not comply with best privacy and security practices unless it presents an unacceptable security risk to the payer's systems.

We also request comment on whether we can leverage and build on other HHS health information exchange initiatives, such as TEFCA, to address these issues. For more background on TEFCA, see the related Request for Information in section III.E. of this proposed rule. The Common Agreement and Framework Agreement include privacy and security requirements for Qualified Health Information Networks (QHINs), Participants, and Subparticipants that elect to exchange information pursuant to it, including entities not covered by the HIPAA Rules.
22

Within the Common Agreement, any QHIN, Participant, or Subparticipant that offers Individual Access Services (IAS)
23

by which an individual can access, inspect, or obtain a copy of that individual's information is an IAS Provider. If a health app developer becomes a signatory to a Framework Agreement and offers IAS Services, that developer would be an IAS Provider. That developer would be providing services utilizing the TEFCA Connectivity Services to an Individual with whom the QHIN, Participant, or Subparticipant has a Direct Relationship to satisfy that Individual's ability to access, inspect, or obtain a copy of that Individual's Required Information that is then maintained by or for any QHIN, Participant, or Subparticipant.

22
For the Common Agreement definitions of the terms used in this section (QHIN, Participant, Subparticipant, IAS Provider, Framework Agreement, Connectivity Services, Individual, Required Information, Direct Relationship, Use, Disclosure), see page 3-14 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.

23
The Common Agreement defines Individual Access Services (IAS) as follows: “with respect to the Exchange Purposes definition, the services provided utilizing the Connectivity Services, to the extent consistent with Applicable Law, to an Individual with whom the QHIN, Participant, or Subparticipant has a Direct Relationship to satisfy that Individual's ability to access, inspect, or obtain a copy of that Individual's Required Information that is then maintained by or for any QHIN, Participant, or Subparticipant.” See page 7 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.

IAS Providers must, among other requirements, have a written privacy and security notice; obtain express written consent from individuals regarding the way their information will be accessed, exchanged, used (as defined in the Common Agreement), or disclosed (as defined in the Common Agreement), including the sale of their health information; provide individuals with the right to delete their individually identifiable information as well as the right to revoke their consent, with certain exceptions, in addition to a disclosure of any applicable fees or costs related to IAS; and provide individuals with the right to obtain an export of their individually identifiable information in a computable format.
24

Additionally, IAS Providers are required to protect all individually identifiable information (including health information) they hold in accordance with security requirements specified in the Common Agreement and applicable Standard Operating Procedures, such as the draft IAS Provider Privacy and

Security Notice and Practices Standard Operating Procedure (SOP)
25

and the IAS Exchange Purpose Implementation SOP.
26 27

24
See pages 33-38 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.

25
The Sequoia Project (2022, June 21). Standard Operating Procedure (SOP): Individual Access Service (IAS) Provider Privacy and Security Notice and Practices. DRAFT FOR PUBLIC FEEDBACK. Retrieved from
https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf.

26
The Sequoia Project (2022). Standard Operating Procedure (SOP): Individual Access Services (IAS) Exchange Purpose Implementation. Retrieved from
https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP_IAS_Exchange_Purpose_Implementation.pdf.

27
See pages 35-37 in, Office of the National Coordinator (January 2022). Common Agreement for Nationwide Health Information Interoperability Version 1. Retrieved from
https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf.

Given the Common Agreement's privacy and security requirements, and particularly those that will apply when patients access their health information through a participating IAS Provider, we request comment on whether CMS should explore requirements or ways to encourage exchange under TEFCA as a way to ensure that more patients are informed about the privacy and security implications of using health apps to access their health information, consistent with the requirements for IAS Providers described previously. For instance, how could CMS encourage health apps that are not subject to the HIPAA Rules to connect to entities that exchange information under TEFCA? If so, what should be the contours of, and levers for, such encouragement? What other approaches can CMS take to encourage app developers to enable exchange under TEFCA and therefore leverage the Common Agreement's privacy and security requirements?

In addition, we request comments on the availability of apps that are accessible to individuals with disabilities, availability of apps in a multitude of languages to ensure that individuals with limited English proficiency can understand the information provided, and availability of apps at an appropriate literacy level and in plain language. We note that the draft IAS Provider Privacy and Security Notice and Practices SOP includes guidance regarding plain language and literacy requirements.
28

We believe apps with these features are important to ensure that all patients can benefit from the proposals in this rule. We request comment on any actions that we can take to ensure patients' equitable access to their health information.

28
See pages 5-6 in, The Sequoia Project (2022, June 21). Standard Operating Procedure (SOP): Individual Access Service (IAS) Provider Privacy and Security Notice and Practices. DRAFT FOR PUBLIC FEEDBACK. Retrieved from
https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf.

d. Patient Access API Metrics

We are proposing to require impacted payers to report metrics in the form of aggregated, de-identified data to CMS on an annual basis about how patients use the Patient Access API. This reporting would help CMS better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have access to their health information and whether payers are providing that required information in a transparent and timely way. Aggregated usage data from every impacted payer would help us evaluate whether the Patient Access API policies are achieving the desired goals. Gathering this information would also help us to provide targeted support or guidance to impacted payers, if needed, to help ensure that patients have access to their data and can use their data consistently across the impacted payer types. We propose to require MA organizations to report these data to CMS at the organization level, state Medicaid and CHIP FFS programs to report at the state level, Medicaid managed care plans to report at the state level, CHIP managed care entities to report at the state level, and QHP issuers on the FFEs to report at the issuer level. We are considering, and therefore seek comment on, whether we should require payers that administer multiple plans under a single contract to report these data to CMS at the contract level. We also seek comment on the benefits or drawbacks of an alternative final policy that would permit MA organizations, entities offering Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data for the same plan type at higher levels (such as the parent organization level or all plans of the same type in a program). We note that in the December 2020 CMS Interoperability proposed rule (85 FR 82594), we proposed that these data be reported quarterly, and received comments from a broad variety of stakeholders strongly in favor of annual reporting. Based on that feedback, we are now proposing annual reporting.

Specifically, we propose that these payers annually report:

• The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and

• The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient.

Tracking multiple data transfers would indicate repeat access, showing that patients are either using multiple apps or are allowing apps to update their information over the course of the year. While we are not certain whether such data transfers would indicate to what extent patients are using the apps to manage their healthcare, it would be a preliminary indicator of interest in the technology to access their data.

We are proposing that payers must report data from the previous calendar year to CMS by March 31 of each year. The first year the requirement would be applicable, payers would report calendar year 2025 data by March 31, 2026. A new MA organization, Medicaid managed care plan, CHIP managed care entity, or QHP issuer on the FFEs would naturally have no data to report in its first year of existence and would be required to report data following its first full calendar year subject to the Patient Access API requirement.

In summary, we propose that beginning in 2026, MA organizations at the organization level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans at the state level, CHIP managed care entities at the state level, and QHP issuers on the FFEs at the issuer level must annually report the following metrics to CMS in the form of aggregated, de-identified data: (1) the total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and (2) the total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient. Collecting this information would facilitate CMS' oversight and evaluation of the MA, Medicaid, and CHIP programs and of QHP issuers on the FFEs. We propose that impacted payers report the previous calendar year's metrics, in the form of aggregated, de-identified data, to CMS by March 31 of each year. MA organizations, Medicaid managed care plans, and CHIP managed care entities would report metrics to CMS following any year that they operated, and QHP issuers would report metrics to CMS following any year that they offered a QHP on the FFEs. We are making this proposal at the CFR sections identified in Table 1.

If we finalize this proposal, we do not plan to publicly report these metrics at the state, plan, or issuer level, but may reference or publish aggregated and de-identified data that does not include names of specific state agencies, plans, or issuers. We solicit comment on this aspect of our proposal.

In addition, we request comment on what other Patient Access API metrics we should consider requiring payers to report to CMS and/or make available to the public on their own websites, for consideration in possible future rulemaking. For instance, we are seeking comments on whether payers could report aggregated demographic information, such as sex, race, age, ethnicity, and geographical (for instance, by zip code) data that they may already have to help identify disparities in patient access to health data or underserved populations and, if so, what policies should be considered to minimize those disparities. We are also seeking comment on the potential benefits and burden of requiring payers to report the names of all apps that patients have used to access the payers' API each year. We are considering either collecting this information, or requiring payers to make it public, not to recommend or endorse specific apps, but to maintain a view of the apps that patients use to access their health information, which could help us review for best practices and to evaluate patient ease of use.

e. Patient Access API Amendments

To accommodate the proposed requirements regarding the use of the Patient Access API, we are proposing two minor terminology changes to the requirements finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558, 25547). We note that unlike most of our proposals, we are proposing that these amendments would go into effect on the effective date of the final rule. We are proposing these changes to clarify terms, but do not expect them to substantively change any current regulatory obligation.

First, we are proposing to revise the description of the clinical data to be made available via the Patient Access API by MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. These provisions currently require payers to make available “clinical data, including laboratory results.” We are proposing to revise these paragraphs to specify that the data that payers must make available are “all data classes and data elements included in a content standard at 45 CFR 170.213.” The standard currently referenced at 45 CFR 170.213 is the USCDI version 1. Laboratory Values/Results is a USCDI version 1 data element, and USCDI version 1 includes data classes for other aspects of clinical information such as Immunizations, Procedures, and Assessment and Plan of Treatment. Referring explicitly to the data set in a standard at 45 CFR 170.213 in the rule text would help avoid unnecessary confusion, as this reference would more clearly identify exactly what data must be available through the Patient Access API.

In the future, as versions of the USCDI evolve, there may be multiple versions of the standard referenced at 45 CFR 170.213 at one time. For the ONC Health IT Certification Program, this allows for a transition period between standards as health IT developers incorporate updated standards versions within their systems and complete required certification. Through this proposal, we are seeking to ensure that the same flexibility would apply for payers as they transition between the versions of the USCDI. During such a period, when 45 CFR 170.213 includes more than one version of the USCDI standard, payers would be allowed to use any of the then-available standards at 45 CFR 170.213 for the data classes and elements that they make available through the API.

Second, we are proposing to revise the language previously finalized for denial or discontinuation of a health app's access to the API. Currently, the rules require that the payer make a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which “enrollees” or “beneficiaries” seek to access EHI. We are proposing to change the terms “enrollees” and “beneficiaries” to “parties” for consistency with our proposal to apply this provision to the Provider Access API, Payer-to-Payer API, and the PARDD API discussed further in sections II.B., II.C., and II.D. of this proposed rule. Because other parties would be accessing these APIs, such as providers and payers, it would be more accurate to use the term “parties” rather than “enrollees” or “beneficiaries.”

In summary, we propose that we will replace “clinical data, including laboratory results” with “all data classes and data elements included in a content standard at 45 CFR 170.213” for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1. We also propose that we will change the terms “enrollees” and “beneficiaries” to “parties” for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 1.

We request comment on these proposals. We also direct readers to section II.F. of this proposed rule for a discussion of proposed changes to the interoperability standards for APIs that affect the Patient Access API.

f. Specific CHIP-Related Regulatory Framework

Specifically, for CHIP, the proposed amendments to 42 CFR 457.1233(d) would align separate CHIP managed care API requirements with the Medicaid managed care API requirements, rather than with the CHIP FFS API requirements. In the CMS Interoperability and Patient Access final rule (85 FR 25559), we finalized requirements for separate CHIP managed care entities at 42 CFR 457.1233(d). API requirements for CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and (3) through cross-references to CHIP FFS program requirements at 42 CFR 457.730 and 457.760, respectively. On November 13, 2020, we published a final rule titled “Medicaid Program; Medicaid and Children's Health Insurance Program (CHIP) Managed Care” (85 FR 72754). In that rule, we removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d), cross-referenced to Medicaid managed care regulatory requirements at 42 CFR 438.242. Therefore, the policies in the CMS Interoperability and Patient Access final rule (85 FR 25559) are applicable to separate CHIP managed care entities per 42 CFR 457.1233(d) through a cross reference to Medicaid managed care at 42 CFR 438.242. We propose to apply the API requirements in this proposed rule to separate CHIP managed care entities through the existing cross reference at 42 CFR 457.1233(d) to Medicaid managed care at 42 CFR 438.242, and have noted this throughout the proposals in this proposed rule.

Most states have Medicaid Expansion CHIP programs, in which a state receives Federal funding to expand Medicaid eligibility to optional targeted low-income children that meet the requirements of section 2103 of the Social Security Act (the Act). We are proposing at 42 CFR 457.700(c) that for states with Medicaid Expansion CHIP programs, the proposals in this rule for Medicaid would apply to those programs rather than our proposals for separate CHIP programs. Functionally, our proposals are the same, however, for clarity, we are making explicit that the Medicaid requirements at 42 CFR 431.60, 431.61, and 431.80 would apply to those programs rather than the

separate CHIP requirements at 42 CFR 457.730, 457.731, and 457.732.

BILLING CODE 4120-01-P

EP13DE22.000

BILLING CODE 4120-01-C
3. Statutory Authorities for the Patient Access API Proposals

a. MA Organizations

For MA organizations, we are proposing these new requirements and the revisions to current requirements under our authority at sections 1856(b)(1) (to promulgate regulations implementing MA standards, including the requirements in section 1852(h) of the Act), and 1857(e)(1) of the Act (to add contract terms determined by the Secretary to be “necessary and appropriate”). Section 1856(b)(1) of the Act requires the Secretary to establish regulatory standards for MA organizations that are consistent with and carry out Part C of the Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act requires that MA organizations have procedures in place to maintain accurate and timely medical records and health information regarding MA enrollees and to assure enrollees have timely access to such records and information. Our proposal for the Patient Access API is to require access for enrollees to specified medical records and health information through a specific mechanism from the MA organization. The Secretary is authorized under section 1857(e)(1) of the Act to add new contract terms, including additional standards and requirements, for MA organizations that the Secretary finds necessary and appropriate and that are not inconsistent with Part C of the Medicare statute. The proposals here meet this standard by addressing and facilitating access to enrollees' medical records and health information for the reasons identified in our discussions for each proposal.

The proposal in section II.A.2.a. of this proposed rule that would require MA organizations to make an enrollee's prior authorization requests and related clinical documentation available through the Patient Access API would, if finalized as proposed, allow these enrollees to have access to that information in a convenient, timely, secure, and portable way, which is in enrollees' best interests. This proposed requirement is consistent with section 1852(h) of the Act, which requires MA organizations to assure enrollees timely access to their records and data that is maintained by MA organizations. To ensure that MA organizations meet modern-day patient expectations of transparency, efficiency, and timeliness when providing prior authorization data to enrollees, it is essential for CMS to ensure that each MA organization has a standardized system in place that offers enrollees access to their own data, including data that pertain to their prior authorizations, using existing and emerging technologies of their choice, specifically in this case, health apps. Therefore, making these data available through the Patient Access API is consistent with our programmatic authority to establish standards to implement section 1852(h) of the Act, and could help patients be more informed about and active in their own care, which could potentially lead to better health outcomes.

Making this information available via the Patient Access API could help enrollees support the prior authorization process, as well. Enrollees could see what information is needed and what information has been provided on their behalf to facilitate a prior authorization request. Enrollees could provide missing information needed by the payer to reach a decision. This could allow MA organizations to address prior authorization requests more promptly, streamlining this process, and thus simplifying prior authorization for the MA organizations. This could also improve an enrollee's experience with the process, by facilitating timelier and potentially more successful initial prior authorization requests. This, again, supports efficient operation and timely provision of information and services.

In addition, to ensure the requirements proposed here and finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) would be most effective, CMS proposes in this rule that MA organizations report specific metrics to CMS on enrollee use of the Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes the adoption of additional reporting to CMS by MA organizations where necessary and appropriate. Here, these proposed metrics would facilitate CMS's oversight, evaluation, and administration of patient health data access in the Part C program and therefore, this data collection is necessary and appropriate to adopt.

In alignment with HHS's priorities and goals, CMS is focused on putting patients at the center of their own healthcare and ensuring patients have secure access to their health information. We believe these proposals are critical and appropriate to ensure that MA organizations stay abreast of industry standards and continue to offer enrollees not only quality coverage but also a quality customer experience.

b. Medicaid and CHIP

Our proposed requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the Act. Section 1902(a)(4) of the Act 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 requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Section 1902(a)(19) of the Act 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.

In addition, section 1902(a)(7) of the Act requires that states must provide safeguards that restrict the use or disclosure of information concerning Medicaid applicants and beneficiaries to uses or disclosures of information that are directly connected with the administration of the Medicaid state plan. The implementing regulations for this section of the Act list purposes that CMS has determined are directly connected to Medicaid state plan administration at 42 CFR 431.302 and provide safeguards states must apply to uses and disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are subject to the same requirements through a cross reference at 42 CFR 457.1110(b). Our proposal to require that the data described in this section be shared via the Patient Access API would be consistent with the requirement that states may share these data only for purposes directly connected to the administration of the Medicaid state plan, since this data sharing would be related to providing services for beneficiaries, a purpose listed in § 431.302(c). As mentioned previously, giving a patient access to their own health information can make them a more active participant in ensuring they receive timely and appropriate care (for example, allowing them to monitor medications or access treatment history). Additionally, states must apply the safeguards described at 42 CFR 431.306 when sharing beneficiary data via the Patient Access API. We remind states that in order to meet the requirements of that regulation, states must have consistent criteria for release and use of information (which should comply with the proposed Patient Access API requirements, if finalized), in accordance with 42 CFR 431.306(a). Access to information concerning beneficiaries must be restricted to persons who are subject to standards of confidentiality that are comparable to that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The

permission requirement at § 431.306(d), which requires that the State agency obtain permission from a family or individual, whenever possible, before responding to a request for information from an outside source, is not relevant to this proposal, because any request for beneficiary information would be from Medicaid beneficiaries themselves and the apps that they are authorizing to receive their information. Beneficiaries are not “outside sources,” and, while apps might be outside sources, information is shared with an app through this API only if the beneficiary has verified their identity (through authentication protocols) and authorized the app to receive information. We do not believe that any of the other requirements at section 431.306 are relevant because they cover data release and use in contexts outside of our proposals in this section. However, we welcome comments from state Medicaid agencies and other members of the public on this topic.

The proposed requirement to make information about prior authorization requests and associated documentation available through the Patient Access API is expected to allow beneficiaries to more easily obtain information about the status of prior authorization requests submitted on their behalf. Beneficiaries could potentially use that information to make more informed decisions about their healthcare, improve the efficiency of accessing and scheduling services, and, if needed, provide missing information that the state (or Medicaid managed care plan, if applicable) needs to reach a decision. Receiving missing information more quickly could enable more prompt responses from Medicaid FFS programs and managed care plans to prior authorization requests, thus 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 improve the efficient operation of the state plan by potentially improving the speed and consistency of prior authorizations, which could, in turn, facilitate faster access to care for beneficiaries. In these ways, these proposals are authorized under section 1902(a)(4), (8), and (19) of the Act.

In addition, this proposal would help implement section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance procedure under which a beneficiary who is eligible for medical assistance may challenge the denial of coverage or payment for such assistance. CMS has traditionally extended requirements applicable to Medicaid managed care organizations to other Medicaid managed care plan types as efficient and proper methods of administration under section 1902(a)(4) of the Act to ensure that Medicaid beneficiaries have the same protections, benefits, and responsibilities regardless of the type of managed care plan in which they are enrolled. Allowing beneficiaries to access the status of their denied prior authorizations within 1 business day could enable beneficiaries to file appeals timelier and receive faster resolution. Enabling beneficiaries to monitor the status of prior authorization requests submitted on their behalf is also consistent with how section 1932(c)(2)(A) of the Act indicates that timely access to care should be assured for beneficiaries. Knowing within 1 business day that a prior authorization has been approved could enable a beneficiary to more promptly schedule or obtain care.

We are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS annually. 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 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, and as is consistent with section 1902(a)(4) and (19) of the Act. Additionally, section 1902(a)(6) of the Act requires Medicaid state plans to provide that the state Medicaid agency will make such reports, in such form and containing such information, as the Secretary may from time to time 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 states that the purpose of Title XXI of the Act 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 patient access to their health information, 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.

We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP beneficiaries' prior authorization data and other standardized data available through standards-based APIs would ultimately lead to these beneficiaries 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) of the Act. 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 healthcare system, including CHIP.

These proposals align with section 2101(a) of the Act in that they also would improve the efficiency of CHIP programs. For example, adding information about prior authorization requests to the Patient Access API would allow beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This would in turn allow 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, the safeguards for applicant and beneficiary information at subpart F of 42 CFR part 431 are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As discussed above for Medicaid, giving CHIP beneficiaries access to their prior authorization statuses through the Patient Access API would be related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a purpose directly related to state plan administration. Allowing beneficiary access to prior authorization statuses also conforms with provisions for beneficiary access to their records at 42 CFR 457.1110(e). We remind states that when they share beneficiary information through the Patient Access API, they must comply with the privacy protections at 42 CFR 457.1110 and the release of information provisions at 42 CFR 431.306.

Finally, proposing to require state CHIP agencies and CHIP managed care entities to report Patient Access API

metrics to CMS annually 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 API's uptake among patients, including how many only use it for a one-time setup consistent with 2107(b)(1) of the Act. 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.

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

We believe generally that certifying only health plans that take steps to make enrollees' prior authorization requests 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 enrollees' best interests. Having simple and easy access, without special effort, to their health information also would facilitate enrollees' ability to detect and report fraud, waste, and abuse—a critical component of an effective program. Adding information about prior authorization requests 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 healthcare, 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. This would also facilitate timelier and potentially more successful initial prior authorization requests. We encourage SBEs (including SBE-FPs) to consider whether a similar requirement should be applicable to QHP issuers on SBEs.

Finally, proposing to require QHP issuers on the FFEs to report Patient Access API metrics to CMS annually would help CMS assess the effect this API is having on enrollees and would inform how CMS could either enhance the policy or improve access or use through activities such as additional patient education. These data could help CMS understand how best to leverage this API, and patient 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 API

1. Background

In the CMS Interoperability and Patient Access final rule, we implemented policies regarding the Patient Access API (85 FR 25558) that would allow patients to access their health information through an app. Patients who do so could then share their information with their provider during an appointment. For example, during a visit with a provider, a patient could share specific diagnoses, procedures, and tests accessed through the Patient Access API and stored on their mobile smart device, which could help inform a discussion with their provider about their health status.

We also discussed the potential benefits of payers sharing patient health information directly with providers in that final rule (85 FR 25555) and encouraged payers to consider an API solution that would enable providers to access appropriate health information through the payers' APIs to support the delivery of care. We sought comment on the feasibility of implementing and maintaining a FHIR API for data exchange between payers and providers and received comments strongly supporting our concept to require data availability through a Provider Access API. Some commenters stated that allowing providers to receive data, including prior authorization information, directly from payers would make FHIR-based data exchange significantly more valuable for patients, providers, and payers. More data could be available to help providers manage an individual's total care and providers could reduce or eliminate duplicate tests, which might avoid diagnostic errors. Payers might also see fewer duplicate requests for services, fewer appeals and, possibly, lower costs. We specifically agreed with commenters that making information about prior authorization decisions available via an API would reduce burden on providers and their staff (85 FR 25541).

While using the Patient Access API is a significant first step toward sharing individual patient health information with providers, it would also be beneficial for payers to make patient data directly available to providers via a FHIR API. In the normal course of business, many providers already maintain EHRs and share data for a variety of purposes authorized by the patient and/or existing law. Therefore, in this rule we propose to require that impacted payers implement and maintain a FHIR API that makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. The proposed Provider Access API has the potential to allow payers to build upon their existing systems and processes to enhance access to patient data, while continuing to protect patient privacy and data security.

In the December 2020 CMS Interoperability proposed rule, we proposed to require payers to build a Provider Access API. As discussed in section I.A. of this proposed rule, we are withdrawing the December 2020 CMS Interoperability proposed rule and issuing this new proposed rule that incorporates the feedback we received from stakeholders on that proposed rule. We understand that many readers may already be familiar with that proposed rule. To distinguis

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2022-26479. Public record. Not legal advice.