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

Federal RegisterDec 13, 2022

Ask Donna

What actually matters in this document.

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

Electronically.

You may submit electronic comments on this regulation to

https://www.regulations.gov.

Follow the “Submit a comment” instructions.

By regular mail.

You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-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.

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)

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

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.

See 45 CFR parts 160 and 164.

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.

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.

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

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.

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.

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.

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,

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.

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.

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.

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.

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.

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.

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.

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.

See 45 CFR 164.524(c)(2).

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.

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.

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.

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.

HL7 International (2022, May 28). HL7 FHIR Release 4. 6.1.0 FHIR Security. Retrieved from

http://www.hl7.org/Fhir/security.html.

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.

For more information about what laws may apply to health apps, see

https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.

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.

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.

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.

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.

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.

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.

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.

CARIN. The CARIN Alliance Code of Conduct (May 2020). Retrieved from

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

Office of the National Coordinator. Model Privacy Notice (MPN). Retrieved from

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

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.

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

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.

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.

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.

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)

and the IAS Exchange Purpose Implementation SOP.

26 27

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.

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.

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.

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.

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.

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 distinguish between that proposed rule and our proposals herein, we refer readers to section I.A. of this proposed rule, which outlines the overarching differences between the two proposed rules.

We are again proposing to require impacted payers to implement and maintain a FHIR API to exchange data with providers, but with changes from the December 2020 CMS Interoperability proposed rule. We are again proposing a FHIR API, but we are now taking a different approach to the standards required for the API, as further described in section II.F. of this proposed rule. We are also proposing a patient opt out (rather than an opt in) policy that would require payers to allow patients to opt out of the Provider Access API proposed herein. Finally, we propose to establish the Provider Access API compliance date as January 1, 2026.

As mentioned in section I.A. of this proposed rule, these proposals do not pertain to Medicare FFS. We seek comment on how each of our proposals discussed below on Provider Access API could be implemented for the Medicare FFS program. We expect that a Medicare FFS implementation would conform to the same proposed requirements that apply to the impacted payers under this proposed rule, as applicable, so Medicare FFS providers and patients enrolled in Medicare FFS could also benefit from this type of data sharing. We seek comment on whether this

could be implemented as proposed for the Medicare FFS program, how we could apply each of these proposals below, and if there would be any differences for implementing the Provider Access API in the Medicare FFS program as a Federal payer. As noted later in this section of this proposed rule, CMS's Data at the Point of Care (DPC) project is currently piloting an API that makes Medicare FFS claims and Part D data available to certain providers. We note that because Medicare FFS provider remittances and enrollee cost-sharing information are not proprietary, those data are shared in the DPC pilot; however, as discussed in this section, impacted payers would not be required to share that information under our proposals. The information gained from the DPC pilot will be useful to implementers should the proposals in this proposed rule be finalized.

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

In the CMS Interoperability and Patient Access final rule (85 FR 25558), we required impacted payers to make certain health information available to health apps when requested by a patient, through a Patient Access API. We believe it would be valuable for providers to have access to the same patient data, except for provider remittances and enrollee cost-sharing information, through a FHIR API that allows a provider to request data for an individual patient, as needed, thereby providing further insight into the patient's care activity. Research shows that patients achieve better outcomes when their record is more complete and there are more data available to the healthcare provider at the point of care.

Making more comprehensive information available to providers could thus improve the care experience for patients. Ensuring that providers have access to relevant patient data at the point of care could also reduce the burden on patients to recall and relay information during an appointment and/or provide confirmation that the patient's recollection of prior care is accurate.

Office of the National Coordinator for Health Information Technology (2019, June 4).

Improved Diagnostics & Patient Outcomes.

Retrieved from

https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.

Therefore, we are proposing to require that impacted payers implement and maintain a Provider Access API to enable current patients' information to be exchanged from payers to providers that are in that payer's network, at the provider's request. A provider in the payer's network, for purposes of this proposal, would be any provider or healthcare facility that is part of a specific health plan's network of providers with which it has a contract. In the case of Medicaid and CHIP FFS programs, it would be any providers or healthcare facilities that are enrolled with the state as Medicaid or CHIP providers. We note that this requirement would only apply to current patients. Once a patient is no longer enrolled with a payer, the payer would not need to share data with providers under this proposal. However, see section II.C. for the proposed Payer-to-Payer API requirements for transferring a patient's data from a previous payer to a new payer.

The proposed Provider Access API would allow a provider to initiate a request, for example, when the provider needs access to a patient's data prior to or during a patient visit. Both this proposed Provider Access API and the Patient Access API would facilitate the FHIR-based exchange of claims and encounter data, as well as all data classes and data elements included in a content standard adopted at 45 CFR 170.213, such as Immunizations, Procedures, and Assessment and Plan of Treatment, should the payer maintain such information. Both the Patient Access and Provider Access APIs would require payers to share information related to prior authorization requests and decisions (including related administrative and clinical documentation) for items and services (excluding drugs). As discussed in section II.A.2.a of this proposed rule, we are 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 payers to share a patient's full prior authorization history, because that could comprise a significant amount of information that may no longer be clinically relevant.

We believe that sharing claims and encounter information, without provider remittances and enrollee cost-sharing information, would complement the clinical data classes and data elements included in a content standard at 45 CFR 170.213 by providing more information to support treatment and care coordination. Claims and encounter data used in conjunction with clinical data can offer a broader, more complete picture of an individual's interactions with all their providers in the healthcare system. With this proposal, we intend to help providers gain efficient access to more comprehensive data on their patients. Thus, we are proposing to require that impacted payers make available any of the applicable patient data with a date of service on or after January 1, 2016. This proposed timeframe for data to be included is consistent with the requirements of the Patient Access API, as finalized in the CMS Interoperability and Patient Access final rule (85 FR 25567), so payers should already be maintaining and making available data from this timeframe via a FHIR API.

Such disclosures from payers to healthcare providers would be permitted under the HIPAA Privacy Rule as disclosures for treatment purposes,

as well as disclosures required by law,

which this proposed rule would be establishing if finalized. Additionally, Medicaid and CHIP agency disclosures of beneficiary data to in-network providers under this proposal would be consistent with section 1902(a)(7) of the Act and implementing regulations at 42 CFR part 431, subpart F, and 42 CFR 457.1110(b). Under these provisions, states must restrict the use or disclosure of information concerning applicants and beneficiaries to purposes directly connected with the administration of the plan. The disclosures of patient data through the Provider Access API would be directly related to the administration of the state plan because they would support the provision of services for beneficiaries, as described in 42 CFR 431.302(c). As mentioned, a provider could better manage a patient's total care when they have access to more of that patient's data because the data would provide a more in-depth medical history, enable more informed decision making, and potentially prevent the provision or ordering of duplicative services. Additionally, states must apply the safeguards described in 42 CFR 431.306 when sharing beneficiary data via the Provider Access API. We remind states that in order to meet the requirements of that regulation, they must have consistent criteria for release and use of information (which should comply with the proposed Provider Access API requirements, if finalized), in accordance with 42 CFR 431.306(a). Access to information concerning

beneficiaries must be restricted to persons or agency representatives 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 in § 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 an enrolled Medicaid or CHIP provider and thus would not be from an “outside source.” A Medicaid or CHIP provider would have a provider agreement with the Medicaid or CHIP agency in order to provide Medicaid or CHIP benefits and services under its state plan. As such, Medicaid and CHIP providers are part of the state's Medicaid and CHIP program assisting the state agency in carrying out core functions of the state's Medicaid or CHIP State Plan, providing benefits and services to beneficiaries. Therefore, no additional consent from the beneficiary or personal representative would need to be obtained by the Medicaid or CHIP agency prior to sharing the individual's information with a Medicaid or CHIP provider. We note that while patient permission is not required under § 431.306(d) for the proposals we discuss here, state, or other laws may require such permission. We do not believe that any of the other requirements of 42 CFR 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.

See 45 CFR 164.506(c)(2).

See 45 CFR 164.512(a).

There are a few notable differences between the requirements for a Patient Access API and our proposals for a Provider Access API. The biggest difference is how and why the end user would access the data. For the Patient Access API, the patient is requesting access to their own data through a health app for their own reference and use. For the Provider Access API proposals, the provider would request and receive access to the patient's information through their EHR, practice management system, or other technology solution for treatment purposes, including care coordination. Providers would securely access their patients' data using at least one of these systems through a FHIR API. Providers would not access patient data through their own health app; rather, the data would flow from the payer to the provider's EHR or practice management system, which would allow them to incorporate the patient data into their records. For example, a provider who is preparing for an upcoming appointment may need more information about the patient than is contained in the patient's record. Under this proposal, the provider would be able to request the additional data from the patient's payer, provided the patient has not opted out (as explained in section II.B.3.b. of this proposed rule). The payer would then be required to share the requested data no later than 1 business day after the provider initiates this request.

Finally, unlike the Patient Access API, we propose that the Provider Access API would not include provider remittances and enrollee cost-sharing information. Many payers consider cost-sharing information proprietary, and we believe that information would have limited benefit for treatment or care coordination. We note that our proposals in section II.C. of this proposed rule would exclude provider remittances and enrollee cost-sharing information from the payer to payer data exchange, and we propose the same for the Provider Access API.

In the CMS Interoperability and Patient Access final rule CMS required standards for the Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). In this proposed rule, we are proposing to amend these cross references, as discussed in section II.F. We also propose, at the CFR citations listed in Table 2, that the Provider Access API would require adherence to the same technical standards, API documentation requirements, and standards for denial or discontinuation of access to the API. Additionally, we note that unlike for the Patient Access API, we are proposing to require the FHIR Bulk Data Access Implementation Guide at 45 CFR 170.215(a)(4). For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526) and to section II.F. of this proposed rule.

We acknowledge that it could be helpful for all providers to have access to their patients' data regardless of contractual or enrollment relationships with a patient's payer. However, if a provider does not have a provider agreement or is not enrolled (in the case of Medicaid and CHIP FFS programs) with a payer that holds their patient's data, the payer would not be required to provide patient data to that provider under this proposal, though it may be permissible or even required by other law or regulation. We recognize that this could make it more difficult for an out-of-network provider to create a comprehensive care record for a patient. We considered requiring payers to share the data with all providers, regardless of whether the provider is under contract or enrolled with the payer. However, for reasons we explain in this section of this proposed rule, we are not proposing to do so, and are instead seeking comment on various issues surrounding that possible requirement. Though we are not proposing to require it at this time, we encourage payers to share information via API with out-of-network or unenrolled providers who have a verified treatment relationship with the patient, to the extent permitted by law.

There could be privacy, security, and program integrity concerns with requiring payers to share patient information with out-of-network providers. For example, because MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must ensure they do not enroll or contract with providers that are on the HHS Office of the Inspector General List of Excluded Individuals/Entities (LEIE), limiting data sharing through the Provider Access API to in-network or enrolled providers can help ensure these data are not shared with providers who have already been determined by the Federal Government to present fraud or other program integrity risks. Since these risks exist, if we were to require payers to share patient information with out-of-network providers, we would also have to require payers to establish safeguards to ensure that an out-of-network provider would be a trustworthy recipient of patient information. This could create significant burden for payers who may need to expend resources towards vetting providers with whom they do not have an existing relationship.

The LEIE does not apply to QHPs, but in order to offer coverage through the FFEs, they must comply with certification rules per 45 CFR part 156, which includes requirements to prevent QHP issuers from contracting with providers known to submit fraudulent or wasteful claims. For example, § 156.810(a)(7) specifies that a QHP issuer may be decertified if, based on credible evidence, they have committed or participated in fraudulent or abusive activities, including submission of false or fraudulent data. Section 156.340 provides that a QHP issuer is responsible for its own compliance and the compliance of any of its delegated or downstream entities with all applicable Federal standards related to Exchanges. Per § 156.20, “delegated entity” means any party that enters into an agreement with a QHP issuer to

provide administrative services or health care services (for example, contracted providers). Section 156.20 also defines a “downstream entity” as any party that enters into an agreement with a delegated entity or with another downstream entity to provide administrative services or health care services (for example, subcontracted providers). Thus, in order to maintain certified status, QHP issuers generally must have processes in place to avoid contracting with providers that engage in fraudulent practices. QHP issuers that also provide out-of-network coverage can make the determination of whether or not to share data with out-of-network providers using their existing processes.

As we consider imposing a requirement to share patient data with out-of-network providers through future rulemaking, we request comment on how payers do so today, the effectiveness of current processes to validate the treatment relationships between patients and providers when a contractual relationship does not exist between the provider and the payer, and what additional program integrity safeguards might be appropriate when other contractual mechanisms are not in place to ensure that patient data are provided only to qualified, trustworthy providers. We are particularly interested in the following questions: How would out-of-network providers request access to their patients' data and demonstrate that the provider has a treatment relationship with the patient? What processes and verification requirements would we need to require each payer to establish to verify the patient-provider treatment relationship? Should payers consider certain provisions in data use or data exchange agreements? If so, what could those provisions address? What are current best practices for terms of service? What other operational best practices for enabling safe data exchange with out-of-network providers should CMS consider in determining whether to propose a policy requiring this?

We emphasize that all data shared and received via this proposed data exchange would still have to be handled in a way that is consistent with all current and applicable laws and regulations, and our proposals are not intended to modify those other laws. Payers and healthcare providers that are covered entities under HIPAA are subject to the HIPAA Rules. Adherence to the HIPAA Rules would ensure that the provider disclosing patient data through the Provider Access API has appropriate security protocols in place.

These include, but are not limited to, administrative and technical safeguards such as access authorization and audit controls.

Regardless of whether a provider meets the definition of a covered entity under the HIPAA Rules at 45 CFR 160.103,

there may also be state laws that require certain privacy and security protections for health information exchange. Additionally, other laws, such as the regulations that focus on confidentiality of patient records associated with substance use disorder at 42 CFR part 2 or state privacy laws, may require the payer to obtain the enrolled individual's permission to disclose certain PHI. We request comment on any other considerations regarding state privacy or other laws that may be implicated by our proposals.

See 45 CFR part 164, subparts A and C.

Department of Health and Human Services (2022).

Security Rule Guidance Material.

Retrieved from

https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es.

Under the HIPAA Rules at 45 CFR 160.103, a “covered entity” includes a health care provider who transmits any health information in electronic form in connection with a transaction covered by the subchapter; see also definitions of health care provider and transaction at

https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103.

We are proposing to require, at the CFR citations identified in Table 2, that impacted payers share certain patient information with in-network and enrolled providers who have a treatment relationship with the payers' patients upon request by the provider. Thus, payers would be required by regulation to make such disclosures if there is a treatment relationship with the individual. The HIPAA Privacy Rule permits a covered entity, such as a health plan, to disclose PHI of the enrolled individual to a health care provider without individual authorization for treatment purposes under 45 CFR 164.506(c)(2) or as required by law per 45 CFR 164.512(a)(1).

Our proposal would not alter any obligation for HIPAA-covered entities to follow the HIPAA Rules or other applicable law, including, but not limited to, standards regarding the use and disclosure of PHI, administrative, physical, and technical safeguards and other security provisions, and breach notification. The security framework of the proposed API, as required via reference to standards at 45 CFR 170.215, would allow payers to verify the requesting provider's identity by using the required authorization and authentication protocols. Authorization refers to the process by which the payer would give the provider permission to access data. The authentication protocols are those that would allow the payer to ensure that the provider that is requesting this access is who they say they are. In addition to using these required protocols, the payer would be required to share the specified data only if it can also attribute the patient to the provider using an attribution process, as discussed in this section of this proposed rule in detail. While FHIR itself does not define security-related functions, used in combination with appropriate security controls (such as authentication and access control), a FHIR API can and should be implemented in compliance with the HIPAA Security Rule for secure data exchange.

Health Level Seven International (2022).

FHIR Security.

Retrieved from

http://www.hl7.org/Fhir/security.html.

HIPAA also requires the Secretary to adopt standards for specific transactions and establish a process for updating those standards. A HIPAA transaction is an electronic transmission of information from a covered entity to carry out financial or administrative activities related to health care (for example, when a health care provider sends a claim to a health plan to request payment for medical services) for which the Secretary has adopted a standard. Under HIPAA, HHS is required to adopt standards for electronically transmitting certain health care information, including:

• Health care claims or equivalent encounter information;

• Health care electronic funds transfers and remittance advice;

• Health care claim status;

• Eligibility for a health plan;

• Enrollment and disenrollment in a health plan;

• Referrals certification and authorization;

• Coordination of benefits;

• Health plan premium payments; and

• Medicaid pharmacy subrogation (not mandated under HIPAA, but, consistent with section 1173(a)(1)(B) of the Social Security Act, a standard has been adopted for this purpose).

The Secretary has adopted a HIPAA transaction standard for transmitting claims or equivalent encounter information. Although our proposals would facilitate sharing claims data from payers to providers, the transmission would not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.

We are also not proposing a mechanism to

report health care encounters in connection with a reimbursement contract that is based on a mechanism other than charges or reimbursement rates for specific services.

Therefore, a HIPAA transaction standard is not required to be used for our proposals in this section because the Secretary has not adopted a HIPAA standard applicable to communicating claims or encounter information for a purpose other than requesting or issuing payment.

See 45 CFR 162.1101(a) and 162.1601(a).

See 45 CFR 162.1101(b)

See 45 CFR 162.923(a).

In summary, we propose that beginning January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period 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 implement and maintain a FHIR API to exchange data with providers conformant to the standards discussed in section II.F and at the CFR citations referenced in Table 9. Individual patient data maintained by the payer with a date of service on or after January 1, 2016, must be made available via that API no later than 1 business day after the payer receives a request for data by an in-network provider, (or in the case of a Medicaid or CHIP FFS program, an enrolled Medicaid or CHIP provider).

We are proposing these requirements for the Provider Access API for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities (excluding Non-Emergency Medical Transportation (NEMT) PAHPs, as explained in this section of this proposed rule), and QHP issuers on the FFEs at the CFR sections identified in Table 2.

For Medicaid and CHIP managed care, we propose that NEMT PAHPs, as defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, and non-NEMT PAHPs would be subject to this proposed rule. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs, in that they only cover transportation and not medical care itself, justify their exclusion from the requirements of the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we do not believe that providers have routine need for NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access API would be an undue burden. However, we propose to include NEMT PAHPs in the scope of most of the other requirements of this proposed rule that apply to all other Medicaid managed care plans listed in Table 2.

We request public comment on the proposal for impacted payers to implement and maintain a Provider Access API to provide access to specified patient information.

3. Additional Proposed Requirements for the Provider Access API

In general, the proposals discussed in this section regarding the data that payers must make available through the API, as well as the technical specifications, align with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) and as proposed in section II.A.2. of this rule. We anticipate that this alignment would provide consistency and help payers build on the work done to comply with the requirements for the Patient Access API, outlined previously. Additional proposed requirements for the Provider Access API regarding attribution, patient opt out process, patient resources, and provider resources are discussed in the sections that follow.

a. Attribution

Patient attribution is a method of identifying a patient-provider treatment relationship. Attribution is a critical component to ensure that patient health data are shared only with appropriate providers. For the Provider Access API, we are proposing to require that payers develop an attribution process to associate patients with their providers to help ensure that a payer only sends a patient's data to providers who are requesting that data and who have a treatment relationship with that patient.

We are aware that the process of attribution can have many functions for payers, including managing contracts, payments, financial reconciliation, reporting, and continuity of care. In addition, HL7 has developed a member attribution process and workflow in the Da Vinci Member Attribution List FHIR Implementation Guide (IG), which defines various terms and describes a general process by which a payer and provider can coordinate and reconcile their understanding of which patients associated with a particular payer-provider contract.

This IG does not specify how the payer and provider identify these patients, but it does specify the FHIR resources (that is, data elements) which are created as an output of this process. We thus encourage payers to use processes that they may already have to attribute patients to their providers for these other purposes.

Health Level Seven International (2021, February 8).

Da Vinci Member Attribution (ATR) List.

Retrieved from

http://hl7.org/fhir/us/davinci-atr/.

A payer may implement a process to generate a provider's current patient roster using claims data, and only permit data exchange through the Provider Access API to providers with whom those patients can be attributed via claims data. For example, payers could accept proof of an upcoming appointment to verify the provider-patient treatment relationship. We know that many providers already verify coverage with the payer before a new patient's first appointment. If an in-network provider is seeing a patient for the first time, the provider's practice can send proof of the upcoming appointment to the payer. Once confirmed, this would then allow the provider to request the patient's data in preparation for the appointment. We further note that the Argonaut Project has developed an implementation guide specifying how to use FHIR's Scheduling and Appointment resources to communicate this information.

We request comments on other examples of how patients can be attributed to the providers from whom they are receiving care, especially for a new patient-provider treatment relationship. We also request comments on whether and how the payer could attribute the patient to the provider at the same time as or through the same data transaction.

Health Level Seven International (2022).

Argonaut Scheduling IG (Release 1.0.0).

Retrieved from

https://fhir.org/guides/argonaut/scheduling/.

CMS has implemented an attribution process in our DPC pilot for Medicare beneficiaries, which is the Medicare FFS version of the Provider Access API. The pilot project requires HIPAA-covered entities or their business associates to agree to certain terms of service

before data can be sent to them. The current Medicare FFS terms of service require each organization to maintain a list of patients which represents the patient population currently being treated at their facilities.

To add a new patient, CMS requires providers to attest that they have a treatment-related purpose for adding a patient to their group. This is accomplished by submitting an attestation with every request to add a

patient to their roster. This pilot will continue to test methodologies to accurately attribute patients to their providers. The information gained from this pilot may assist the industry to develop procedures to identify providers under this proposed requirement.

Centers for Medicare & Medicaid Services. (n.d.)

Data at the Point of Care. Retrieved from

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

Centers for Medicare & Medicaid Services. (n.d.)

Attestation & Attribution.

Data at the Point of Care. Retrieved from

https://dpc.cms.gov/docsV1#attestation--attribution.

Based on feedback from the industry, the HL7 Da Vinci attribution work group has developed a published Member Attribution List IG.

The Da Vinci Member Attribution List IG defines the mechanisms (that is, protocols), data structures and value sets to be used for exchanging the Member Attribution List. The Member Attribution List supported by the Da Vinci Member Attribution List IG typically contains: (1) plan/contract information which is the basis for the Member Attribution List, (2) patient information, (3) attributed individual provider information, (4) attributed organization information, and (5) member and subscriber coverage information. DPC has been working with the Da Vinci Member Attribution List team towards compatibility with this IG.

We also note that the list capability of this IG is informing updates to the Da Vinci Payer Data Exchange (PDex) IG.

We encourage payers to review the information from the workgroup.

Health Level Seven International. (2021, February 8).

Da Vinci Member Attribution (ATR) List.

Retrieved from

http://hl7.org/fhir/us/davinci-atr/.

Centers for Medicare Medicaid Services. (n.d.) Groups. Data at the Point of Care. Retrieved from

https://dpc.cms.gov/docsV2#groups.

Health Level Seven International (2020).

Da Vinci Payer Data Exchange.

Retrieved from

http://hl7.org/fhir/us/davinci-pdex/STU1/

We do not wish to be overly prescriptive about how payers could generate an attribution list for providers, but it would be necessary for payers to establish a process to meet these proposed attribution requirements for the Provider Access API. Because the standards for the attribution process continue to evolve, we are not specifying how payers should identify whether a specific patient can be attributed to the requesting provider. Instead, we encourage the community to continue to collaborate on viable approaches.

We also recognize that impacted payers may already have multiple arrangements in place with providers to support data exchange, and may even participate in community, local, state, or private health information exchanges (HIEs). In many cases, these HIEs include patient attribution capabilities for which payers may already have a process. Once again, our goal is for payers to avoid having to develop multiple approaches to address attribution, and we encourage collaboration on potential solutions.

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 maintain a process to associate patients with their in-network or enrolled providers to enable payer to provider data exchange via the Provider Access API.

We are proposing these attribution requirements for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans other than NEMT PAHPs, CHIP managed care entities, and QHP issuers on the FFEs at the CFR sections identified in Table 2.

We solicit comments on our proposal to require payers to develop processes for verifying the patient-provider treatment relationship, including any processes that may be in place today.

b. Opt Out

We are proposing that all impacted payers would be required to establish and maintain a process to allow patients or their personal representatives to opt out of having the patients' data available for providers to access through the Provider Access API. We note that this differs from our Payer-to-Payer API proposal in section II.C.3.c. of this proposed rule, under which all impacted payers would have an opt in process. Similar to the proposed attribution process, as previously discussed, we do not intend to be prescriptive regarding how this opt out process should be implemented, but payers would be required to make this opt out process available, and give all currently enrolled patients or their personal representatives a chance to opt out, before the first date on which patient information is made available via the Provider Access API. Specifically, we are proposing that impacted payers must maintain a process to allow patients or their personal representatives to opt out of data sharing, or if they have already opted out, to opt back in. The process for opting out and opting back in would have to be available before the first date on which patient information is made available via the API and at any time while the patient is enrolled with the payer. We are not proposing to require specific methods for patients to opt out, but anticipate that payers would make that process available by mobile smart device, website, and/or apps. We also anticipate that mail, fax, or telephonic methods may be necessary alternatives for some patients, which payers would have to accommodate if this policy is finalized as proposed. We invite comments on whether we should establish more explicit requirements regarding patient opt out processes.

Our proposal would require payers to allow patients to opt out of the Provider Access API data exchange for all providers in that payer's network. However, we also encourage payers to implement processes that allow more granular controls over the opt out process, so patients can opt out of having data exchanged with individual providers or groups of providers. We are not proposing implementation of such processes as a requirement in this rulemaking, as we are concerned about the potential administrative and technical burden this may place on some payers. However, we request comments about the technical feasibility of implementing an opt out process that would allow patients to make provider-specific opt out decisions, and whether we should consider proposing such a requirement in future rulemaking.

We are proposing an opt out approach because opt in models of data sharing, as we discuss in this section of this rule, have been shown to inhibit the utilization and usefulness of data sharing efforts between patients and healthcare providers. We acknowledge that there are positives and negatives to both opt in and opt out policies, and many patients may prefer to control or direct their health information via an opt in process because opt in policies require affirmative permission from a patient before their data can be shared. However, patients who are less technologically savvy or have lower health literacy may be less likely to use the Patient Access API, so having an opt out policy for the Provider Access API would facilitate sharing data directly with the provider, without requiring intervention by the patient. We believe this would promote the positive impacts of data sharing between and among payers, providers, and patients to support care coordination and improved health outcomes, which could lead to greater health equity. In formulating our proposal, we carefully weighed the issues related t

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

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