Thisdocumentisscheduledtobepublishedinthe
FederalRegisteron02/08/2024andavailableonlineat
DEPARTMENT OF HEALThHttpAs:/N/fDedeHraUlreMgisAterN.goSvE/dR/20V24I-C00E89S5,andonhttps://govinfo.gov
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-F]
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,
Childrens 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: Final rule.
SUMMARY: This final rule will improve the electronic exchange of health care data and
streamline processes related to prior authorization through new requirements for Medicare
Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Childrens
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). This final rule will also add new measures for eligible hospitals and critical access
hospitals (CAHs) to report underthe Medicare Promoting Interoperability Program and for MIPS
eligible clinicians to report under the Promoting Interoperability performance category of the
Merit-based Incentive Payment System (MIPS). These policies, taken together, will reduce overall payer and provider burden and improve patient access to health information while
continuing CMSs drive toward interoperability in the health care market.
DATES: These regulations are effective on [INSERT DATE 60 DAYS AFTER DATE OF
PUBLICATION IN THE FEDERAL REGISTER].
FOR FURTHER INFORMATION CONTACT: Alexandra Mugge, (410) 786-4457, for
general questions related to any of the policies in this final 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 Application Programming Interface (API).
Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-Payer API, the
Electronic Prior Authorization measures 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 final rule.
David Koppel, (303) 844-2883, for issues related to the data exchange policies generally,
Patient Access API policies, or patient privacy.
Scott Weinberg, (410) 786-6017, for issues related to the Provider Access API policies.
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.
Carolyn Kraemer, (301) 492-4197, 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: Table of Contents
I. Background and Summary of Provisions
A. Purpose and Background
B. Summary of Major Provisions
C. Specific Terms Used in this Final Rule
D. Global Comments
II. Provisions of the Proposed Rule
A. Patient Access API
B. Provider Access API
C. Payer-to-Payer API
D. Prior Authorization API and Improving Prior Authorization Processes
E. Extensions, Exemptions, and Exceptions; Federal Matching Funds for Medicaid and
CHIP
F. Electronic Prior Authorization Measures for the Merit-based Incentive Payment
System (MIPS) Promoting Interoperability Performance Category and the Medicare Promoting
Interoperability Program
G. Interoperability Standards for APIs
III. Collection of Information Requirements
IV. Regulatory Impact Analysis
I. Background, Summary of Provisions, and Terms
A. Purpose and Background
In the December 13, 2022 Federal Register (87 FR 76238), we issued the 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, Childrens 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 proposed rule (CMS Interoperability and Prior Authorization proposed rule), in which
we proposed new requirements for MA, state Medicaid FFS programs, state CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs (collectively impacted payers) to improve the electronic exchange of health care
information and streamline prior authorization for medical items and services. The proposed rule
also included proposals for new electronic prior authorization measures for MIPS eligible
clinicians (as defined at 42 CFR 414.1305) under the Promoting Interoperability performance
category of the MIPS, as well as for eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program.
This rule also builds upon the policies established 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, May 1, 2020) (hereinafter
referred to as the CMS Interoperability and Patient Access final rule).
We received nearly 900 timely pieces of correspondence containing comments on the
CMS Interoperability and Prior Authorization proposed rule. Some public comments were
outside of the scope of the proposed rule and those out-of-scope comments are not addressed in
this finalrule. Summaries of the public comments that are within the scope of the proposed rule
and our responses to those public comments are addressed in the various sections of this final
rule under the appropriate heading. However, in this section we address certain comments that
pertain across policies or to the rule overall. In this final rule, we are finalizing our proposals with modifications in response to
commenter feedback. Taken together, these final policies will help to increase health information
data exchange, streamline prior authorization process policies, and help to address a significant
source of provider burden and burnout to ultimately improve patients access to timely care.
B. Summary of Major Provisions
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 apps of their choice, to easily access their claims and encounter information as
well as clinical data, including laboratory results, provider remittances, and patient cost-sharing
pertaining to such claims, if maintained by the impacted payer (85 FR 25558).In this final rule,
we are finalizing our proposal to require that impacted payers include information about certain
prior authorizations in the data that are available through the Patient Access API. For those
changes to the Patient Access API, we are finalizing compliance dates in 2027 (by January 1,
2027, for MA organizations and state Medicaid and CHIP FFS programs;by the rating period
beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care
entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).
In addition, starting January 1, 2026, we are requiring impacted payers to annually report to
CMS certain metrics about patient data requests made via the Patient Access API. We are also
finalizing our proposal to directly reference the content standard at 45 CFR 170.213, so that the
data content requirement is automatically updated as HHSs Office of the National Coordinator
for Health Information Technology (ONC) adopts new versions. As of this final rules
publication, the content standards adopted at 45 CFR 170.213 are USCDI v1, which will expire
on January 1, 2026, and USCDI v3. To improve coordination of care across the care continuum and movement toward value-
based care, we are finalizing our proposal to require impacted payers to implement and maintain
a Provider Access API that is consistent with the technical standards finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558), including the Health Level Seven
(HL7) International Fast Healthcare Interoperability Resources (FHIR)Release 4.0.1
standard. Providers can use that API to access current patient data from payers, including
adjudicated claims and encounter data (excluding provider remittances and patient cost-sharing
information), all data classes and data elements included in a content standard at 45 CFR
170.213 (USCDI), and prior authorization information. For the Provider Access API policy, we
are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027
for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning
on or after January 1, 2027 for QHP issuers on the FFEs).
We are finalizing, with modifications, our proposal to require impacted payers to
implement and maintain a Payer-to-Payer API to exchange patient data when a patient moves
between payers to ensure continued access to their health data and support continuity of care
between payers. Specifically, the payer to payer data exchange will include adjudicated claims
and encounter data (excluding provider remittances and patient cost-sharing information), all
data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI), and
certain information about the patients prior authorizations. Impacted payers will be required to
request data from a patients previous payer, with the patients permission, no later than 1 week
from the start of coverage or at the patients request. Impacted payers will then be required to
integrate any data they receive in response to that request into the patients record, which could
facilitate care continuity as patients move between payers. We are finalizing a policy that payers
will be required to exchange five years of patient data,as opposed to the entire patient health
record. Five years of data are sufficient to support care continuity and continuation of prior authorizations as necessary, as well as maintaining patient access to their most recent data
without significant burden to payers. In addition, if a patient has two or more concurrent
impacted payers, the impacted payers will be required to exchange the patients data at least
quarterly, to ensure that all impacted payers have a more complete patient record. For the Payer-
to-Payer API policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs).
To improve the patient experience and access to care, we are also finalizing several new
requirements for prior authorization processes that will reduce burden on patients, providers, and
payers. To streamline the prior authorization process, we are requiring impacted payers to
implement and maintain a Prior Authorization API. In the proposed rule, we used the term Prior
Authorization Requirements, Documentation, and Decision API (PARDD API). For simplicity,
we are finalizing the name of that API as simply the Prior Authorization API. This name
change alone does not indicate any changes to the requirements or standards that we proposed.
Providers can use the Prior Authorization API to determine whether a specific payer
requires prior authorization for a certain item or service, thereby easing one of the major points
of administrative burden in the existing prior authorization process. The Prior Authorization API
will also allow providers to query the payers prior authorization documentation requirements
directly from the providers system, which could facilitate the automated compilation of
necessary information to submit a prior authorization request. For the Prior Authorization API
policy, we are finalizing compliance dates in 2027 (by January 1, 2027, for MA organizations
and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January
1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs). We are also finalizing our proposals to establish certain requirements for the prior
authorization process, regardless of whether the payer receives the prior authorization request
through the Prior Authorization API. We are requiring that impacted payers send notices to
providers when they make a prior authorization decision, including a specific reason for denial
when they deny a prior authorization request. We are also finalizing our proposal to require
impacted payers, except for QHP issuers on the FFEs, to respond to prior authorization requests
within certain timeframes. Finally, we are requiring all impacted payers to publicly report certain
metrics about their prior authorization processes, which will enhance transparency. For these
prior authorization process policies, we are finalizing compliance dates in 2026 (by January 1,
2026, for MA organizations and state Medicaid and CHIP FFS programs;by the rating period
beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care
entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).
We are finalizing, with modifications, our proposal for new electronic prior authorization
measures for MIPS eligible clinicians under the MIPS Promoting Interoperability performance
category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability
Program. To promote Prior Authorization API adoption, implementation,and use among MIPS
eligible clinicians, eligible hospitals, and CAHs, we are adding new measures 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 calendar year (CY) 2027 performance period/2029 MIPS payment
year and CY 2027 electronic health record (EHR) reporting period, respectively. As detailed in
section II.F. of this final rule, we are finalizing a modification to our proposal for the Electronic
Prior Authorization measure that will require a MIPS eligible clinician, eligible hospital, or CAH
to report a yes/no attestation or (if applicable) an exclusion, rather than a numerator and
denominator. We are additionally finalizing our proposals, with modifications, for more specificity as
to which of the required standards at 45 CFR 170.215 are applicable to each API. Impacted
payers will only be required to use the specifications that CMS has identified as necessary for the
Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior Authorization
APIs. Since the publication of the CMS Interoperability and Prior Authorization proposed rule,
ONC has published the Health Data, Technology, and Interoperability: Certification Program
Updates, Algorithm Transparency, and Information Sharing (HTI-1) final rule (January 9, 2024;
89 FR 1192) (hereinafter referred to as the HTI-1 final rule), which reorganized the structure of
45 CFR 170.215 to delineate the purpose and scope more clearly for each type of standard or
implementation specification. The standards we are finalizing in this rule, including updated
citations are as follows:
 Health Level Seven (HL7) FastHealthcare Interoperability Resources (FHIR)
Release 4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR).
 HL7 FHIR US Core Implementation Guide (IG) Standard for Trial Use (STU)
3.1.1, which expires on January 1, 2026, at 45 CFR 170.215(b)(1)(i) (US Core IG).
 HL7 SMART Application Launch Framework IG Release 1.0.0 which expires on
January 1, 2026, at 45 CFR 170.215(c)(1) (SMART App Launch IG).
 FHIR Bulk Data Access (Flat FHIR) IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1) (Bulk
Data Access IG).
 OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1)
(OpenID Connect Core).
We refer readers to the HTI-1 final rule for further information (89 FR 1192). More detail
about the required standards can be found in section II.G. and Table H3. We are also strongly
recommending that payers use specific IGs to supplement the required standards at 45 CFR
170.215. Additionally, we are finalizing our proposal to allow payers to voluntarily use updated
versions of the standards,specifications, or IGs for each of these APIs prior to the adoption of updated versions in regulation, subject to certain conditions and provided the updated standard
does not disrupt an end users ability to access the data available through the API. We are also
finalizing terminology changes related to the Patient Access API (in section II.A.2.d. of this final
rule). These policies will take effect on the effective date of the final rule.
We are finalizing, as proposed, some clarifications to existing Medicaid beneficiary
notice and fair hearing regulations that apply to Medicaid prior authorization decisions. Because
these are clarifications and improvements to existing regulations, as we proposed, Medicaid
agencies will have to comply with these policies upon the effective date of a final rule.
In our proposed rule, we proposed compliance dates in 2026 (by January 1, 2026, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs), for all policies
that require API development and enhancement. Based on commenter feedback and as noted
previously, we are delaying the compliance dates in this final rule for the provisions that require
API developmentand enhancement in 2027 (by January 1, 2027, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027,
for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning
on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally
refer to these compliance dates as in 2027 for the various payers.
We believe this approximately 3-year timeline to recruit and train staff, update, or build
the APIs, and update operational procedures will be sufficient to implement these policies, based
on comments and public information from some payers and providers regarding similar
initiatives already in progress. In addition to the 3-year implementation timeframe, we are
finalizing our proposal to give state Medicaid and CHIP FFS programs an opportunity to seek an
extension to the compliance dates, or an exemption from meeting certain requirements, in certain
circumstances. Additionally, we are finalizing our proposal to provide an exceptions process for QHP issuers on the FFEs. We believe the approximately 3-year timeframe for implementation in
the final rule will offer sufficient time for state Medicaid and CHIP FFS programs and QHP
issuers on the FFEs to determine whether they can timely satisfy the API development and
enhancement requirements in this final rule and to prepare the necessary documentation to
request an extension, exemption, or exception, as applicable.
Executive Order 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.1 CMS is committed to pursuing a comprehensive approach to advancing health
equity for all, and the policies in this final rule are aligned with that Executive order because they
represent efforts to mitigate existing inefficiencies in policies, processes,and technology that
affect many patient populations. Some patient populations are more negatively affected by
existing processes than others and should realize greater benefits through the improvements these
policies will provide. One of the main components of this final rule is our continued support for
the individuals 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.
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 by using secure technologies, such as Open
1ExecutiveOrder13985,sec.1,86FR7009(January20,2021). Authorization/Open ID (OAuth)2.0 and OpenID Connect Core for authentication,2 as previously
discussed in the CMS Interoperability and Patient Access final rule (85 FR 25520). While we
proposed policies that we believed would address some health care inequities, we solicited
comments about how to ensure that individuals from all communities and populations can
actively benefit from our health care interoperability proposals.
C. Specific Terms Used in this Final Rule
Our policies emphasize improving health information exchange and facilitating
appropriate and necessary patient, provider, and payer access to information in health records.
We also include several policies intended to reduce payer, provider, and patient burden by
improving prior authorization processes and helping patients remain at the center of their care.
Prior authorization refers to the process through which a health care provider, such as an
individual clinician, acute care hospital, ambulatory surgical center, or clinic, obtains approval
from a payer before providing care. Payers establish prior authorization requirements to help
control costs and ensure payment accuracy by verifying that an item or service is medically
necessary, meets coverage criteria, and, for some payers, is consistent with standards of care
before the item or service is provided. A prior authorization is made up of two partsa request
from a provider and a decision by a payer. We refer to the providers workflow and associated
information and documentation as the prior authorization request and the payers processes
and associated information and documentation as the prior authorization decision.
For purposes of this final 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 provisions of this final rule, as we believe that the standards
could be overly burdensome for both SADP and Small Business Health Options Program
2HealthLevelSevenInternational.SmartAppLaunchImplementationGuide,OpenIDandAuthenticationfor
SmartApps.Retrievedfromhttps://hl7.org/fhir/smart-app-launch/. (SHOP) issuers. We are finalizing an exceptions process for QHP issuers on the FFEs from the
API requirements; the grant of an exception is conditioned upon our annual approval of a
narrative justification, as further detailed in section II.E. of this final rule. For the purposes of
this finalrule, 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 will not be subject
to the requirements in this final 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 final rule, we use terms such as patient, consumer, beneficiary,
enrollee, and individual. Every reader of this final rule is a patient who has received or will
receive, medical care at some point in their life. In this final 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 policies herein, we will use additional,
specific terms applicable to individuals covered under the health care programs that we
administer and regulate. We also note that when we discuss patients, the term includes, where
applicable, a patients personal representative. For example, a patient or their personal
representative may opt into or out of certain types of information exchange under the policies in
this finalrule. But when we refer to a patients medical needs or health records, we do not
include the medical needs or health records of the patients personal representative. Per the
Standards for Privacy of Individually Identifiable Health Information (Health Insurance
Portability and Accountability Act (HIPAA) Privacy Rule)3 issued under HIPAA (Pub. L. 104-
191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), and related guidance, a
personal representative is a person authorized under state or other applicable law to act on
behalf of an individual in making health care-related decisions (such as a parent, guardian, or
3See45CFRparts160and164,subpartsAandE. person with a medical power of attorney).4 Under the HIPAA Privacy Rule (45 CFR part 164,
subpart E), the individuals personal representative generally may exercise the right to access the
individuals protected health information (PHI). For many processes described in this final rule,
a patients personal representative could act on a patients behalf, as permitted by the HIPAA
Privacy Rule and other applicable laws.
We also use terms such as payer, plan, and issuer in this final rule. Certain portions
of this final 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
provisions may not apply 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 final rule as
an inclusive term for all these entities and programs and, in the case of plans, plan types, but we
also use specific terms as applicable in various sections of this final rule.
We use the term policies that require API enhancement or development to describe the
requirements that involve technical development work to either establish a new API, such as the
Provider Access or Payer-to-Payer APIs, or to enhance the functionality of an existing API, such
as the addition of prior authorization data to the Patient Access API. We are finalizing these
policies with compliance dates in 2027. As discussed throughout this rule, we are finalizing a
modification to our proposal forcertain requirements by establishing compliance dates in 2027,
rather than in 2026, as we proposed. Specifically, those policies include adding prior
authorization information to the Patient Access API, implementing the Provider Access API
(including a process for patients to opt out and disseminating educational resources to patients
4U.S.DepartmentofHealthandHumanServices.HealthInformationandPrivacy.Retrievedfrom
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.htmland
https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html. and providers), implementing the Payer-to-Payer API (including processes for gathering
previous/concurrent payer information and for patients to opt in, and disseminating educational
resources to patients), and implementing the Prior Authorization API. We are not including in
the group of policies that require API enhancement or development terminology changes for
the Patient Access API, reporting Patient Access API metrics, changes to prior authorization
processes, reporting prior authorization metrics, Medicaid notice and fair hearings changes, the
MIPS and Medicare Promoting Interoperability measures, and updated standards. An explanation
of why we are establishing these deadlines for each policy is found in section I.D.2. of this final
rule and throughout this rule.
We use the term items and services when discussing prior authorization in this final
rule. Unless otherwise stated, the policies 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
final rule (for example, prescription drugs that may be self-administered, administered by a
provider, or that may be dispensed or administered in a pharmacy or hospital), because the
processes and standards for priorauthorization of drugs differ from the other items and
services included in our final policies. In the CMS Interoperability and Patient Access final rule,
we finalized policies that require payers to send claims data related to prescription and other drug
claims via a Patient Access API, and we are finalizing certain provisions related to claims data in
this finalrule. 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 patients record and
giving patients, providers, and payers access to claims data for prescription and other drugs can
offer valuable insights into a patients health care, 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 of drugs for the impacted payers in this final rule. Thus, while the claims data included in this final rule and existing policies do include
prescription and other drug claims, our policies in this final rule related to prior authorization 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 covered by an MA
(including an MA-PD) plan.
Additionally, we use the terms provider and supplier as inclusive terms composed of
individuals, organizations, and institutions that provide or furnish health services, such as
clinicians (that is, physicians and other practitioners), hospitals, skilled nursing facilities (SNF),
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 final rule, we finalize API provisions in which we refer to the API
functionality as a single API, though we acknowledge that payers may implement this
functionality by using one or multiple APIs. For example, while we refer to the Patient Access
API (discussed in section II.A. of this final rule) as a single API to describe the functionality,
payers may achieve the same functionality with one or multiple APIs, depending on the
implementation approach.
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, which are familiar in other aspects
of patients daily lives, such as travel and personal finance smartphone apps, which can function
without being integrated into the smartphones operating system. Standardized, secure, transparent, and pro-competitive API technology can provide similar benefits for patients of
health care services.5
Health Level 7 (HL7) is the standards development organization (SDO) that develops
the Fast Healthcare for Interoperability Resources (FHIR) standard and IGs referenced
throughout this final 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.6
Finally, throughout this final rule we discuss the APIs in relation to the programmatic
requirements to share data between payers, providers, and patients under specific rules.
However, payers could use these APIs to exchange data for myriad purposes, beyond those in
this finalrule. For instance, a patient could request data outside the scope of this final rule, or
program integrity entities could request data from payers (such as under the Inspector General
Act of 1978). Nothing in this final rule prevents payers from sharing the requested data via these
APIs, if technologically feasible, for appropriate purposes permitted by law. We encourage using
these standards-based APIs for purposes beyond our requirements to improve the interoperability
of health data, regardless of the use case.
D. Global Comments
CMS received nearly 900 timely pieces of correspondence in response to the CMS
Interoperability and Prior Authorization proposed rule. We summarize comments that are
globally applicable to the final rule here. In this section, we address comments related to
Medicare FFS implementation, the National Directory of Healthcare (NDH), final policy
compliance dates, exclusion of drugs from the prior authorization policies in this final rule, the
payers impacted by this final rule, the withdrawal of the Medicaid Program; Patient Protection
and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior
5 OfficeoftheNationalCoordinatorforHealthInformationTechnology(n.d.).ApplicationProgramming
Interfaces.Retrievedfromhttps://www.healthit.gov/api-education-module/story_html5.html.
6HealthLevelSevenInternational(2023).GuidetoUsingHL7Trademarks.Retrievedfrom
http://www.hl7.org/legal/trademarks.cfm?ref=nav. Authorization Processes, and Promoting Patients' Electronic Access to Health Information for
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed
Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges;
Health Information Technology Standards and Implementation Specifications proposed rule
(December 2020 CMS Interoperability proposed rule) (87 FR 76239), and compliance and
enforcement.
1. Medicare Fee-for-Service Implementation of Final Policies
Although these requirements do not directly pertain to Medicare FFS, we want to ensure
that people with Medicare can benefit from the policies in this final rule, 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 we solicited comments on how these proposals could apply to Medicare FFS.
We also encouraged other payers not directly impacted by this final rule to consider the policies
in this final rule for voluntary adoption to reduce burden and support greater interoperability.
A significant number of commenters expressed support for our intention to ensure that
Medicare FFS will comply with the requirements of this final rule by the compliance dates we
are establishing. We did notmake any policy proposals regarding this effort, but we are
considering comments as we plan our roadmap for implementation.
2. Compliance Dates and Enforcement
For our proposals that require API enhancement or development, we proposed
compliance dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and
CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid
managed care plans and CHIP managed care entities; and for plan years beginning on or after
January 1, 2026, for QHP issuers on the FFEs) (87 FR 76289) and indicated that we thought that
a 3-year timeline to recruit and train staff, update or build the APIs, and update operational
procedures would be sufficient. In the proposed rule we used the term implementation dates rather than compliance dates as we are using in this final rule. Because payers may implement
APIs before the compliance dates, we want to be clear when we are discussing the regulatory
deadlines in this final rule. This terminology does not indicate any changes to the substance of
any proposals or finalized requirements.
Comment: Many commenters expressed support for the proposed compliance dates in
2026. A commenter stated that the proposed compliance dates give impacted payers, health
information technology (IT) developers, and providers sufficient time to prepare for widespread
adoption and utilization. A commenter stated that the feasibility of implementation in 2026 will
depend on the complexities of the implementation and the date the final rule is published.
Another commenter suggested that CMS provide an implementation timeline with steps to
ensure all parties are ready for implementation in 2026. Another commenter wrote that CMS
should conduct pilots before the proposed 2026 compliance dates.
Multiple commenters recommended that CMS establish a shorter timeframe for the
revisions to the Patient Access API and the implementation of the new APIs. Commenters stated
that the benefits of our priorauthorization proposals are especially necessary and encouraged us
to finalize compliance dates as early as possible. A commenter recommended that CMS require
MA organizations to implement the requirements within 90 days of publication of this final rule.
Another commenter stated that they believe that MA organizations have the revenue and
resources to implement the provisions in CY 2024.
Payers have indicated that they are already collecting information about how patients are
using their Patient Access API, and many submitted comments based on the patient uptake they
are witnessing. We did not receive comments that indicated that collecting and reporting these
metrics would be a burden on payers.
Multiple commenters expressed concern regarding the proposed 2026 compliance dates,
for most of the requirements in the rule. Other commenters emphasized that payers would have
to begin work on implementation immediately following publication of this finalrule to meet all requirements by the 2026 compliance dates. Multiple commenters recommended that CMS delay
the compliance dates to 2027 or 2028, citing the feasibility of technology implementation and
operational changes.
Commenters indicated that state Medicaid and CHIP FFS programs may need more time
to implement because they need to secure funding and engage in the states procurement process.
A commenter recommended compliance dates no earlier than January 1, 2027, with state
Medicaid and CHIP agencies having the ability to request up to two 1-year extensions following
that date. The commenter noted that due to unique funding cycles and procurement requirements,
states could require more time than other payers to implement the proposed requirements.
Multiple commenters weighed in on the amount of time that payers will need to
implement the provisions in the proposed rule. Multiple commenters noted that the proposed
requirements for payers to implement four APIs within less than 3 years from publication of the
final rule would create a significant burden on payers. A commenter stated thatdevelopers will
need 12-18 months from the publication of a final rule to design, develop, test, and release
updated software. The commenter stated that payers will also need time to implement the
updated functionality and train staff to assist patients and other API end users. Another
commenter stated that developers would need 18 months per API. A commenter recommended
that CMS finalize any policies with at least 24 months of lead time. Another commenter
suggested that CMS provide at least 24 to 36 months after the publication of the final rule for
payers to comply. Other commenters suggested 3 years between publishing a finalrule and the
compliance dates. Several commenters recommended that CMS consider a staggered
implementation approach for the API requirements.
Commenters indicated that, of our proposals, the technical developmentand enhancement
of the required APIs would necessitate a longer implementation period than the prior
authorization process improvements. Response: Having taken into consideration comments about the implementation timeline
generally and about each of the policies specifically, we are finalizing our policies that require
API developmentor enhancement with compliance dates in 2027. Specifically, MA
organizations and state Medicaid and CHIP FFS programs must comply with those policies by
January 1, 2027; Medicaid managed care plans and CHIP managed care entities must comply
beginning with the first rating period that begins on or after January 1, 2027; and QHPs in FFEs
must comply by the first plan year beginning on or after January 1, 2027. For simplicity,
throughout this rule we generally refer to these compliance dates as in 2027 for the various
payers. However, we are finalizing some of our other policies with the proposed 2026
compliance dates, as noted in the Summary of Major Provisions.
Specifically, we are finalizing 2026 compliance dates for the requirements that impacted
payers report Patient Access API metrics to CMS, make standard and expedited prior
authorization decisions within specific timeframes, send notices to providers, including a specific
denial reason for denied prior authorizations, and publicly report prior authorization metrics on
their websites. While these policies require a certain level of development and implementation
effort, they are not as technically challenging as implementing the APIs. Thus, we believe a
nearly 2-year implementation timeframe is sufficient and will allow payers to prioritize them for
an earlier deadline.
Because impacted payers should already have Patient Access APIs implemented based on
requirements finalized in the CMS Interoperability and Patient Access final rule, reporting on
usage of that API should not be a significant burden to payers. We proposed to gather those data
to understand how the Patient Access API is being adopted across the industry. We do not
believe there is any benefit to delaying this reporting requirement, as we need these data to help
inform future policies.
Importantly, the prior authorization policies we are finalizing with 2026 compliance dates
should reduce the burden of prior authorization processes, even before the 2027 compliance dates for the API development and enhancement policies. Requiring impacted payers to send
provider notices, including a specific denial reason, respond within specific timeframes, and
report prior authorization metrics will apply regardless of how the payer received the prior
authorization request, and are not dependent on the API. Therefore, we do not believe there is a
reason to tie those requirements to the API compliance dates. Delaying the changes to prior
authorization timeframes and procedures would only delay the benefits of those new policies.
However, we are sensitive to the implementation burdens on payers, particularly for the
final policies that require API development or enhancement. We understand that payers need
time to design, develop, test, and implement major system changes to implementthe new
Provider Access, Payer-to-Payer, and Prior Authorization APIs. We considered finalizing
staggered API compliance dates between 2026 and 2027, as some commenters suggested, but
concluded that we are not in the best position to prioritize and understand what work can feasibly
be completed by 2026 and what scope is better in a second phase for 2027. Instead, we are
delaying the compliance dates for the three new APIs and modifications to the Patient Access
API by 1 year from the proposed compliance dates to allow payers time to sufficiently plan,
develop, test, and implement this technology. After considering the comments we received, we
agree with the volume of commenters that indicated that more than 2 years is necessary from the
publication of the final rule for payers to meet the new API requirements. In consideration of the
schedule for this final rules publication, we are finalizing compliance dates in 2027, for the new
Provider Access, Payer-to-Payer, and Prior Authorization API requirements in this final rule.
Throughout the final rule, we specify the exact regulatory citations that are being modified from
our proposed rule to reflect the finalized compliance dates for each payer.
We are addressing concerns specific to state Medicaid and CHIP programs with the
availability of an extension for Medicaid and CHIP agencies, under which states could seek to
delay implementation until 2028, as discussed in section II.E. of this final rule. In that section, we also discuss the possibility of states receiving enhanced Federal Financial Participation (FFP)
for expenditures related to implementing these requirements.
Comment: Many commenters expressed concern regarding the lack of discussion in the
proposed rule for mechanisms to ensure compliance with the provisions of the rule once
finalized. Multiple commenters recommended that CMS clearly outline how it will conduct
oversight and enforcement of the requirements in the rule and commenters recommended that
CMS outline a process for formal oversight, audit, and enforcement, including financial penalties
and other consequences to promote accountability. A commenter questioned the enforcement and
oversight activities for the CMS Interoperability and Patient Access final rule (CMS-9115-F).
Another commenter highlighted the lack of penalties for non-compliance with the Provider
Directory API. Other commenters recommended that CMS develop a structured process for the
public to report non-compliance. Multiple commenters recommended that CMS closely monitor
payer compliance and impose civil monetary penalties on payers that are non-compliant.
Response: As explained in the proposed rule and the CMS Interoperability and Patient
Access final rule, each CMS program oversees compliance under existing program authorities
and responsibilities for the different types of payers impacted by these API requirements (for
example, MA organizations, Medicaid programs, etc.). Oversight and compliance procedures
and processes vary among these CMS programs and CMS may choose from an array of possible
enforcement actions, based on a payers status in the program, previous compliance actions, and
corrective action plans. Therefore, we do not address specific potential compliance and
enforcement actions across impacted payers in this final rule, although we do discuss categories
of enforcement actions that CMS could consider for various payers in the discussion later in this
section. Patients and providers may submit an inquiry or complaint to the appropriate authority,
depending on their coverage.
For MA organizations, because these are program requirements, depending on the extent
of the violation, CMS may take compliance actions from warning letters or requiring a corrective action plan, to enforcement actions including sanctions, civil money penalties and other
measures specified at 42 CFR part 422, subpart O. If an MA enrollee believes a plan is not
fulfilling its responsibilities with respect to the API requirements, they have a right to file a
grievance with a plan under the procedures at 42 CFR 422.564. Individuals may also submit
complaints about their MA plans to 1-800-MEDICARE and the online complaint system at
https://www.medicare.gov/my/medicare-complaint. The State Health Insurance Assistance
Programs (SHIP) are available to help Medicare beneficiaries, including with filing complaints.
When states use enhanced funding for expenditures related to system modifications or
enhancements, CMSs enforcement is based upon 45 CFR 95.612 (Disallowance of FFP) and the
methodology described in the Centers for Medicaid and CHIP Services (CMCS) Informational
Bulletin (CIB), Medicaid Enterprise Systems Compliance and Reapproval Process for State
Systems with Operational Costs Claimed at the 75 Percent Federal Match Rate, published May
24, 2023. If a state is not compliant with the requirements included in this final rule, the
appropriate program policy team will address compliance enforcement.
States are obligated by 42 CFR 438.66(b) and (c) to have a monitoring system for all of
their managed care programs, including the performance of each managed care plan, to ensure
that all managed care plans are fulfilling their contractual obligations. States report the results of
their monitoring activities in an annual Managed Care Program Annual Report, in accordance
with 42 CFR 438.66(e). Further, per 42 CFR 438.3(a), CMS must review and approve all
managed care plan contracts. Should information in a states Managed Care Program Annual
Report or contract indicate a need for improvement or correction, CMS would work with the
state to ensure that the issue is remedied. Patients or providers with concerns regarding Medicaid
or CHIP FFS should contact their state Medicaid or CHIP agency. Patients and providers can
contact Medicaid.gov@cms.hhs.gov if the state agency is not responsive.
For any concerns related to compliance by Medicaid managed care plans and CHIP
managed care entities, enrollees and providers should first contact their managed care plan or managed care entity. Enrollees or providers can contact the state Medicaid or CHIP agency to
report issues that they cannot resolve by working with the managed care plan or entity directly.
Consistent with the authority under 45 CFR 156.715, the Center for Consumer
Information and Insurance Oversight (CCIIO) performs compliance reviews of issuers in the
FFEs. In addition, 45 CFR 156.800 through 156.815 provides for additional enforcement
remedies including Civil Money Penalties (CMPs) and Notices of Non-Compliance (NONCs) as
well as paths to QHP issuer Suppression and Decertification. If enrollees in a QHP on the FFEs
or theirproviders have concerns aboutan issuers interoperability implementation, they should
first contact their health plan with questions. For issues that they cannot resolve by working
directly with the plan, enrollees and providers can contact the Marketplace Call Center at 1-800-
318-2596 (TTY: 1-855-889-4325).
CMS manages compliance with the HIPAA administrative transaction standards under
the authority of the administrative simplification rules.Complaints about non-compliance can be
submitted to CMS at https://asett.cms.gov/ASETT_HomePage.
3. Exclusion of Drugs
In the CMS Interoperability and Prior Authorization proposed rule, we stated thatwe
were excluding drugs from the Prior Authorization API and proposed process requirements for
prior authorizations because the standards and processes for issuing prior authorizations for
drugs differ from those that apply to medical items and services.
Under state Medicaid programs and the MA program, there are similar timing
requirements for prior authorizations for coverage of drugs. MA plans are required to respond to
expedited requests for Part B drugs within 24 hours (42 CFR 422.572) and to non-expedited
requests as expeditiously as the enrollee's health condition requires, but no later than 72 hours
after receipt of the request (42 CFR 422.568). Further, MA-PD plans that cover Part A, B, and D
benefits must comply with similar timelines in responding to prior authorization requests for Part
D prescription drugs (42 CFR 423.568, 423.572). Similarly, under Medicaid (both FFS and managed care), if a state requires prior authorizations for covered outpatient drugs, a response
must be provided within 24 hours of the request for prior authorization (see section 1927(d)(5) of
the Social Security Act (the Act) and 42 CFR 438.3(s)(6)). We acknowledge that other drugs do
not meet the definition of covered outpatient drugs, including cancer drugs, special treatments,
and other important medications, and thus are not subject to these prior authorization timeline
requirements.
Comment: A plethora of commenters provided input and requested that CMS reconsider
the proposal to exclude drugs and instead include drugs in the prior authorization policies for all
or some impacted payers.
Some commenters expressed support for CMSs exclusion of drugs from the proposed
requirements and CMSs decision to defer Prior Authorization API requirements for drugs to
future rulemaking. Multiple commenters recommended that CMS make clear the exclusion of
drugs from all the requirements in a final rule.
Response: We believe it is clear throughout this final rule that none of the prior
authorization policies apply to any drugs covered by any impacted payer. However, based on the
overwhelming number of comments in support of our reconsideration of the policy, and
additional conversations with SDOs and stakeholders, we will consider options for future
rulemaking to address improvements to the prior authorization processes for drugs.
Comment: Multiple commenters expressed disappointment that CMS excluded outpatient
prescription drugs from the prior authorization process and Prior Authorization API policies in
the proposed rule, explaining that drug prior authorizations constitute the majority of all prior
authorizations. Multiple commenters recommended that CMS reconsider the exclusion of drugs
from the proposed rule and suggested that CMS expand a final rule to include outpatient
prescription drugs covered under a medical benefit.
A few commenters specifically requested that CMS include drugs covered under a
medical benefit in the prior authorization process and Prior Authorization API policies in the final rule and explained that the exclusion was troubling because health plans may cover
physician-administered drugs and specialty drugs through a patients medical benefits, including
specialty drugs. A commenter urged CMS to include administered drugs, which are inextricably
related to other provider services. Some commenters stated that by failing to include
administered drugs throughout the proposed rule, CMS is failing to address the biggest culprit of
delay to timely care and administrative burden for cancer patients. Commenters described
barriers to access for prescriptions for specialty drugs, cancer drugs, and certain drugs for
chronic conditions that require ongoing re-authorizations. The commenters believed that
including prescription drugs in our prior authorization policies would improve the effectiveness
of this final rule and would support CMSs goals of reducing barriers and burdens in health care.
Response: While we acknowledge the request for reconsideration, when making the
decision to exclude prescription drugs from the proposed rule, we believed there would be
operational complexities in applying the requirements of this rule to prior authorization for
prescription drugs under current conditions and did not anticipate the overwhelming response to
that exclusion under currentconditions. Based on the scope and breadth of the comments, it is
essential for us to conduct a thorough evaluation of both existing policies and standards, and the
impact any mandatory changes will have on impacted payers, providers, and patients, as well as
on other policies before making a proposal for public consideration. We are committed to
ensuring transparency of the process, and the development of the right policy to support all
entities who might benefit. We anticipate engaging with the public on this topic in the near future
and encourage the public to provide additional feedback.
Comment: Many commenters questioned whether impacted payers are permitted to
include the functionality necessary to conduct prior authorization for drugs via the Prior
Authorization API. A commenter also requested that CMS require all payers to include drug-
related prior authorization requirements in the Prior Authorization API to ensure prescribers have
ready access to uniform policies, and patients have timely access to their medications. Another commenter recommended that CMS explain that even if prescription drugs are excluded from the
requirements, the rule does not prohibit the sharing of drug prior authorization data via the
Patient Access, Provider Access, and Payer-to-Payer APIs.
Response: While we did not propose a requirement for prior authorization policies for
drugs to be included in the Prior Authorization API, payers may add such coverage rules and
requirements to their APIs; nothing in this final rule prohibits broader use of the required Prior
Authorization API by impacted payers and we encourage them to do so to the extent permitted
by law. The scope of the IGs for the Prior Authorization API includes prior authorization for
medications covered under a medical benefit. We describe the IGs and the Prior Authorization
API in further detail in section II.D.2. of this final rule.However,we note that a FHIR API
cannot be used with a National Council for Prescription Drug Programs (NCPDP) SCRIPT
standard because the data elements have not yet been mapped. Also, the HL7 FHIR Da Vinci
Prior Authorization Support (PAS) IG states it SHOULD NOT be used for any medication that
is covered under a prescription drug program benefit where Prior Authorization is provided by
another electronic exchange process (for example, NCPCP SCRIPT).7
We confirm that nothing would prohibit an impacted payer from sharing the same
information about prior authorizations for drugs that they are required to share for items and
services via the Patient Access, Provider Access, and Payer-to-Payer APIs, if they choose.
Comment: A commenter sought clarification on whether the prior authorization
requirements would apply to supplies dispensed at a pharmacy, such as diabetic test strips. This
commenter stated that an API would likely not provide any additional benefit or improve the
timeliness of a decision and might increase handling timeframes while the API is in the early
stages of use. This commenter recommended that pharmacy dispensable supplies maintain their
current timeframes for coverage decisions. Another commenter recommended that CMS require
7HealthLevelSevenInternational(n.d.)UseCasesandOverview.Retrievedfrom
https://build.fhir.org/ig/HL7/davinci-pas/usecases.html#scope-of-work-flow. impacted payers to include durable medical equipment (DME) administered under the DME
benefit in the Prior Authorization API. Another commenter sought clarification on whether
therapeutic devices are excluded from the Prior Authorization API requirements.
Response: Supplies, including those dispensed at a pharmacy and DME, that are
considered medical benefits and are not prescription drugs, are subject to the prior authorization
requirements of this final rule. Payers will be required to include these supplies in their APIs, to
the extent they are covered as a medical benefit and require prior authorization. DME, for
example, includes continuous glucose monitors, test strips, lancets, orthotics, wheelchairs, and
other devices. All prior authorizations covered as a medical benefit, including those for DME,
supplies dispensed at a pharmacy, or therapeutic devices, must still meet the timeframe
requirements established in this final rule, regardless of whether the request is made through an
API or other means, as described in section II.D.4. However, for MA-PDs, this final rule
excludes the entire scope of Part D drugs, as defined at 42 CFR 423.100, from the scope of the
prior authorization requirements; therefore, certain supplies that are included in the definition of
Part D drugs at 42 CFR 423.100 are not subject to the prior authorization requirements adopted
here.
4. Impacted Payers
As stated previously, certain portions of this final rule apply to MA organizations, state
Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs. We received numerous comments
regarding applicability to the payers impacted by the rule and summarize these comments and
responses.
Comment: Many commenters supported CMSs proposed categories of impacted payers
for this rule. Specifically, commenters supported the inclusion of Medicaid and CHIP FFS,
which were excluded from the payer to payer data exchange requirements in the CMS
Interoperability and Patient Access final rule, and MA plans, which were excluded in the December 2020 CMS Interoperability proposed rule. Commenters noted that the benefits of
interoperable data exchange will only accrue if there is widespread adoption by payers across the
health care system.
Response: We appreciate the support for the proposed types of impacted payers and agree
that the more payers that implement the requirements of this final rule, the greater the beneficial
impact will be on patients.
Comment: A commenter requested clarification as to whether dental plans that provide
coverage to MA enrollees or Medicaid beneficiaries are impacted payers and encouraged CMS
to exclude those plans, akin to the exclusion of QHP issuers on the FFEs offering only SADPs.
Another commenter specifically encouraged CMS not to exclude SADPs and to include dental
plans for MA and Medicaid or CHIP managed care.
Response: We did not propose new interoperability or prior authorization standards on
SADPs on the FFEs because they have relatively lower enrollment and premium intake
compared to individualmarket medical QHPs. Requiring those plans to comply with the
requirements in this final rule could result in those issuers no longer participating in the FFEs,
which would not be in the best interest of enrollees. These plans are therefore outside the scope
of this final rule. We appreciate input from commenters who view prior authorization and
interoperability as important for SADP enrollees and will continue to monitor this issue and
work with stakeholders to understand how to best meet patient needs while considering the
potential burden on payers.
For Medicare beneficiaries enrolled in MA plans, when dental coverage is a supplemental
benefit covered by the MA plans, it is offered by the MA organization, directly or through
contract arrangements the MA organization uses to provide the MA supplemental benefit.
Regardless of the mechanism, the dental coverage is part of the MA plan itself and offered under
the MA organizations contract and bid with CMS, not a separate plan. MA organizations can project expenditures to comply with the policies in this final rule to incorporate into their overall
operational costs when setting premiums.
An organization that has a risk-based contract directly with a state to provide dental
benefits only to Medicaid and CHIP beneficiaries is usually a PAHP. We proposed, at 42 CFR
438.210 and 438.242 for Medicaid (applicable to separate CHIP through existing cross-
references at 42 CFR 457.1230(d) and 457.1233(d)), that all PAHPs other than Non-Emergency
Medical Transportation (NEMT) PAHPs, including those that cover dental benefits,would be
subject to the requirements of this rule. Per 42 CFR 438.4, capitation rates, which are required
for all risk-based MCOs, PIHPs, and PAHPs, must be projected to provide for all reasonable,
appropriate, and attainable costs that are required under the terms of the contract and for the
operation of the managed care plan for the time period, as well as the population covered under
the terms of the contract, in addition to meeting specific additional requirements at 42 CFR 438.4
through 438.7. Similarly, for separate CHIP, per 42 CFR 457.1201(c) and 457.1203(a),
capitation rates are based on public or private payment rates for comparable services for
comparable populations and must represent a payment amount that is adequate to allow the
MCO, PIHP, or PAHP to efficiently deliver covered services to beneficiaries in a manner
compliant with contractual requirements. Therefore, the concerns of upward pressure on
premiums that impact participation that are applicable to SADPs offered on the FFEs are not
present for Medicaid and CHIP risk-based managed care plans.
Comment: A commenter suggested that CMS define the term payer to encompass
health insurance issuers and group health plans subject to the Public Health Service Act.
Multiple commenters expressed their concern that private payers, commercial plans, and
employer-sponsored plans would not be subject to the rule requirements. A commenter
expressed concern regarding the 150 million Americans who are in employer-sponsored
coverage, who may not have access to the benefits of the proposed rule. Another commenter suggested that CMS could use its authority over the public sector
Consolidated Omnibus Budget Reconciliation Act(COBRA) group health plans to extend
interoperability requirements to those payers.
Response: We appreciate commenters supporting implementation of the policies by
private payers, commercial plans, and employer-sponsored plans. However, we proposed to
impose these requirements under our authority to regulate issuers in the Exchanges that CMS
operates, which does not apply to health insurance issuers and group health plans outside the
FFEs. There is nothing prohibiting those payers from implementing the provisions in this final
rule voluntarily, as long as there are no conflicts with other Federal or state laws, and we do
encourage those plans to voluntarily meet the requirements of this final rule to allow patients
they cover to have the same interoperable access to their data as impacted payers are required to
provide.
Title XXII of the Public Health Service (PHS) Act applies COBRA requirements to
group health plans that are sponsored by state or local government employers. They are
sometimes referred to as public sector COBRA to distinguish them from the Employee
Retirement Income Security Act of 1974 (ERISA) and Internal Revenue Code requirements that
apply to private employers. We did not make any proposals regarding public sector COBRA
plans, so they are not included as impacted payers in this final rule, but we will consider whether
we can and should propose similar interoperability requirements on such plans in future
rulemaking.
Comment: A commenter sought clarification regarding why CMS exempted SHOP
issuers from the proposed rule.
Response: As discussed in the proposed rule, we proposed to exclude QHP issuers
offering only QHPs in the FF-SHOPs. We believe that the proposed standards would be overly
burdensome for both SADP and SHOP issuers. Requiring issuers offering only SADPs and
issuers offering only QHPs in the FF-SHOPs, which have relatively lower enrollment and premium intake compared to individual market medical QHPs, to comply with our proposals,
could result in those issuers no longer participating in the FFEs, which would not be in the best
interest of the enrollees.
Comment: Multiple commenters recommended that CMS work with ONC and other
Federal agencies, such as the Veterans Administration (VA), the U.S. Department of Defense
(DoD), and other government payers, to bring additional data into the interoperability universe.
Response: We continue to work with ONC and agencies across the Federal Government
to move toward a fully interoperable health care system. We are committed to sharing any
insights and best practices from our experience working with impacted payers with other
agencies that provide health care coverage to inform their own interoperability goals. These are
independent agencies over which HHS has no authority.
5. Withdrawal of Proposed Rule
In the CMS Interoperability and Prior Authorization proposed rule, we explained that we
were withdrawing the December 2020 CMS Interoperability proposed rule (87 FR 76239). We
received multiple comments in support of this decision.
Comment: Commenters supported our withdrawal of the December 2020 CMS
Interoperability proposed rule. Several commenters expressed that the burden of prior
authorization has grown since that proposed rule was published and voiced their support for
finalizing our proposals.
Response: We appreciate the support and believe that the proposals that we are now
finalizing reflect the feedback we received from the health care industry.
6. National Directory of Healthcare
On October 22, 2022, we released a Request for Information (RFI) (87 FR 61018) to
solicit public comments on establishing an NDH that could serve as a centralized data hub for
health care provider, facility, and entity directory information nationwide. We also received
many comments to this proposed rule that discussed the possibility of an NDH, particularly to discover payers digital endpoints (in this case, a FHIR servers URL or IP address) to facilitate
our Payer-to-Payer API policy.
Comment: Many commenters stated that the lack of a national directory makes it difficult
to identify digital endpoints to facilitate payer to payer data exchange. Multiple commenters also
expressed how important an NDH would be to the success of a ProviderAccess API, because as
information on provider digital endpoints remains limited, widespread access to such a directory
could advance efforts to connect payers to providers. Commenters urged CMS to establish an
NDH before the API compliance dates and explained that not doing so could result in an
industry-wide scramble and search for verified plan endpoints necessary for implementation. A
commenter recommended that CMS establish and maintain a national payer directory that
includes verified information on payers, including their API endpoints, contact information for
their API project managers, and their readiness for participation in payer to payer data exchange.
Another commenter stated they are currently trying to set up their own Payer-to-Payer API and
encountered problems without a centralized location of payer endpoints. This led to issues
identifying a new member's previous payer and making secure connections to exchange
information. A commenter cautioned that a draft version of the National Directory IG developed
by the FHIR at Scale Taskforce (FAST) originally published in September 20228 describes a
payer to payer data exchange but is based on the projected existence of a national directory of
payer endpoints and governance framework. A commenter noted scalability issues that could
arise without a national directory of endpoints to connect in a unified and meaningful manner.
Response: We understand that a directory of payer and provider digital endpoints would
be highly beneficial to facilitate our Payer-to-Payer, Provider Access, and Prior Authorization
API requirements. Without such a directory, payers would need to discover other payers
endpoints one by one, and each payer would have to maintain a listof payers that they have
8HealthLevelSevenInternational(n.d.).NationalDirectoryofHealthcareProviders&Services(NDH)
ImplementationGuide.Retrievedfromhttps://build.fhir.org/ig/HL7/fhir-us-ndh/. previously connected with for data exchange. The Trusted Exchange Framework and Common
Agreement (TEFCA) provides a directory of digital endpoints that can be used by TEFCA
Participants.9
Additionally, CMS is committed to exploring an NDH that contains payers and
providers digital endpoints to facilitate more interoperable data exchange in healthcare for a
variety of use cases, including support for the Payer-to-Payer, Provider Access, and Prior
Authorization APIs.
9OfficeoftheNationalCoordinatorforHealthInformationTechnology(n.d.).TrustedExchangeFrameworkand
CommonAgreement(TEFCA).Retrievedfromhttps://www.healthit.gov/topic/interoperability/policy/trusted-
exchange-framework-and-common-agreement-tefca. II. Provisions of the Proposed Rule and the Analysis of and Responses to Public Comments
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 set 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 individuals
health care experience. Patients tend to receive care from multiple providers, leading to
fragmented patient health records where various pieces of an individuals 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 patients 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.
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 (at 42 CFR
422.119), state Medicaid and CHIP FFS programs (at 42 CFR 431.60 and 457.730), Medicaid
managed care plans (at 42 CFR 438.242(b)(5)), CHIP managed care entities (at 42 CFR
457.1233(d)), and QHP issuers on the FFEs (at 45 CFR 156.221), to implement and maintain
APIs that permit patients to use health apps to access specified data. The Patient Access API
must make available, at a minimum, adjudicated claims (including provider remittances and
patient 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. 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 clinicaldata are received. In the CMS Interoperability and Prior Authorization proposed rule, we proposed various changes to enhance the Patient Access
API that are discussed further elsewhere. We also received comments about the Patient Access
API more generally, which we summarize and respond to in this section.
To support the ongoing maintenance of the Patient Access API, we are requiring certain
specifications and recommending certain IGs, as further discussed in this section and in section
II.G. With the publication of the HTI-1 final rule, our cross references to 45 CFR 170.215 have
been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR
170.215 and versions of the API standards codified there are discussed further in section II.G.
and reflected throughout this final rule. For the Patient Access API, impacted payers must use
the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU
3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45 CFR
170.215(c)(1) and OpenID Connect Core 1.0 at 45 CFR 170.215(e)(1). Impacted payers are
permitted to voluntarily use updated standards, specifications, or IGs that are not yet adopted in
regulation for the APIs discussed in this final rule, should certain conditions be met. For the
standards at 45 CFR 170.215 required for the Patient Access API, updated versions available for
use under our policy include, but are not limited to, US Core IGSTU 6.1.0 and SMART App
Launch IGRelease 2.0.0, which have been approved for use in the ONC Health IT Certification
Program.10 We refer readers to policies finalized for the Patient Access API in the
Interoperability and Patient Access final rule, as well as section II.G.2.c. of this final rule for a
full discussion on using updated standards. We are also recommending payers use the HL7
FHIR CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button) STU
2.0.0, HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, and HL7 FHIR
Da Vinci PDex US Drug Formulary IG STU 2.0.1. We also direct readers to section II.G. of this
10OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap. final rule for a discussion of the standards for the Patient Access API, and Table H3 for a full list
of the required standards and recommended IGs to support API implementation.
Comment: Multiple commenters expressed general support for the Patient Access API, as
it would promote transparency and improve patient access to health data. Many commenters
agreed that the proposed modifications to the Patient Access API would improve patient
engagement, shared decision making, and be an opportunity for patients to improve health
literacy. Commenters stated that it is critical to ensure that data are shared interoperability to
prevent unnecessarily restrictive or expensive proprietary systems from inhibiting patient and
provider access. A commenter noted that the API places the patient at the center of care, which
could lead to improvements in quality care and a seamless patient experience. Other commenters
noted that it will help improve predictability for patients and help them identify potential
violations in mentalhealth parity law and facilitate better communication between patients and
providers. Another commenter noted that the most convenient way for patients to access their
health information is via apps.
Multiple commenters expressed support for the standardization of the Patient Access API
across different payer types and coverage programs. A commenter stated that establishing
standardized processes for the Patient Access API would benefit patients and enable them to
have efficient and secure access to their records while maintaining their privacy.
Response: We thank the commenters for their feedback and will continue to look for
ways to drive adoption and use of the Patient Access API to benefit patients. We agree that
requiring a standard API will unlock potential for developers to create patient-friendly apps.
Comment: Other commenters stated that they do not believe the Patient Access API will
be a dominant means for accessing health care data because patients may get similar or better
information elsewhere. Commenters stated that they have not seen significant uptake of health
apps since the implementation of the Patient Access API. Commenters relayed that while they
believe in the potential for the Patient Access API to improve the utility and portability of patient medical information, they have not seen robust utilization of these tools, possibly because many
payers have their own portals. Some commenters believe that their members prefer to speak with
a customer service representative, for instance, to discuss the status of their claims. Some payers
noted that although they currently have a low rate of members using apps, they anticipated
higher utilization as younger cohorts, who are more familiar with how smartphone apps can
benefit their care, reach the age of Medicare eligibility.
A commenter flagged that the Patient Access API could result in administrative costs
being spread over a smaller than expected user base due to its low utilization. They
recommended that CMS continue to monitor the utilization of the proposed APIs as it considers
new functionalities and requirements.
Multiple commenters expressed concerns that certain patients may not be able to access
the Patient Access API due to a variety of factors (for example, limited access to
technology/internet, software, or apps or low digitalliteracy), and they encouraged CMS to
consider how it can help patients with limited digital or broadband access to have equitable
access to necessary coverage information. Stating that some patients may not have access to the
appropriate software or app, multiple commenters recommended that CMS require states and
other entities to continue to provide written notices instead of relying on electronic
communication via the Patient Access API. Commenters also recommended that CMS continue
to monitor the Patient Access API usage and closely track any potential disparities in access due
to social determinants of health (SDOH) or differences in digital literacy.
Response: We understand that some patients cannot or may not want to access their
health information electronically or through a health app. Nothing in this rule will require
patients to use the Patient Access API to access their health information. Nor will the rule change
any applicable obligation for payers to make information available in non-electronic formats,
should such a requirement exist. For example, 42 CFR 435.918(a) requires Medicaid agencies to
give individuals the choice whether to receive notices electronically or by mail. Similar requirements for MA organizations can be found at 42 CFR 422.2267(d)(2). Furthermore, under
the HIPAA Privacy Rule, covered entities generally must provide individuals access to their PHI
in the form and format requested by the individual, if it is readily producible in such form and
format; or, if not, in a readable hard copy form or such other form and format as agreed to by the
covered entity and the individual.11
However, making available digital tools, such as standardized APIs and health apps that
can access them, aligns with how many people interact with other industries today, such as
banking and e-commerce. Making health information similarly available and interoperable
broadens patients options for accessing their records. While many patients may be satisfied
using their payers portal, and we do not wish to take that option away from them, using
proprietary systems and data formats has led to a health care system where patient data are
fragmented and often difficult to exchange between parties. Entities such as HIEs, health apps,
and TEFCA Participants and Subparticipants may be able to gather data from payers, providers,
and other sources to create a more comprehensive patient record than could be maintained by the
payer alone. Advances in nationwide data sharing,such as payers Patient Access APIs,
connections across HIEs, and exchange enabled by TEFCA, can facilitate secure and reliable
access to these data sources. That is the reason that CMS and HHS are invested in establishing
open standards and requirements for payers and providers to use standardized technology. While
many patients are most familiar with their payers portal, until the Patient Access API provisions
went into effect on January 1, 2021, their options may have been limited. We also anticipate that
adoption will take time as patients learn about their options and choose methods for accessing
their health information that work best for them.
Comment: Multiple commenters recommended that CMS ensure that the Patient Access
API allow caregivers and dependents to have access where patients have provided consent. A
commenter urged CMS to explain how an individual can ensure caregivers have access to their
11See45CFR164.524(c)(2)(i). health information via the Patient Access API. Another commenter recommended that CMS
explain that representatives should be included in all relevant communication and considered as
payers develop the API.
Response: Per the HIPAA Privacy Rule at 45 CFR 164.502(g), a personal representative
is a person authorized under state or other applicable law to act on behalf of the individual in
making health care related decisions (such as a parent, guardian, or person with a medical power
of attorney). With limited exceptions, a personal representative is treated as the individual for
purposes of the HIPAA Privacy Rule. Similarly, our existing Patient Access API policies (at 42
CFR 422.119(a) and (b)(1), 431.60(a) and (b), and 457.730(a) and (b) and 45 CFR 156.221(a)
and (b)) explicitly apply to patients personal representatives.
Payers likely have different processes and policies for designating someone as a personal
representative under the HIPAA Privacy Rule and also may be subject to similar state laws.
Nothing in this rule will require a change to those processes.Therefore, patients and personal
representatives should contact their payer for the steps to ensure appropriate access to
information via the Patient Access API. We do not explicitly require impacted payers to send to
their patients personal representatives the required educational resources. However, payers are
required to post those resources on their public websites and to convey them via other
appropriate mechanisms through which they ordinarily communicate with current patients. If
payers send other resources to personal representatives on a patients behalf, then educational
resources should be sent to them as well. In addition, there may be program- or state-specific
requirements to transmit such resources to a patients personal representative.
Comment: A few commenters recommended that CMS require payers to update patient
information that they are told is incorrect by a patient or provider.
Response: Under the HIPAA Privacy Rule, at 45 CFR 164.526, individuals have the right
to have a covered entity amend PHI or a record aboutthe individual in a designated record set for
as long as the PHI is maintained in the designated record set, with certain exceptions.The Patient Access API does not require the impacted payer to include the capability to send information
from a patient to a payer. Therefore, while patients have the right under the HIPAA Privacy Rule
to request that a HIPAA-covered entity (such as a provider or payer) amend their record, that
functionality is out of scope for the Patient Access API.
a. Prior Authorization Information
To enhance our policy finalized in the CMS Interoperability and Patient Access final rule,
we proposed in the CMS Interoperability and Prior Authorization proposed rule to add
information about prior authorizations to the categories of data required to be made available to
patients through the Patient Access API. We stated that this proposal would apply to all prior
authorization requests and decisions for items and services (excluding drugs) for which a payer
has data in the patients record, as discussed further in this section. We also proposed that the
Patient Access API must include certain information about prior authorizations within 1 business
day of receipt of, or change of status to, the prior authorization. The primary goal of the Patient
Access API is to give patients access to their health information, and by expanding patient access
to prior authorization information, we aim to help patients be more informed decision makers
and true partners in their health care.
As discussed in section I.D. of this final rule, our prior authorization proposals did 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,
drugs that may be dispensed or administered in a pharmacy or hospital, or over-the-counter
(OTC) drugs.
In section II.D. of this final rule, we finalize several proposals focused on making the
prior authorization process less burdensome for providers and payers, which we anticipate will
reduce delays in medically necessary access to covered items and services and improve patient
outcomes. Giving patients access to information about prior authorization requests and decisions
will enable them to take a more active role in their own health care. We are finalizing our proposal to require impacted payers to provide patients, through the
Patient Access API, with access to information about prior authorization requests and decisions
made fortheir care and coverage. However, we are finalizing a modification to our proposal and
not requiring payers to share the quantity of items or services used under a priorauthorization or
unstructured documentation related to a prior authorization, as discussed elsewhere in this final
rule. We are finalizing these changes with compliance dates in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), which is a year
after the proposed 2026 compliance dates.
Comment: A significant majority of commenters expressed supportfor CMSs proposal
to include prior authorization information in the Patient Access API. Commenters listed multiple
benefits to making prior authorization information available via the Patient Access API,
including empowering patients in their care, reducing the burden of repeated inquiries to payers,
and facilitating faster decisions by allowing patients to help providers submit the necessary
documentation. Multiple commenters highlighted current challenges for patients to access their
prior authorization information.
Response: We appreciate commenters feedback confirming the significant burden that
prior authorizations processes place on patients.We received comments from across the industry
that indicated that those processes could be improved by interoperable data exchange. Those
comments have informed the policies we are finalizing to require impacted payers to make
available via the Patient Access API certain information about prior authorizations.
Comment: Multiple commenters expressed concerns that because many patients do not
have an overall understanding of the prior authorization process, giving patients access to prior
authorization information would add to existing confusion, and that this information may be
overwhelming. Some commenters stated that they do not believe that additional requirements and burden on impacted payers around the Patient Access API are warranted based on current
app adoption by patients. The commenters stated that there should be greater Patient Access API
use before adding more requirements to the Patient Access API.
Commenters cautioned against creating any expectations for patientinvolvement in a
prior authorization process that they may not understand and over which they may have little
control. Other commenters recommended that CMS explore strategies to promote access to
timely prior authorization-related information for patients who cannot or do not want to use
health apps.
Response: We understand that not all patients will want to access their prior authorization
data,and some may not be able to fully understand the information that is presented to them.
However, we do not believe that this is a sufficient justification for not making those data
available to patients who want that access and insight into their care. We strongly encourage
payers to make data transparent and explain the processes involved in a patients coverage in an
easily understandable manner.
We do not intend to create expectations for patient involvement in the prior authorization
process but want to make that opportunity available where it can be beneficial to expedite prior
authorization decisions. To the extent that program-specific requirements do not already require
such disclosures to enrolled patients, we urge payers to make prior authorization information
available to patients regardless of what method they use to inquire about their coverage or care
whether that is an online patient portal, a phone call to customer service agents, or an e-mail
inquiry. However, our proposals in this section only addressed information available to patients
via the Patient Access API.
Comment: Some commenters stated that, because prior authorization requests today are
commonly submitted via multiple modalities, CMS should modify its proposal to require prior
authorization information be included in the Patient Access API only if it came from requests
submitted via a Prior Authorization API. Commenters flagged that prior authorization data received in non-standard formats, such as fax, would require significant resources for many
payers to translate into a standard format to be shared via the Patient Access API. Commenters
stated that adoption of electronic prior authorization by providers would be gradual, and it would
be administratively complex and burdensome to require payers to convert prior authorizations
submitted via phone or fax to electronic format. The commenters recommended that CMS make
sharing prior authorizations received via phone or fax optional for payers.
Response: We understand that data submitted for prior authorization requests via non-
electronic or non-standardized modalities could require an additional step to make available
through the Patient Access API. However, we also note that the burden of ingesting data from
non-standard and non-electronic requests into a payers prior authorization systems exists
regardless of the requirement to share data with the patient. While sharing requests submitted via
a Prior Authorization API might be simpler, as they are already in a FHIR format, we do not
believe that the burden of converting data from the format payers currently use in their prior
authorization systems outweighs the benefit of making prior authorization information available
to patients. We also note that the same prior authorization data are largely required to be shared
via the Provider Access and Payer-to-Payer APIs, thus creating an economy of scale by
spreading the benefit to all parties while the burden of data translation would only have to
happen once. We believe that all patients should have access to their prior authorization
information, regardless of the process between their provider and payer.
In section II.D. of this rule, we are finalizing a requirement for impacted payers to
implement and maintain a Prior Authorization API and in section II.F. of this rule, we are
finalizing a measure within MIPS to incentivize providers to use that Prior Authorization API.
We are finalizing those policies to promote the adoption of electronic prior authorization and,
therefore, expect that as electronic prior authorization increases over time, the overall burden of
making available prior authorization information submitted and received through other
modalities will decrease. We believe that payers will also encourage their providers to use electronic prior authorization to decrease that burden, which will lead to greater interoperability
and data availability for patients.
Also, if we required only prior authorization data submitted via a Prior Authorization API
to be available via the Patient Access API, we would be excluding patients whose providers may
not be able to implement electronic prior authorization for technological or other reasons.
Therefore, we are finalizing a Patient Access API policy that covers data from all prior
authorizations, regardless of the medium through which the payer receives the request.
Comment: A commenter noted challenges that state Medicaid agencies would face to
include prior authorization data in the Patient Access API. The commenter stated that there are
differences between how states process prior authorizations today, with some state Medicaid
agencies relying on manual processes.
Response: State expenditures on designing, developing, installing, enhancing, or
operating state Medicaid systems that can conduct electronic prior authorization may be eligible
for enhanced Federal financial participation. Implementation of the Prior Authorization API
should facilitate a faster and more automated workflow to make prior authorization data
available. We encourage states to take this opportunity to determine whether modernizing prior
authorization systems beyond the implementation of a Prior Authorization API can improve their
prior authorization processes. We describe the enhanced Medicaid Federal matching percentages
in fuller detail in section II.E. of this final rule.
Comment: A commenter requested that CMS explain thatthe information it is requiring
to be available does not need to be pushed to a patient app, but should be available for query, if
a patient chooses to use their app to retrieve their information.
Response: We confirm that the PatientAccess API works on a query mechanism and not
a push. Our final policy requires that the data be available for a patients app to query and
receive from an impacted payer. Comment: Some commenters suggested that patients should be able to provide supporting
documentation directly to their payer via the Patient Access API. The commenters stated that
patients should have the choice to submit prior authorization requests themselves, or to have a
provider or third party do it, and should also have the option to initiate, monitor, and appeal prior
authorization decisions. Another commenter believed that patients should be able to challenge
decisions and report delays.
Response: We did not propose to require impacted payers to accept a prior authorization
request or supporting documentation directly from patients. We fear that this would create
confusion about the prior authorization process and whether the provider or patient is ultimately
responsible for the submission of prior authorization requests and documentation. Providers are
in the best position to understand the clinical requirements to obtain prior authorization and are
responsible for using their clinical judgment to decide on the best course of treatment. As
discussed, it is valuable for patients to have transparency into that process and be able to assist
providers to submit necessary information. However, without a clinical understanding, patients
may submit extraneous or irrelevant information. Furthermore, patients likely do not have
systems that would be able to communicate and submit information via the Prior Authorization
API. That would require the availability of an alternative system and negate some of the
efficiencies the Prior Authorization API will bring to the prior authorization process. Taken
together, such a requirement would add burden to payers and may end up delaying the prior
authorization decision process. Nothing in this rule will prohibit a payer from accepting
information directly from patients if that would benefit the payers processes or patient care.
Furthermore, payers are already required to have a process in place for patients or providers to
appeal prior authorization decisions and to file a complaint with the appropriate Federal or state
oversight agency.
i. Compliance Dates For the requirement to include prior authorization information in the data available via
the Patient Access API, we proposed compliance dates in 2026 (by January 1, 2026, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs).
Comment: Some commenters supported the proposed compliance dates. However,
several commenters recommended that the compliance dates for adding prior authorization
information to the Patient Access API be acceleratedwith recommendations for July 1, 2024,
January 1, 2025, or 12 months after the finalization of this rule. Multiple commenters
recommended earlier compliance dates due to the significant impact that this information could
have on patient empowerment and information transparency.
Conversely, multiple commenters recommended that CMS delay the proposed
compliance date until the Prior Authorization API, discussed in section II.D. of this final rule, is
widely adopted. Commenters stated that while the technical data standards may be mature, CMS
should also consider the status of payers data infrastructure, which may not have prior
authorization information in a structured format to be shared via the Patient Access API. As
discussed previously, some commenters recommended limiting the requirement to make prior
authorization data available through the Patient Access API only to data contained in
standardized HIPAA-compliant electronic prior authorization transactions, such as those
facilitated by the Prior Authorization API. These commenters recommended that CMS work
with payers, providers, health IT developers, and consumer advocacy groups to first advance
electronic prior authorization uptake before determining appropriate compliance dates. A
commenter suggested CMS consider additional flexibilities and exceptions for impacted entities
unable to comply with the proposed 2026 compliance dates.
Another commenter recommended delaying the compliance dates by another 2-3 years to
allow for simultaneous implementation with the Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and
Modification to Referral Certification and Authorization Transaction Standard proposed rule
(hereinafter referred to as the HIPAA Standards for Health Care Attachments proposed rule) (87
FR 78438).
Response: Afterreviewing public comments, we have elected to finalize the provision
with a 1 year delay to the compliance dates, to 2027 (by January 1, 2027, for MA organizations
and state Medicaid and CHIP FFS programs; by the rating period beginning on or after January
1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs). While making data related
to prior authorization available to patients is necessary and urgent, we also understand that it will
take time for payers to implement the policies we are finalizing. We believe that the additional
year will allow payers to ensure a smooth rollout of this additionalfunctionality. However, we
encourage payers to meet the requirements of this rule as soon as possible to benefit their
patients.
We decline to delay the compliance date for including prior authorization information in
the Patient Access API until after the Prior Authorization API compliance dates and are
finalizing the same compliance dates for both this policy and the Prior Authorization API. The
purpose of the Prior Authorization API is to facilitate the exchange of structured prior
authorization data, and we agree that receiving requests electronically may expedite payers
ability to make that information available to patients. However, even after the Prior
Authorization API compliance dates, we expect that a number of prior authorizations are going
to be submitted through other channels (hopefully in declining number). As discussed
previously, payers will need to have the ability to share prior authorization information that is
submitted via channels other than the Prior Authorization API, regardless of the compliance
dates. By finalizing 2027 compliance dates, we are providing payers with an additional year
beyond what we proposed to implement the needed functionality within their internal systems. Comment: A commenter suggested that prior authorization decisions issued before the
compliance dates should not be required to be available via the Patient Access API.
Response: We proposed, and are finalizing, that impacted payers must give patients
access to existing prior authorization information maintained by the payer beginning on the
compliance dates. In the CMS Interoperability and Patient Access final rule, we required payers
to make available the specified data they maintained with a date of service on or after January 1,
2016, which meant that patients had access to their historical data beginning on the January 1,
2021, compliance date. That date range also applies to the prior authorization data that must be
included. However, unlike the other categories of data, there is a period of time after which prior
authorization data no longer needs to be available. As discussed elsewhere in this final rule, prior
authorization information must be shared while the prior authorization is active and for 1 year
after the last status change. As of the compliance dates, payers must make all required data
available via the Patient Access API. However, it is unlikely that a significant number of patients
will have data from many years before the compliance dates. On January 1, 2027 (or the actual
compliance date), payers will be required to make available data about all active prior
authorizations, regardless of how long they have been active, and any requests that have had a
status update within the previous 1 year period (thatis, since January 1, 2026, if a payer
implements on these changes on that day).
ii. Data Content
We proposed that the information required to be available through the API would include
the prior authorization request and related administrative and clinical documentation, including
allof the following:
(1) The prior authorization status.
(2) The date the prior authorization was approved or denied.
(3) The date or circumstance under which the authorization ends.
(4) The items and services approved. (5) The quantity used to date under the authorization.
(6) If denied, the specific reason why the request was denied.
In section II.D.3. of this final rule, we are finalizing that in the case of a prior
authorization denial, the payer mustgive the provider a specific reason for the denial that is
separate from the content requirements for the APIs finalized in this rulemaking. Including the
reason in the Patient Access API can help patients understand why a payer denied a prior
authorization request. The administrative and clinical documentation related to a prior
authorization request that we proposed must be shared through the Patient Access API would
include 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. For the reasons discussed, we
are finalizing modifications to our proposals to not require impacted payers to include the
quantity used to date or unstructured documentation in the data available via the Patient Access
API.
As further discussed in sections II.B. and II.C. of this final rule, we are requiring
impacted payers to make available generally the same information about prior authorization
requests and decisions via the Provider Access and Payer-to-Payer APIs. In this way, these prior
authorization data can be available to all relevant parties. We note that the requirement to share
information about prior authorizations via the Patient Access and Provider Access APIs is in
addition to any notice requirements that apply to prior authorization requests and decisions, such
as the requirement to notify providers of a decision within certain timeframes discussed in
section II.D.5.b. of this final rule.
Comment: Some commenters recommended that CMS require payers to make data more
actionable and descriptive by including detailed reasons why a prior authorization request is
pending. Many commenters recommended a status for when certain services do not require prior
authorization. Conversely, to make status updates simpler via the Patient Access API, multiple commenters suggested only having a pending, active, denied, or expired status update.A
commenter requested clarification on whether, in our proposal, the listed another status was a
status unto itself or used as a catch-all description of any statuses other than those listed.
Response: While we consider five basic statuses (pending,active, denied, expired,
authorization not required) to cover the general scope of a prior authorization request and
decision, we are neither defining the term status as used in this rule, nor these five basic
statuses or the conditions under which they must be used by impacted payers. We understand
that payers use a variety of processes and do not intend to prescribe exactly when a particular
status must be used. Rather, we are indicating that impacted payers must make clear to patients
(via the Patient Access API) and providers (via the Provider Access API discussed in section
II.B. of this final rule), the status of a prior authorization decision, such as when it is pending,
approved, denied, or expired or a request has been submitted for an item or service that does not
require prior authorization. We expect payers will generally use those statuses, but they are also
welcome to use other statuses that provide additional information or are more specific to the
particular payers process. Such statuses should be clear and understandable to patients and
providers. For example, a payer could use statuses such as under appeal or expired
approved quantity used. However, in some cases, the status information available beyond
pending could be meaningless to patients if it refers only to the payers internal processes.
We also agree that patients could benefit from payers making it clear through the Patient
Access API when an item or service submitted for prior authorization does not require prior
authorization for coverage. However, we emphasize that a mere query as to whether prior
authorization is required would not create a record that needs to be shared via the Patient Access
API (or the Provider Access API). For instance, a provider may use the HL7 FHIR Da Vinci
Coverage Requirements Discovery (CRD) IG, which is the part of the Prior Authorization API
that allows a provider to query whether a payer requires prior authorization before they will
cover a specific item or service for a specific patient. Similar queries made through other channels, or submissions that are rejected for being unnecessary, need not be made available
through the Patient Access API unless the request creates a record in the patients data
maintained by the payer. Though not required, impacted payers would be welcome to make that
information available.
Comment: Multiple commenters supported our proposal that the Patient Access API
enhance transparency by including a specific reason for denial.Commenters stated that including
a reason for denial would help beneficiaries dispute decisions in a more effective manner. A few
commenters urged CMS to require impacted payers to disclose via the Patient Access API the
specific coverage or clinical criteria upon which the impacted payer relied to issue a denial.
Response: While we encourage payers to provide coverage or clinical criteria that they
used to make a prior authorization decision if that information would help the patient or provider
understand the prior authorization decision, many payers consider that specific information to be
proprietary. In addition to potentially being proprietary, those clinical criteria may be
significantly more complicated than the information we are requiring, and not easily understood
by patients. Therefore, we did not propose to require that detailed clinical criteria for a prior
authorization decision be shared with patients through the Patient Access API. Instead, we
proposed and are finalizing that when a payer denies a prior authorization request, they must
provide a specific reason for that denial through the Patient Access API. That reason may
indicate which clinical criteria the patient did not meet to be approved for the items or services.
We reiterate that the requirement that the specific reason for a denial be included in the Patient
Access API is in addition to any other applicable requirements regarding notice of decisions,
such as the requirement at 42 CFR 422.568(e) that MA organizations issue a notice containing
specific content when denying a prior authorization request and similar requirements for
Medicaid managed care plans at 42 CFR 438.210(c) and for health insurance issuers offering individual health insurance coverage (which includes QHP issuers on the FFEs) at 45 CFR
147.136(b)(3)(ii)(E).12
Comment: A few commenters questioned whether CMS would provide standardized
denial codes and how much flexibility payers will have to define denial reasons.
Response: In this final rule, we are requiring impacted payers to provide a specific reason
for a denial. We did not propose standardized denial codes or a specific set of denial reasons for
payers to use. However, there is a list of standardized codes that must be used when a prior
authorization decision is sent to a provider via the adopted HIPAA standard, which is maintained
by the SDO X12.13 While using those codes is not required for the Patient Access API, we
strongly encourage payers and providers to evaluate the code set and make recommendations to
X12 for updated or new denial codes, as appropriate. If those X12 denial codes meet the
requirement for specificity, they could be used in both the HIPAA transaction and the Patient
Access API.
Comment: A few commenters urged CMS to require payers to include plain language
information about appealing a prior authorization decision, including processes to request
internal review and external appeal of a decision and information about consumer programs to
assist with appeals.
Response: We did not propose to make that information available via the Patient Access
API. Our educational requirements, discussed in the CMS Interoperability and Patient Access
final rule (85 FR 25550-52), only cover using the Patient Access API and not the prior
authorization process writ large. However, impacted payers are already required to include that
12Forexample,45CFR147.136(b)(3)(ii)(E)(3)providesthatindividualhealthinsuranceissuersnotificationsof
anyadversebenefitdeterminationmustincludethereasonorreasonsforthedeterminationalongwiththedenial
codeanditscorrespondingmeaning,andadescriptionoftheissuer'sstandard,ifany,thatwasusedindenyingthe
claim.Inthecaseofanoticeofafinalinternaladversebenefitdetermination,thisdescriptionmustincludea
discussionofthedecision.
13X12Standards(2022,August).ServiceReviewDecisionReasonCodes.Retrievedfrom
https://x12.org/codes/service-review-decision-reason-codes. information with a notice of denial.14 For requirements to make information about the appeals
process available to patients via other modalities, see further discussion in section II.D. of this
final rule. Depending on the specific requirements of their program, impacted payers may be able
to meet that requirement by providing notice about the appeals process via the Patient Access
API.
Comment: Multiple commenters recommended that CMS not require the prior
authorization information included in the Patient Access API to include the quantity used to
date requirement, because that information would come from payer claims data. Commenters
explained that those data are not a reliable source for patients and providers to track the number
of authorized services used to date because of the lag time for processing claims. As such, payers
would not be able to update that information until claims have been submitted and processed for
the items or services covered by the prior authorization, which could result in inaccurate
information being given to a patient for weeks or months until claims are processed.
Response: We understand that payers may not always have accurate or current
information about the quantity of approved items or services that a patient has used as of a
specific date under a prior authorization. Payers must rely on claims data for that information,
which are often not current because there is typically a time lag between when an item or service
is rendered and when the claim is submitted and/or processed. If a patient knows that they have
used some quantity of the approved items and services, but is not sure of the specific quantity,
receiving inaccurate information from their payer about the quantity used to date would lead to
confusion and possibly unnecessary inquiries that take patients, providers, and payers time to
resolve. Therefore, we are not finalizing our proposal to include quantity of approved items or
services used to date in the prior authorization information available via the Patient Access API.
14See42CFR422.568(e)(3)(forMA),431.210(d)(forMedicaid),and457.1180(forCHIP)and45CFR
147.136(b)(2)(ii)(E)(4)(forQHPissuersontheFFEs). However, we are finalizing our proposal to require a total number of items or services approved
under the prior authorization decision.
Comment: Some commenters recommended that administrative and clinical
documentation sent by the provider for prior authorization requests be included in the Patient
Access API. However, multiple other commenters recommended that CMS not finalize its
proposal to include supporting documentation for prior authorization requests. Some commenters
specifically recommended that CMS not require payers to include data or forms that were not
sent in a standardized electronic manner, such as via the Prior Authorization API. The
commenters expressed concern about the feasibility for impacted payers to provide information
that they received in a non-electronic or unstructured format (such as scanned documents or
PDFs) and whether third-party patient apps can access or display such documentation. Instead,
commenters recommended that CMS focus on requiring that discrete data elements and
structured data related to prior authorizations be available to patients. While some commenters
expressed that structured data may be duplicative or unnecessary, a majority of commenters
indicated that including such data would not be overly burdensome for payers.
Other commenters requested clarification regarding what types of provider-generated
documentation would be required and some recommended that CMS assess the prior
authorization information requirements against information already available in the APIs to
mitigate redundant or duplicative information.
Response: Afterreviewing the comments, we agree that the burden of requiring impacted
payers to make unstructured documentation available via the Patient Access API outweighs the
benefits such documentation would provide, so we are finalizing a requirement that the Patient
Access API must include structured administrative and clinical documentation submitted by a
provider related to the prior authorization request.
Structured documentation includes any data received from a provider and stored in the
payers system in a standardized format with defined data attributes, such as USCDI or FHIR. Examples of structured documentation include data sent by the provider via a transaction
standard for prior authorization(s), which utilizes standard code sets, data sent via a Prior
Authorization API in a format other than as an attachment, or structured questionnaires that a
payer requires providers to fill out when making the prior authorization request. Unstructured
data include any attachments submitted by providers, such as radiological scans, large PDFs of
clinical data, or, generally, another file that a provider sends to the payer as an attachment to the
prior authorization request.
We note that documentation received in an unstructured format does not need to be
parsed and converted to structured data to be included in the Patient Access API. However, if a
payer does parse the unstructured documentation to store the contained data in a structured
format, those structured data would then be maintained by the payer, as defined in the CMS
Interoperability and Patient Access final rule (85 FR 25538), and the payer would be required to
make it available via the Patient Access API.
At this time, the standards for transmitting documentation and attachments via the FHIR
APIs are still under development and in testing, and thus not yet in widespread use across the
industry. The developing standard forexchanging attachments via FHIR APIs is the HL7
FHIR Da Vinci Clinical Data Exchange (CDex) IG.15 Version 2 of the IG completed the HL7
consensus-based process in 2023 and was published as an STU, indicating that it is being
prepared for additional testing by implementers before being proposed for adoption. Without the
FHIR standard, payers might implement unstructured documentation attachments within the
Patient Access API in a variety of ways, which would lead to confusion and lack of
interoperability. At this time, attachments exchanged via CDex are considered unstructured
documentation and would not need to be made available via the Patient Access API as part of the
prior authorization information. If the CDex becomes a mature standard, we may reconsider in
15HealthLevelSevenInternational(2023).DaVinciClinicalDataExchange.Retrievedfrom
https://hl7.org/fhir/us/davinci-cdex/. future rulemaking whether it would be beneficial to share unstructured documentation as
attachments via the Patient Access API.
We recognize that unstructured administrative and clinical documentation from a
provider could be importantto help patients understand the prior authorization process, so we
encourage payers to make that information available when possible. Furthermore, the policy we
are finalizing will require impacted payers to make available any documentation that a provider
sends to the payer to support a prior authorization requestthat is received in a structured format.
Since we are finalizing that only structured data be made available, and structured data are
formatted in a way that makes them easily transmissible between systems, our final policy
should place significantly less burden on payers than our proposal, while still giving patients
access to information about their prior authorization processes.
We note that some of that information may already be available via the Patient Access
API as clinical data. However, we believe that there is value to patients being able to ensure that
the clinical information reviewed by the payer is accurate and up to date. Therefore, it is
important for payers to make available the specific clinical data that they are looking at to decide
on the prior authorization request, even if that information may be elsewhere in the patients
record.
Comment: Multiple commenters suggested that the Patient Access API should include
information regarding whether the requesting provider is in-network or out-of-network, by
requiring payers to fully implement the X12 270/271 transaction standards for health plan
eligibility benefit inquiry and responses. Another commenter recommended that CMS require
payers to make available via the Patient Access API the names and contact information for the
in-network provider who can furnish the appropriate service within the time and distance
standards required by law. Multiple commenters believed that patients should be able to access
prior authorization information via the Patient Access API regardless of their provider. A
commenter noted consideration for varying network adequacy standards and that a patient may need to seek care from an out-of-network provider. A commenter noted that Medicaid managed
care plans have wide discretion for measuring provider network adequacy and that a patients
provider should be able to offer the same services for prior authorization despite their network
status with the patient.
Response: This rule makes no distinction between in-network and out-of-network
providers with regard to making prior authorization information available through the Patient
Access API. Regardless of the requesting providers network status, the required information
must be shared with patients. We understand that it is important for patients to know whether the
provider they are seeing is in their payers network, but we do not believe that the appropriate
place for that information is with prior authorization information. Furthermore, the FHIR API
technical specifications and IGs for the Patient Access API are not built to include information
on a providers network participation. We note that in the CMS Interoperability and Patient
Access final rule(85 FR 25563), we required MA organizations, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, and CHIP managed care entities to build and maintain
a Provider Directory API. We encourage developers to integrate within their apps network
information from payers Provider Directory APIs for easy patient access.
To the extent that a providers network status may increase a patients out of pocket
costs, we encourage payers to inform patients before they receive items or services from an out-
of-network provider to the extent that applicable programmatic requirements do not already
require the payer to do so.
Comment: A commenter recommended that a log of all instances that a patients data was
transferred via the Provider Access and Payer-to-Payer APIs should also be documented and
accessible under the Patient Access API.
Response: We did not propose that payers must make that information available via the
Patient Access API but encourage payers to do so for transparency with respect to when and with whom a patients data are being shared. We will consider proposing to require this in future
rulemaking.
iii. Timeline for Data Sharing
We proposed to require impacted payers to make available, via the Patient Access API,
information about prior authorization requests and decisions for items and services (excluding
drugs) to patients no later than 1 business day after the payer receives the prior authorization
request or there is another status change for the prior authorization. Examples of status changes
include: a payer receives a request, a payer approves or denies a pending prior authorization
request, or a provider updates a denied prior authorization request with additionalinformation for
reconsideration. We expect that impacted payers use a variety of terminology, but, generally, any
meaningful change to the payers record of the prior authorization request or decision will
require an update to the information available to the patient.
We proposed 1 business day as the appropriate timeframe because 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 final rule, we proposed to require payers to
make much of the same information aboutprior authorization requests and decisions available
via the Prior Authorization API during the decision-making process. In addition, we stated that
because impacted payers would be required to have the ability to exchange prior authorization
information electronically, it would be reasonable for them to share prior authorization
information with patients within 1 business day of any update to the prior authorization request
or decision.
Comment: Many commenters expressed that the prior authorization process is opaque
and burdensome to patients. Commenters stated that patients often wait for approval for critical
items and services without status updates from their payer. Those commenters voiced support for
the proposed requirement that payers make prior authorization information, including decision
status and documentation information, available through the Patient Access API within 1 business day after the payer receives the request. Multiple commenters noted that this will
provide greater transparency with respect to the prior authorization process.
Response: We appreciate commenters confirming that our proposed policies would ease
the burden of prior authorization processes and benefit patients and providers. We agree that
timely access to information about their prior authorizations is important to increase transparency
and ensure that patients understand their care and coverage.
Comment: Multiple commenters, specifically payers, noted that the proposed 1 business
day window may not be operationally feasible for payers. A commenter noted that, to implement
this requirement, payers would need to develop an interface to move prior authorization data
between multiple internal systems, which will be especially difficult for requests submitted in a
non-electronic format. Other commenters noted business process and operational challenges that
would make 1 business day difficult and burdensome, such as the time to manually assess
whether they can legally make the information available via the Patient Access API under
applicable state law. A commenter stated that 1 business day would not be feasible forMedicaid
agencies due to the necessary updates to the Medicaid Management Information System (MMIS)
systems.
Many commenters recommended that CMS instead consider requiring a 2 business day
response requirement. A commenter recommended extending the proposed requirementto 2
business days until electronic Prior Authorization APIs are widely adopted and proven, and only
then consider a 1 business day requirement. Another commenter recommended that CMS extend
the timeframe window to 7 calendar days. Some commenters noted that although the prior
authorization process would be automated by the implementation of the Prior Authorization API,
they recommend extending the 1 business day timeframe for the Patient Access API to match the
period a payer has to make a determination on the prior authorization.
Response: We appreciate commenters perspectives regarding the feasibility of a 1
business day timeframe. Per the comments we received, the most significant barrier to the 1 business day timeframe we proposed was the proposed requirement to include unstructured
documentation with prior authorization information. As discussed previously, we are not
finalizing a requirement to make available unstructured prior authorization documentation via
the Patient Access API. That exclusion from the data required to be made available will reduce
the amount of data translation and transformation required to have data available via the Patient
Access API. In addition, as discussed in section I.D., we are delaying the compliance dates by 1
year from our proposed 2026 to 2027 in order to give impacted payers additional time to make
system changes necessary to meet the requirements of this final rule. We acknowledge that this
may be particularly challenging for Medicaid and CHIP agencies based on existing MMIS
systems. As discussed in section II.E. of this final rule, expenditures for required changes to
states MMIS or other state systems may be eligible for enhanced Federal financial participation.
That funding may be available, not just for systems and processes that directly contribute to data
available via the Patient Access API, but for other systems, such as those that track prior
authorization requests and decisions. We also note that the Prior Authorization API discussed in
section II.D. will greatly facilitate the movement of structured prior authorization data. Payers,
including Medicaid and CHIP, should consider levers for promoting its usage by their providers.
After reviewing comments, we believe that between the changes to the data that must be
shared and the additional implementation time, payers will be able to make necessary changes to
meet these requirements by the finalized compliance dates. Therefore, we are finalizing the
timeframe as proposed and are requiring payers to make prior authorization information
available via the Patient Access API within 1 business day of receiving a request. Impacted
payers must update prior authorization information made available via the Patient Access API
within 1 business day of any status change.
Comment: Multiple commenters recommended that CMS retain the proposed 1 business
day timeframe for prior authorization requests received via the Prior Authorization API but
extend the timeframe for prior authorizations received through other channels (for example, by proprietary portal, fax, or phone). A commenter noted that, in the dental field, not all prior
authorizations are submitted electronically. An additional commenter noted this timeframe does
not provide impacted issuers adequate time to transfer information received by alternate methods
(phone, fax) to interoperable, electronic formats. A commenter stated that the turnaround is not
operationally feasible if the information is not received in a standardized format.
Response: As discussed in the previous section, we are finalizing our proposal with a
modification to require that only structured documentation related to prior authorizations be
made available via the Patient Access API. We believe this modification will, in large part,
address this issue. Payers will not be required to convert documentation from non-electronic or
non-standardized prior authorization requests into standardized data that can be available via the
Patient Access API. However, by requiring only the structured data elements, including
documentation, and not unstructured documents or images, we believe that this will streamline
that conversion process and make the 1 business day timeline feasible for payers.
Comment: A commenter recommended that CMS create flexibility for delays between a
provider sending the request and the payers receipt. Another commenter recommended that
CMS finalize a policy that the 1 business day timeline for making prior authorization data
available via the Patient Access API begins only once the payer has information adequate to
adjudicate the prior authorization request, as defined by payers prior authorization policies. The
commenter noted that some payers may require additional time to gather the information and
perform any necessary data transformation to the FHIR standards. Similarly, another commenter
recommended that the 1 business day requirement only applies after a request is received via the
X12 278 transaction standard or Prior Authorization API electronic transaction that passes
validation. Another commenter recommended that CMS require information about prior
authorization be made available no later than 1 business day after a payer makes a decision.
Response: Our proposal was for the 1 business day timeframe to begin when the payer
receives the prior authorization request. We are not requiring payers to share information that they do not possess. However, we disagree with the commenters suggestions that the 1 business
day timeline should begin when the payer has sufficient information to adjudicate a prior
authorization request, or an adjudication has been made. A payer could not know whether there
is sufficient information in the request to make a decision before the request is reviewed. As
other commenters noted,it is critical that patients know that a payer has received the prior
authorization request made on their behalf, even if it has not yet been reviewed or adjudicated. In
section II.D., we are finalizing a policy that requires certain payers to make a decision within 7
calendar days for standard requests and 72 hours for expedited requests. It may take a payer
several days to review a prior authorization request, and not having any status updates during
that time would leave patients and providers in limbo.
We did not propose and are not finalizing a requirement that the timeline for making data
available only applies to prior authorization requests received via an electronic HIPAA-
compliant X12 278 transaction and/or FHIR transaction. We know that payers currently support
a variety of modalities for providers to submit prior authorization requests, including online
portals, phone, and fax. We believe that patients should have access to their prior authorization
data within the same timeframe, regardless of how the prior authorization requestwas submitted.
Because we are not finalizing the requirement to include unstructured documentation, receiving
documentation in an unstructured format as part of a request will not hamper or delay a payers
ability to make the required prior authorization data available through the Patient Access API. A
HIPAA-compliant X12 278 transaction is, by definition, composed of structured data, which
must be made available through the Patient Access API, though attachments to such a transaction
are likely unstructured documentation. Finally, we note that if the payer receives a request that
does not pass validation or cannot be processed for some other reason,this could be an
acceptable status to provide. If a payers system fails to receive such a request, we cannot expect
the data to be made available via the Patient Access API. Comment: A commenter recommended that CMS require providers to respond to payers
requests for information within a certain timeframe and include information on provider response
timeliness in the Patient Access API.
Response: We did not propose a timeline for providers to respond to payers requests for
additional information. However, it is entirely appropriate for a prior authorization status to be
waiting for additional information from provider or similar. That would indicate to the patient
that the provider must take some action to receive approval of the prior authorization, which
would allow them to follow up with the provider to ensure that is done in a timely manner.
Comment: A couple of commenters requested clarification about the relationship between
our Patient Access API requirements and ONCs information blocking regulations at 45 CFR
part 171. Specifically, commenters questioned the implications of the information blocking
regulations if payers also meet the definition of a health information network (HIN) or HIE at 45
CFR 171.102. They questioned whether our timeline requirement is compatible with the 21st
Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification
Program final rule (85 FR 25642) (ONC Cures Act final rule), which the commenter explained
requires information to be made available to the patient without delay.
Response: Any impacted payer should consider reviewing the ONC Cures Act final rule
to determine whether they are an actor (as defined at 45 CFR 171.102) and to ensure they are
complying with any applicable information sharing policies. The information blocking
regulations (45 CFR part 171) are based on separate statutory provisions (see 42 U.S.C.
300jj-52), unrelated to our authority to issue this rule. We encourage commenters to address
questions or complaints regarding information blocking to ONC.16
We work closely with ONC and our other Federal partners to ensure thatour regulations
do not place conflicting requirements or unnecessary burdens on entities that are regulated by
16OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,November2).Information
Blocking.Retrievedfromhttps://www.healthit.gov/topic/information-blocking. more than one Federal agency. However, comments specific to the information blocking
regulations or other regulations issued by ONC are outside the scope of this rule. Additional
information is available from the Information Blocking page of ONCs website:
https://www.healthit.gov/topic/information-blocking.
iv. Length of Prior Authorization Data Availability
We proposed to require that information about prior authorizations 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, under the proposal, information on denied and expired prior
authorizations would be available for at least 1 year after expiring or being denied. We did not
propose to require payers to share a patients full prior authorization history because thatcould
comprise a significant amount of information that may no longer be clinically relevant. Claims,
encounter, and clinical data can provide valuable information about a patients health history.
With those data available through the Patient Access API, we believe that process-related
information about long-expired or denied prior authorizations will be irrelevant. Also, as payers
prior authorization policies may change over time, that information has a limited lifespan of
usefulness to a patients 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 include
information related to ongoing care.
Comment: A majority of commenters supported CMSs proposal to require prior
authorization information to be available via the Patient Access API for as long as the
authorization is active and for 1 year after the last status change. Commenters opined that this
timeframe balanced the benefits of data availability and the burden of maintaining data.
Some commenters suggested that CMS require payers to make prior authorization
information available through the Patient Access API for longer than 1 year after the last status
change. For example, some commenters suggested 3 years and others 5 years as the appropriate
period to make information available after the last status change. Other commenters recommended that CMS require payers to make all prior authorization information available via
the Patient Access API until 1 year after the patient is no longer covered by that payer. Those
commenters stated that historical prior authorization information may yet be relevant to a
patients care or could create a record for patients to demonstrate that they face repeated barriers
in accessing care or receiving coverage. Finally, another commenter suggested that those data
may be important for long-term treatment that exceeds 1 year.
Response: We continue to believe that 1 year after the last status change is the
appropriate amount of time to require payers to make historical prior authorization information
available to patients through the Patient Access API. There may be other requirements outside
the scope of this rulemaking that require certain payers to make health care records available to
individuals over a longer time period. Further,this rulemaking does not address the record
maintenance requirements that apply to impacted payers. We only address the timeframe during
which certain data must be made available through specific APIs. While background information
may impact and improve patient care, we believe that the availability of claims and clinical data
are more important to patients and providers than information about prior authorizations that
have expired or been denied. In fact, a patients claims or encounter data are likely to include any
items or services that were subject to a past prior authorization. As finalized in the CMS
Interoperability and Patient Access final rule, and as modified by this final rule, payers are also
required to make available through the Patient Access API any claims and encounter data, and all
data classes and data elements included in a content standard at 45 CFR 170.213 (USCDI),
which includes clinical data, maintained by the impacted payer with a date of service on or after
January 1, 2016.
As discussed previously, some commenters stated that including prior authorization
information in the Patient Access API could lead to information overload and confusion for
patients. While we do not believe that to be the case for active and recent prior authorizations, it
may be so if patients were presented with a large amount of historical prior authorization data that may no longer be relevant. Therefore, we believe that 1 year is the appropriate timeframe for
requiring prior authorization data to be available via the Patient Access API. We emphasize that
for ongoing long-term care, any active prior authorizations must be included, even if they have
been in that status for more than 1 year. Furthermore, we encourage payers to make these prior
authorization data available for longer than 1 year if they believe it adds value to patients,
providers, or themselves and their own processes.
b. Interaction with HIPAA Right of Access Provisions
Previous CMS interoperability proposals have elicited numerous comments regarding the
interaction between the Patient Access API and HIPAA Privacy Rule individual right of access.17
Per 45 CFR 164.524, an individual patient generally has a right of access to inspect and obtain a
copy of 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 policies complement that right by requiring payers
to make availablethrough a standards-based and interoperable FHIR API (that is, the Patient
Access API)PHI that patients already have a right to access. It is critical that individuals have
access to their own health information and the ability to share it with others who are involved in
their care, particularly when it could involve care coordination between providers or prior
authorization.
Consistent with the HIPAA Privacy Rule, we believe that it behooves us to require all
impacted payers to have the capability to provide individuals PHI via an industry standard FHIR
API, so that patients can access their data through apps of their choice. We believe that, in
addition to the other benefits described in this final rule, ensuring that patients can receive their
PHI in a standard, interoperable format that they can use with the latest technologies will reduce
17SeeCMSInteroperabilityandPatientAccessfinalrule(85FR25516-19)andDecember2020CMS
Interoperabilityproposedrule(85FR82586). instances of an individual requesting PHI in an electronic format that is not readily producible,
which could reduce costs and burden for patients and payers.
In the CMS Interoperability and Patient Access final rule, we established that the only
reason payers could deny API access to a patients preferred health app is if it would present an
unacceptable level of risk to the security of PHI on the payers system. 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.18
As we discussed in the CMS Interoperability and Patient Access final rule (85 FR
25518), disagreement with the patient about the worthiness of a health app as a recipient of
patient data, or even concerns about what the app might do with the requested data, are not
acceptable reasons to deny an individuals request. Impacted payers may offer advice to patients
on the potential risks of permitting an app or entity access to the patient data required to be made
available via the Patient Access API. However, such efforts generally must stop at education and
awareness or advice related to a specific app. Payers can inform the patient that the patient may
not want to allow an app to access their data without a clear understanding of how that app may
use their data, including how the patients personal data would be used or sold (a possibility for
apps that are not covered entities or business associates under the HIPAA Privacy Rule and the
Security Standards for the Protection of Electronic Protected Health Information19 [the Security
Rule]). For instance, if a payer learns that a particular app has publicly known privacy or security
vulnerabilities, they could inform patients who use that app to access their data of those known
vulnerabilities. Per our policies finalized in the CMS Interoperability and Patient Access final
rule, if a patient still wants to use the app, or does not respond to the payers warning, the
18See42CFR422.119(e)forMAorganizations;42CFR431.60(e)forstateMedicaidFFSprograms,throughthe
existingcrossreferenceat42CFR438.242(b)(5)forMedicaidmanagedcareplans;42CFR457.730(e)forstate
CHIPFFSprograms,throughtheexistingcrossreferenceat42CFR457.1233(d)forCHIPmanagedcareentities;
and45CFR156.221(e)forQHPissuersontheFFEs.
19SeealsotheHIPAASecurityRule,45CFRparts160and164,subpartsAandC. impacted payer is required to share their data via the API, absent an unacceptable security risk to
the payers own system. For more information on this ability to inform patients, see the CMS
Interoperability and Patient Access final rule at 85 FR 25550. Again, the finalized policies in this
rule do not affect or alter any obligations under the HIPAA Privacy and Security Rules.
While FHIR 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,at 45 CFR
parts 160 and 164, subparts A and C, for secure data exchange.20 Furthermore, a covered entity is
not liable for what happens to the PHI once the designated third party receives the information as
directed by the individual.21
Our policies in this section address how an impacted 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 patient data. Regardless of whether the HIPAA
Privacy and Security Rules apply to a health app, and even where they do not apply, other
Federal laws such as the Federal Trade Commission (FTC) Act may apply. 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 individuals health
information in a manner inconsistent with the apps privacy policy, terms of use, or an
individuals 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
20HealthLevelSevenInternational(2022,May28).HL7FHIRRelease4.6.1.0FHIRSecurity.Retrievedfrom
http://www.hl7.org/Fhir/security.html.
21OfficeforCivilRights(2020,January31).Whatistheliabilityofacoveredentityinrespondingtoan
individualsaccessrequesttosendtheindividualsPHItoathirdparty?Retrievedfrom
https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-
responding/index.html. has applied its section 5 authority to a wide variety of entities, including health apps.22 For more
information about what laws may apply to health apps, see https://www.ftc.gov/business-
guidance/resources/mobile-health-apps-interactive-tool.
The FTC also enforces the FTC Health Breach Notification Rule (16 CFR part 318),
which applies to most health apps and similartechnologies that are not covered entities or
business associates under HIPAA and, therefore, are not subject to the HIPAA Breach
Notification Rule (45 CFR 164.400 through 164.414).23 The FTCs Health Breach Notification
Rule sets forth steps that entities covered by that rule must follow when there has been a breach
of unsecured personal health information. Any violation of the FTCs Health Breach Notification
Rule is treated as an unfair or deceptive act or practice under section 18 of the FTC Act and is
subject to civil penalties of up to $50,120 per violation per day.24 In 2023, the Commission
brought its first enforcement actions under the Health Breach Notification Rule.25
c. Patient Access API Metrics
We proposed to require impacted payers to report metrics to CMS on an annual basis
about how patients use the Patient Access API, in the form of aggregated, de-identified data.We
stated that those reports would help CMS better understand whether the Patient Access API
requirement is efficiently and effectively ensuring that patients have access to their health
22SeeU.S.v.EasyHealthcareCorp.,CaseNo.1:23-cv-3107(N.D.Ill.2023),https://www.ftc.gov/legal-
library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v;IntheMatterofBetterHelp,Inc.,
FTCDkt.No.C-4796(July14,2023),https://www.ftc.gov/legal-library/browse/cases-proceedings/2023169-
betterhelp-inc-matter;U.S.v.GoodRxHoldings,Inc.,CaseNo.23-cv-460(N.D.Cal.2023),
https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-holdings-inc;IntheMatterofFlo
HealthInc.,FTCDkt.No.C-4747(June22,2021),https://www.ftc.gov/legal-library/browse/cases-
proceedings/192-3133-flo-health-inc.
23FederalTradeCommission(January2022).ComplyingwithFTCsHealthBreachNotificationRule.Retrieved
fromhttps://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule.See
alsoFederalTradeCommission(2021,September15).StatementoftheCommissiononBreachesbyHealthApps
andOtherConnectedDevices.Retrieved
fromhttps://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_br
eaches_by_health_apps_and_other_connected_devices.pdf.
2416CFR1.98makesinflationadjustmentsinthedollaramountsofcivilmonetarypenaltiesprovidedbylawwithin
theCommission'sjurisdiction.
25SeeU.S.v.EasyHealthcareCorp.,CaseNo.1:23-cv-3107(N.D.Ill.2023),https://www.ftc.gov/legal-
library/browse/cases-proceedings/202-3186-easy-healthcare-corporation-us-v;U.S.v.GoodRxHoldings,Inc.,Case
No.23-cv-460(N.D.Cal.2023),https://www.ftc.gov/legal-library/browse/cases-proceedings/2023090-goodrx-
holdings-inc. information and whether payers are providing that required information in a transparent and
timely way. Additionally, we stated that aggregated usage data from every impacted payer would
help us evaluate whether the Patient Access API policies are achieving the desired goals. We
also stated that gathering this information would 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.
Specifically, we proposed that impacted 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 allowing apps to update their information over the course of the
year. While data transfers may not indicate to what extent patients are using apps to manage their
health care, it would be a preliminary indicator of interest in the technology.
Comment: A majority of commenters supported CMSs proposal to require impacted
payers to report aggregated, de-identified data metrics on how patients use the Patient Access
API to CMS annually.
Response: We thank commenters for their feedback.
Comment: Commenters recommended that these metrics only be used to evaluate the
effectiveness of CMSs policies and to assess whether patients are using the Patient Access API
in a volume sufficient to justify the administrative burden of existing and future requirements. A
commenter stated that these metrics would not reflect factors within a payers control and
recommended that CMS work with FTC to have third-party app developers directly report these
metrics. Another commenter warned that these metrics may not accountfor patient preferences
for portals or other resources aside from apps. A commenter recommended that neither CMS nor state Medicaid agencies attempt to regulate or oversee the usage of third-party apps by their
users. Another commenter supported the annual public reporting of Patient Access API metrics
provided that this information is not made publicly available in a manner that identifies specific
payers or apps.
Response: We acknowledge that patient app usage is generally outside the control of
payers, though education can help patients make informed decisions. We emphasize that we
proposed and will be collecting these metrics, not to evaluate or compare payers, but to help us
understand how patients are using apps, the effectiveness of our Patient Access API policies, and
to assess potential future rulemaking.
Making data available via a FHIR API gives patients a wider range of options to access
their data. Ultimately, patients must decide what method of accessing their health information is
most useful to them. If patients prefer to use online portals, rather than apps, that could inform
future rulemaking. However, to understand how patients are accessing data made available
through the API using a heath app designated by the patient, we must have access to the relevant
data.We do not intend to interfere with how a patient uses a third-party app (and neither should
impacted payers, including state Medicaid agencies), but to provide them options to access their
data in the way that best suits them. As discussed previously, the only permissible reason to deny
or discontinue an apps access to an API is if the payer reasonably determines that the app
presents an unacceptable level of risk to the security of PHI on the payers systems.
We do not have the authority to require app developers to report usage metrics, and even
if we did collect data from them, it would not provide the information that we are seeking, as
developers would notknow a patients health coverage status. For instance, a developer could
tell us that an individual connected to a specific payer organization but would not be able to
report whether the patient is covered under by an MA plan or QHP. Finally, as noted in the
proposed rule, we do not intend to publicly publish these Patient Access metrics in a way that
identifies specific payers or apps. Comment: A few commenters suggested that CMS establish an easy-to-use standardized
format for reporting Patient Access API metrics.
Response: We appreciate the request from commenters and are finalizing a modification
to our proposed regulatory text to require reporting in a specified form and manner to ensure
consistency between impacted payers. We will issue specific format and process guidance for
submitting Patient Access API metrics before reporting is required.
Comment: Most commenters supported CMSs proposed metrics, as they could provide
valuable information regarding Patient Access API adoption and use.
Commenters voiced widespread support for the first metric to measure usage of the
Patient Access API. Support for the second metric was mixed, with multiple commenters
questioning its value to the APIs policy evaluation. Commenters warned that this metric would
be affected by many external factors, including the user experience of the app, as opposed to acts
of the payer. Another commenter stated that the second measure would not provide meaningful
insight into patient use patterns, and instead suggested that CMS should solicit information about
usage patterns from app developers.
Response: We understand that the metric on repeat usage may not provide a high level of
statistical validity, which is why we are not requiring these metrics to be reported publicly.
However, it is important for CMS to understand how many patients are using the Patient Access
API and whether they have simply tried it once or are invested in using health apps to manage
their data. These findings will help us monitor our interoperability policies and plan for the
future. We did not receive any comments that indicated that submitting either of these metrics
would be a significant burden for impacted payers.
We acknowledge that these metrics could be affected by a plethora of external factors
outside of payers control. As noted previously, we are collecting these metrics to better enable
us to evaluate our policies in this area. As we do not have regulatory authority over app
developers, we did not propose to impose reporting requirements on them. Comment: A commenter requested that CMS explain what constitutes a "unique patient"
so that payers can identify unique patients in the same manner, so the results are not varied.
Response: We define a unique patient by the record of the individual covered by the
payers benefits, not by the individual accessing the data. Therefore, if both a patient and their
personal representative access their data, that will only be counted as usage by a single patient
for the purpose of these metrics.
i. Reporting Level
We proposed to require MA organizations to report these data to CMS at the organization
level, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities to report at the state level, and QHP issuers on the FFEs to report at the
issuer level. We solicited 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 solicited
comment on an alternative final policy that would permit MA organizations, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to report aggregate data at
higher levels (such as the parent organization level or all plans of the same type in a program).
Comment: We received comments espousing a range of opinions on the appropriate level
of reporting for impacted payers.
Specifically for MA organizations, multiple commenters recommended a more granular
metric reporting level, noting that reporting Patient Access API metrics at the plan level would
better drive plan-specific improvement efforts and be more consistent with current industry
practice. Conversely, a commenter stated that organization level would simplify report
preparation since some MA organizations have ten or more separate plan contracts with CMS. A
commenter recommended that CMS not require reporting at the more granular contract level as
any metrics based on small populations could lead to skewed data. Many commenters supported our proposed reporting levels for Patient Access API use
metrics for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs.
On the other hand, a commenter recommended that payers be required to report metrics
at the county level, rather than the state level. Another commenter warned that too much
aggregation can make data meaningless and stated that payers should prioritize data metrics that
can be acted upon effectively. Conversely, a commenter recommended that CMS allow
consolidation of Patient Access API use metrics at the holding or parent company level, which
would aggregate that companys MA plans, Medicaid managed care plans, CHIP managed care
entities, QHPs, and commercial plans. Another commenter suggested that CMS begin collecting
metrics at a more aggregated level and wait to implement more refined data segmentation as a
clear use case arises.
Response: Upon further consideration, we determined that contract level is the more
appropriate reporting level for MA organizations. Contract-level data are aggregated data that are
collected from the plan benefit packages (PBPs) offered under an individual contract; it is
specific to the contract to which it corresponds. CMS already requires MA organizations to
annually report some contract-level data about their organization determinations to the agency. A
consistent approach of contract-level reporting in the MA program will give us useful
information while limiting payer burden. By requiring contract-level reporting for these metrics,
we ensure thatthe format of these reported data remain consistent with other data that MA
organizations are required to report. There could be value to requiring MA organizations to
report on a plan level in the future to get more discrete data. However, at this time, we believe
that the burden of requiring MA organizations to report at the plan level, and the small sample
sizes that some plans would have, outweigh the benefits of that information.
We agree that requiring Medicaid managed care plans and CHIP managed care entities to
report at the state level and QHP issuers on the FFEs to report at the issuer level balances the reporting burden and the meaningfulness of the data. Aggregating by holding company would
provide data that are not particularly useful. Many commenters recommended that we use this
information to monitor disparities in data access, which would be hindered without
disaggregation between MA, Medicaid, CHIP, and QHPs. Similarly, we do not believe that
additionally segmenting data into smaller geographic areas would provide useful information
now, though in the future we may consider whether it would be beneficial.
We note that CMS programs may assess whether to collect more detailed metrics than we
are finalizing here. For instance, we may consider requiring in future rulemaking that MA plans
report at a more discrete level. Similarly, should a state Medicaid or CHIP agency believe it
would be beneficial, they may require additional metrics in their managed care contracts.
Comment: A few commenters requested that we explain whether integrated care plans for
dually eligible individuals, such as fully integrated dual eligible special needs plans (FIDE
SNPs), should report consistent with MA organizations, at the contract level, or with Medicaid
managed care plans, at the plan level.
Response: An integrated care plan generally combines a dual eligible special needs plan
(D-SNP), which includes FIDE SNPs and highly integrated dual eligible special needs plans
(HIDE SNPs)  both as defined at 42 CFR 422.2, and a Medicaid managed care plan offered by
the same parent organization. D-SNPs are a type of MA plan designed to meet the needs of
individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible
individuals. Therefore, an MA organization will report information about Patient Access API
usage by its D-SNP enrollees to CMS at the MA organizations contract level. The affiliated
Medicaid managed care plan will report information about Patient Access API usage by its
enrollees to CMS at the plan level.
We understand that this means an organization that offers an integrated product for dually
eligible individuals (for example, a FIDE SNP), may report twice and in different ways for the
same population. We do not believe this duplication outweighs the benefits of capturing the data as we proposed, but we may consider future rulemaking to separate reporting for integrated D-
SNPs from the overall MA organization.
ii. Annual Reporting
We proposed that payers must reportmetrics from the previous calendar year to CMS by
March 31st of each year. Under our proposal, in the first year the requirement would be
applicable, payers would report CY 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 subjectto the Patient Access API requirement.
Comment: Multiple commenters expressed support for CMS's proposal to require payers
to share patient use metrics annually starting with CY 2025 to be reported to CMS by March 31,
2026. Some commenters recommended that we delay the first year of the reporting requirement
to CY 2026, which would be reported no later than March 31, 2027. Another commenter
suggested that we delay the reporting deadline because a technical solution would need to be in
place by the end of late 2024 to have metrics for CY 2025 to report in March 2026.
Response: We note that per the CMS Interoperability and Patient Access final rule,
impacted payers were required to implement the Patient Access API no later than January 1,
2021. The metrics that we proposed were not tied to the implementation of any other proposals
in the CMS Interoperability and Prior Authorization proposed rule, including adding prior
authorization information to the data available via the Patient Access API. Based on this rules
publication schedule, payers should have sufficient time to implement any necessary changes to
report these metrics.
Comment: A majority of commenters supported the proposed annual reporting
requirement, though multiple commenters recommended that CMS consider requiring payers to
report Patient Access API metrics quarterly. A commenter recommended that as the popularity
for Patient Access API grows, use metrics should be reported on a quarterly basis. Commenters agreed that requiring payers to report data on API usage from the previous
calendar year to CMS by March 31 provides an appropriate amount of time for payers to validate
the data before submitting it to CMS.
Response: Afterreviewing the comments, we agree that annual reporting is the
appropriate frequency for these metrics. Given that we are looking to understand the overall
usage of third-party apps and any patterns between payers, we do not believe that the burden of
requiring payers to report these metrics quarterly would improve our understanding of whether
patients are accessing the Patient Access API. We may in the future consider proposing more
frequent reporting or additional metrics, but for the two metrics we are finalizing now, we do not
expect that it would be beneficial to require payers to report more often than annually.
iii. Public Reporting
In the preamble to our proposed rule, we stated that 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 do not include names of specific state agencies, plans, or issuers.
Comment: Some commenters recommended that CMS require payers to publicly report
Patient Access API metrics, as they believe that health IT companies and developers would
benefit from the information. Commenters stated that by making these metrics public, CMS can
help patients and stakeholders better understand the impact of access APIs and help inform
future innovations that promote patient access and future decision making. A commenter
recommended that CMS consider publicly reporting plan-reported information at the state, plan,
or issuer level.
Other commenters did not support CMS publicly reporting Patient Access API use
metrics. Multiple commenters stated that this could provide inaccurate information and
potentially reveal identifying information. A commenter cautioned that publicizing reports,
particularly of the second proposed metric (the total number of patients whose data are transferred more than once to a specific third-party app), may give consumers an inaccurate
portrayal of API success.
Response: There may be value to publicly reporting aggregated and de-identified data to
give the public a sense of Patient Access API adoption across the industry. But we agree with
commenters that, absent the proper context, those data could be perceived inaccurately or
misleadingly. As discussed, some commenters expressed that there is currently low health app
adoption among patients regardless of the type of payer. We also understand that low patient
adoption does not necessarily indicate a lack of payer readiness or compliance. Therefore, until
we are confident that these data can be presented in an easy-to-understand and meaningful way,
we may publicly report aggregated and de-identified data, but will not include names of specific
state agencies, plans, or issuers unless and until proposed through future rulemaking.
iv. Other Metrics
We requested comment on what other Patient Access API metrics we should consider
requiring payers to report to CMS and/or make available to the public in future rulemaking. For
instance, we solicited comments on whether payers could report aggregated demographic
information, such as sex, race, age, ethnicity, and geographic data and whether that could help
identify underserved populations or disparities in patient access to health data and, if so, policies
that should be considered to promote equity. We also solicited comments on the potential
benefits and burdens of requiring payers to report the names of all apps that patients have used to
access the payers API each year. We considered collecting this information, or requiring payers
to make it public, not for the purpose of recommending or endorsing specific apps, but to review
for best practices and evaluate patient ease of use.
Comment: Commenters provided many recommendations for additionalPatient Access
API metrics.
Response: We greatly appreciate the wide range of metric suggestions, such as indicators
on demographic information, utilization, query management, successful requests, and barriers to accessing records. We will continue to research additional ways to evaluate the effectiveness of
the API for consideration in future rulemaking.
d. Patient Access API Amendments
We proposed two minor terminology changes to the requirements finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558). Unlike most of our proposals, we
proposed that these amendments would take effect on the effective date of the final rule. We
proposed these changes to explain terms but did not expect them to substantively change any
current regulatory obligation.
First, we proposed to revise the description of the clinical data impacted payers must
make available via the Patient Access API. These provisions, finalized in the CMS
Interoperability and Patient Access final rule, currently require payers to make available clinical
data,including laboratory results (85 FR 25536-40). We proposed 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. That citation is to a content standard
maintained by ONC of clinical data classes and data elements for interoperable health
information exchange. Referring explicitly in the rule text to a data set in a standard at 45 CFR
170.213 will help avoid unnecessary confusion, as this reference will more clearly identify
exactly what data must be available through the Patient Access API. Furthermore, this change
brings us into greater alignment with the standards promulgated by ONC and used by certified
health IT developers.
As versions of the USCDI evolve, there may simultaneously be multiple versions of the
standard referenced at 45 CFR 170.213 (as both v1 and v3 are listed at the time of publication of
this finalrule). In the HTI-1 final rule, ONC finalized the adoption of USCDI v3 in 170.213 and
finalized a January 1, 2026, expiration date for USCDI v1 (89 FR 1192). For the ONC Health IT
Certification Program, this allows for a transition period between standards, and, during that
time, health IT developers could incorporate updated standards versions within their systems and complete required certification. 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-referenced
content standards to meet the requirement to make clinical data available through the Patient
Access API. If a standard has a listed expiration date (as USCDI v1 is currently listed to expire
on January 1, 2026), payers would not be able to be use it after expiration.
Second, we proposed to revise the language previously finalized for denial or
discontinuation of a health apps access to the API. Currently, the rules require impacted payers
to make a determination to deny or discontinue access to the PatientAccess API using objective,
verifiable criteria that are applied fairly and consistently across all apps and developers through
which enrollees or beneficiaries seek to access patient data. We proposed to change the
terms enrollees and beneficiaries to parties for consistency with our proposal to apply this
provision to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. We stated that
because parties other than patients, such as providers and payers, would be accessing these APIs,
it would be more accurate to use the term parties rather than enrollees or beneficiaries.
Those APIs are discussed further in sections II.B., II.C., and II.D. of this final rule.
Comment: All comments we received on these technical language proposals supported
our effort to keep the Patient Access API required data aligned with ONCs standards. However,
we did receive a variety of comments on the USCDI standard currently referenced at 45 CFR
170.213. Those comments are discussed in section II.G. of this final rule.
A commenter requested clarification on whether payers would be required to request
information from providers to fill any data classes and data elements of the standard at 45 CFR
170.213 that are missing within their records. Similarly, another commenter requested that CMS
explain that the requirement to provide claims and encounter data within 1 business day applies
only to information available at the time of the request.
Response: In the CMS Interoperability and Patient Access final rule, we defined
maintain to mean the payer has access to the data, control over the data, and authority to make the data available through the API (85 FR 25538). Under that existing regulation, payers are
required to share data that they maintain as part of their normal operations. Nothing in this final
rule will change that existing policy; payers are not required to reach outto providers or other
entities to gather data that the payer does not already maintain, if it is not part of their normal
operations, to share via the Patient Access API. We thank commenters for their feedback and are
finalizing this proposal without modification.
We note that we are not modifying the Patient Access API applicability date for MA at
42 CFR 422.119(h), for Medicaid FFS at 42 CFR 431.60(h), for CHIP FFS at 42 CFR
457.730(h), and for QHP issuers on the FFEs at 45 CFR 156.221(i) because these amendments
do not substantively change any existing requirements finalized in the CMS Interoperability and
Patient Access final rule.
e. Medicaid Expansion CHIP Programs
In the CMS Interoperability and Prior Authorization proposed rule, we discussed
implementation for states with Medicaid Expansion CHIP programs (86 FR 76279). See section
II.E. of this final rule for that complete discussion, including a summary of public comments
received and our final action statement.
f. Specific CHIP-related Regulatory Framework
For CHIP, we proposed amendments to 42 CFR 457.1233(d) that would align separate
CHIP managed care API requirements with the Medicaid managed care plan 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 Childrens 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 apply the API
requirements in this final 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.
3. Other Requests for Comment
We requested comment on a variety of topics on which we did not make specific
proposals but are reviewing for future consideration. We appreciate commenters submissions
regarding the following:
 How we could and should apply these requirements to Medicare FFS and its existing
prior authorization requirements and standards.
 What policy levers we might have to create norms or best practices for privacy policies
by health app developers.
 How we could leverage ONCs TEFCA or other HHS HIE initiatives to facilitate
secure interoperable data exchange with health apps.
 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 appropriate literacy levels
and in plain language. A) B)
IssuersonFFEs (b)(1)(iv)( (b)(1)(iv)( 156.221(f) (b)(1)(iii) (e)(2)
S HP FR221 FR221 FR FR221 FR221
E Q C6. C6. C C6. C6.
I 55 55 5 55 55
C 41 41 4 41 41
I
L
O 2
d 4
ACEFINALP yerCHIPManageCare ThroughexistingcrossreferencetoCFR438.242atexisting42CFR457.1233(d)
F Pa
NGINTER chImpacted CHIPFFSCFR7.730(b)(5)(i) CFR7.730(b)(5)(ii) CFR7.730(f) CFR7.730(b)(3) CFR7.730(e)(2)
MI Ea 4245 4245 4245 4245 4245
r
NPROGRAM RegulationsfoMedicaidgedCareManaThroughcrossreferenceto42CFR431.60at42CFR438.242(b)(5)Throughcrossreferenceto42CFR431.60at42CFR438.242(b)(5) Throughcrossreferenceto431.60at42CFR(b)(5)(iii)438.242Throughcrossreferenceto42CFR431.60at42CFR438.242(b)(5) Throughcrossreferenceto42CFR431.60at42CFR438.242(b)(5)
O
ATI FFS 5)(i) 5)(ii) 3) 2)
PPLIC edicaidCFR1.60(b)( CFR1.60(b)( CFR1.60(f) CFR1.60(b)( CFR1.60(e)(
M23 23 23 23 23
A 44 44 44 44 44
S
ENTACCES MedicaregeAdvanta2CFR22.119(b)1)(iv)(A) 2CFR22.119(b)(1)(iv)B) 2CFR22.119(f) 2CFR22.119(b)(1)(iii) 2CFR22.119(e)(2)
I 44( 44( 44 44 44
T
A
TABLEB1:P RequirementAddingPriorAuthorizationInformation(Compliancedatey1,2027)JanuarTimeframeforPriorAuthorizationInformationAvailability(Compliancedatey1,2027)JanuarReportingPatientAccessAPIMetrics(CompliancedateJanuary1,2026) RevisionstotheScopeofClinicalDatatobeMadeAvailableviathePatientAccessAPI(EffectiveDateoftheFinalRule)PatientAccessAPIDenial/DiscontinuationofAccess(EffectiveDateoftheFinalRule)
ofal
nnea. a. c. d. d.
ctioeFiRulA.2. A.2. A.2. A.2. A.2.
Seth II. II. II. II. II. 4. Final Action
After considering the comments received, and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule and our response to those comments (as
summarized previously), we are finalizing our proposals with the following modifications:
 Impacted payers must make information about prior authorization requests and
decisions available via the Patient Access API beginning 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), rather than in
2026.
 Impacted payers are not required to share the quantity of items or services used under
a prior authorization via the Patient Access API.
 Impacted payers are not required to share unstructured documentation related to prior
authorizations via the Patient Access API.
 MA organizations must report Patient Access API metrics at the contract level rather
than at the proposed organizational level.
See further discussion for exact details of the final requirements for impacted payers.
Specifically, we are finalizing a requirement that, beginning 2027 (by January 1, 2027,
for MA organizations and state Medicaid and CHIP FFS programs; by the rating period
beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care
entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs),
impacted payers must make the all of following information available about prior authorization
requests and decisions (excluding for drugs) available via the Patient Access API:
 The prior authorization status.
 The date the prior authorization was approved or denied.
 The date or circumstance under which the prior authorization ends.  The items and services approved.
 If denied, a specific reason why the request was denied.
 Related structured administrative and clinical documentation submitted by a provider.
We are finalizing the requirement that impacted payers make this information about prior
authorizations available no later than 1 business day after the payer receives a prior authorization
request and must update that information no later than 1 business day after any status change.
This information must be available for the duration that the authorization is active and at least 1
year after the prior authorizations last status change.
We are finalizing a requirement that, beginning 2026, impacted payers must annually
report Patient Access API metrics to CMS in the form of aggregated, de-identified data.
Specifically, by March 31, MA organizations at the contract level, state Medicaid and CHIP FFS
programs, Medicaid managed care plans and CHIP managed care entities at the state level, and
QHP issuers on the FFEs at the issuer level must report the following metrics: (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. Impacted
payers must report the previous calendar years metrics to CMS by March 31 following any year
that they offered that type of plan.
We are finalizing,as of the effective date of this final rule, the replacement of clinical
data,including laboratory results with all data classes and data elements included in a content
standard at 45 CFR 170.213 in the required content for the Patient Access API. We are also
finalizing,as of the effective date of this final rule, to change the terms enrollees and
beneficiaries to parties at 42 CFR 422.119, 431.60, and 438.62 and 45 CFR156.221.
These final policies apply to 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 listed in Table B1. 5. Statutory Authorities for the Patient Access API Policies
We note that we received no public comments on the statutory authorities for our Patient
Access API policies.
a. MA Organizations
For MA organizations, we proposed these new requirements and the revisions to current
requirements under our authority at sections 1856(b)(1) of the Act (to promulgate regulations
implementing MA organization 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 policy 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 policies 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 policy.
The policy in section II.A.2.a. of this final rule that will require MA organizations to
make an enrollees prior authorization requests and related clinical documentation available
through the Patient Access API will allow these enrollees to have access to that information in a
convenient, timely, secure, and portable way, which is in enrollees best interests. This
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 patients support
the prior authorization process as well. Patients could see what information is needed and what
information has been provided on their behalf to facilitate a prior authorization request. Patients
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
enrollees experience with the process, by facilitating more timely 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 finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25558 through 25559) would be most effective, CMS finalized in this
rule that MA organizations reportspecific metrics to CMS on patient 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 metrics would facilitate
CMSs 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 HHSs priorities and goals,CMS is focused on putting patients at the
center of their own health care and ensuring that patients have secure access to their health
information. We believe these policies 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 finalized 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 under
a Medicaid state plan 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
purposes that are directly connected with the administration of the Medicaid state plan. The
implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list
purposes that CMS has determined are directly connected with administration of Medicaid state
plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to
restrict uses and disclosures of Medicaid beneficiary data, including requirements aboutreleasing
applicant and beneficiary information at 42 CFR 431.306.
Our policy to require that the prior authorization data described in this section be shared
via the Patient Access API would be consistentwith the requirement at section 1902(a)(7) of the
Act, providing that states may share these data only for purposes directly connected with the administration of the Medicaid state plan. The data sharing policy for the Patient Access API
would be related to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR
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).
The finalized 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 health care, 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 state Medicaid FFS programs and Medicaid managed care
plans to prior authorization requests, thus facilitating more timely and successful prior
authorizations. This 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 policies are authorized under
section 1902(a)(4), (8), and (19) of the Act.
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 to meet the requirements of
that regulation, states must have consistent criteria for release and use of information (which
should comply with the finalized Patient Access API requirements), 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 state Medicaid agency, in
accordance with 42 CFR 431.306(b). The permission requirement at 42 CFR 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
policy, 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 42 CFR 431.306 are relevant because they cover data release and use in contexts
outside of our policies in this section of the final rule. We note that while the beneficiarys
permission is not required under 42 CFR 431.306(d) for the Patient Access API we discuss here,
state or other laws may require such permission.
With respect to Medicaid managed care, and in addition to the general authorities cited
previously mentioned regarding Medicaid programs, this policy will also help implement section
1932(b)(4) of the Act, which provides that each Medicaid MCO 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 MCOs 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 theirdenied 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)
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 also proposed to require state Medicaid agencies and Medicaid managed care plans to
report Patient Access API metrics to CMS annually. These metrics will support CMSs
oversight, evaluation, and administration of the Medicaid program, as it will allow us to evaluate
beneficiary access to the Patient Access API. API usage 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 Actrequires 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 will serve as a report
to evaluate the implementation and execution of the Patient Access API.
For CHIP, we finalized 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 finalized 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 various 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 will lead to these beneficiaries accessing that information in a convenient,
timely, and portable way. This improved access will 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 will result in better health outcomes and patient satisfaction and improve the cost
effectiveness of the entire health care system, including CHIP.
These policies align with section 2101(a) of the Act in that they also will improve the
efficiency of CHIP programs. For example, adding information about prior authorization
requests to the Patient Access API will allow beneficiaries to easily obtain the status of prior
authorization requests made on their behalf. This will 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, streamlining the prior authorization
process.
Additionally, the safeguards for applicant and beneficiary information at 42 CFR part
431, subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). As
discussed previously 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, by finalizing the requirement for state CHIP agencies and CHIP managed care
entities to report Patient Access API metrics to CMS annually will 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 APIs
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 Patient Access APIs usage, 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. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we finalized these new requirements under our authority at
section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the
Health Care and Education Reconciliation Act of 2010 (Pub. L. 111148, enacted March 23,
2010, and Pub. L. 111152, enacted March 30, 2010, respectively) (collectively referred to as 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. 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 health care, improve the
efficiency of accessing and scheduling services, and, if needed, provide missing information
needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more
promptly address prior authorization requests and would also facilitate more timely 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, requiring QHP issuers on the FFEs to report PatientAccess API metrics to CMS
annually will help CMS assess the effectthis API is having on enrollees and will 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, and to ensure this requirement is being met efficiently and adding
value to CMS operations, including leading to the intended efficiencies. B. Provider Access API
1. Background
In the CMS Interoperability and Patient Access final rule, we required impacted payers to
implement a Patient Access API (85 FR 25558) that allows patients to access their health
information through a third-party 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, to
inform the discussion with their provider.
In the CMS Interoperability and Patient Access proposed rule (84 FR 7610), we had
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 a patients care
and providers could reduce or eliminate duplicate tests. Payers might also see fewer duplicate
requests for services, fewer appeals and, possibly, lower costs. In the final rule, we specifically
agreed with commenters that making available information aboutprior authorization decisions
via an API would reduce burden on providers and their staff (85 FR 25541). We also discussed
the potential benefits of payers sharing patient health information directly with providers (85 FR
25555) and encouraged payers to consider an API solution that would enable direct provider
access to appropriate health information to support the delivery of care.
While the Patient Access API was a significant first step toward sharing individual
patient health information with providers, we believe it would benefitpatients if payers were
required 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 the CMS Interoperability
and Prior Authorization proposed rule, we proposed to require impacted payers to 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 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.
We also proposed 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. Finally, we proposed Provider
Access API compliance dates in 2026 (by January 1, 2026, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2026,
for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning
on or after January 1, 2026, for QHP issuers on the FFEs).
As mentioned in section I.A. of this final rule, these policies do not pertain to Medicare
FFS. In the proposed rule, we solicited comment on whether our Provider Access API proposal
could be implemented in the Medicare FFS program. We expect that a Medicare FFS
implementation would generally conform to the same requirements that apply to the impacted
payers under this final rule, so Medicare FFS providers and beneficiaries enrolled in Medicare
FFS could also benefit from this type of data sharing. We solicited comment on whether these
requirements could be implemented as proposed, how we could apply each of these proposals,
and if there would be any differences implementing the Provider Access API for the Medicare
FFS program as a Federal payer. CMSs 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.
However, some differences exist for Medicare FFS. For instance, provider remittances and
patient cost-sharing information are not proprietary, so those data are shared in the DPC pilot;
however, we proposed that impacted payers would not be required to share that information
under our policies. Because the DPC API currently enables provider access to patient data and involves processes like authenticating the provider and verifying a patient treatment relationship
with an attribution process, the information gained from the DPC pilot will be useful to impacted
payers as we finalize proposals in this rule.
2. 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 through a Patient Access API when
requested by a patient. We stated that it would be valuable for providers to have access to the
same patient data, except for provider remittances and patient cost-sharing information, through
a FHIR API that allows a provider to request data for an individual patient,as needed, thereby
providing them with further insight into the patients health care. Research shows that patients
achieve better outcomes when their record is more complete, and more data are available to the
health care provider at the point of care.26 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 appointmentand/or provide confirmation that the patients
recollection of prior care is accurate.
Therefore, we proposed to require impacted payers to implement and maintain a Provider
Access API to make current patients information available to in-network or enrolled (as
applicable) providers, at the providers request. Under our proposal, an in-network provider is
any provider or health care facility that is part of a specific health plans network of providers
with which it has a contract to furnish covered items or services. In the case of state Medicaid
and CHIP FFS programs, that means any providers or health care facilities that are enrolled with
the state as Medicaid or CHIP providers. We noted that this requirement would only apply to
26OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(2019,June4).Improved
Diagnostics&PatientOutcomes.Retrievedfromhttps://www.healthit.gov/topic/health-it-basics/improved-
diagnostics-patient-outcomes. current patients. Once a patient is no longer enrolled with a payer, the payer would not need to
share data with providers under our proposed policy.
We explained that the Provider Access API would allow a provider to initiate a request
when the provider needs access to a patients data, such as prior to or during a patient visit. Both
the Provider Access and Patient Access APIs would facilitate the FHIR-based exchange of
claims and encounter data, all data classes and data elements included in a content standard at 45
CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the
payer.
We also stated that we believed that sharing claims and encounter data (without provider
remittances and patient cost-sharing information) would complement the data classes and data
elements included in a content standard at 45 CFR 170.213 (USCDI) by providing more
information to support treatment and care coordination. Claims and encounter data, used in
conjunction with clinical and other available data, can offer a broader, more complete picture of
an individuals interactions with all their providers in the health care system. With that proposal,
we intended to help providers gain efficient access to more comprehensive data on their patients.
Specifically, we proposed to require impacted payers to make available any of the applicable
patient data with a date of service on or after January 1, 2016, that they maintain. This 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 the same set of data from this timeframe via a
FHIR API.
Finally, we explained that, unlike the Patient Access API, the Provider Access API would
not include provider remittances and patient cost-sharing information. Many payers consider
cost-sharing information proprietary and, while we do not necessarily agree with such a
characterization, we believed that information would have limited benefit for treatment or care coordination and thus excluded it from the scope of data required to be accessible through the
Provider Access API.
We proposed that payers would be required to make available via the Patient Access and
Provider Access APIs information related to prior authorization requests and decisions for items
and services (excluding drugs). This information would include, as applicable:
 The prior authorization status.
 The date the prior authorization was approved or denied.
 The date or circumstance under which the prior authorization ends.
 The items and services approved;
 If denied, a specific reason why the request was denied.
 Related structured administrative and clinical documentation submitted by a provider.
We proposed that information about prior authorizations be available via the Patient
Access API for as long as the authorization is active, and for at least 1 year after the last status
change, and that this would apply to the Provider Access API, as well. We noted in the proposed
rule that 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 did
not propose to require payers to share a patients full prior authorization history, because that
could comprise a significant amount of information that may no longer be clinically relevant.
In general, our proposal for the data that payers would have to make available through the
Provider Access API, as well as the technical specifications, aligned with the requirements for
the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85
FR 25558) and those that were proposed for the Patient Access API in the CMS Interoperability
and Prior Authorization proposed rule (87 FR 76238).
However, we further explained that there are a few notable differences between the
requirements for a Patient Access API and those for a Provider Access API. The biggest
difference is how and why the end user will 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, and potentially to share the data with a provider. For the Provider Access API, we expect
that a provider will request and receive access to the patients information through their EHR,
practice management system, or other technology for treatment purposes. Providers will securely
access their patients data through a FHIR API using at least one of these systems. Providers will
not access patient data through their own health app; rather, the data will flow from the payer to
the providers EHR or practice management system, which will allow them to incorporate the
patient data into their records, should they choose to do so. For example,a provider who is
preparing for an upcoming appointment may need more information about the patient than is
contained in the patients record in their own systems. Under this proposal, the provider would
be able to request the additional data from the patients payer. The payer would then be required
to share the requested data no later than 1 business day after receiving a request from a provider
who meets all other requirements to access the data.
In the CMS Interoperability and Patient Access final rule we required standards forthe
Patient Access API by cross reference to 45 CFR 170.215 (85 FR 25558). We proposed to
require certain standards at 45 CFR 170.215 that are applicable to the Provider Access API. We
are finalizing our proposals for the Provider Access API with modifications, requiring impacted
payers to use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US
Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0 at 45
CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). We are
also recommending payers use the CARIN IG for Blue Button STU 2.0.0, PDex IG STU 2.0.0,
and SMART App Launch IG Release 2.0.0 to support Backend Services Authorization. We
proposed but are not finalizing to require impacted payers to use OpenID Connect Core for
reasons discussed later in this section. We refer readers to Table H3 for a full list of the required
standards and recommended IGs to support API implementation. We refer readers to section II.G. of this final rule for further discussion of the required and recommended technical standards
for the Provider Access API.
For Medicaid and CHIP managed care, we proposed 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. As proposed at 42 CFR 438.242(b)(7) and by cross-reference at 42 CFR
457.1233(d), all other Medicaid managed care plans and CHIP managed care entities (that is,
MCOs, PIHPs, and non-NEMT PAHPs) would be subject to this final rule. We stated our belief
that the unique nature and limited scope of the services provided by NEMT PAHPs, which only
cover transportation and not medical care itself, justified their exclusion from the requirements of
the Provider Access API. Specifically, we did not believe that providers have routine need for
NEMT data; therefore, requiring NEMT PAHPs to implement and maintain a Provider Access
API (and a Payer-to-Payer API, as discussed in section II.C.3. of this final rule) would be an
undue burden. However, we did propose that NEMT PAHPs be subject to the requirements for
the Patient Access API, Prior Authorization API, and prior authorization processes.
We acknowledged that it could be helpful for all providers to have access to their
patients data regardless of contractual or enrollmentrelationships with a patients payer.
However, we proposed to only require impacted payers to share data with in-network or enrolled
providers. We recognized that this could make it more difficult for an out-of-network provider to
create or access a more comprehensive care record for a patient. We considered requiring payers
to make the data available to all providers, regardless of whether the provider is under contract or
enrolled with the payer. We will continue to consider a requirement to share patient data with
out-of-network providers for future rulemaking. To this end, we requested comment in the
proposed rule on existing processes for sharing data with out-of-network providers. Though we
did not propose to require it, we encouraged payers to share information via API with out-of-
network or unenrolled providers to the extent permitted by law if they can verify a treatment
relationship. For state Medicaid and CHIP FFS programs specifically, data sharing with out-of- network and unenrolled providers would need to comply with Medicaid confidentiality rules as
required by section 1902(a)(7) of the Act and implemented in our regulations at 42 CFR part
431, subpart F.
We are finalizing our proposal to require impacted payers to make available to providers,
via the Provider Access API, claims and encounter data (without provider remittances and
patient cost-sharing information), all data classes and data elements included in a content
standard at 45 CFR 170.213, and certain information aboutprior authorizations (excluding those
for drugs). However, as with the Patient Access API policies, we are finalizing a modification to
our proposal and not requiring payers to share the quantity of items or services used under a prior
authorization or unstructured documentation related to a prior authorization. We are finalizing
these changes to the Provider Access API policy with compliance dates in 2027 (by January 1,
2027, for MA organizations and state Medicaid and CHIP FFS programs;by the rating period
beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP managed care
entities; and for plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs),
which is a year after the proposed 2026 compliance dates. Throughout this rule, we generally
refer to these compliance dates as in 2027 for the various payers.
To support the Provider Access API implementation and maintenance, we are requiring
certain standards and recommending certain IGs, as further discussed later and in section II.G. of
this finalrule. With the publication of the HTI-1 final rule, our cross references to 45 CFR
170.215 have been updated to reflect the updated citations as needed. Changes to the structure of
45 CFR 170.215 and versions of the API standards codified there, are discussed further in
section II.G. and reflected throughout this final rule. For the Provider Access API, impacted
payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US
Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), SMART App Launch IG Release 1.0.0at 45
CFR 170.215(c)(1), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1). Impacted
payers are permitted to use updated standards, specifications, or IGs that are not yet adopted in regulation for the APIs required in this final rule, should certain conditions be met. For the
standards at 45 CFR 170.215, updated versions available for use under our policy include, but
are not limited to, US Core IGSTU 6.1.0, the SMART App Launch IGRelease 2.0.0, and the
Bulk Data Access IG v2.0.0: STU 2, which have been approved for the ONC Health IT
Certification Program.27 We refer readers to section II.G.2.c. of this final rule for a full
discussion on using updated standards. We also recommend payers use the CARIN IG for Blue
Button STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support
Backend Services Authorization. We refer readers to Table H3 for a full list of the required
standards and recommended IGs to support API implementation.
a. General Comments
Comment: Multiple commenters supported CMSs proposal to require impacted payers to
develop and maintain a Provider Access API and recommended that CMS finalize the proposal.
Multiple commenters also noted that the API would give health care providers invaluable
insights into patient care, which could lead to better quality care, reduce duplicate services, and
streamline provider workflows. A commenter recommended that CMS focus its efforts on the
secure exchange of data from patients to providers via the Patient Access API, which could allow
the patient to be an intermediary who can choose which payer data to share with the provider.
Response: We agree with commenter sentiments about the various benefits to both
providers and patients of providers having improved and direct access to patient data. As
explained throughout this final rule, the requirements and standards for the Provider Access API
will largely align with those currently in place and that we are finalizing for the Patient Access
API. We anticipate that this alignment will provide consistency and help payers build on the
work done to comply with the requirements for the Patient Access API. Enabling improved data
27OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(2023,September11).Standards
VersionAdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-
advancement-process-svap. sharing directly with providers, who have the clinical expertise to effectively use the data to
improve patient care, is a logical next step for our API implementation requirements.
b. Compliance Dates
Comment: Multiple commenters supported the proposed 2026 compliance dates for the
Provider Access API, as the appropriate time when the IGs will be sufficiently mature. Other
commenters supported earlier compliance dates for the Provider Access API, including dates in
calendar years 2024 and 2025.
By contrast, multiple other commenters requested that CMS delay the implementation of
the Provider Access API. Many recommended the compliance dates for the Provider Access API
be at least 3 years after the issuance of the final rule to allow for provider and payer
collaboration. Commenters stated this would allow payers and providers to stagger the separate
implementation of the HIPAA Standards for Health Care Attachment proposed rule (87 FR
78438). A commenter stated that delaying the implementation of the Provider Access API
requirement would enable the industry to develop consistent attribution methodologies and
establish opt out policies.A commenter suggested that if CMS finalizes its proposal to require
payers to implement Provider Access APIs and require a response within 1 business day, it
should delay the compliance dates until 2027.
Multiple commenters flagged that CMS does not have to require implementation on any
particular calendar date, since it would not affect an enrollees plan benefits or premiums. A
commenter specifically stated that the implementation does not need to be synchronized to the
beginning of the plan benefit year for MA organizations and QHP issuers on the FFEs.
A commenter sought clarification on the compliance dates as it relates to onboarding new
providers to a payers network, in order to ensure these new providers are following all
applicable regulations, laws, and testing requirements by the proposed compliance dates in 2026.
Multiple commenters recommended that CMS develop the Prior Authorization API before fully
implementing the Provider Access API. A commenter further recommended that CMS phase in implementation of the Provider Access API. They believe CMS should allow additional time for
development of the Provider Access API to maximize its utility and provided suggestions for
additional capabilities to do this.
Response: After consideration of public comments, we are finalizing a 1 year delay in the
compliance dates, to 2027 (by January 1, 2027, for MA organizations and state Medicaid and
CHIP FFS programs; by the rating period beginning on or after January 1, 2027, for Medicaid
managed care plans and CHIP managed care entities; and for plan years beginning on or after
January 1, 2027, for QHP issuers on the FFEs). As discussed in section I.D. of this final rule, we
are delaying the compliance dates for each of our policies that require API development and
enhancement (though other policies on new reporting metrics and prior authorization processes
are being finalized with different compliance dates). While making data related to prior
authorizations available to providers is necessary and urgent, we also understand that the policies
we are finalizing will take time for payers to implement. An additional year will give payers time
for a smooth rollout of this new API, as well as to onboard their providers. Payers may
communicate these policies to any new providers through the same channels they currently use
to communicate participation rules, coverage guidelines, and other important plan information
with new providers joining their network. Because we are delaying the compliance dates, we do
not believe a phased implementation is necessary, even if the additional time is used to
implement functionalities for the API that we are notrequiring in this final rule. We emphasize
that the compliance dates are merely a deadline, and we encourage payers to meet the
requirements of this rule as soon as possible to benefit their patients and providers. The
additional year will also give impacted payers the requested time to establish the required
attribution and opt out processes (discussed in sections II.B.3.a. and II.B.3.b. of this final rule,
respectively).
Finally, we decline to delay the compliance dates for this policy until after the Prior
Authorization API is implemented and are finalizing the same compliance dates for all three new APIs. We agree that the purpose of the Prior Authorization API is to facilitate the exchange of
structured (as defined in section II.A.2.a.ii. of this final rule) prior authorization data, and
therefore receiving requests electronically may expedite payers ability to make that information
available to providers. However, even after the Prior Authorization API compliance dates, we
expect that a number of prior authorizations are going to be submitted through other channels
(hopefully in declining number). A providers access to this information should not depend on
the method and process that a payer sets for providers to submit a prior authorization request.
Rather, the purpose of our Provider Access API policies is that providers have access to their
patients data (if patients do not opt out). That means that payers will need to be able to share
through the required APIs any prior authorization information that is submitted in ways other
than the Prior Authorization API, regardless of the compliance dates. By finalizing 2027
compliance dates, we are providing payers an additional year beyond our proposal to implement
the needed functionality within their internal systems. While we acknowledge that the
compliance dates may not need to be at the start of a calendar, contract, or rating year, finalizing
our proposal with specific compliance dates will ultimately reduce confusion for all parties.
Comment: A commenter cautioned that without information that will be contained in an
anticipated ONC proposed rule, it is difficult to provide realistic timelines for making prior
authorization data available. They recommended that CMS offer an additional public comment
period after the publication of this separate, anticipated ONC rule to allow the industry
appropriate time to review the proposed changes that would be incorporated into the providers
workflow.
Response: Regarding ONC regulations, we recognize that commenters are interested in
future ONC policies which may relate to the policies in this rule. ONC issued both the HTI-1
proposed and final rules since the publication of ourproposed rule. As discussed, cross
references in this final rule have thus been updated accordingly. We will continue to work with
ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies associated with the
policies in this final rule. We further note that the Unified Agenda, at the time of publication of
this finalrule, has been updated to include an entry for a proposed rule from ONC entitled
Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and
Public Health Interoperability (RIN 0955-AA06). The description indicates that the proposed
rule aims to advance interoperability, including proposals to expand certified APIs for electronic
prior authorization.28However, the policies in this rule can be finalized independently of future
rulemaking by ONC and we are not providing an additional period for comment.
c. Identifying Providers and Networks
Comment: Multiple commenters requested clarification on the definition of providers
that are eligible to use the Provider Access API. A commenter recommended that CMS permit
providers who use a Type 2 National Provider Identifier (NPI) number to use the Provider
Access API. Multiple commenters also believed that providers other than physicians should have
access to patient data via the Provider Access API. A commenter recommended that the final
rule explain whether the Provider Access API can be used by clinical laboratories. Another
commenter believed that a Tax Identification Number (TIN) should be used for patient
attribution purposes, rather than an NPI because it would give an opportunity for multiple
providers in the same practice to access a patients information.
Response: Providers who should have access to a patients data are those, whether they
are an individual, a facility, or a group of providers who have come together as an Accountable
Care Organization (ACO), who are appropriately licensed, provide items or services eligible for
coverage by the payer, and are enrolled with the payer or in the payers provider network. Should
a clinical laboratory, or other entity such as an ACO, meet these criteria, it would indeed be a
provider who could use the Provider Access API to access patient data, assuming all other
28OfficeofInformationandRegulatoryAffairs.ExecutiveOfficeofthePresident(2023).HealthData,Technology,
andInteroperability:PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. criteria outlined in this final rule are met. Multiple providers in the same practice may also be
able to access a patients data if the practice is enrolled with a plan under a Type 2 NPI (that is,
an organizations NPI), or if those providers are part of an ACO that is requesting data on a
providers behalf, because all the providers in such organizations would be part of the payers
network. Furthermore, an ACO typically has business associate agreements with the providers
that comprise the ACO, that should allow them to request data on the providers behalf.
Impacted payers may even elect to use patient rosters from such multi-provider practices or
ACOs, as well as a practices TIN, as part of its attribution process (see section II.B.3.a. of this
final rule) since the patients on these rosters could be attributed to all the providers in these
organizations.
Comment: Multiple commenters sought clarification on how CMS defines a payers
network. A commenter inquired whether CMSs intention was to only include contracted
providers who have both a contractual relationship with the payer and a treatment relationship
with the patient, and as to which facilities are considered contracted or out-of-network. Another
commenter asked for CMS to further define treatment relationship with the patient. A different
commenter sought clarification on the definition of in-network providers for a plan that operates
in multiple territories and has some providers that may be in-network for one location and out-
of-network for another.
A commenter further recommended that CMS consider how to allow for effective patient
data transfers in more complex provider-facility relationships, meaning contracted individual and
institutional providers. A commenter also recommended that CMS consider the nuances of
cancer therapy networks when developing its final policies, as some payers utilize a cancer
therapy network and cover services furnished by certain providers who may be considered out-
of-network generally, but in-network for certain cancer treatments.
Other commenters suggested that CMS explain whether impacted payers with leased
networks would be subject to the in-network requirement and recommended that leased network providers not be considered in-network for purposes of the Provider Access API. One of these
commenters raised the concern that requiring QHP issuers on the FFEs to share patient
information with leased network providers would impose a burden on QHPs, noting that the in-
and out-of-network status of these providers could depend on a plan's benefit package. These
commenters noted that these networks are often rented or leased from other payers, and that the
QHP issuer that is renting the network may not have control over provider contract standards.
Response: We are finalizing that impacted payers will be required to make the specified
patient data available to in-network or enrolled providers with whom the patient has a verified
treatment relationship (determined via an attribution process, as discussed in section II.B.3.a. of
this finalrule), assuming the data access conforms to all other applicable laws and regulations,
such as state privacy laws. As discussed elsewhere, a payer can establish a treatment relationship
by determining whether the patients claims history, proof of an upcoming appointment, or other
information (for example, hospital admission letter) demonstrates a treatment relationship with
the provider. Nothing in this final rule would require the information used to verify the
providers relationship to the patient to be shared or exchanged via the Provider Access API
itself. We also remind readers that, though we are not requiring payers to share patient data with
out-of-network or unenrolled providers, we encourage them to do so to the extent permitted by
law if they can verify a treatment relationship.
Impacted payers that operate in multiple service areas, and therefore have some providers
that are in-network in a particular area but out-of-network in other areas, should treat the
providers based on network status on a case-by-case basis, depending on the payers service area
applicable to each enrollee. For example, if Providers A and B are both in-network for the plan,
but Enrollee C resides in a service area where only Provider A is in-network, then the plan can
treat Provider A as in-network and Provider B as out-of-network for making Enrollee Cs data
available via the Provider Access API. However, we remind readers that while not required, it
would still be permissible to grant access to the Provider Access API to Provider B. The fact that Provider B already has a contract with the payer would even help to mitigate the potential
privacy, security, and program integrity concerns we discussed in the proposed rule. The
presence of this contractual relationship is also why we agree with the commenter regarding
providers who are part of a cancer therapy network. If providers are in-network for some services
for a patient, then they are an in-network provider. Our goal with our Provider Access API
policies is to maximize the number of providers who can use it.
We acknowledge that there may be health care settings and facilities where only some of
the providers are enrolled with or have a provider agreement with the impacted payer (as
applicable). Under the HIPAA Privacy Rule, covered health care providers generally may
disclose certain PHI to other health care providers fortreatment purposes.29 Thus, there may be
cases where a provider may share relevant patient data obtained via the Provider Access API
with another provider who may not be in-network or enrolled with the impacted payer. However,
under our requirements, payers would only be required to share data through the Provider Access
API in response to requests from in-network or enrolled providers (as applicable).
Providers in a leased network are in-network for purposes of the Provider Access API
requirement because the lease effectively creates a contract with the providers in that network.
By way of example, QHP issuers on the FFEs include leased network providers in the Network
Adequacy template they submit as part of the annual QHP Certification application process, to
the extent that a networks providers are available to enrollees in that QHP and are treated by the
issuer as providing in-network benefits.30 In addition, per 45 CFR 156.340, QHP issuers on the
29See45CFR164.506(a).
30ECPandNetworkAdequacy(n.d.).EssentialCommunityProvidersandNetworkAdequacy.Retrievedfrom
https://www.qhpcertification.cms.gov/s/ECP%20and%20Network%20Adequacy. FFEs are responsible for their own compliance and the compliance of any delegated31 or
downstream entities32 with all applicable Federal standards related to Exchanges.
d. Provider Adoption and Use
Comment: Multiple commenters agreed with the scope of the Provider Access API, but
expressed concern about potential penalties for providers who are unable to adopt technology
that supports data exchange via this API.
Response: We did not propose any requirements for providers to use the Provider Access
API, nor did we propose penalties for providers who do not use the API. However, accessing
patient data through the Provider Access API will improve providers ability to furnish quality
care to patients. We expect that providers too will see the benefit of this technology and having
patient data available directly from payers.
Comment: Multiple commenters flagged that providers should have access to a patients
health information without technological or financial barriers, and that CMS should consider the
costs to health centers, safety net providers, long-term and post-acute care (LTPAC) settings, and
hospitals with low resources, as well as their unique needs with regard to implementing use of
the Provider Access API. They believed that considering these provider types would ensure more
widespread use of the API. A commenter stated that some small businesses do not have the staff
or funding to set up a complex data exchange and they believed there is a need to engage them in
discussions about the benefits of the health information exchange. Another commenter stated
that the proposed rule did not offer any indication of available resources to help providers
implement the API. A commenter recommended CMS consider investments that health centers
make to ensure appropriate interoperability and access.
31Adelegatedentityisdefinedat45CFR156.20tomeananypartythatentersintoanagreementwithaQHP
issuerontheFFEstoprovideadministrativeservicesorhealthcareservices(forexample,contractedproviders).
32Adownstreamentityisdefinedat45CFR156.20asanypartythatentersintoanagreementwithadelegated
entityorwithanotherdownstreamentitytoprovideadministrativeservicesorhealthcareservices(forexample,
subcontractedproviders). A commenter urged CMS to track and counteract any equity issues that may manifest
from operationalizing the Provider Access API. Multiple other commenters flagged that the true
impact of APIs on everyday practices will not be understood until they are implemented and
being used by providers, with another commenter recommending that CMS focus targeted efforts
to engage provider specialties and groups who have traditionally lagged in uptake of
interoperable technology.
Response: We agree that technology should not be a barrier to accessing appropriate
patient information and our policies are intended to make such access easier for providers. We
recognize that there are care settings that lag in adoption of EHR and other health IT, and/or lack
the staff or resources to make use of the Provider Access API, which could result in these care
settings missing outon the benefits of data exchange. Nevertheless, making data available via a
FHIR API, which ensures these data are available to any authorized system seeking to access it,
will benefit settings that may not have sophisticated technological solutions. Furthermore,
making these data available is a vital antecedent to increased data sharing and interoperability
across the health care system. We will be closely monitoring implementation and use of the
Provider Access API to assess its real-world impact on care delivery, such as the possible equity
concerns described by the commenters, as well as continue to work with providers to encourage
and enable them to use the API, should they wish to do so.
Comment: Multiple commenters recommended that CMS seek to understand the current
state of health IT and the needs of end users before mandating Provider Access API
implementation. A commenter stated that the health IT infrastructure across the industry is not
ready to support the APIs. Another commenter representing payers, providers, and
clearinghouses in both the public and private sector noted that when they surveyed their payer
members on the Provider Access API implementation, 64.3 percent of payers responded it would
be very difficult or difficult to implement. Response: We disagree with the commenters assessment that existing health IT
infrastructure is not ready to support the Provider Access API. Payers are currently required to
maintain a Patient Access API that enables the exchange of the same data as we are requiring to
be available via the Provider Access API, with the caveat that this rule establishes new
requirements to include information related to prior authorizations.The Patient Access API
establishes the foundation to ensure that existing payer health IT infrastructure is indeed capable
of also supporting the Provider Access API. For providers, as of October 2018, eligible
professionals and hospitals collectively received over $38 billion in incentives to adopt,
implement, upgrade (AIU), and demonstrate meaningful use of certified EHR technology
(CEHRT) through the Medicare and Medicaid Promoting Interoperability Programs (formerly
the Medicare and Medicaid EHR Incentive Programs).33,34,35As of 2021, 78 percent of office-
based physicians and 96 percent of non-Federal acute care hospitals had adopted CEHRT.36
CEHRT now incorporates functionality for standards-based FHIR APIs. We thus believe health
IT developers can build on these standards-based APIs to further develop functionality in
provider systems that supports access to Provider Access APIs.
Comment: Multiple commenters underscored the need to establish incentives for
providers to adopt the Provider Access API to offset any provider burden. Commenters cited
quality measure reporting through the MIPS and CEHRT programs as possible avenues for
incentives. Another commenter recommended that CMS and ONC work together to create
33CentersforMedicareandMedicaidServices(2018).PromotingInteroperability(PI)ProgramMedicareIncentive
Programs.Retrievedfromhttps://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Downloads/October2018_MedicareEHRIncentivePayments.pdf.
34CentersforMedicareandMedicaidServices(2018).PromotingInteroperability(PI)ProgramMedicareIncentive
Programs.Retrievedfromhttps://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Downloads/October2018_MedicareEHRIncentivePayments.pdf.
35CentersforMedicareandMedicaidServices(2017).MAOrganization(MAO)IncentivePaymentsforEligible
Professionals.Retrievedfromhttps://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Downloads/May2017_MAO-Report.pdf.
36OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(2020).NationalTrendsinHospital
andPhysicianAdoptionofElectronicHealthRecords.Retrievedfrom
https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records. incentives for vendors to improve EHR functionality and for providers to utilize the API, as well
as provider educational resources to encourage adoption.
Response: For reasons explained previously, we believe that providers will see the
benefit of using the Provider Access API, but we intend to closely monitor providers
experience, as well as consider ways to encourage use of the API in future rulemaking, if need
be. We remind readers that nothing in this final rule would prohibit impacted payers themselves
from incentivizing and/or requiring use of the Provider Access API. However,should they
choose to implement such a policy, we remind impacted payers to carefully weigh the expected
benefits against any potential new burden on providers.
Comment: Multiple commenters stated that the Provider Access API may be duplicative
of existing resources (for example, HIEs or HINs, multi-payer portals, or other existing
mechanisms for accessing claims data). Many other commenters supported creating the ability to
integrate information from the Provider Access API into the providers EHR system. These
commenters recommended that CMS work closely with both providers and EHR vendors to
ensure that integrating data from the Provider Access API is user-friendly and incorporated into
the clinical workflow. They stated that that would make patientdata from the Provider Access
API organized and navigable. Another commenter stated that because patients often receive care
from multiple health providers, they often have fragmented patient health records, which can
make it difficult for providers to get a clear picture of a patient's health history.
Multiple commenters, however, expressed concerns regarding the feasibility of the
Provider Access API. A commenter stated that the biggest challenge to the implementation of
Provider Access API is that providers generally interact with many payers and it is not feasible
for provider organizations to support many one-to-one connections with payers. The commenter
stated that while it would be costly and risky, the urgency to implement a National Data
Warehouse Exchange Hub/Clearinghouse has never been greater. Response: We understand commenters concern about the potential for duplication of the
Provider Access API functionalities that existing resources may provide. However, not all
providers currently use or have access to other resources that can access patient data.37,38
Further, the data we are requiring payers to make available under this final rule may not be
available from other sources. Thus, the Provider Access API can be a valuable tool for providers,
even if they currently have access to data via an HIE/HIN or other source. We anticipate that
providers will find benefits to patient care from having patient data available from multiple
sources.
We emphasize that the responsibility for implementing and maintaining the Provider
Access API falls on impacted payers, not on providers or provider organizations. Further, in this
final rule, we prioritize sharing structured data elements through standardized APIs (see section
II.A.2.a.ii. of this final rule). Thus, even though this final rule does not obligate providers to use
the Provider Access API, we anticipate that health IT vendors will integrate data from this API
for providers in a manner that is organized, navigable, and useful to providers. We encourage
vendors to work with their clients so that information accessed via the Provider Access API is
useful for filling in gaps in the patient record, rather than creating duplicative data, and providers
can take full advantage of their benefits.
Comment: Multiple commenters suggested that CMS should take steps to ensure that
costs borne by EHR vendors are not passed onto providers, and that implementation is done in a
manner that minimizes burden for providers. Multiple commenters also recommended that CMS
explicitly require payers to allow providers to use the Provider Access API at no charge and that
CMS should monitor and enforce such a requirement against payers who attempt to charge
providers a user fee to access the APIs.
37OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(2021).ElectronicHealth
InformationExchangebyOffice-basedPhysicians.Retrievedfrom
https://www.healthit.gov/data/quickstats/electronic-health-information-exchange-office-based-physicians.
38OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(2023).Interoperabilityand
MethodsofExchangeamongHospitalsin2021.Retrievedfromhttps://www.healthit.gov/data/data-
briefs/interoperability-and-methods-exchange-among-hospitals-2021. Response: Our goal is to improve care and reduce burden on patients, health care
providers, and payers. We also recognize that EHR vendors, providers, and payers have costs of
doing business. We strongly encourage EHR vendors to only charge reasonable fees for any
initial or periodic system configurations required to access payers API endpoints.Furthermore,
EHR vendors and payers should ensure that any fees charged per API call are necessary and
reasonable based on any actual maintenance costs for that entity. We also strongly encourage
payers to permit providers to use their Provider Access API at no cost to maximize usage and
benefits to patient care, which would ultimately benefit the payer as well. We will continue to
work with interested parties to ensure that health care providers are not unnecessarily burdened
and to ensure that our regulations do not place conflicting or unnecessary burdens on entities that
may be regulated by more than one Federal agency.
Furthermore, EHR vendors and some impacted payers may be information blocking
actors (as defined at 45 CFR 171.102) that must abide by ONCs regulatory requirements.
Specific details of the information blocking regulations and other regulations issued by ONC are
outside the scope of this final rule. Additional information about ONC information blocking
regulations is available from the Information Blocking page of ONCs website:
https://www.healthit.gov/topic/information-blocking. Questions may be sent to ONCs Health IT
Feedback and Inquiry Portal at https://inquiry.healthit.gov/. Payers who are information blocking
actors (as defined at 45 CFR 171.102) and have committed information blocking (as defined at
45 CFR 171.103) may be subject to civilmoney penalties by the HHS Office of the Inspector
General (OIG). Interested parties should address questions regarding when particular practices
might be considered information blocking to ONC.
Finally, we did not propose to implement a prohibition against payers charging providers
a user fee to access their APIs. We will closely monitor implementation of the Provider Access
API and whether user fees present a significantimpediment to interoperable data exchange. We
will also be monitoring the frequency and type of feedback we receive from providers, patients, and payers related to burden and cost, to determine whether other policies might be ripe for
consideration in future rulemaking. See section I.D.2. of this final rule for more information
about CMSs enforcement and compliance policies.
Comment: A commenter wanted to ensure that payers cannot require providers and
clinical staff to use multiple different tools that might leverage the Provider Access API to treat
patients. The commenter stated that providers should have autonomy to deliver care without
having to add new technology that payers may require them to implement. Another commenter
similarly recommended that CMS ensure payers do not increase burden on providers, stating that
a significant burden would be placed on providers if their network participation gets conditioned
on payer requirements to use the Provider Access API. Another commenter urged CMS to
prohibit payers from placing additional contractual demands on providers, such as unrealistic
turnaround times for physicians to retrieve patient information. The commenter expressed
concerned that if providers cannot comply with payers' potential new requirements, they may be
forced out of network.
Response: This rule does not require payers to impose requirements to use the Provider
Access API on their in-network or enrolled providers. However, both providers and patients can
benefit from the improved interoperability facilitated by FHIR APIs, with providers in particular
seeing the benefits of having more patient data available to them. Contractual requirements set
by payers for their in-network or enrolled providers are out of the scope of this rule. Nonetheless,
if payers do choose to require providers to use the Provider Access API in some capacity, or
even if they develop and require their own apps, we expect that they would do so to improve
coordination with the provider and patient care, and also in a way that does not add provider
burden.
Comment: A commenter noted that clinical data managed by payers are often derived
from claims submitted by providers, which often results in them being in a different level of
detail and format than clinical data exchanged between providers. The commenter stated that when the data are made available to providers, clear communication of those differences and
accurate interpretation by the receiving providers system is essential for enabling the provider to
use the data to address care gaps and make treatment decisions. The commenter added that
because the data are derived from claims, which would have been submitted by many of the
same providers requesting it from the payer, deduplication of the data can become more
complex. They further recommended that standards for representing the provenance of data
when transmitted from payers to providers be enhanced to avoid adding a reconciliation burden
on providers who receive the patient data. Another commenter said that EHR vendors would
need to develop a curation function that could allow providers (and patients) to select the
specific data to incorporate into the patients record, warning that without this capability, there
will be a significant amount of duplicate and junk data that will render the Provider Access API
unusable.
Response: We thank the commenter for the comments, and we appreciate the concerns
regarding the level of detail, format, and potential duplication of data received by providers
systems. One of the IGs we recommend for the Provider Access API is the PDex IG (see Table
H3 in section II.G. of this final rule) is a set of guidelines that describes how to exchange data
between payers and providers. A key PDex IG feature is the capability to include provenance
records, if they exist, when exchanging data. Provenance records describe where the data came
from and how they were processed. The PDex IG strongly recommends that payers create
provenance records when they are not included in a data set. We also strongly recommend
provenance records in cases, like those cited by the commenter, when clinical data are derived
from claims. The provenance profile contains contextual information about the data, including
the datas original author(s), transmitters, and formats (including whether they are derived from a
claim-related transaction). Thus, using the PDex IG can help mitigate the problem of duplicating
data by including provenance information. We also strongly recommend that the data source be
included at the point of record creation, so that users can appropriately understand the source and context of the data.While we acknowledge the potential complexity of deduplicating data,
creating contextual provenance information could help providers systems identify data that
already exist in the system, which can make the data actionable, rather than duplicative. In this
way, payers can help providers unlock the benefits of accessing patient information through the
Provider Access API. Finally, nothing in this final rule obligates providers to incorporate data
they access via the Provider Access API into their patients record, if they do not believe there is
a benefit.
Comment: A commenter suggested that CMS permit payers to include audit rights and
penalties in their provider contracts to ensure that payers are able to monitor and regulate
information access requests, as the structure of the proposed rule effectively asked payers to trust
that providers who request access to patient information have a valid need to access that
information.
Response: Nothing in this final rule prohibits impacted payers from includingadditional
requirements in their provider contracts and/or terms of service for requesting patient data.
However, we emphasize that our requirement to provide access is limited to in-network
providers who have a treatment relationship with the patient. We understand that payers need to
ensure that provider requests are appropriate, so it follows that those entities would want to
define roles and responsibilities through provider contracts, as these are established vehicles
which delineate other payer requirements. If payers choose to implement such requirements, or a
separate terms of service agreement, we strongly encourage them to balance the benefits to
patients against any additional burden this would place on providers. Further, our requirements
on the impacted payer will ensure that patients are informed of their data sharing options and will
have the opportunity to opt out of data sharing under this policy if they do not wish for their
providers to have access to their data. Any requirements that payers implement to use the
Provider Access API must not conflict with the HIPAA Rules, or any otherapplicable law. See sections II.B.2.j. and II.B.3.b.ii. for discussions on the interaction of this final rule with the
HIPAA Rules.
Comment: Multiple commenters cautioned that this rule puts a large burden on payers
with little burden on providers and that given the number of resources needed to implement the
API, provider uptake is critical. A commenter further stated that this rule requires payers to build
a new API and share information with providers without asking providers to contribute or share
information with payers, which they believe will lead to a breakdown in communication between
providers and payers.
Response: As discussed previously, the technical requirements for the Provider Access
API align almost identically with those already established for the Patient Access API (85 FR
25510) that impacted payers are currently required to maintain. We also emphasize that our
recommended IGs will provide further clarity for payers on how to implement the APIs, thus
reducing some of the implementation burden. As we discuss in section II.B.3., we are not being
prescriptive as to how impacted payers implement their attribution and opt out processes, so that
they can design processes that work best for them. We believe that all parties will see the benefit
of improved data exchange facilitated by the Provider Access API. Because this final rule does
not prohibit it, impacted payers may also decide to require providers to share certain data with
them as part of their network/enrollment requirements. In fact, we understand that such
requirements already exist in some situations. However, should payers implement such polices,
we expect that they would do so only to the extent that it would benefit patient care and not add
provider burden. We strongly encourage payers to carefully weigh any expected benefits against
this potential burden. Finally, the Health IT Certification Program has already established
requirements for FHIR APIs in EHR systems, which creates the capability for providers to make
data available to payers via FHIR APIs. Using those APIs would allow payers to implement any
requirements in a way that imposes minimal burden on providers. Comment: A commenter recommended that CMS explain whether only providers, not
EHR vendors, can trigger a request for patient records.
Response: We are only requiring impacted payers to make patient data available to in-
network or enrolled providers. Vendors are not permitted to request data for themselves, as they
are not providers and thus cannot meet the criteria for making such a request. However, an EHR
vendor may request the patient data via the providers system at the behest of a provider who is
eligible to request the data, with appropriate authentication and if consistent with other
applicable law.
e. Data Content
Comment: Multiple commenters recommended that CMS streamline the proposed
required data to limit duplicative information and potentially overwhelming providers. A
commenter recommended that CMS initially focus the Provider Access API on sharing claims
data before introducing other types of data. Another commenter recommended that CMS
consider the burden that this proposalmay place on providers if they must maintain multiple
versions of USCDI and whether it would even be feasible for their EHR to support this.
Multiple commenters, however, suggested additional data that should be made available
via the Provider Access API. Some commenters suggested that to facilitate a simpler prior
authorization request process, CMS consider requiring payers to make patients insurance
coverage information readily available to providers through the Provider Access API. A
commenter recommended that patient data collected by payer-owned providers and health
service companies also be included in the Provider Access API.
Response: We understand the concern over duplicative information, and it is not our
intention to increase provider burden. Under this final rule, we are only requiring the exchange
of data that are already structured, meaning they can be received by the providers system in a
standardized format with defined data attributes  this includes data classes and data elements in
the USCDI and FHIR resources (see more discussion of how we define structured documentation in section II.A.2.a.ii. of this finalrule). Most EHR systems use standardized clinical data in their
systems today and, if certified under the ONC Health IT Certification Program, are also required
to use the data classes and data elements in the content standard at 45 CFR 170.213 (USCDI).
There are IT solutions available for providers EHRs or practice management systems, such as
Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR apps, that can
make the data received via the Provider Access API actionable and avoid duplicative
information. Further, for administrative ease and consistency, we are keeping the required types
of data consistent (excluding provider remittances and patient cost-sharing information, as
explained elsewhere in this final rule) with those required under the Patient Access API. We did
not propose to include patients insurance coverage information, to which providers should
already have access through existing channels with payers or from patients themselves.
However, a Health Insurance Information data class has been added to USCDI v3, and includes
the data elements Coverage Status, Coverage Type, Relationship to Subscriber, Member
Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier.39 As payers adopt USCDI
v3 (as required after January 1, 2026, under the regulations at 45 CFR 170.213), this information
would be required to be available.
We remind impacted payers that if there is additional information beyond that which we
are requiring that they do or can share with providers,they can use the Provider Access API as a
mechanism for sharing that information, as permitted by applicable law. To the extent that
impacted payers maintain patient data (per the CMS Interoperability and Patient Access final
rule [85 FR 25536]) collected by payer-owned providers and health service companies, only the
data elements specified in this final rule are included in the Provider Access API requirements.
39OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(2023).HealthInsurance
Information.Retrievedfromhttps://www.healthit.gov/isa/uscdi-data-class/health-insurance-information#uscdi-v3. Comment: A commenter recommended that CMS support the development of content
and technical standards for prior authorization decisions that can be incorporated into IGs for
testing before requiring inclusion of prior authorization information in the Provider Access API.
Response: Our recommended IGs (listed in Table H3) are currently in production and
several versions of the IGs have been updated since publication of the proposed rule.
Additionally, the recently published PDex IG STU 2.0.0 specification includes a prior
authorization profile that enables payers to communicate prior authorization decisions and
changes to the status of a prior authorization requests. The process for IG development is open
and we encourage industry engagement in their further development via opportunities such a
HL7 FHIR Connectathons.
Comment: A commenter recommended that CMS require USCDI v3, since the proposed
Provider Access API would not be implemented until 2026. The commenter stated that the
USCDI v1 does not have digital data standards forsocial determinant of health (SDOH), sexual
orientation and gender identity (SOGI), nor other data standards important for public health
capabilities, and this could be a missed opportunity to drive national digital data standardization
in this area. The commenter suggested this requirement would create a business case and drive
adoption of standards and a move by industry to align.
Response: At the time the proposed rule was published, USCDI v1 was the only standard
included at 45 CFR 170.213. The HTI-1 final rule, however, finalized that USCDI v1 expire on
January 1, 2026, and also adopted USCDI v3 at 45 CFR 170.213 (89 FR 1210). Both versions
will be available USCDI versions at 45 CFR 170.213 until January 1, 2026. Until this date,
payers may meet the Provider Access API requirements by sharing all data classes and data
elements in either USCDI v1 or v3. After January 1, 2026, payers must make available all data
classes and data elements in USCDI v3. ONC accepts submissions from the public for new
USCDI data classes and data elements through the USCDI ONC New Data Element and Class (ONDEC) Submission System40 and regularly publishes updated versions of the USCDI.41 Any
change in a content standard at 45 CFR 170.213 will go through notice-and-comment
rulemaking. Impacted payers are permitted to voluntarily use updated standards, specifications,
or IGs that are not yet adopted in regulation forthe APIs discussed in this final rule, should
certain conditions be met. We specifically encourage impacted payers to make all data classes
and data elements available from more advanced versions of the USCDI prior to the expiration
date.We refer readers to section II.G.2.c. of this final rule for a full discussion on using updated
standards.
Comment: A commenter noted that while there is a FHIR resource for a scheduled
appointment, it is not included in USCDI v1, which means a provider cannot send an
appointment even when they have implemented the latest version of USCDI. The commenter
stated that adding that element would require additional EHR vendor development.
Response: All data classes and data elements included in a content standard at 45 CFR
170.213 (USCDI) for dates of service after January 1, 2016, maintained by the payer are required
to be made available to the provider who requests them (assuming all other applicable
requirements specified in this final rule are met). Whether or not a scheduled appointment data
element is included in USCDI has no bearing on how API developers use the Scheduling and
Appointment FHIR Resources for other purposes.
Comment: Multiple commenters disagreed with the proposalto require payers to include
clinical documentation and forms related to a prior authorization, with one noting that this
information will be duplicative of the clinical information in a persons medical record. Another
commenter stated that clinical documentation is often submitted to payers in the form of lengthy
PDF documents, and sometimes by fax, making manually translating these data into FHIR
40OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(n.d.).USCDIONDEC(ONCNew
DataElementandClass)SubmissionSystem.Retrievedfromhttps://www.healthit.gov/isa/ONDEC.
41OfficeoftheNationalCoordinatorforHealthInformationTechnology(ONC)(n.d.).UnitedStatesCoreDatafor
Interoperability(USCDI).Retrievedfromhttps://www.healthit.gov/isa/united-states-core-data-interoperability-
uscdi. challenging and infeasible to do within the proposed 1 business day timeframe. A commenter
recommended that CMS explain whether payers have to convert clinical documentation
submitted by providers by fax or in PDF or JPEG file formats into FHIR. A commenter
recommended that CMS require the same discrete data element standards that the agency applied
to the original Patient Access API to the Provider Access API, since distributing patient clinical
attachments to all requesting clinicians raises concerns under the HIPAA minimum necessary
standard. The commenter stated that an alternative is that providers could share clinical
attachments as needed through clinician data sharing consultation and collaboration. However, a
commenter recommended that CMS should include the administrative and clinical
documentation requirements and require specific information for prior authorization data.
Response: After reviewing the comments, we agree that the burden of requiring payers to
make unstructured documentation (as explained in section II.A.2.a.ii. of this final rule) available
via the Provider Access API outweighs the benefits such documentation would provide. Thus,
like forthe Patient Access API, we are finalizing a requirement that the Provider Access API
include only structured administrative and clinical documentation related to the prior
authorization requests.
As with the Patient Access API, documentation received in an unstructured format does
not need to be parsed and converted to structured data for the purposes of inclusion in the
Provider Access API. However, if a payer does parse the unstructured documentation to store the
contained data in a structured format, that structured data would then be maintained by the
payer, as defined in the CMS Interoperability and Patient Access final rule (85 FR 25538). For
example, a payer may receive and maintain an unstructured PDF that contains lab results. If a
payer maintains those lab results in a structured format, they would be required to share them
under this final rule. If they are maintained in an unstructured format, they would not.
We recognize that unstructured administrative and clinical documentation could be
important to help providers understand certain prior authorization requirements, so we encourage payers to make that information available when possible. Furthermore, the policy we are
finalizing would require payers to make available any documentation or materials that the
provider sends to the payer to support a decision that are received in a structured format. Since
we are finalizing that only structured documentation be made available, and structured
documentation are formatted in a way that makes them easily transmissible between systems, our
final policy should place significantly less burden on payers than our proposal, while still giving
providers access to information about their prior authorization processes.
It is important for payers to make available the specific clinical data at which they are
looking to make a determination on the prior authorization request, even if that information may
be elsewhere in the patients record. As to the commenter concerned about clinical attachments
and the HIPAA Privacy Rules minimum necessary standard, we refer them and all readers to
section II.B.3.b.ii. of this rule for more discussion about the HIPAA Rules.
Comment: A commenter sought clarification on whether the data sharing requirement
applies to only claims and encounter data that are available at the time of the request, reasoning
that if so, it could avoid any inappropriate pressure on providers to submit claims immediately
after the provision of an item or service.
Response: Per the CMS Interoperability and Patient Access final rule (85 FR 25536),
payers are only required to share data that they maintain as part of their normal operations.
Nothing in this final rule would change that existing policy that payers are not required to reach
out to providers or other entities to gather data that they do not maintain, if it is not part of their
normal operations, in order to share via the Provider Access API.
f. Provider Remittances and Cost-Sharing Information
Comment: Multiple commenters agreed with CMSs proposal to not require payers to
make available provider remittances and patient cost-sharing information, as it would likely only
have a limited beneficial impact on care. A commenter stated the cost-related data currently
available via from the Patient Access API are not very clear, which could lead to different implementations and increased ambiguity when implementing the Provider Access API. A
commenter warned that implementers are inconsistent, with some sending Explanation of
Benefits (EOB) scrubbed of the item level detail, whereas others exclude EOBs altogether and
only provide clinical data.
Response: Regardless of whether provider remittance information or cost-sharing
information are truly confidential or proprietary information protected from disclosure under
Federal law (which we do not address here), excluding such data from the Provider Access API
is appropriate. Thus, if commenters believe that cost-sharing information would largely not be
helpful information for providers to have access to, then we emphasize that sharing this
information is not a requirement for the Provider Access API. We further agree with commenters
that including this information in the Provider Access API will have limited benefit for treatment
or care coordination. This rule does not prohibit payers from sending that information. Therefore,
if a payer believes that implementing their Provider Access API in such a way that includes
provider remittances and patient cost-sharing information would provide benefit or reduce
burden, they are not prohibited from doing so under this rule, and may do so consistent with
other applicable laws.
Comment: Multiple commenters urged CMS to reconsider excluding cost-sharing
information from the Provider Access API because providers with access to this information can
make more informed decisions regarding patient care by incorporating cost into treatment plans,
and in turn, maintain a good provider-patient relationship. A commenter encouraged CMS to
examine standards-based, patient-facing, and real-time benefit check capabilities that can be
facilitated by patient cost-sharing information. A commenter also cautioned that excluding
provider remittances and cost information conflicts with the cost-sharing information needed to
enable Good Faith Estimates (GFE) under the No Surprises Act (NSA), which was enacted as
part of the Consolidated Appropriations Act, 2021 (CAA).42 They suggested that the rule be
42PublicLaw116260(December27,2020). revised to allow necessary cost-sharing information required under the NSA. Another commenter
highlighted that providers must be able to calculate sustainable total cost of care for patients
attributed to them as part of value-based payment models.
Multiple commenters proposed potential solutions to facilitate the sharing of cost-sharing
information. A commenter suggested that CMS consider a bi-directional exchange mandate (as
opposed to one-way provider access to payer data) to cover payment and operations, in addition
to treatment. A commenter suggested that it does not make sense to restrictpatient cost-sharing
information since it is available in the X12 270/271 transaction standard. The commenter stated
the Provider Access API can potentially replace the need for a separate 270/271 transaction and
instead incorporate the information in 270/271 transactions. Another commenter expressed that
modifications could be made to the CARIN IG for Blue Buttonto align with the proposed
requirement to remove remittances and cost-sharing data from the FHIR transaction.
Response: While we appreciate the various suggestions we received; we did not propose
any related policies because the primary purpose of our Provider Access API policies is to
improve the exchange of data for health care treatment. We acknowledge that some providers
may find cost information helpful for gaining a clearer picture of a patients financial situation.
However, there is nothing prohibiting a provider from discussing the costs of various items or
services and comparing the costs when furnished in-network and out-of-network to help a patient
understand how to limit their out-of-pocket costs. Further, in-network or enrolled providers
should be generally aware of the costs of various treatments, as their contracts would address
payment amounts and conditions of payment for services furnished by that provider to a covered
individual. We finally note that the GFE provision of the NSA relates to prospective costs, rather
than cost information from past claims; that provision is beyond the scope of this final rule.
Comment: A commenter stated that the CARIN IG for Blue Button will require updates
to support CMSs proposal to remove remittances and cost-sharing data from the FHIR
transaction for the Provider Access API. Response: Further development is currently underway on the CARIN IG for Blue Button,
which is one IG that we are recommending to support the Patient Access, Provider Access, and
Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule). These developments will
support exchanging information without provider remittances and patient cost-sharing
information.
Comment: A commenter supported CMSs effort to establish the infrastructure needed to
support paymentreform and value-based care initiatives via the Provider Access API, stating that
these initiatives are critical to reducing the costs of health care delivery while maximizing quality
for Medicare enrollees. Multiple commenters stated, however, that the Provider Access API does
not facilitate sharing the complete set of information needed by providers for participation in
value-based care programs and recommended that CMS prioritize additional information, such as
financial targets, spending, coordination of care payments, payer-generated attributed
beneficiaries, and cost performance reporting. They believe these would allow a better exchange
of value-based care paymentmodels summary-level data. A commenter recommended that
ONC and CMS encourage industry to prioritize APIs to exchange information that would reduce
administrative burden and lead to value-based care scalability.
Response: We did not propose to include cost information for value-based care, as the
primary goal of the Provider Access API is to give providers both immediate and direct access to
patient data in order to improve patient care. However, we remind impacted payers that they can
use the API to exchange additional data, should they so choose. We agree that FHIR APIs have
the potential to support participation in value-based care programs, as these initiatives are critical
to reducing the costs of health care delivery while maximizing quality for patients. We will
continue to explore ways to leverage FHIR APIs to achieve CMS and broader HHS priorities.
The requirements in this final rule are a critical foundation for this future work.
g. Prior Authorization Data Comment: Multiple commenters supported including prior authorization information in
the data made available through the Provider Access API, noting that it would help future
providers understand the patients current health status more quickly and better meet their care
needs, increase transparency, and reduce burden on patients and providers. A commenter stated
that adding prior authorization information to the Provider Access API will enhance functionality
and incentivize use of the API.
Response: We thank commenters for their support and agree that giving providers access
to the same prior authorization data as patients will have a positive impact on patient care.
Comment: Multiple commenters recommended notincluding the quantity of services
used due to delays in claims processing. A commenter recommended that CMS include just the
approved number of units.
Response: In response to commenter feedback to both the Provider and Patient Access
API proposals, we are finalizing our proposal with the modification that quantity of approved
items or services used to date will not be a required field. We refer readers to section II.A.2.a.ii.
of this final rule for a full discussion of our reasoning.
Comment: A commenter recommended including a standardized comment code(s) and
comment description(s) for each status update sent to the provider to help with future data
analysis of prior authorization improvements and tracking quality metrics.
Response: While we consider five basic statuses (pending, active, denied, expired,
authorization not required) to cover the general scope of a prior authorization requests and
decisions, we do not intend to prescribe or delineate the exact statuses that payers must use. The
requirement for the Provider Access API (and the other APIs in this rule) to include the status of
the prior authorization is intended to provide information to the provider, patient, or other payer
that is using the API to access this information. Therefore, compliance with the requirement is
not based on using specific terms, buton providing clear information. We refer readers to section
II.A.2.a.ii. of this final rule for a full discussion on prior authorization status definitions. Comment: A commenter recommended that CMS crosswalk the required types of data for
the Provider Access API with the other proposed APIs to avoid duplication, such as having to
include supporting documentation through the Provider Access API, even if it is available via the
Prior Authorization API.
Response: If the commenter is recommending that the Provider Access API make
available a mutually exclusive set of data from the Prior Authorization API to avoid confusion,
then we note that Prior Authorization API will not have prior authorization data from other
providers. We refer readers to section II.D.of this final rule forour full discussion of the Prior
Authorization API requirements. We further intend to provide educational resources related to all
the APIs in this final rule. We are not finalizing our proposal that related unstructured
administrative and clinical documentation be included in the prior authorization data that
impacted payers would have to make available to providers via the Provider Access API.
Comment: A commenter recommended including the following additional data elements
related to prior authorization: timestamps of any change in the status of the prior authorization;
date/time received, reviewed, denied/approved; how the decision was made; software
tools/artificial intelligence (AI) tools used; and persons involved in making the prior
authorization decision. Another commenter stated that prior authorization metrics should be
available via the Provider Access API to give providers an aggregated view of their attributed
patients prior authorizations. A commenter also recommended that CMS should require payers
to make available through the Provider Access API contact information for the entity responsible
for managing the payers prior authorization program.
Response: While these specific additional data and functionalities may provide value to
some providers at this time, we do not believe that the value outweighs the additional effort
impacted payers would need to expend to add these data and functionalities to the Provider
Access API. The PDex IG STU 2.0.0, which has been published since the publication of the
CMS Interoperability and Prior Authorization proposed rule, states that payers using this IG shall make available pending and active prior authorization decisions and related clinical
documentation and forms for items and services (not including prescription drugs), including the
date the prior authorization was approved, the date the authorization ends, as well as the units
and services approved and those used to date. It also requires a creation date, issued date, and
specific codes relevant to the approval status.43 However, as discussed in section II.G., we are
not yet ready to require this IG. We are thus prioritizing the data that are most important and
useful at this time for clinical decision-making in proximity to a patient visit. To use one
commenters example, requiring payers to provide contactinformation for the entity responsible
for managing the payers prior authorization program would be duplicative, as providers who
have a contractual relationship with the payer should already be aware of whom to contact
regarding their prior authorization submissions. Providers can also use the Prior Authorization
API to obtain this information. We remind impacted payers, however, that they may choose to
include additional information if they believe it adds value to patients,providers, or themselves
and their own processes. FHIR inherently provides flexibility to include additional information
without reducing interoperability and the associated IGs are designed to both require and
constrain specific elements identified as core to the IGs use case. We encourage the public to
engage in the HL7 balloting process44 to provide feedback on data elements they believe would
be most widely useful and applicable.
Comment: A commenter recommended that sharing prior authorization information
through the Provider Access API be required, even if the patient opts out.
Response: We certainly agree with the benefits of providers having access to prior
authorization information via an API and note that providers will have access to the Prior
Authorization API. Providers will thus have access to these data for prior authorization requests
43HealthLevelSevenInternational(2020).DaVincipayerdataexchangeSTU2.0.0.Retrievedfrom
https://build.fhir.org/ig/HL7/davinci-epdx/.
44HealthLevelSevenInternational.HL7Balloting(n.d.).Retrievedfrom
https://confluence.hl7.org/display/HL7/HL7+Balloting. that they make, regardless of whether the patient has opted out of the Provider Access API. We
refer readers to section II.D.2.c. of this final rule for our discussion on patient opt out and the
Prior Authorization API.
Comment: A commenter urged CMS to require impacted payers to provide a statement
through the Provider Access API when they are not requiring a prior authorization for an item or
service. The commenter stated that this will ensure a level of transparency and paper trail
between payer and provider.
Response: This information will be available through the Prior Authorization API, so
does not need to be included in the Provider Access API. We refer readers to section II.D. of this
final rule for our full discussion of the Prior Authorization API requirements and section
II.A.2.a.ii. for that of prior authorization statuses.
Comment: A commenter encouraged CMS to work with impacted payers to ensure the
supporting data fields of laboratory test results, clinical data, and a specific reason for a denial
are standardized to ensure information is consistent across sources. They urged CMS to work
with payers, providers, and patients to determine the balance of data included in the requirements
and provide the needed clarification and guidance to all parties.
Response: As explained in section II.B.2.e. of this final rule and in more detail in section
II.A.2.a.ii. of this final rule, we are finalizing a requirement for payers to share only data that are
already structured, which include laboratory test results, clinical data, and a specific reason for a
prior authorization denial. We also remind readers that payers are not obligated under this rule to
parse or convert documentation received in an unstructured format for the purposes of inclusion
in the Provider Access API. However, they may choose to do so. We will continue to work with
interested parties to ensure that all parties benefit from the data sharing requirements we are
finalizing and explore possible enhancements to our policies that require API development or
enhancement in future rulemaking.
h. Data Availability Comment: A commenter stated that prior authorization information should be available
from the entire duration of the patients history and not just for 1 year after the last status change
because it would improve transparency in decision-making for providers.
Response: Like with the Patient Access API, we believe that 1 year after the last status
change is the appropriate amount of time to require payers to make historical prior authorization
information available to providers. While historical information can certainly affect and be
useful in improving patientcare, we believe that historical claims and clinical data are more
important to providers than information about prior authorizations that have expired or been
denied more than a year in the past. Furthermore, our policy allows payers to make these prior
authorization data available for longer than 1 year, if they believe it adds value to patients,
providers, or themselves and their own processes. To inform ongoing long-term care, any active
prior authorizations must be included, even if they have been in that status for more than a year.
Comment: A commenter supported the payer maintaining patient health data and making
available any data to the provider with a date of service on or after January 1, 2016. A
commenter recommended that CMS explain whether all data included in this rule will be subject
first to corporate data retention standards, then retained from January 1, 2016, to present.
Another commenter sought clarification as to whether CMSs intention is to include all data
since 2016 and not only the last 5 years.
Response: We remind impacted payers that the policy we are finalizing aligns with the
similar one finalized in the CMS Interoperability and Patient Access final rule:45 the data
available through the Provider Access API are data with a date of service on or after January 1,
2016 maintained by the payer. By maintained, we mean data that are maintained as part of
45See42CFR422.119(h)(1)(i)forMAorganizations,431.60(g)(1)(i)forMedicaidFFS,and457.730(g)(1)(i)for
CHIPFFS,crossreferenceto42CFR431.60at42CFR438.242(b)(5)forMedicaidManagedCare,crossreference
to42CFR438.242at42CFR457.1233(d)forCHIPManagedCare,and45CFR156.221(i)(1)forQHPissuerson
theFFEs. normal operations, as is currently the policy for the Patient Access API under the CMS
Interoperability and Patient Access final rule.
We did not propose a policy for impacted payers to make data available only from the
previous 5 years in either the proposed rule or the CMS Interoperability and Patient Access final
rule, nor did we receive comments specifically in favor of shortening the timeframe to 5 years.
However, we also recognize that the data a payer maintains dating back to January 1, 2016,
could be a substantial amount and, depending on the capabilities of the providers EHR or
practice management system, potentially more than some providers will need. We remind
providers that this final rule does not obligate them to incorporate data they access via the
Provider Access API into their patients record. While we are finalizing our proposal to require
impacted payers to make available via Provider Access API any of the applicable patientdata
with a date of service on or after January 1, 2016, that the payer maintains, we will closely
monitor whether this timeframe is appropriate, to inform possible future rulemaking.
i. Response Timeframe for Requested Data
Comment: Multiple commenters expressed their support for the proposal to require
payers to share the requested patient data no later than 1 business day after the payer receives the
request. A commenter stated this will enable the provision of historical health care data and may
affect current care recommendations. Multiple other commenters sought clarification on whether
the proposed 1 business day turnaround time for a payer to respond to a providers request for
patient data included time for payers to complete an authentication of the providers identity and
the provider-patient treatment relationship.
Multiple commenters recommended that CMS increase the amount of time payers have to
respond to providers data requests. Recommendations included suggestions to establish a two-
day response time to balance timely access to information and reduce the operational burden and
cost of the requirement. Commenters also noted that not all provider systems are FHIR-enabled
and that could lead to longer data exchange times. A commenter stated that because of CMSs technical standards, specifications, and IG requirements, payers will likely need more time than
one day to comply with CMSs proposed requirements. They believe that payers may need
additional time to establish technical connections and contractual terms for a first-time request
from a provider.
However, other commenters believed the time for payers to respond to the data request
should be decreased from 1 day and that the response should come as soon as possible, to be
real-time or near real-time. A commenter sought clarification from CMS as to why 1 business
day is allowed for the payer to respond to a request, particularly if the initial request is being
transmitted during a patient visit. The commenter continued that real-time responses should be
expected from new technology. Another commenter stated having real-time data would help
providers see a more complete view of a patients complete care history. A commenter warned
that, often, providers and patients review data during a visit and that delayed access to the data
could undermine efforts to promote care coordination and provider-patient engagement. A
commenter also recommended that CMS consider requiring that the requested data be provided
within 1 calendar day to accommodate facilities that have 24/7 operations, like SNFs.
Response: We foresee providers needing access to the specified data in order to review
them in proximity to a patient visit. Thus, we do not believe that the turnaround time should be
greater than 1 business day. We specify in the regulation that a payer must make the data
available through the Provider Access API no later than 1 business day after receiving a request
from the provider, if all the following conditions are met:
 The payer authenticates the identity of the provider that requests access and attributes
the patient to the provider under the required attribution process;
 The patient does not opt out of the Provider Access API; and
 Disclosure of the data is not prohibited by law.
Authenticating the identity of the provider will include confirming that the requesting
provider is in-network or enrolled with the payer and the attribution process will include confirming that a verified treatment relationship exists. The technical standards at 45 CFR
170.215 set requirements for identity proofing and authentication processes that must be met in
order for a providers EHR or practice management system to connect to the Provider Access
API and access a patients data (see section II.B.2.k. for more discussion on authorization and
authentication). Those standards allow authentication to be completed within 1 business day, if
not immediately, when the provider accesses their system via login. Impacted payers can also
verify the patient-provider treatment relationship before the provider request. In fact, payers are
permitted and highly encouraged to design their attribution processes to verify treatment
relationships prospectively. We believe that the patient relationship can be verified for the vast
majority of providers who will be requesting data via the Provider Access API eitherahead of
time or relatively quickly. However, we recognize that this may be difficult, if not impossible,
for a new patients first visit because there will be no claims history between that patient and the
provider. Thus, there might be instances where the conditions previously mention may take
longer to be met for some data requests. We strongly encourage impacted payers to ensure
completion of these steps in a reasonable amount of time, so the provider can make use of the
data they are requesting.
While we appreciate the commenters who pointed out that some providers might need the
patient information as soon as possible or in real time, we also believe that requiring that
standard would cause undue burden on impacted payers. We nonetheless encourage payers to
make data available to requesting providers as soon as they are able.
We are therefore finalizing our proposal that impacted payers respond to a providers
request for patient data no later than 1 business day after the payer receives the request if all
conditions are met. This timeframe adequately balances a providers need for timely data with
impacted payers capability to make data available. Further, as discussed in detail in section
II.A.2.a.ii. of this final rule, we are not finalizing our proposal for impacted payers to share unstructured documentation related to prior authorizations, as sharing such documentation would
currently be difficult to accomplish in 1 business day.
Comment: A commenter stated that the required response time for the Provider Access
API could be administratively time consuming because the process to determine whether a
disclosure is permitted under applicable law is a manual process that involves research, review,
and analysis to determine which laws are applicable to the requester of the information, the type
of data requested, and the intended recipient. Another commenter recommended thatCMS
consider the extent to which payers will be burdened by connecting and testing EHRs to
facilitate the Provider Access API implementation.
Response: We are only requiring impacted payers to share data elements that are already
structured, and are requiring certain mature IGs and standards (see Table H3 in section II.G. of
this finalrule) that will enable the Provider Access API to connectto third-party apps and/or
providers EHRs or practice management systems. Because of this foundation, along with the
2027 compliance dates that we are finalizing, payers should have sufficient time to not only test
their API connections, but also to develop internalprocesses and train staff to make the
necessary determinations of which of the known and structured data are permitted to be shared
via the Provider Access API. For instance, impacted payers may use this time to develop
processes that flag certain data elements  as the payer receives them  as those that may require
special permissions or are prohibited to disclose underother law. Such processes can ease any
manual review and decision-making that might be necessary when a provider requests patient
data.
Comment: A commenter recommended that CMS make it clear that the provider must
request access to patient data and attest to their treatment relationship with the patient at the time
of connection.
Response: While payers might utilize a process for providers to attest to a treatment
relationship at the time of the data request, we did not propose, nor are we finalizing such a requirement. This is not the only way to attribute patients, but impacted payers are certainly
permitted to utilize a provider attestation as part of their attribution process (discussed in section
II.B.3.a. of this final rule). Our regulations do not prohibit using an attestation where another law
that permits disclosure requires an attestation.
Comment: Multiple commenters sought clarification on whether CMSs 1 business day
proposed requirement complies with the 21st Century Cures Act (Pub. L. 114255, Dec. 13,
2016) (Cures Act) around information sharing without delay.
Response: We refer readers to section II.A.2.a.iii. of this final rule for a discussion of
how our timeline requirements relate to ONC information blocking regulations.
Comment: A commenter recommended that CMS require payers to notify providers once
they have received a request and the specific date a provider should expect to receive
information in response.
Response: While we did not propose such a requirement, it would be good practice for
the payer to verify that they have received the request for patient data from the provider. We
expect payers to have a process for providers to track their requests. Additionally, it would
benefit providers for them to receive a notification if the patient cannot be attributed to them. In
the DPC pilot, participating providers have the ability to request data for a patient with whom
they have no prior treatment relationship, however they will receive a response with no data if
they do so.
j. Interaction with HIPAA Privacy, Security, and Administrative Transaction Rules
Under our policies, all data shared and received via the Provider Access API must be
handled in a way that is consistent with all applicable laws and regulations. Payers and health
care providers that are covered entities under the HIPAA Rules46 are subject to the HIPAA
46UndertheHIPAARulesat45CFR160.103,acoveredentityincludesahealthcareproviderwhotransmitsany
healthinformationinelectronicforminconnectionwithatransactioncoveredbythesubchapter.Seealso
definitionsofhealthcareproviderandtransactionathttps://www.ecfr.gov/current/title-45/subtitle-A/subchapter-
C/part-160/subpart-A/section-160.103. Privacy and Security Rules.47 Adherence to both the HIPAA Privacy and Security Rules helps to
ensure that the covered entity 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 security management processes;48 access controls;49 and audit
controls.50 Regardless of whether a provider meets the definition of a covered entity under the
HIPAA Rules at 45 CFR 160.103, there may be state laws that require certain privacy and
security protections for an HIE. Additionally, other laws, such as the regulations that focus on
confidentiality of substance use disorder patient records at 42 CFR part 2 or state privacy laws,
may require the payer to obtain the enrolled individuals permission to disclose certain health
information. We requested comment on any other considerations regarding state privacy or other
laws that may be implicated by our proposals.
Commenters provided many thoughts and recommendations related to the Provider
Access APIs intersection with existing privacy laws, including the HIPAA Privacy Rule. We
thank the commenters for their perspectives and will use the feedback to inform future guidance,
educational resources, and/or rulemaking. We remain committed to safeguarding patient
information across the health care industry. Our policies provide an opportunity to engage
patients in their data sharing and privacy rights while offering them the opportunity to more
meaningfully engage with their care.
Our policies will not alter any obligation for providers or payers to comply with
applicable law, including obligations for HIPAA covered entities to follow the HIPAA Rules.
Such other applicable law includes, but is not limited to, standards regarding the use and
4745CFRparts160and164,subpartsA,C,andE.DepartmentofHealthandHumanServices(2022).Security
RuleGuidanceMaterial.Retrievedfromhttps://www.hhs.gov/hipaa/for-
professionals/security/guidance/index.html?language=es.
48See45CFR164.308(a)(1).
49See45CFR164.312(a).
50UndertheHIPAARulesat45CFR160.103,acoveredentityincludesahealthcareproviderwhotransmitsany
healthinformationinelectronicforminconnectionwithatransactioncoveredbythesubchapter.Seealso
definitionsofhealthcareproviderandtransactionathttps://www.ecfr.gov/current/title-45/subtitle-A/subchapter-
C/part-160/subpart-A/section-160.103. disclosure of PHI, administrative, physical, and technical safeguards and other security
provisions, and breach notification. The minimum required security framework of the Provider
Access API is specified in the technical standards at 45 CFR 170.215 and will allow payers to
verify the requesting providers identity by using the required authorization and authentication
protocols. Authorization refers to the process by which the payer gives the provider permission
to access data. The authentication protocols are those that allow the payer to verify the identity of
the requesting provider. In addition to using these required protocols, the payer will 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 section II.B.3.a. of this final rule. 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.51
Under section 1173(a) of HIPAA, the Secretary is required to adopt standards for specific
financial and administrative transactions and may adopt standards for other financial and
administrative transactions. Although our policies will facilitate sharing claims data from payers
to providers for the purpose of helping to improve patientcare, the FHIR API data transmission
will not be subject to HIPAA transaction standards because the purpose of the exchange would
not be to request or issue a payment.52 We also did not propose 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.53 The Secretary has not adopted a
HIPAA transaction standard applicable to transmitting claims or encounter information for a
purpose other than requesting or issuing payment, thus HIPAA administrative simplification
standards do not apply to the Provider Access API.54
51HealthLevelSevenInternational(2022).FHIRSecurity.Retrievedfromhttp://www.hl7.org/Fhir/security.html.
52See45CFR162.1101(a).
53See45CFR162.1101(b).
54See45CFR162.923(a). k. Technical and Standards Considerations
Comment: Multiple commenters recommended that CMS detail the requirements forthe
Provider Access API, with many offering that the rule should describe the workflow,
authorization, provider authentication, and attribution processes in more detail. They cautioned
that without a standardized governance framework and legal terms, it will be unreasonable to
expect payers and providers to establish connections and respond to requests within a set
timeframe since they will need to negotiate bespoke agreements.
Multiple commenters stated that CMSs proposed standards and recommended IGs are
insufficient for the Provider Access API. One payer cautioned that this would result in payers
struggling to comply with the requirements and limited improvements to information exchange.
Another commenter warned that the lack of endpoint standardization between payer and provider
systems will likely create technical difficulties. A commenter stated that without requiring an IG
for the Provider Access API, the data will not be standardized and might not be able to be
directly incorporated into a providers EHR or practice management system. A commenter also
noted that the IGs that CMS recommends do not include direction for how sensitive data such as
behavioral health data will be shared and with what privacy guidelines. A commenter was
additionally concerned that the recommended IGs are notenough to support the attribution
process.
Response: We refer readers to section II.G.of this final rule for further discussion
regarding the required technical standards for the Provider Access API and IG maturity. Further,
the IGs we are recommending, listed in Table H3, are primarily meant to help implement the
APIs themselves, not to facilitate related payer processes, like segmenting sensitive data or the
attribution process. We recommend that industry look to existing trust community agreements
for guidance on a standardized governance framework and legal terms. These agreements include, but are not limited to TEFCA or others used by state and regional HIEs.55 We anticipate
that affected entities will need to adopt new practices and methods to enable data sharing with
new trading partners, including payers supporting new types of interoperability with providers.
This final rule affords flexibility to define those approaches. We will continue to evaluate and
consider specifications that are well-adapted to meet the legal and regulatory needs for possible
future guidance or rulemaking.
Comment: A commenter recommended that CMS exercise caution when selecting
authentication mechanism requirements for the Provider Access API and stated that allowing
simpler authentication mechanisms may make it easier to incorporate into workflows. Another
commenter stated that it is unclear the extent to which payers would be expected to support trust
and authentication processes for individual clinicians via the OpenID Connect Core standard,
versus SMART integration that could rely on organization-level authentication. They noted that
without specificity on workflows for exchange and authentication, authorization, and consent
processes, payers and developers will need to support the numerous permutations that could be
adopted by providers to address those needs, increasing complexity and burden. The commenter
acknowledged the specifications developed by the HL7 Da Vinci Project and others have
begun to address technical aspects of those needs, however, they are not yet mature and, because
they are technical standards, do not address needed governance agreements.
Another commenter stated that while the FHIR resources in the current Patient Access
APIs are mostly reusable, the mechanism for providers to access information is entirely different.
The commenter discussed system authentication and access protocols (OAuth and OpenID
Connect Core) that are used to enable members to use portal credentials to pull data into a third-
party app. The commenter mentions that while OAuth can and should be used for server-to-
server connections to enable access to a wider set of data while maintaining security practices,
55OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023).CommonAgreementfor
NationwideHealthInformationInteroperability.Retrievedfrom
https://www.healthit.gov/sites/default/files/page/2023-11/Common_Agreement_v1.1_FINAL_508_1.pdf. current APIs do not have this capability. Therefore, they believe that this modification to enable
a health care provider to access data on multiple patients is a significant change and will require
rebuilding the FHIR APIs available for provider access.
Response: Impacted payers are required to use authorization and authentication protocols
to verify the requesting providers identity. However, there is no single security protocol
approach that will address all use cases. Additionally, within a single API, implementers may
need to utilize more than one protocol to address specific population and trading partner needs.
We are finalizing a modification to our proposal to not require the OpenID Connect Core for the
Provider Access API. However, we are requiring impacted payers to use the SMART App
Launch IG, which includes the capability to perform authentication via OAuth. However, we
recognize that other methods such as Backend Services Authorization (which is included in both
the SMART App Launch IG Release 2.0.0 and the Bulk Data Access IG v1.0.0), Mutual
Transport Layer Security (mTLS), Unified Data Access Profiles (UDAP), or other trust
community specified means may be appropriate depending on the needs.
The PDex IG,56 which we are recommending payers use to support the Patient Access,
Provider Access, and Payer-to-Payer APIs (see Table H3 in section II.G.4. of this final rule),
includes using mTLS for the purposes of authentication. We are also supporting efforts to further
refine the specifications for security (that is, authentication) at scale through UDAP via the
FAST Security IG and will consider recommending this specification in the future. We recognize
the importance of scalable technologies needed to support secure, protected, and authorized
connectivity and communication across a wide range of interested parties throughout the
industry. There are several approaches available, including the ones cited by commenters, and
others implemented by various trust networks operating throughout the United States today.
56HealthLevelSevenInternational(2020).DaVinciPayerDataExchange.Retrievedfrom
http://hl7.org/fhir/us/davinci-pdex/STU1/. Comment: Multiple commenters supported CMSs proposed requirement to leverage the
Bulk Data Access IG for the Provider Access API, so that if a provider has a panel of patients
associated with a single payer, the payer can share those data asynchronously in one transaction.
Response: We thank commenters for their support of our policies. As discussed in section
II.G. of this final rule, we are finalizing our proposal for impacted payers to use the Bulk Data
Access IG at 45 CFR 170.215(d)(1) to support implementation of the Provider Access API.
Comment: Multiple commenters recommended that CMS limit the API to only individual
data requests and that CMS not require the FHIR Bulk Data Access specification at this time, but
instead consider it at a later date after it has been more thoroughly tested by HL7. Multiple
commenters also stated that more work is needed on the Bulk Data Access IG before it is
mandated, as it has not been adequately implemented; this makes it difficult to assess if it will be
able to meet the proposed need and timelines.
Multiple commenters also highlighted concerns with the technical functions of the Bulk
Data Access IG and noted that large bulk downloads could pull time away from more urgent
requests. The commenters recommended that payers be able to put reasonable limits on bulk data
requests or that CMS should remove the bulk data transfer from the initial requirements. A
commenter stated that CMS should only require impacted payers to respond to requests for
certain patients data quarterly. The commenter stated this would ensure that vendors do not set a
default of daily retrievals of data that risk sharing more patient information than necessary.
Multiple commenters additionally flagged that payers, especially smaller health plans,
could struggle to respond to bulk requests within the 1 business day response period and that
they could be faced with significant costs to implement this requirement correctly. A commenter
stated concern about bulk patient attribution and requested CMS clarification and/or limitations
on bulk data sharing requirements.
Response: Bulk data exchange can allow payers to prioritize more urgent requests and
defer bulk data requests until a later time when sufficient system resources can be allocated to create bulk data export. However, we remind payers that they are still required to comply with
the 1 business day timeframe discussed in section II.B.2.i. of this final rule. We emphasize that
although we are requiring impacted payers to support FHIR Bulk Data Access at 45 CFR
170.215(d)(1) under this final rule, this requirement does not obligate them to use it for every
data exchange if it is not feasible. However, we agree with commenters that impacted payers
have leeway to place reasonable limits on bulk data requests. At the same time, we also believe
that the benefits of access to these data outweigh any potential concern that vendors will set daily
retrievals of data. This is because a provider would first need to request the data for individual
patients, as well as the fact that the Provider Access API is better suited to enable discrete
provider use when seeing a patient, rather than ongoing patient monitoring.
Comment: A commenter stated that the PDex IG could support the opt out process by
adding a flag to indicate an attributed member has opted out of provider data sharing.
Response: We appreciate the commenters suggestion and urge impacted payers to
explore ways to leverage FHIR IGs for the other processes that we are requiring in this rule.
l. Interaction with ONC Policies
Comment: Multiple commenters made recommendations regarding how CMS can work
with ONC. They recommended that CMS work with ONC to implement additional requirements
as part of the ONC Health IT Certification Program for developers to implement API interfaces
into CEHRT in such a way that fits with provider workflow.
Multiple commenters also recommended that CMS partner with ONC to create guidance
regarding implementation of the Provider Access API and the technical capabilities of payers,
EHR vendors, and providers. A commenter further suggested that CMS work with ONC to
ensure that both payers and CEHRT vendors are aligned in the technical capabilities to
implement Provider Access APIs in a way that does not hamper provider workflow and negate
efforts to reduce prior authorization burdens. Multiple commenters strongly encouraged CMS to work with ONC to consider how the
Provider Access API could be expanded in future rulemaking to support bi-directional, real-time
data exchange between payers and providers to support patient care and to automate prior
authorization requests, rather than a one-way data exchange from payer to provider. A
commenter stated that including such criteria could ensure compliance with the ONC Cures Act
final rule information blocking policies.
Response: We appreciate commenters support for leveraging of the ONC Health IT
Certification Program to ensure APIs are implemented in a standardized fashion. We will
continue to work with ONC to explore the adoption of standards and health IT certification
criteria where appropriate to streamline data exchange, support interoperability, and increase
efficiencies associated with the policies in this final rule, as well as to align and mutually
reinforce all of our respective policies.
m. Interaction with Trusted Exchange Framework and Common Agreement
Comment: Multiple commenters suggested that promoting payer to provider information
exchange through the TEFCA may be a better path to achieve improved data exchange,
including that of large-scale data sets, between payers and providers,rather than a requirement to
implement FHIR APIs. A commenter recommended that CMS should collaborate with ONC and
the Recognized Coordinating Entity (RCE)57 to determine an approach for payers to fulfill the
payer to provider exchange requirement by joining the TEFCA network once responses are
required for requests made as payment and operations exchange purposes, as described in the
Qualified Health Information Network (QHIN)) Technical Framework (QTF).58
Response: We will continue to work closely with our ONC colleagues on our policies as
they relate to TEFCA, including how it can support the exchange of large-scale datasets. As we
wrote in the proposed rule (87 FR 76328), we agree that connections between QHINs can
57TheSequoiaProject(2023).WhatistheRCE?Retrievedfromhttps://rce.sequoiaproject.org/rce/.
58TheSequoiaProject(2022).TrustedExchangeFrameworkandCommonAgreementQHINTechnicalFramework
(QTF).Retrievedfromhttps://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf. support exchange of patient information between payers and providers and could eventually
provide the similar functionality to the Provider Access API. As requirements for using FHIR are
incorporated into the QTF in the future,59 Participants and Subparticipants60 will be positioned to
not only exchange the same data using the same standards that we are requiring in this final rule,
but to do so under the TEFCA framework. Participants under TEFCA may include those, such as
payers, who have entered into a contract to participate in a QHIN. As we expect payer
participation in TEFCA to become more widespread in the future, we will continue to explore
how we can align policies that require API development or enhancement for payers with TEFCA
to ensure Participants and Subparticipants can utilize this network infrastructure to meet these
API requirements.
We remind commenters that though we are finalizing our proposals for APIs to use and
comply with certain standards and technical specifications, this would not preclude payers from
also leveraging QHIN-to-QHIN exchange or HIEs/HINs to exchange patient data.
Comment: A commenter recommended that CMS establish a consistent set of technical
standards between TEFCA and the proposed APIs that are required so that the industry does not
have to implement different standards depending upon the exchange partner or mechanism for
exchange.
Response: ONC and CMS will continue to work closely together to identify ways that
TEFCA can support the payer API requirements. We further agree that use of TEFCA could help
to reduce burden associated with implementation variation that may arise in developing direct
connections with exchange partners. ONC and the RCE are implementing the FHIR Roadmap
for TEFCA Exchange to align and accelerate adoption of FHIR across the industry.61
59TheSequoiaProject(2023).FHIRRoadmapforTEFCAExchangeVersion2.0.Retrievedfrom
https://rce.sequoiaproject.org/wp-content/uploads/2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf.
60TheSequoiaProject(2023).HowCanIParticipateinTEFCA?Retrievedfrom
https://rce.sequoiaproject.org/participate/.
61TheSequoiaProject(2023).FHIRRoadmapforTEFCAExchangeVersion2.0.Retrievedfrom
https://rce.sequoiaproject.org/wp-content/uploads/2023/12/FHIR-Roadmap-for-TEFCA-Exchange.pdf. n. Federal Matching Funds for State Medicaid and CHIP FFS Expenditures on Implementation
of the Provider Access API
In section II.E. of this final rule, we discuss Federal matching funds for certain state
Medicaid and CHIP FFS programs expenditures related to implementation of the Provider
Access API (this was also addressed in the proposed rule at 87 FR 76264).
o. Medicaid Expansion CHIP
In section II.E. of this final rule, we discuss implementation for states with Medicaid
Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76264).
3. Additional Requirements for the Provider Access API
Additional 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 purposes of our policies, we use the term attribution as shorthand
for the determination that a treatment relationship exists between the patient and provider. For
the Provider Access API, we proposed to require impacted payers to maintain an attribution
process to associate patients with their in-network or enrolled (as applicable) providers to ensure
that a payer only sends a patients data to providers who have a treatment relationship with that
patient.
We are aware that the process of attribution can relate to many payer functions, including
managing contracts, payments, financial reconciliation, reporting, and continuity of care. We
thus encourage payers to use processes that they already have in place to attribute patients to
their providers for these other purposes.
We expect that many payers will rely primarily on claims data to establish a treatment
relationship between a patient and a provider. Other payers might use existing patient rosters for individual providers or organizations, such as ACOs. For new patients, we explained that payers
could accept proof of an upcoming appointment to verify the provider-patient treatment
relationship. We know that many providers already verify coverage with a payer before a new
patients first appointment. A payer could establish a process that aligns with that query, using
some evidence of a scheduled appointment. Once confirmed, the provider would be able to
request the patients data in preparation for the visit. Payers may have other existing processes
that they prefer to use. We did not propose a prescriptive attribution process in order to provide
payers the flexibility to use systems and processes they already have in place, where appropriate,
or to develop new policies and procedures to ensure that access to a patients data through the
Provider Access API is limited to providers who have a treatment relationship with the patient.
CMS has implemented an attribution process in the DPC pilot for Medicare beneficiaries
(the Medicare FFS version of the Provider Access API), which can serve as an example for
impacted payers. The pilot requires HIPAA covered entities or their business associates to agree
to certain terms of service before data can be sent to them.62 The current Medicare FFS terms of
service require each organization to maintain a list of patients that represents the patient
population currently being treated at their facilities.63 CMS requires providers to attest that they
have a treatment-related purpose to add 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 methods 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 requirement.
In addition, HL7 has developed a HL7 Da Vinci Risk-Based Contracts Member
Attribution (ATR) List IG. The ATR List IG does not specify how the payer and provider
62CentersforMedicareandMedicaidServices(n.d.).TermsofService.DataatthePointofCare.Retrievedfrom
https://dpc.cms.gov/terms-of-service.html.
63CentersforMedicareandMedicaidServices(n.d.).Attestation&Attribution.DataatthePointofCare.Retrieved
fromhttps://dpc.cms.gov/docsV1.html#attestation--attribution. identify these patients, but defines the protocols, data structure, and value sets to be used for
exchanging a Member Attribution List. The Member Attribution List 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. The DPC pilot program has
been working with the Da Vinci Member Attribution List workgrouptowards compatibility with
that IG.64 The ATR List IG is also informing updates to the PDex IG. We encourage payers to
review the information from the workgroup. We further note that the HL7 Argonaut Project, a
private sector initiative that advances using FHIR, has developed an IG specifying how to use the
Scheduling and Appointment FHIR Resources to communicate this information.65
We solicited comments on our proposal to require payers to maintain an attribution
process to associate patients with their enrolled or in-network (as applicable) providers to ensure
that a payer only sends a patients data to providers who have a treatment relationship with that
patient. We requested comments on other examples of how patients can be attributed to the
enrolled or in-network providers from whom they are receiving care, especially for a new
patient-provider treatment relationship. We also requested comments on whether and how payers
could attribute the patient to the provider at the time a provider makes a request for patient data
through the Patient Access API.
As discussed in more detail elsewhere, we are finalizing our proposal without changes.
i. General Comments on Attribution
Comment: Multiple commenters expressed their support for CMSs proposed
requirement that impacted payers maintain a process to verify a provider-patient relationship.
Multiple commenters also underscored the importance of developing a patient attribution system
64CentersforMedicareandMedicaidServices(n.d.).Groups.DataatthePointofCare.Retrievedfrom
https://dpc.cms.gov/docsV2.html#groups.
65HealthLevelSevenInternational(2022).ArgonautSchedulingIG(Release1.0.0).Retrievedfrom
https://fhir.org/guides/argonaut/scheduling/. to ensure those data are shared appropriately. A commenter further stated that payers should only
develop an attribution process for in-network providers.
Response: We thank commenters for their support for this proposal. We emphasize that
the requirement we are finalizing  that impacted payers be required to make the specified
patient data available to providers  only applies to those that are in-network or enrolled with the
payer. However, we encourage payers to consider making the Provider Access API available to
out-of-network providers. This rule requires that impacted payers maintain an attribution process
to associate patients with their providers. Thus, if payers choose to make the API available to
out-of-network providers, they would still need to establish an attribution process to ensure that a
treatment relationship exists before making patient data available.
Comment: A commenter recommended that CMS align patient attribution requirements
and processes across payer types and leverage the CMS Innovation Center to identify where the
process can be streamlined. A commenter also recommended that CMS permit payers to set
reasonable requirements for providers to demonstrate that the provider is treating an individual,
which could reduce the risk of providers making unauthorized inquiries in the system.
Response: We recognize that there are multiple ways for impacted payers to verify a
treatment relationship. Payers may already have a process that they want to use, so requiring a
different process that deviates from an established and effective workflow may add burden. We
encourage payers to work together to establish industry-wide principles and standards for patient
attribution. As previously stated, payers are permitted to set requirements for providers as part of
their processes, such as requiring an attestation of a treatment relationship and/or a need for the
data.We agree with the commenter that such requirements should be reasonable and not overly
burden providers.
Comment: A commenter stated that some specialties are referred patients at a higher rate
and requested that CMS take into account the additional burdens of the attribution process for
providers who may only see a patient once. Another commenter suggested that the final rule should ensure that any attribution process will not negatively impact those patients who have a
high number of providers. A commenter further noted the significant technological challenges of
attribution and expressed concern that patients that most need their data to follow them through
clinicians, systems, and payers are those that are most likely to have data discontinuity due to
clinicians receiving erroneous patient data.
Response: We emphasize that payers should consider all types of patients and providers
when designing their attribution processes to prevent creating disparities. Making the specified
data available via API may be particularly beneficial for patients experiencing data
fragmentation. Establishing and maintaining an attribution process will benefit patients who may
see multiple providers, so that all such a patients providers (assuming they are in-network or
enrolled) can have access to necessary information. We remind readers that we are not being
prescriptive on when attribution needs to take place, as long as it occurs before patient data are
made available through the Provider Access API. We encourage payers to perform the attribution
prior to the first visit and/or in a reasonable amount of time to determine whether there are legal
restrictions on the data that may be shared and so that providers can have the opportunity to
review any relevant data in proximity to the patient encounter.
Comment: A commenter expressed concern regarding the attribution process for
Medicaid patients, noting that developing a proactive process for providers who will see a patient
would be challenging for Medicaid agencies. Another commenter stated that there should be
special consideration for patients with mental health and substance use disorder issues. For
example, proof of upcoming appointments can be an inadequate test of a patient-provider
relationship due to high no-show or cancellation rates. A commenter also stated that verifying
a provider-patient relationship will be difficult to accomplish in a single business day.
Response: We understand the concerns of Medicaid agencies, including challenges in
attributing new patients, and believe that proof of an upcoming appointment could sufficiently
indicate the patient-provider relationship. However, impacted payers have latitude to determine when proof of an upcoming appointment can be used. For example, payers may implement a
policy where providers can only successfully receive requested data if they have an upcoming
appointment with the given patient within a specific number of days. Such a process can also
mitigate potential no show or cancellation situations which one commenter cited. Many
providers confirm appointments in the days prior to their appointment. A patient who confirms
their appointmentin proximity to the visit is less likely to cancel or not show. As stated
previously, impacted payers must send the requested data no later than 1 business day after the
payer receives a request and the following conditions are met: (1) the payer authenticates the
identity of the provider and attributes the patient to that provider; (2) the patient has not opted
out; and (3) disclosure of the requested information is notprohibited by law. Nothing in the rule
requires payers to establish that these conditions are met in one business day; rather, data must
be made available through the Provider Access API no later than one business day after these
conditions are met. We encourage payers to verify these conditions are met in advance as often
as possible. If this is difficult or not possible, such as in the case of new patient visits, we
strongly encourage payers to complete the attribution process in a reasonable amount of time
with minimal involvement from the provider, so as not to increase burden.
ii. Providers Role in Attribution
Comment: A commenter sought clarification from CMS regarding whether the provider
or the payer must maintain records of the attribution. They also asked how to accountfor ACO
or value-based care coverage models that permit patients to choose a provider. Another
commenter agreed, pointing out that most attribution processes in these coverage models are
currently geared toward identifying a singular accountable primary care physician within value-
based arrangements and that often, a patients identification of their doctor may not match
results generated through automated attribution approaches.
Response: This final rule imposes on impacted payers the requirement to maintain a
process to attribute a patient to in-network or enrolled providers. Payers are responsible for maintaining attribution records and ensuring that only in-network or enrolled providers who have
a treatment relationship with the patient (or should they choose, out-of-network or unenrolled
providers to whom the impacted payer has attributed a patient) have access to patient data.
However, the process of attribution inherently requires provider participation in some instances.
For example, when a patient has their first visit with a particular provider, we cannot expect the
payer to have that information without some provider input. In other instances, payers may
involve patients in their attribution processes, especially if they wish to account for providers
who might not be identified via existing automated approaches. Should they do so, any such
involvement should not be onerous for the patient.
Comment: A commenter stated that CMS should allow payers and providers to adopt an
approach that assures payers that any provider request for patient data meets the requirements of
this rule,while also allowing providers to delegate the ability to request information to support
staff. Another commenter sought clarification on whether physicians and their staff would be
expected to operate outside of their normal workflows to demonstrate a care relationship with a
patient. A commenter sought clarification on whether multiple providers could be attributed to
the same patient at a time. A commenter further sought clarification on whether the rendering
provider is the provider who has a treatment relationship with the patient, or if the billing
provider could also be attributed to the patient to request data using the Provider Access API. A
commenter stated that CMS should require payers to make an attribution prior to the first visit.
Response: While we are not being prescriptive in how payers should design their
attribution processes; we caution that payers should not set overly onerous criteria for providers
to prove their treatment relationship with a patient. Both patients and providers will benefit from
the provider having access to the specified information; the attribution process should not
impede this benefit. Furthermore, it is appropriate for providers to be able to delegate
administrative tasks to their staff. Similar to other processes, such as submitting claims, payers should set reasonable requirements that allow staff to provide information or perform tasks on a
providers behalf.
We do not intend to overburden providers or their staff with the attribution process. As
stated, we believe that payers can attribute most patients to providers via claims, which should
not require providers to operate significantly outside their normal workflows to demonstrate a
care relationship with a patient. Furthermore, we acknowledge that patients can (and in many
cases should) be attributed to multiple providers who would be able to request access to the
patients data. This may apply, for example, to a multi-provider practice or an ACO.
Comment: Multiple commenters recommended that CMS reevaluate the attribution
process as outlined in the proposed rule. Multiple commenters also stated that payers have
significantly different attribution processes, and this adds burden to hospitals and SNFs. A
commenter agreed that varying attribution processes across payers would increase administrative
burden for providers and clinics under the proposed rule. A commenter recommended that CMS
permit providers not only to attribute patients through individual requests, but also to be able to
submit information in a bulk format by submitting a list of all a payers enrollees currently in
their care. Another commenter cautioned CMS to not adopt any standard for attribution more
rigorous than the HIPAA Privacy Rule and avoid imposing burdensome requirements.
Response: We emphasize that the requirement to implement an attribution process
applies to impacted payers, not providers. As discussed, a payer may verify the patient treatment
relationship in a variety of ways. While verification may necessitate some action by the
providers, we strongly encourage payers to implement a process that is least burdensome to
providers as possible. When information from providers is required, payers should allow bulk
submission in order to impose the leastpossible burden on providers. Finally, because we did not
propose to adopt any attribution standard or method at all, we are not adopting one that is more
rigorous than what is required under the HIPAA Privacy Rule.
iii. Attribution Process Design and Suggestions Comment: A commenter recommended that CMS establish minimum attribution criteria
and a uniform claims attribution process. Multiple commenters suggested that CMS create
guidance on best practices and specific ways that payers can accurately attribute patients to
specific providers and when a payer can determine that a treatment relationship between a patient
and provider has ended to allow flexibility in the attribution process rather. Multiple commenters
also stated that payers should be able to un-attribute a patient from a provider when a treatment
relationship is inactive to protectpatient data. A commenter stated that it is crucial for CMS to
define the timeline for which the patient attribution roster on both the payer and provider side
must be updated to ensure that it is never shorter than the 30 days mandated by some states. A
commenter also stated that the attribution process will be difficult because it will require two
separate processes, one for new and one for established patients. A commenter further stated that
payers will need to prioritize implementation of the Provider Access API, which will make
developing an attribution process difficult.
Response: In order to permit impacted payers the flexibility to leverage their existing
processes or utilize another method that may be the least burdensome for them, we did not
propose, and are not finalizing, a standardized attribution method. In the DPC pilot, for a
provider to establish a treatment-related purpose for viewing patient data, they must have an
existing treatment relationship, defined as a processed claim with the providers NPI number
for that patient within the past 18 months. The DPC pilot currently does not have the ability for
providers to access data for patients before theirfirst claim. As noted in the proposed rule and
previously mentioned, with each roster addition or renewal, a provider must also attest that there
is an active treatment relationship. We have had significantinterest in our DPC pilot from
providers and provider organizations that participate in the Medicare program and continue to
gather information from interested parties. However, we do not have information beyond what is
currently publicly available to share at this time. This DPC process is just one attribution method and we encourage payers to leverage
their existing processes and develop methods that work best for them and that place the least
amount of burden on providers. Nothing in this final rule would require a specific timeframe
after which a treatment relationship expires. Payers are permitted to establish a period after
which the treatment relationship is considered inactive and a patient could be un-attributed from
a provider. However, many patients may only see a particular provider annually, which would
clearly signify a continuing treatment relationship. We did not propose a requirement for
providers to maintain a patient roster, though it may be required under other Federal or state
regulations or under the providers contract with the payer.
Finally, we understand that some payers may have challenges implementing an
attribution process. One of the reasons we are finalizing a 2027 compliance dates rather than the
proposed 2026 dates (see section I.D. of this final rule) is to give impacted payers additional time
to prepare and test any new or modified process. We intend to provide more information and
education on potential authentication processes prior to the compliance dates.
Comment: Multiple commenters expressed concern with how difficult it is to verify the
patient-provider relationship. A commenter sought clarification on the intended level of
attribution for access to a members data. Another commenter stated their belief that the
proposed attribution requirement, specifically how a treatment relationship is defined, requires
further development and feedback from consumers before implementation so that they can feel
in control of their data. They noted that it is not uncommon to have dozens of providers involved
in a single patients care, nor is it uncommon to have a single interaction with a specialty
provider, or to have a provider consultanother provider on a course of care without the patients
knowledge.
Response: Payers should be able to meet the requirement to have an attribution process
by verifying the patient-provider treatment relationship in a variety of ways, as discussed in this
section. Payers should consider Federal and state law, internal risk policies, and their own processes to determine what level of assurance they require to attribute a patient to a provider for
the Provider Access API. Establishing specific requirements or procedures would add burden to
payers who may establish different, but equally acceptable and effective, processes.
We do not believe it is necessary to define a treatment relationship only for the
purposes of this rule. Payers may have different definitions that may be based on Federal or state
law, internal policies, or provider contracts. Therefore, an additional definition would be
unnecessary, duplicative, and possibly confusing. We do note that if there is doubt about whether
a patient and provider are in a treatment relationship, information from the patient could be one
method of making that determination. However, we emphasize that placing burden on a patient
should only be used a last resort, and only if the benefits of making data available outweigh that
burden.
In some cases, verifying a treatment relationship could result in providers having access
to data about patients they have treated only once and whom they may not treat again. However,
we believe that these providers would have little reason to request this information because they
would be creating unnecessary work for themselves without benefitting patient care. Further,
data from the Provider Access API is only required to be made available to in-network or
enrolled providers. Such providers have already been vetted to participate in the impacted
payers network, so it is unlikely these participating providers would seek out patient data they
do not need for patient care. Finally, some impacted payers might utilize an attestation process,
as suggested by some commenters, where providers must attest that they have a clinical need for
any data they request. A provider requesting data that they do not need could endanger their
payer network or contract status if they fraudulently attest that they are only requesting data for
patient care, should the impacted payer implement such a policy. We thus believe that the
benefits of the Provider Access API outweigh concerns that already-attributed providers will
inappropriately request patient data. We look forward to working with interested parties to
develop best practices for attribution processes. Comment: A commenter stated that a claims-based approach to verifying a treatment
relationship is the most reliable. Conversely, another commenter stated that it was not necessary
to verify a treatment relationship through claims data. They recommended using processes that
show the onset or evidence of treatment like Admission, Discharge, Transfer (ADT) or
Scheduling Information Unsolicited (SIU) transaction. Another commenter stated that a hospital
admission letter should be enough for payers to grant the provider access to the Provider Access
API for the specified patient. A commenter also encouraged payers to consider whether a
providers signed orderfor treatment (on behalf of a patient) is enough to establish this
relationship. A commenter highlighted that the CMS companion guide on the HIPAA-mandated
eligibility transaction supporting Medicare Beneficiary Matching could serve as a model for data
elements that could facilitate attribution.66 These data and the associated eligibility and benefit
request essentially serve as proof of a scheduled appointment. A commenter also recommended
leveraging TEFCA for the attribution process.
Response: Because different approaches and standards for an attribution process continue
to evolve, we did not propose to specify how payers should identify whether a specific patient
can be attributed to the requesting provider. Instead, we encouraged the community to continue
to collaborate on viable approaches. We agree that a claims-based approach is both reliable and
puts little, if any, burden on providers. We expect that payers will also find this to be the simplest
way to verify the treatment relationship because they will have a record of a treatment
relationship as of the most recent date of service on a claim. We also agree that the other
methods suggested could be leveraged by payers to attribute patients to providers for the
Provider Access API.
Comment: Multiple commenters highlighted existing resources or models that CMS
could leverage to establish an attribution process. Another commenter recommended that payers
66CentersforMedicareandMedicaidServices(n.d.).HIPAAEligibilityTransactionSystem(HETS).Retrieved
fromhttps://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp. be allowed to use the existing processes to verify treatment relationships, including the ATR List
IG. Multiple commenters also stated that this IG could be updated to provide the necessary tools
to support implementation of the attribution process and some recommended that CMS adopt
that standard when it is mature enough for large scale implementation.
Multiple commenters expressed support for HIEs and HINs as unique entities that have
the capability to create and manage patient-provider attribution for the Provider Access API. The
commenters provided an example from the Active Care Relationship Service (ACRS), which
enables organizations to send data files that record the relationships between their providers and
patients. Another commenter stated that CMS should work with HIEs to expand capabilities and
create IGs and processes for patient matching, attribution, and opt out to support the Provider
Access API.
Response: We thank readers for their comments and will consider them for future
guidance or rulemaking. As we did not propose a specific attribution method, we encourage
impacted payers to consider these existing resources and models. As members of the HL7 Da
Vinci Project, we will continue to monitor development of the ATR List IG.
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 HIEs.
These HIEs may already have a process to attribute patients to providers. To the extent it would
benefit payers, we encourage them to work with HIEs and HINs to facilitate the Provider Access
API. Nothing in our policies prohibits a payer from using an intermediary to aid with patient
matching, data exchange, or data hygiene. Once again, our goal is to allow payers to develop the
least burdensome approach to attribution, and we encourage collaboration on potential solutions.
Comment: Multiple commenters requested that CMS consider implementing a national,
digital patient identification standard. A commenter recommended that CMS implement a
standardized patient identification framework to ensure that patient data are not inadvertently co-
mingled and does not pose a threat to patient privacy and safety within the Provider Access API. Another commenter stated that an electronic standard should be developed to verify a patient
relationship and appointment status.
Multiple commenters stated the importance of making sure the CEHRT programs require
that record requests can only be made when a treatment relationship is present. A commenter
recommended that CMS and ONC work together to establish standards for ONCs Health IT
Certification Program.
Response: A standard unique health identifier for each individual, which is in accord with
numerous commenters recommendations, would be associated with a HIPAA standard arising at
section 1173(b)(1) of the Act. We will continue to work with our Federal partners as we consider
future guidance or additional rulemaking within the ambit of our authority.
Comment: A commenter recommended that CMS establish a workgroup or advisory
committee to establish an appropriate attribution process. Another commenter recommended that
CMS monitor the state of evolving technology and maintain flexibility in its requirements as
technology continues to develop.
A commenter recommended CMS utilize public feedback to establish minimum criteria
as proof of an authentic patient-provider relationship, because a lack of clear guidance in this
area may cause disputes between payers and providers regarding the appropriate criteria for
establishing proof of a relationship.
Response: We intend to continue our work with industry as they develop attribution
processes that do not overly burden payers, providers, or patients. Additionally, based on
feedback from the public, we believe that the public would benefit from further educational
resources, and we will explore avenues by which we may offer those in the future.
Comment: A commenter asked whether payers can integrate an attestation of a treatment
relationship with a FHIR transaction. Response: While we are not prohibiting use of a FHIR transaction as part of the
attribution process, the IGs we are recommending are primarily meant to help implement the
APIs themselves, not to facilitate related payer processes, like the attribution process.
b. Opt Out
We proposed that all impacted payers would be required to establish and maintain a
process to allow patients or their personal representatives to opt out of (or if they have already
opted out, to opt back in to) having the patients data available for providers via the Provider
Access API. We noted that this differed from our Payer-to-Payer API, which was structured as
an opt in process. Similar to the attribution process, as previously discussed, we did not intend to
be prescriptive regarding how this opt out process should be implemented, but payers would be
required to give all patients or their personal representatives the opportunity to opt out, including
those currently enrolled on the compliance dates, before making patient information available via
the Provider Access API, and at any time while the patient is enrolled with the payer.
We did not propose to require specific methods for patients to opt out, but anticipated that
payers would make that process available by mobile app or on their website. We also anticipated
that mail, fax, or telephonic methods may be necessary alternatives for some patients, which
payers would have to accommodate. We invited comments on whether we should establish more
explicit requirements regarding the patient optout processes.
Our proposal would require impacted payers to allow patients to opt out of the Provider
Access API data exchange for all providers in that payers network. However, we also
encouraged payers to implement processes that allow more granular controls over the opt out
process, so patients can opt out of making data available to individual providers or groups of
providers. We did not propose to require those more granular controls, as we were concerned
about the potential administrative and technical burden this would place on some payers.
However, we requested 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 appreciate commenters feedback to our requests, and understand concerns about the
potential for administrative burden associated with providing patients with more granular
controls over data sharing, as well as which specific providers can receive their data. We used
the term granular broadly because we wanted to know which data elements commenters
thought were most important to be able to segment out. We are committed to minimizing the
burden on patients and providers as much as possible and continue to weigh the benefits of
providing patients with more control over their data against the potential administrative burden
on impacted payers. We appreciate the suggestions we received for how to implement a more
granular opt out approach and will consider these suggestions for future rulemaking.
We proposed an opt out approach because, as we discussed in the proposed rule,opt in
models of data sharing have been shown to inhibit the utilization and usefulness of data sharing
efforts between patients and health care providers. We acknowledged that there are positives and
negatives to both opt in and opt out policies, and that some patients may prefer to control or
direct their health information via an opt in process,which requires 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 action by the patient. We stated our belief that opt out 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 to both opt in and opt out
policies, especially as they relate to making data available to providers. We wrote that a policy
defaulting to sharing data with providers, unless a patient opts out, appropriately balances the
benefits of data sharing with the right of patients to control their health information. As we also detailed in the proposed rule, payers would be responsible forproviding patient resources to
ensure that patients understand the implications of opting out. We noted that, should patients not
opt out of data sharing, then the data that would be made available via the Provider Access API
would be available to in-network providers whose identity has been authenticated and to whom
the patients have been attributed, meaning that the payer has verified a treatment relationship
between the provider and the patient. However, we stated that our proposals, taken together, gave
patients ample opportunities to change their data sharing permission as they see fit.
As we explained in detail in our proposed rule (87 FR 76260), opt in models can create
greater administrative burden for smaller health care organizations, depending on where the
responsibility for obtaining and updating the patients data sharing permission is held. We also
pointed to the fact that a larger health care organization that employed an opt in model, the
Veterans Health Administration within the VA, saw the vast majority of provider requests for
patient information rejected for lack of patient permission.
We additionally stated our belief that an opt out model could address equity issues by
ensuring that patients from lower socioeconomic and minority groups, who are more likely to
have limited health literacy, can benefit from the improved care that the Provider Access API can
facilitate. We believe that data sharing as the default option for all patients enhances both
personal and organizational health literacy, as these terms are defined by the Healthy People
2030 report,67 while protecting patients choice to limit data sharing.
The ability for patients to opt out was specific to the data we proposed requiring payers to
share via the Provider Access API. As discussed previously, nothing in the proposed rule would
alter any other requirements under applicable privacy and security laws and regulations. If there
is other authority to share patient information with respect to which a patient may not opt out,
such as disclosures required by law, nothing in this proposal would change the payers obligation
67HealthLiteracyinHealthyPeople2030(2020).HistoryofHealthLiteracyDefinitions.Retrievedfrom
https://health.gov/healthypeople/priority-areas/health-literacy-healthy-people-2030/history-health-literacy-
definitions. to disclose that information. However, we encouraged payers and providers to use the proposed
Provider Access API as a technical solution to transmit data between payers and providers
beyond the scope of these policies, provided such disclosure is consistent with all other
applicable requirements, such as the requirements set out in the HIPAA Privacy Rule and the
HIPAA Security Rule.
We value the importance of safeguarding the quality and integrity of patient health
information. We acknowledged that there may be potential program integrity risks associated
with sharing patient data under both an opt in and opt out models. We expect that if payers
identify any vulnerabilities, they will work to make changes to their operations to address risks
that could lead to potential fraud and to limit the impact on patient information.
We requested comments on our proposal for a patientopt out framework for the Provider
Access API. As discussed in more detail elsewhere, we are finalizing this proposal without
changes.
i. General Comments on Opt Out
Comment: Multiple commenters expressed support for the proposed policy to require an
opt out framework for the Provider Access API. Commenters provided various rationales for
their support, including that the opt out framework would enable patients to protect and control
their health information while still making patient data available to providers, encourage
increased data transmission, and allow patients to terminate a providers access to their data
when the patient no longer has a treatment relationship with the provider.
Multiple commenters specifically expressed their support for an opt out approach instead
of an opt in approach. These commenters noted that it is less burdensome for payers and that an
opt in approach would require patients to have a higher level of education or better technology
and health literacy to utilize than an opt out process, which may result in fewer patients having
their data exchanged via the Provider Access API under an opt in approach. Response: We appreciate the comments we received in supportof our proposal to allow
patients or their personal representatives to opt out of the Provider Access API if they do not
wish for their data to be made available via the API requirement. We agree with the commenters
that an opt out approach will enable patients or their personal representatives to better protect
and control their health information while still making patient data available to providers. We
remind commenters that the opt out would notnecessarily allow patients or their personal
representatives to terminate a providers access to their data when the patient no longer has a
treatment relationship with the provider, because we did not propose to require a granular opt out
policy (though some payers might choose to implement such a policy). However, we did note in
section II.B.3.a. of this final rule that payers have latitude to determine when a patient-provider
treatment relationship ends via their attribution process. Thus, regardless of the opt out
granularity, payers should also use their attribution process to determine whether and when an
individual provider should have access to a patients data via the Provider Access API.
Comment: Other commenters voiced their concerns with an opt out approach but did not
specifically recommend that CMS take a different approach. Multiple commenters noted that
offering patients an opportunity to opt out would limit information sharing and that information
sharing is important to facilitate the prior authorization process. Multiple commenters also stated
their belief that an opt out approach would reduce, or even remove patient control over their
health information. Those commenters stated that because CMS expects most patients not to opt
out, the confidentiality of this patient data will effectively not be the default.
Response: For reasons we discussed in both the proposed rule and previously, the opt out
approach appropriately balances the benefits of data sharing with the ability of patients to control
their health information. All patients will be given the opportunity to opt out of our Provider
Access API policy. We agree that this information sharing is important to improve the efficiency
of the priorauthorization process and to ensure that patients have timely access to the care they
need. While patients may opt out of data flowing from their payer to their provider via the Provider Access API, they cannot opt out of the prior authorization process established by their
payer or the communications between their provider and payer that enable that process.
Comment: Multiple commenters recommended that CMS adopt an opt in approach
instead of an opt out approach for the Provider Access API. Commenters provided various
rationales for recommending an opt in approach, including that an opt in would give patients
more control over their data and is more understandable than an opt out process. A commenter
explained that while they support an opt in approach, they do not agree that it would benefit
disadvantaged people (such as people with low health literacy or limited English proficiency)
because patients may not understand what it means to give permission for data sharing. Multiple
commenters also supported an opt in approach due to patient privacy concerns with opt out.
Specifically, a commenter with concerns about sharing patients mental health and substance use
information recommended that CMS adopt an opt in process, including a requirement for
patients to provide written authorization before such information is accessible through the
Provider Access API. The commenter explained that there are laws in place requiring a written
authorization from a patient to disclose mental health and substance use information. Another
commenter also recommended that CMS align requirements for the Provider Access API opt out
approach with consent requirements under 42 CFR part 2. A commenter further stated their
belief that most patients would choose to opt into the Provider Access API if they are adequately
informed of their rights and the potentialfor API data exchange.
Response: We refer readers to our proposed rule fora full discussion of why we proposed
an opt out patient permission framework (87 FR 76259). As discussed elsewhere, we are
finalizing a requirement that impacted payers must provide patients with plain language
information about the Provider Access API, including how to opt out of data sharing, in order to
help maximize patient control. This requirement should ensure that patients, including those with
low health literacy or limited English proficiency, are aware of their rights and have the
opportunity to make an informed decision about whether or not to allow payers to share their data with their providers through the Provider Access API. We further remind readers that all
data sentand received via the Provider Access API must still be handled consistent with all other
applicable laws and regulations regarding disclosure of these data.For instance, rules of
confidentiality for patient records associated with mental health or substance use disorder, such
as 42 CFR part 2, which may require patient consent to share with providers, will still apply.
ii. Interaction with HIPAA
Comment: Multiple commenters stated that a process requiring patient permission for
data sharing via the Provider Access API is not necessary because the HIPAA Privacy Rule
permits PHI disclosure without patient permission under certain circumstances. Specifically, they
reasoned that patient permission is not necessary if the PHI disclosed via the Provider Access
API falls within the scope of HIPAA treatment, payment, and operations (TPO) disclosures, and
recommended that CMS limit the data shared via the Provider Access API to the scope of
permitted TPO disclosures. In support of their recommendation, these commenters noted that
requiring an opt out process could be confusing and cumbersome to patients, negatively affect
patient care, and would conflict with Federal and state laws (including the HIPAA statute). In a
similar vein, commenters stated that CMS should rely on the HIPAA Privacy Rule requirements
instead of requiring an opt out process, and a commenter suggested that CMS require impacted
payers to include the Provider Access API exchange in their HIPAA Notices of Privacy Practices
(NPP). Another commenter recommended that CMS make it clear that payers may still share
certain patient health information with providers if it falls under the scope of a TPO disclosure,
even when a patient elects to opt out of data sharing. Multiple commenters recommended that
CMS provide additional guidance as to whether the Provider Access API is to be used for
purposes beyond treatment, and indicated that providers should be able to access payer data for
other purposes permitted under the HIPAA Privacy Rule, such as payment.
Response: We understand that there are those who believe that an opt out patient
permission process is not necessary, given existing HIPAA Privacy Rule provisions that permit PHI disclosure without an individuals authorization under certain circumstances. However, we
emphasize that by virtue of this final rule, impacted payers would be required to disclose any
PHI specified within the content standards for the Provider Access API, if the applicable
requirements of this rule were met. That disclosure would be permitted under the HIPAA
Privacy Rule as uses or disclosures that are required by law,68 rather than as a permitted TPO
disclosure. Required by law disclosures are limited to the relevant requirements of such law, not
to the HIPAA minimum necessary standard,69 thereby ensuring that all content required by our
Provider Access API policy may be disclosed. Because our policies would potentially give
providers access to more than what would have been considered to be the minimum necessary
PHI under the HIPAA Privacy Rule for certain purposes (for example, administrative data in the
USCDI that would not be used for treatment purposes), we are requiring impacted payers to give
patients or their personal representatives an opportunity to opt out so that they have some control
over whether or not to share this additional data with their provider(s). We believe that patients
should control their own data to the extent possible and with an opt out approach to data sharing,
we are giving patients this opportunity. Where the requirements of this rule change how covered
entities or their business associates may use or disclose PHI, covered entities should consider
their obligations under the HIPAA Privacy Rule.
We emphasize that the opt out process described here only applies to the Provider Access
API policies in this final rule. That is, the requirement for impacted payers to share individual
claims and encounter data, all data classes and data elements included in a content standard at 45
CFR 170.213 (USCDI), and certain information about prior authorizations maintained by the
payer with a date of service on or after January 1, 2016, with in-network providers who have a
treatment relationship with the patient. If a patient or their personal representative opts out under
our policy, then the impacted payer should not share these data with a provider who requests it
68See45CFR164.512(a).
69See45CFR164.502(b)(2)(v). under this policy. However, there may be other permissible bases for payers and providers to
share data, such as under the HIPAA Privacy Rules permitted uses and disclosures to carry out
TPO. Patients or their personal representatives do not have the ability to opt out of a payer or
provider using the API itself as a mechanism for sharing data under such bases for disclosure.
We also note that the data that may be shared under other permissible bases, such as the
TPO exception, may overlap with the data required to be shared by our Provider Access API
policy. For instance, a payer may be permitted to disclose clinical data included in a content
standard at 45 CFR 170.213 with a health care provider for treatment purposes under 45 CFR
164.506(c)(2). If that disclosure is permissible, a patient opting out of the Provider Access API
policy in this final rule would not prohibit a payer from using the Provider Access API to make
that disclosure. In addition, there may be permissible bases for sharing data outside the scope of
our Provider Access API policy. As an example, payers may be permitted to disclose clinical
data that is not included in a content standard at 45 CFR 170.213, such as information related to
SDOH, under the TPO exception. Similarly, a patient or personal representative opting out of the
Provider Access API policy in this final rule would not prohibit a payer from using the Provider
Access API as the mechanism to make that permissible disclosure.
Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an
individual to use or disclose PHI to carry out TPO. Per 45 CFR 164.522(a), individuals also have
the right to request restrictions on how a covered entity will use and disclose PHI about them for
TPO. Except in limited circumstances, a covered entity is not required to agree to an individuals
request for a restriction. Where a covered entity agrees to a restriction, it is bound to it unless the
restriction is subsequently terminated. We emphasize that the opt out process described in this
final rule is specific to the Provider Access API policy and therefore is not, on its own, a consent
mechanism per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a). Payers should make these nuances clear to patients in their required educational
resources, so that patients understand that their PHI may still be shared in some instances, even if
they or their personal representative opts out of the Provider Access API policy.
iii. Interaction with Health Information Exchanges
Comment: Multiple commenters noted that HIEs would be great partners for payers when
implementing the Provider Access API, with one noting that they could be used to reduce the
number of endpoints providers would need to query for patient information. Commenters
suggested that because many providers already have connections to HIEs set up within their
EHRs, HIEs could act as a conduit for the information impacted payers are required to make
available. Furthermore, commenters stated that HIEs could make available patient clinical data
beyond what is maintained by the payer.
Response: We agree that HIEs could be helpful partners for payers when implementing
the Provider Access API and nothing in this rule would prohibit an impacted payer from
partnering with an HIE to meet its requirements. As a commenter noted, HIEs have extensive
experience and expertise with patient matching and attribution, as well as with various consent
models. We additionally agree that provider participation in an HIE can reduce the number of
endpoints they would need to query for care coordination and treatment. We further encourage
payers to look to HIEs or HINs as models for implementing a legal framework for data
exchange.
Comment: Multiple other commenters recommended that CMS both explain and
reexamine its interpretation of 42 CFR 431.306(d) and 457.1110(b) to prohibit Medicaid and
CHIP programs from releasing beneficiary information to outside sources without first obtaining
permission from the beneficiary or their personal representative. The commenters stated that
CMSs current interpretation would effectively prohibit Medicaid agencies from participating in
HIEs for Provider Access API and TPO purposes. The commenters stated that CMS should
consider expanding this to include out-of-network providers. Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid
or CHIP agencies from contracting with an entity that offers the technology to allow for digital
access and transfer of a patient's medical records, often referred to as an HIE. Section 1902(a)(7)
of the Act, which our regulations at 42 CFR part 431, subpart F, implement, requires that a
states Medicaid plan provide safeguards which restrict the use or disclosure of information
concerning Medicaid applicants and beneficiaries to purposes directly connected with
administration of the state plan. Our regulations at 42 CFR part 431, subpart F, setforth
requirements for states to safeguard Medicaid applicants and beneficiaries information in
accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the
information, what types of information must be safeguarded, and when and how to release
otherwise safeguarded information. The same requirements also apply to separate CHIP
programs through a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data
to an HIE contracted to develop and maintain the required Provider Access API would be
directly related to the administration of the state plan, because sharing beneficiary data through
the Provider Access API supports the provision of services for beneficiaries, as described at 42
CFR 431.302(c). Access to beneficiary data could help a provider better manage a beneficiarys
total care because the data would provide a more in-depth medical history, enable more informed
decision making, and potentially prevent orders for, or the provision of, duplicative services.
Further, under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations
to enhance the agencys capability for effective administration of the program.
The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from
an individual Medicaid or CHIP applicant or beneficiary, or their personal representative, before
responding to a request for information from an outside source, or disclosing that applicants or
beneficiarys data safeguarded under 42 CFR 431.305. There is no requirement for a state
Medicaid or CHIP agency to obtain permission from an individual or family member prior to
providing information about a Medicaid or CHIP beneficiary to an enrolled Medicaid or CHIP provider because enrolled providers are not outside sources as described at 42 CFR 431.306(d).
Enrolled Medicaid and CHIP providers are part of a states Medicaid and/or CHIP FFS programs
because they are contracted to support the agencys administration of its Medicaid or CHIP state
plan. Specifically, an enrolled Medicaid or CHIP provider has a provider agreement with the
Medicaid or CHIP agency to provide Medicaid or CHIP benefits and services under the state
plan. Thus, the state Medicaid agency could share Medicaid or CHIP beneficiary information
with enrolled providers for purposes directly connected to administration of the state plan,
without prior permission from the Medicaid or CHIP beneficiary required by 42 CFR 431.306(d)
and 457.1110(b) respectively.
Similarly, state Medicaid and CHIP agencies may share Medicaid and CHIP beneficiary
information with entities with which the state Medicaid or CHIP agency has contracted to
support the agencys administration of its Medicaid or CHIP state plan. Such contractors would
not be considered outside sources because they are contracted to carry out functions directly
related to administration of the state Medicaid or CHIP plan, such as case management and long-
term services and supports for Medicaid or CHIP beneficiaries. Thus, if a state Medicaid or
CHIP agency contracts with an HIE to carry out administrative functions of the states Medicaid
or CHIP program, such as developing and maintaining the required Provider Access API, the
HIE would not be considered an outside source and the state Medicaid or CHIP agency could
share Medicaid or CHIP beneficiary information with the HIE for the purposes directly
connected to administration of the state plan, without prior permission from the Medicaid or
CHIP beneficiary required by 42 CFR 431.306(d) and 457.1110(b) respectively.
In addition, to receive beneficiaries information from the Medicaid or CHIP agency,
Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality
comparable to those of the state Medicaid or CHIP agency in accordance with 42 CFR
431.306(b) and 457.1110(b) respectively. Furthermore, the Medicaid regulation at 42 CFR
434.6(a)(8) requires that each of the state Medicaid agencys contracts must provide that the contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F.
Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other
entity, the contractor would be required to meet the same standards of confidentiality as the state
Medicaid or CHIP agency (as set forth in section 1902(a)(7) of the Act and our implementing
regulations at 42 CFR part 431, subpart F), including but not limited to--
 Providing safeguards that restrict the use or disclosure of information concerning
applicants and beneficiaries to purposes directly connected with the administration of the plan in
accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
 Not disclosing data to an outside source, such as providers that are not enrolled with
the state Medicaid or CHIP agency, and that might be participating in an HIE, without prior
permission from the individual in accordance with 42 CFR 431.306(d).
iv. Opt Out Process Design
Comment: Commenters provided thoughts about the implementation of the proposed opt
out requirement. Multiple commenters suggested that CMS require a standardized opt out
process to improve the patient and provider experience. A commenter expressed concern that the
proposed implementation flexibility could be difficult for patients to navigate, while another
commenter requested clarification on what opting out and opting back in means.
Response: We agree that it is important to make it easy for patients or their personal
representatives to opt out of data sharing. However, it is also important to give payers flexibility
in how they implement the opt out process required by this rule. We recognize that payers
approaches may vary depending on their systems, capabilities, and specific enrollee population.
Requiring a specific process could impose unnecessary burden on payers. We remind readers
that regardless of what process payers choose, a patient or their personal representative must
have the ability to change their data sharing permission at any time. For example, if a patientor
their personal representative previously opted out of having their data shared under the Provider
Access API policy, they should be able to reverse this decision, effectively choosing to opt back into having their data shared under the Provider Access API policy. We additionally note that
each of our policies in this final rule is targeted toward individual patients, not any family
members that may be covered through the same benefits. In some cases, applicable law may
allow one individual (such as a parent or guardian) to act as a personal representative for another
individual covered under the same benefits (such as a minor) and could therefore opt out of data
sharing under the Provider Access API forthat person. No data should be shared about any
patient that has opted out (or whose personal representative has opted out), regardless of whether
another patient covered under the same benefits has chosen to not opt out. We will continue to
monitor implementation of the Provider Access API opt outrequirement to ensure payers opt
out processes for the Provider Access API are easy and intuitive for patients or their personal
representatives to use.
Comment: Commenters recommended that CMS include several additional, explicit
requirements related to the Provider Access API opt out process. Multiple commenters also
recommended requiring or permitting payers to incorporate the opt out process into their existing
platforms and communications, including patient portals, payers websites, and within payers
regular communications with patients. A commenter encouraged CMS to collaborate with
interested parties to develop a single platform for patients to give permission for data sharing.
Response: While we are not requiring impacted payers to incorporate their optout
processes into their existing platforms and communications, we generally expect that that would
result in the least amount of burden on payers and patients. There are solutions available that
could be leveraged to manage permissions across payers, such as HIEs. We encourage impacted
payers to investigate a variety of options to determine the solution that is best for them and their
patients.
Comment: Multiple commenters made recommendations related to the accessibility of the
opt out process. They recommended that CMS require impacted payers to provide options to
patients for opting out of data sharing that are accessible to patients with varied technological literacy (that is, via mail, fax, and phone). A commenter recommended that opt out information
be available for the Provider Access API in multiple languages to reduce disparities and barriers
to patients understanding of the opt out process. Another commenter recommended that CMS
establish clear expectations for how payers should accommodate patients who may have
difficulty accessing the opt out process or that CMS should track the extent to which patients
encounter difficulties with opting out of data sharing. A commenter further recommended that
payers collect patients opt out elections at the point of treatment, so that it is clear which
provider(s) have access to the patients data via the Provider Access API policy.
Response: We agree with commenters that payers should make efforts to ensure their
patients or their personal representatives have the opportunity to opt out of data sharing under the
Provider Access API policy and should be accommodated accordingly. These accommodations
certainly include accounting for varied technology literacy and language barriers (see section
II.B.3.c.ii. of this final rule for a discussion on plain language and existing requirements to make
information accessible in other languages or formats). However, we do not want to be overly
prescriptive to payers, as we believe they would know best how to accommodate their particular
patient population. We disagree that payers should collect patient opt out elections at the point of
treatment because we intend for these data to be available to the provider before patient
appointments, and such practices are also outside the scope of a providers role. We therefore
intend to monitor patient experience and payer compliance with the opt out process and will
consider our observations through this monitoring for future rulemaking.
Comment: Multiple commenters recommended implementing processes for payers to
notify providers of patients election to opt out of the Provider Access API data exchange. A
commenter identified some potential implementation challenges for providers, including that
tracking patient permission would be challenging and that the opt out approach could create
segmented data captures and multiple workflows. Another commenter flagged that CMS should
not rely on physicians to educate patients on the intricacies of APIs, instead encouraging CMS to provide standardized language and guidelines to payers around how the process to opt out will be
communicated to patients and the process for collecting and communicating opt outs to
physicians.
Response: While we are not requiring impacted payers to notify providers of their
patients election to opt out of the Provider Access API data exchange, we agree that notification
can increase the utility of the Provider Access API for providers. We remind readers that we are
not requiring providers to track patient data sharing permission, educate patients about their data
sharing options, or utilize the Provider Access API at all. However, we believe that giving
providers access to more patient data will benefit the care that they provide, and we encourage
them to adjust their workflows and work with their EHR developers to take advantage of the data
availability through this new mechanism.
Comment: A commenter noted that it will take time for payers to process opt out requests
from patients or their personal representatives who choose to opt out of having their data shared
after enrollment. Another commenter suggested that patients should be able to record their
permission through multiple channels (for example, OAuth 2.0, portal access, and the FHIR
consent profile). A commenter also stated that payers may have to design related processes to
allow patients to opt in to sharing of sensitive information that adhere to state or local privacy
laws. A commenter further sought guidance on whether specific consent language would be
required for patients or their personal representatives to opt in and whether an opt in election
may be included in the HIPAA authorization form or other enrollmentmaterials.
Response: Payers will have flexibility in how they process patient data sharing
permission and the channels that patients may use to make their election. We caution, however,
that any such opt out channels should be both optimally accessible to patients or their personal
representatives and not onerous for them to navigate. Part of managing an opt out process will
include cognizance of other laws that may restrict data sharing, such as state privacy laws. In
fact, if other applicable law requires an opt in permission for data sharing, payers may integrate both the Provider Access API opt out and other permission gathering processes to simplify
patients ability to control their data, to the extent permitted by law. Finally, regarding the
commenter seeking specific consent language for opt in and clarification related to leveraging
the HIPAA authorization form for this purpose, we emphasize that this final rule finalizes an opt
out framework for the Provider Access API, not an opt in. We further note that compound
HIPAA authorizations are generally prohibited, per 45 CFR 164.508(b)(3).
v. Opt Out Timeframes
Comment: Multiple commenters stated that patients or their personal representatives
should be allowed to opt out at any time. Other commenters supported payers providing an
option to opt out at a certain time, such as at the time of enrollment. A commenter recommended
that CMS allow payers 30 days to process a patients request to opt out and stop sharing the
patients data via the Provider Access API.
Response: We agree that patients or their personal representatives should be able to opt
out of data sharing under the Provider Access API policy at any time and we are requiring
impacted payers to give their patients the opportunity to do so. As discussed in section II.B.3.c.
of this final rule, no later than one week after the start of coverage and annually, patients will
need to be given information about their opt out rights and instructions both for opting out. We
remind readers that start of coverage is defined differently, as applicable, for each type of
impacted payer. We refer readers to section II.C.3.c.i. of this final rule for discussion of these
differences. We do not agree that the opt out option should be time-limited, as that reduces
patient control over their health data.
c. Patient Educational Resources Regarding the Provider Access API
To help patients understand the implications of the opt out provision for the Provider
Access API, we proposed to require impacted payers to disseminate certain educational
resources to their patients. We proposed that those resources would include information about
the benefits to the patient of API data exchange, their opt out rights, and instructions both for opting out of the data exchange and for opting in after previously opting out. We proposed that
payers would have to provide this information, in non-technical, simple, and easy-to-understand
language, before the first date on which the payer makes patient information available through
the Provider Access API, at the time of enrollment and annually thereafter. We also proposed
that payers would be required to make this information available at all times, in an easily
accessible location on payers public websites. We did not propose to require this information to
also be distributed to patients personal representatives. However, we highly encourage impacted
payers to do so, especially if distributing other materials to personal representatives is typical.
We also did not propose specific text or format for this information,but requested suggestions
and comments on whether required content or format would be beneficial or burdensome. In
particular, we sought comments on language explaining how patient data that is shared through
the Provider Access API could be used. We anticipated that payers would want to include this
information in their regular communications, such as annual enrollment information, privacy
notices, member handbooks, or newsletters. However, we requested comment on the most
appropriate and effective communication channel(s) for conveying this information to patients.
We also requested comment on whether a requirement to provide this information at the time of
enrollment and annually is appropriate, or whether we should require payers to share this
information more frequently.
We believe it is important to honor patient privacy preferences. Offering patients
educational resources about their right to opt out of the Provider Access API data sharing is thus
fundamental to empowering patients with respect to their data.
As discussed in more detail, we are finalizing a modification to these proposals, that
impacted payers must provide this information to patients no later than one week after the start of
coverage. Start of coverage is defined differently, as applicable, for each type of impacted
payer and we refer readers to section II.C.3.c.i. of this finalrule for discussion of these
differences. i. Dissemination
Comment: Multiple commenters supported the proposed requirement for payers to
disseminate patient educational resources and made recommendations for communicating with,
or sending information to patients. These recommendations include disseminating educational
resources through existing patient portals, letters, text messages, and information posted on
websites, in handbooks, and by mail.
Conversely, a commenter recommended that CMS not require physical materials be sent
annually to patients. The commenter recommended that payers should only send hard copies to
patients who have opted out of data sharing. However, another commenter stated that separate
patient resources for the Provider Access API are not necessary at all. A commenter additionally
stated that many plan renewals do not actually generate patient-visible paperwork, forms, or
formal documents of any sort and provided examples for how frequently sharing patient
resources currently occurs. A commenter further stated that payers should have the flexibility to
communicate with their members in a manner consistent with a set format and content for
consistency and clarity.
Response: We emphasize that impacted payers can indeed use their existing processes for
producing patient-facing resources and will be permitted to send their patient education resources
through the communication channels they think are most effective for reaching their patients,
including e-mails, messages through a payer portal, or physical mail. It is not our intention to
overburden payers, and thus we do want to be overly prescriptive in a way that thatwill unduly
disrupt how they currently communicate with their patients. We disagree that only patients who
have opted out of data sharing should receive these resources. Under our policies, patients may
choose to change their data sharing permission at any time and we thus believe that they should
remain maximally informed of their choices.
We are also finalizing a modification to the proposed rule regarding payer deadlines, to
give payers more clarity and an appropriate amount of time to meet these requirements, as well as to align with policies we are finalizing for the Payer-to-Payer API (see section II.C.3.c.i. of
this finalrule). Specifically, payers will be required to provide patients, no later than one week
after the start of coverage, information about the benefits of API data exchange with their
providers, their opt out rights, and instructions for both for opting out of data exchange and for
opting in after previously opting out. This timeframe is intended to provide a reasonable amount
of time after a payer receives confirmation that a patient will be enrolled in coverage with them.
As further discussed in section II.C.3.c.i., to ensure feasible timeframes, we are finalizing
deadlines to account for situations when coverage starts prospectively or retroactively for MA
plans and QHPs issuers on the FFEs and retroactively for Medicaid and CHIP.
Comment: Multiple commenters supported our proposal to require impacted payers to
provide patient education resources at enrollment and annually thereafter. A commenter stated
that educational resources could also come from providers at patient interactions. Other
commenters expressed that CMSs requirements should not add burden to providers or interfere
with their clinical workflow. A commenter recommended that CMS not require Medicaid
agencies to provide information on the Provider Access API opt out policy more frequently than
at member enrollment and annually. The commenter stated that it would be resource intensive
and would require new workstreams and member outreach processes.
Response: We thank commenters for their support of our proposal to require impacted
payers to provide patient education resources at enrollment and annually thereafter (though we
are finalizing a modification to this proposal, as explained above). We did not propose to require
any role for providers, as we agree this would increase their administrative burden. We also
agree with commenters that providing these resources more frequently would indeed increase
burden, which is why we did not propose for impacted payers to do so.
ii. Content
Comment: Multiple commenters suggested that CMS require payers to use clear and plain
language and ensure the opt out policy is prominent. Response: We agree with commenters sentiments and thus proposed that patients should
be able to easily understand the patient education resources. In response to both these comments
and comments on our opt out proposals, as well as for consistency with other policies, we are
finalizing this rule slightly differently from how it was proposed. We had proposed that impacted
payers provide patient education resources in non-technical, simple, and in easy-to-understand
language, but our finalized requirement is that they use plain language. This change is not
intended to alter that the educational information be non-technical, simple, and easy-to-use, but
to make clear that we encourage impacted payers to follow the Federal Governments plain
language guidelines. Those guidelines were informed by the Plain Writing Act of 2010, which
requires Federal agencies to use clear government communication that the public can understand
and use. That statute only applies to Federal Government agencies, but the plain writing
guidance70 that has been developed for the Federal Government will be useful for impacted
payers when developing educational resources for patients. We note that providing these patient
educational resources is a separate requirement from the requirement to create an NPP under the
HIPAA Privacy Rule.71
Comment: A commenter expressed concern about language access, while another
recommended CMS set inclusivity requirements, based on a payers patient population, for
translating into languages other than English. Multiple commenters recommended that notices
about the Provider Access API be focus group tested, written in accurate but positive language
(so as not to unduly discourage participation), and translated into the required threshold
languages for the coverage area.
Response: Impacted payers may already be required to provide plain language resources
in languages other than English, per 45 CFR part 92, which requires impacted payers (as health
70GeneralServicesAdministration(n.d.).Federalplainlanguageguidelines.Retrievedfrom
https://www.plainlanguage.gov/guidelines/.
71DepartmentofHealthandHumanServices(n.d.).NoticeofPrivacyPracticesforProtectedHealthInformation.
Retrievedfromhttps://www.hhs.gov/hipaa/for-professionals/privacy/guidance/privacy-practices-for-protected-
health-information/index.html. programs or activities under that section) to provide meaningful access to individuals with
limited English proficiency and accessibility requirements for individuals with disabilities. The
requirements of that part apply to impacted payers, as described at 45 CFR 92.3.
Additionally, this rule does not affect standards already in place for specific payers on
state or Federal levels. For example, 45 CFR 156.250 requires QHP issuers on the FFEs to
provide information in accordance with the accessibility standards for individuals with
disabilities and individuals with limited English language proficiency at 45 CFR 155.205(c).
Other impacted payers might have their own standards for accessible patient-facing resources, as
well, that would not be affected by this final rule.
Comment: Multiple commenters recommended, for ease of readability, that resources or
notices be written at a certain grade level. Multiple commenters recommended that CMS amend
the patient resources proposal to require impacted payers to write resources at a fourth-to-sixth
grade reading level.
Response: While we agree that these resources need to be understandable, we do not
believe that it is prudent to establish a specific grade level requirement. A grade level score is
based on the average length of the words and sentences. Readability formulae vary and the grade
level scores for the same text can differdepending on how it is used. Furthermore, edits that are
made to make text score at a lower grade level can produce choppy text that lacks cohesion.
Comment: A commenter did not support the development of patient education resources
that may be duplicative or confusing to patients, while another did not support the proposal for
separate patient outreach and education if the data sharing under the Provider Access API is
permitted under the HIPAA Privacy Rules TPO exception.
Response: We refer readers to section II.B.3.b.ii. of this final rule for a full discussion of
the HIPAA Privacy Rules applicability and why we are requiring an opt out policy for the
Provider Access API. We believe that plain language educational resources will inform rather
than confuse patients. We encourage payers to explain to patients that notopting out of data sharing would not limit or negatively affect their rights under the HIPAA Privacy Rule. Rather, it
is an opportunity for them to control where their data are shared under the policies of this final
rule. Where the requirements of this rule change how covered entities or their business associates
may use or disclose PHI, covered entities should also consider their obligations under the
HIPAA Privacy Rule.
Comment: Commenters recommended that CMS require additional details from payers
about their opt out process for the Provider Access API. A commenter stated patients should
receive detailed communications that include the potential benefits and harms of sharing versus
not sharing this information, including the potential impact on quality and timeliness of care.
Commenters further recommended that resources include information on privacy and security,
moving data to a third-party app, and guidelines for patient-provider dialogue on consent.
Response: As explained, we did not want to be overly prescriptive for the specific
language used for the patient resources, but we did propose that they include patient instructions
for opting out of data sharing and controlling their permission. We specifically proposed that the
patient education resources include information about the benefits of API data exchange. In
addition, impacted payers may, if they choose, include reasonable and objective information
about any risks to data sharing. However, the purpose of the information in the educational
resources, regardless of the particular content, should be to inform patients. We believe that
patients educated with accurate information will realize the benefits of data sharing via the
Provider Access API and most will notopt out.
We agree that plain language resources should include information about privacy and
security, in order to give patients an informed view of how the Provider Access API works. It is
also reasonable and acceptable for payers to bundle or combine the educational resources about
the Provider Access API with the educational resources about the Patient Access and Payer-to-
Payer APIs, discussed in sections II.A. and II.C. of this final rule, to give patients a holistic view
of how our interoperability policies work together to improve data exchange. Comment: Commenters recommended that CMS partner with ONC to develop templates
and content for these educational resources, which impacted payers could use to meet this
requirement. Many commenters recommended that CMS work with the health care community
and patient advocates to develop language on the benefits and risks of data exchange.
Commenters also recommended that CMS work with industry to develop and disseminate
educational resources by creating a webpage dedicated to interested party-specific newsletter
inserts, holding CMS open door virtual forums, and using other methods to communicate
regulatory and implementation updates.
Response: We intend to continue working with Federaland industry partners to increase
patient engagement in a way that both protects their autonomy and enables the sharing of the
data to improve their health care. Based on feedback, we intend to develop additional outlines or
templates for patient education resources.
d. Provider Resources Regarding the Provider Access API
We proposed to require impacted payers to develop non-technical and easy-to-understand
resources for providers about the Provider Access API. We proposed that those resources would
have to include information about the process for requesting patient data from payers via the
Provider Access API and how to use the payers attribution process to associate patients with the
provider. We proposed that impacted payers provide these resources to providers through the
payers website and other appropriate provider communications, such as annual contract updates
or handbooks. Non-technical resources will help providers understand how they can use the API
to access patient data, thus realizing the expected benefit of the proposed API. We requested
comment on this proposal, including whether CMS should develop guidance regarding, or
address in future rulemaking, the specific content of these educational resources about the
Provider Access API.
As discussed in more detail, we are finalizing this proposal, with a modification that
provider resources be in plain language. i. Dissemination
Comment: Multiple commenters expressed support for requiring impacted payers to make
these resources easily available on a payers website, in contracts, and in provider handbooks.
However, other commenters sought clarification on what other appropriate provider
communications are and whether existing provider communication channels can be used to
provide these resources. A commenter stated that it is unreasonable to expect providers and their
staff to access each payers website to obtain the payers specific resources and they do not
believe this will happen in a reliable manner. Other commenters stated that the resources should
be incorporated into a clinical workflow or EHRs.
Response: While the provider resources must be available on the payers website, we are
also requiring impacted payers to send those resources directly to providers through other
appropriate channels. We encourage payers to use existing methods of communication by which
providers expect to receive information from payers. We use the term other appropriate
provider communications to provide payers with flexibility, but that term includes existing
communication channels. For example, 42 CFR 422.202 requires MA organizations to provide to
participating physicians written notice of rules of participation, including terms of payment,
credentialing, and other rules directly related to participation decisions. The Provider Access API
resources can be disseminated along with such resources.72 While payers are welcome to use the
Provider Access API to make those resources available, they would have to develop an operable
solution. Furthermore, if a provider needs guidance to access the Provider Access API, requiring
a connection and query would not be useful.
ii. Content
Comment: Multiple commenters supported the proposal for impacted payers to
disseminate provider-facing resources, particularly with instructions for attributing patients to a
provider.
72See42CFR422.202(a)(1). Response: We appreciate commenters support for this requirement. As finalized, payers
will be required to include information about the payers process to attribute patients to a
particular provider. We also highly recommend that payers include contact information for
provider assistance. To be consistent with our revision to the patient education resources policy,
but also being clear that we have not altered the intent, we are finalizing regulatory text slightly
different than what we had proposed, to require provider education resources in plain
language, as opposed to our proposed non-technical, simple, and in easy-to-understand
language.
Comment: Multiple commenters recommended more technical education resources than
we proposed because of the technical nature of API data exchange. A commenter suggested that
the resources include information about the IGs, links to the payers technical documentation and
contact information for assistance with the Provider Access API. Another commenter warned
that the educational resources need to be better defined, because they believe that the information
we describe will be more appropriate for EHR vendors than providers. In fact, another
commenter stated that it may be more appropriate for EHR and practice management system
vendors to provide education resources that offer greater specificity about how data are
integrated into provider data systems and workflows.
Response: While payers will have to include instructions for accessing patient data, we
disagree with the recommendation that payers include more technical documentation. We do not
believe that most providers will be interested in the specific implementation details of the API,
but will rely on their technology vendor. We remind payers that, per the final requirements in the
CMS Interoperability and Patient Access final rule, they are required to make technical
information about their Patient Access APIs available by posting directly on their website.73 We
are finalizing this requirement by reference for the Provider Access, Payer-to-Payer, and Prior
Authorization APIs, as well. References or links to that material would be entirely appropriate to
73See42CFR422.119(d),431.60(d),and457.730(d)and45CFR156.221(d). include in the required provider resources. EHR and practice management vendors also have a
role to play in educating providers about the functionality of their particular system. However,
only payers will be able to offer provider specific details about their Provider Access API and the
process for attributing patients.
Comment: Commenters suggested that CMS require using language regarding limitations
related to disclosures of sensitive conditions that are subject to 42 CFR part 2 and disclosures to
minors.
Response: Though we are not requiring it to be included in the provider resources, payers
should adequately inform providers of what data are and are not available through the Provider
Access API. Providers should be aware of what they can expect to receive in response to a
request, whether that is because of the data content requirements, payer maintenance policies, or
privacy limitations.
Comment: Multiple commenters requested that CMS develop educational resources that
impacted payers could disseminate to their providers to ensure consistency and that providers are
aware of any reporting protocols for payer non-compliance. A commenter added that these
requirements and related guidance should be posted on CMS provider webpages and print
publications. Multiple commenters recommended that CMS consult with Federal partners at
ONC, the Health Resources and Services Administration (HRSA) and the Agency for Healthcare
Research and Quality (AHRQ), and the provider community in order to understand their
educational needs and how best to promote the resources. A commenter recommended that CMS
provide additional guidance on the education and training efforts to provider specialties who are
lagging the industry in interoperable technology adoption.
Response: Based on comments we received, we intend to provide general guidelines to
impacted payers about whatthis final rule requires to be disseminated to providers,which may
include information on potential best practices. However, unlike the patient-facing educational
resources described previously, we expect that provider resources could vary significantly between payers. Payers will have different processes to allow providers to request data via the
Provider Access API and policies for patient attribution to explain to their providers. Therefore,
there is less benefit to standardized templates or content for these resources. We provided links
to resources for APIs to support payers implementing provisions of the CMS Interoperability and
Patient Access final rule (85 FR 25510)74 and we intend to identify similar resources for health
care providers for this final rule. We will continue to work with our partners to ensure providers
can access patient data, regardless of the technology they use. Requiring an API that can be
accessed with systems other than CEHRT is a step toward that goal, and payer-developed
resources should address allthe ways providers could interact with the Provider Access API.
4. Extensions, Exemptions, and Exceptions
See section II.E. of this final rule for a discussion of extensions and exemptions and the
final policies for the Provider Access API for state Medicaid and CHIP FFS programs and
exceptions for the Provider Access API for QHP issuers on the FFEs (this was also addressed in
the proposed rule at 86 FR 76279).
74CentersforMedicareandMedicaidServices(n.d.).BestPracticesforPayersandAppDevelopers.Retrievedfrom
https://www.cms.gov/files/document/best-practices-payers-and-app-developersupdated21023.pdf. rs (i) (ii)
ssueFEs a)(1) a)(2) a)(3) a)(4) a)(4) a)(5) c)
QHPsIonF45CFR156.222( 45CFR156.222( N/A 45CFR156.222( 45CFR156.222( 45CFR156.222( 45CFR156.222( N/A N/A 45CFR156.222(
ManagedCareexistingerenceto438.242at 3(d) 6(b)(6) existingerenceto438.242at 3(d)
r CHIP Throughcrossref42CFR42CFR457.123 42CFR457.120 Throughcrossref42CFR42CFR457.123 N/A N/A N/A
e
y
a
ES dP S ) ) ) )(i) )(ii) ) ) )
I e F 1 2 3 4 4 5 1 2
C ct F )( )( )( )( )( )( )( )(
POLI hImpa CHIPCFR7.731(a CFR7.731(a A CFR7.731(a CFR7.731(a CFR7.731(a CFR7.731(a CFR7.731(c CFR7.731(c A
L ac 4245 4245 N/ 4245 4245 4245 4245 4245 4245 N/
A E
FIN nsfor aged CFRR CFRR )(7) CFRR CFRR CFRR CFRR
I o n F F b F F F F
ACCESSAP Regulati MedicaidMaCareThroughcrossreferenceto42431.61at42C438.242(b)(7)Throughcrossreferenceto42431.61at42C(b)(7)438.24242CFR438.9( Throughcrossreferenceto42431.61at42C438.242(b)(7)Throughcrossreferenceto42431.61at42C438.242(b)(7)Throughcrossreferenceto42431.61at42C438.242(b)(7)Throughcrossreferenceto42431.61at42C438.242(b)(7)N/A N/A N/A
R
DE FFS (i) (ii)
I d 1) 2) 3) 4) 4) 5) 1) 2)
V ai )( )( )( )( )( )( )( )(
PRO MedicCFR1.61(a CFR1.61(a A CFR1.61(a CFR1.61(a CFR1.61(a CFR1.61(a CFR1.61(c CFR1.61(c A API.
: 4243 4243 N/ 4243 4243 4243 4243 4243 4243 N/ ss
1 e
C cc
A
TABLE MedicaregeAdvantaCFR2.121(a)(1) CFR2.121(a)(2) A CFR2.121(a)(3) CFR2.121(a)(4)(i) CFR2.121(a)(4)(ii) CFR2.121(a)(5) A A A theProvider
4242 4242 N/ 4242 4242 4242 4242 N/ N/ N/ or
f
d
RequirementProviderAccessAPIforIndividualPatient75Information(CompliancedateJanuary1,2027)DataContent(CompliancedateJanuary1,2027) ApplicabilityofProviderAccessAPItoNEMTPAHPs(CompliancedateJanuary1,2027)Attribution(CompliancedateJanuary1,2027) OptOut(CompliancedateJanuary1,2027) PatientEducationalResourcesRegardingAPI(CompliancedateJanuary1,2027)ProviderEducationalResourcesRegardingAPI(CompliancedateJanuary1,2027)ExtensionforMedicaidandCHIPFFS(EffectiveDateoftheFinalRule)ExemptionforMedicaidandCHIPFFS(EffectiveDateoftheFinalRule)ExceptionsforQHPIssuersontheFFEs(EffectiveDateoftheFinalRule) rwhichstandardsarerequire
o
f
SectionoftheFinalRuleI.B.2. I.B.2. I.B.2. I.B.3.a. I.B.3.b. I.B.3.c. I.B.3.d. I.B.4.a. I.B.4.a. I.B.4.b. ableH1
I I I I I I I I I I T
e
e
S
5
7 5. Final Action
After considering the comments received, and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule and our response to those comments (as
summarized previously), we are finalizing our proposal with the following modifications:
 Impacted payers must implement and maintain a Provider Access API beginning 2027
(by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by the
rating period beginning on or after January 1, 2027, for Medicaid managed care plans and CHIP
managed care entities; and for plan years beginning on or after January 1, 2027, for QHP issuers
on the FFEs) rather than in 2026.
 Impacted payers are not required to use OpenID Connect Core at 45 CFR
170.215(e)(1) for the Provider Access API.
 Impacted payers are not required to share the quantity of items or services used under
a prior authorization via the Provider Access API.
 Impacted payers are not required to share unstructured documentation related to prior
authorizations via the Provider Access API.
 Impacted payers are required to provide educational resources to patients no later than
one week after the start of coverage, as that term is defined for each type of impacted payer,
rather than at enrollment.
 The educational resources that impacted payers are required to provide to patients and
providers are described as plain language rather than in non-technical, simple, and in easy-to-
understand language.
See further discussion later for exact details of the final requirements for impacted payers.
We are finalizing that beginning 2027 (by January 1, 2027, for MA organizations and
state Medicaid and CHIP FFS Programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must implement and maintain a Provider Access API that is conformantwith certain technical
standards, documentation requirements, and denial or discontinuation policies. Specifically,
those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR
170.215(b)(1)(i), SMART App Launch IG at 45 CFR 170.215(c)(1), and Bulk Data Access IG at
45 CFR 170.215(d)(1).
We are finalizing that, by the deadlines, impacted payers must make available upon
request from an in-network provider, via the Provider Access API, claims and encounter data
(excluding provider remittances and patient cost-sharing information), all data classes and data
elements included in a content standard at 45 CFR 170.213 (USCDI), and certain information
about prior authorizations (excluding those for drugs) that the payer maintains no later than 1
business day after receiving a requestfrom such a provider, if all the following conditions are
met:

The payer authenticates the identity of the provider that requests access and
attributes the patient to the provider under the required attribution process;

The patient does not opt out of the Provider Access API; and

Disclosure of the data is not prohibited by law.
The required prior authorization information is:
 The prior authorization status;
 The date the prior authorization was approved or denied;
 The date or circumstance under which the prior authorization ends;
 The items and services approved;
 If denied, a specific reason why the request was denied; and
 Related structured administrative and clinical documentation submitted by a
provider.
We are finalizing that impacted payers are required to make this information about prior
authorizations available no later than 1 business day after the payer receives a prior authorization request and must update that information no later than 1 business day after any status change.
This information must be available for the duration that the authorization is active and at least 1
year after the prior authorizations last status change.
We are finalizing that impacted payers mustestablish and maintain an attribution 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 finalizing that, by the deadlines, impacted payers must establish and maintain a
process for patients to opt out of data exchange via the Provider Access API and to change their
permission at any time. We are finalizing that this process must be made available before the
first date on which the payer makes patient information available via the Provider Access API,
and at any time while the patient is enrolled with the payer.
We are finalizing that, by the deadlines, impacted payers provide educational resources in
plain language to their patients about the Provider Access API. Those resources must include
information about the benefits of API data exchange with providers, patients opt out rights, and
instructions for both opting out of data exchange and for subsequently opting in. Impacted payers
must make this information available to patients before the first date on which the payer makes
their information available via the Provider Access API, no later than one week after the start of
coverage, and at least annually. These resources must also be available in an easily accessible
location on payers public websites. We remind readers that start of coverage is defined
differently, as applicable, for each type of impacted payer. We refer readers to section II.C.3.c.i.
for discussion of these differences.
We are finalizing that, by the deadlines, impacted payers must provide on their website
and through other appropriate provider communications, information in plain language
explaining the process for requesting patient data using the Provider Access API. The resources
must include information about how to use the payers attribution process to associate patients
with their providers. These policies apply to MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans and CHIP managed care entities (excluding NEMT PAHPs), and
QHP issuers on the FFEs at the CFR sections listed in Table C1.
6. Statutory Authorities for Provider Access API
We received no public comments on the statutory authorities for our Provider Access API
policies.
a. Medicare Advantage Organizations
For MA organizations, we are finalizing these Provider Access API requirements under
our authority at sections 1856(b)(1) of the Act to promulgate regulations that adopt standards to
implement provisions in Part C of Title XVIII of the Act (such as section 1852(d)(1)(A)) of the
Act to adopt new terms and conditions for MA organizations that the Secretary finds necessary
and appropriate. Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition
of using a network of providers, make covered benefits available and accessible to enrollees in a
manner that assures continuity in the provision of benefits. As noted in this section of this final
rule, these regulations implement this requirement by requiring implementation of an API that
will make available data to improve the provision of benefits. The Secretary also has authority
under section 1857(e)(1) of the Act to add new contract terms, including additional standards and
requirements, for MA organizations the Secretary finds necessary and appropriate and that are
not inconsistent with Part C of the Medicare statute.
In implementing section 1852(d)(1)(A) of the Act, we previously adopted a regulation, at
42 CFR 422.112(b), that requires MA organizations to ensure the continuity of care and
integration of services through arrangements with providers that include procedures to ensure
that the MA organization and the contracted providers have access to the information necessary
for effective and continuous patient care. Our policy for MA organizations to implement and
maintain a Provider Access API will facilitate exchanges of information about enrollees that are
necessary for effective and continuous patient care, which is consistent with the requirement at section 1852(d)(1)(A) of the Act for continuing the provision of benefits. The Provider Access
API policy, which will support sharing claims, all data classes and data elements included in a
content standard at 45 CFR 170.213 (USCDI), as well as certain information about prior
authorizations (sections II.B.2. and II.B.3. of this final rule) and a requirement for MA
organizations to offer provider educational resources (section II.B.3.d. of this final rule), will
give providers tools to support continuity of care and care coordination for enrollees. Were a
provider able, through a Provider Access API established by an MA organization, to gather
information for their patient, the provider potentially could make more informed decisions and
coordinate care more effectively. In addition, if a patient moves from one provider to another, the
new provider will be able to ensure continuity of care if they are able to access relevant health
information for the patient from the MA organization in an efficient and timely way. A Provider
Access API could support this; thus, the policy will carry out and be consistent with the Part C
statute.
This policy will complement and align with MA organization obligations at 42 CFR
422.112(b)(4) by providing a means, through a Provider Access API, for the exchange of
information that supports effective and continuous patient care. A Provider Access API may
increase the efficiency and simplicity of administration. It will give providers access to a
significant amount of their patients information with limited effort, and it could reduce the
amount of time needed during provider visits to establish a patients prior history, which could
introduce efficiencies and improve care. These policies are also expected to allow for better
access to other providers prior authorization decisions, which could give a provider a more
holistic view of a patients care and reduce the likelihood of ordering duplicate or misaligned
services. Ultimately, we anticipate that sharing patient information will ensure that providers
receive patient information in a timely manner and could lead to more appropriate service
utilization and higher patientsatisfaction. In addition, the policy that MA organizations make
available educational resources and information will increase access to and understanding of this Provider Access API, leading to more efficient use and integration of the API as a means for
providers to access patient information. Thus, the Provider Access API will be necessary and
appropriate for the MA program and consistent with existing requirements.
b. Medicaid and CHIP
Our finalized requirements in this section for Medicaid FFS and Medicaid managed care
plans fall generally under the authority in the following provisions of the statute:
 Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such
methods of administration as are found by the Secretary to be necessary for the proper and
efficient operation of the state Medicaid plan;
 Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services
are furnished with reasonable promptness to all eligible individuals; and
 Section 1902(a)(19) of the Act, which requires states to ensure that care and services
are provided in a manner consistent with simplicity of administration and the best interests of the
recipients.
The final Provider Access API policies are authorized under these provisions of the Act
because they will ensure that states are able to ensure that Medicaid providers can access data
that could improve their ability to render Medicaid services effectively, efficiently, and
appropriately. The policies are expected to help states fulfill their obligations to operate their
state plans efficiently and to ensure that Medicaid services are furnished with reasonable
promptness and in a manner consistent with the best interest of 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
purposes that are directly connected with the administration of the Medicaid state plan. The
implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list
purposes that CMS has determined are directly connected with administration of Medicaid state
plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to restrict uses and disclosures of Medicaid beneficiary data, including requirements for sharing
applicant and beneficiary data at 42 CFR 431.306.
Our finalized policy, that the data described in this section of the final rule be shared via
the Provider Access API, is consistent with the requirement at section 1902(a)(7) of the Act,
providing that states may share these data only for purposes directly connected with the
administration of the Medicaid state plan. The Provider Access API data sharing policy is related
to providing services for Medicaid beneficiaries, a purpose listed at 42 CFR 431.302(c). As
mentioned previously, a provider can better manage a patients total care when they have access
to more of that patients data because the data will provide a more in-depth medical history,
enable more informed decision making, and potentially prevent the provision or ordering of
duplicative services. More details about how the policies will be implemented in a manner
consistent with state Medicaid requirements under 42 CFR part 431, subpart F, are discussed in
section II.B.2. of this final rule.
Requiring states to implement a Provider Access API to share data with enrolled
Medicaid providers about certain claims, encounter, and clinical data, including data about prior
authorization decisions, for a specific individual beneficiary, may improve states ability to
ensure that care and services are provided in a manner consistentwith simplicity of
administration, and to cover services more efficiently. We remind states that enrolled Medicaid
providers includes managed care plan providers, per 42 CFR 438.602(b). This Provider Access
API will enable Medicaid providers to access beneficiary utilization and authorization
information from the state or managed care plan(s) prior to an appointment or at the time of care,
and that, in turn, should enable the provider to spend more time on direct care. The policy will
support efficient and prompt delivery of care as well, which will be in beneficiaries best
interests. These policies are also expected to give providers better access to prior authorization
decisions for care provided by other enrolled Medicaid providers, which will give a provider a
more holistic view of a patients care and reduce the likelihood of ordering duplicate or misaligned services. This may also facilitate easier and more informed decision-making by the
provider and should therefore support efficient coverage decisions in the best interest of patients.
The Provider Access API is expected to make available a more complete picture of the patient to
the provider at the point of care, which could improve the quality and efficiency of a patient
visit. These outcome and process efficiencies may help states fulfill their obligations to ensure
prompt access to services in a manner consistent with the best interest of beneficiaries, consistent
with sections 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might
help the state administer its Medicaid program more efficiently, consistent with section
1902(a)(4) of the Act. These analyses apply similarly to FFS and managed care programs and
delivery systems, so we are exercising our authority to adoptvirtually identical regulatory
requirements for a Provider Access API for both Medicaid FFS programs and Medicaid managed
care plans.
For CHIP, we finalized 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. We believe this policy will
strengthen states abilities to fulfill these statutory obligations in a way that will recognize and
accommodate using electronic information exchange in the health care industry today and will
facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries.
When providers have access to patient utilization and authorization information from
payers or other health IT systems, they may be able to provide higher quality care. Improving the
quality of care aligns with section 2101(a) of the Act, which requires states to provide CHIP
services in an effective and efficient manner. The more information a provider has to make
informed decisions about a patients care, the more likely it is that patients will receive care that
best meets their needs. Additionally, providers can be more effective and efficient in their
delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information abouta patient prior to or at the point of care, the
provider will be able to spend more time focused on the patient, rather than on their need to
collect information. In addition, the information providers do collect will not be based solely on
patient recall. This will save time, improve the quality of care, and increase the total amount of
direct care provided to CHIP beneficiaries. When data are standardized, and able to be
incorporated directly into the providers EHR or practice management system, they can be
leveraged as needed at the point of care by the provider and also can be used to support
coordination across providers and payers. This is inherently more efficient, and, ultimately, more
cost-effective, as the information does not have to be regularly repackaged and reformatted to be
shared or used in a valuable way. As such, the Provider Access API policies also align with
section 2101(a) of the Act in that these proposals will improve coordination between CHIP and
other health coverage. For these reasons, we believe this policy is in the best interest of the
beneficiaries and within our long-established statutory authorities.
Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431,
subpart F, are also applicable to CHIP through a cross-reference at 42 CFR 457.1110(b). More
details about how the policies could be implemented in a manner consistent with these CHIP
agencies requirements are also discussed in section II.B.2.of this final rule. As discussed
previously for Medicaid, giving CHIP providers access to attributed beneficiary data through the
Provider Access API is related to providing services to beneficiaries, which is described at 42
CFR 431.302(c) as a purpose directly related to state plan administration. We remind states that
when they share beneficiary information through the Provider 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.
c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we are finalizing 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 an Exchange determines that making available such health plans
through that Exchange is in the interests of qualified individuals in the state in which the
Exchange operates. We believe the benefits will outweigh any additional burdens this might
impose on issuers. By using the finalized technologies, patients could experience improved
health, payers could see reduced costs of care, and providers could see better compliance with
care regimens. We also do not believe that premiums will significantly increase because some of
the infrastructure necessary to implement the technology has been completed to comply with the
CMS Interoperability and Patient Access final rule. Furthermore, QHP issuers on the FFEs might
combine investments and staff resources from other programs for implementation efforts,
avoiding the need to increase premiums.
We believe that certifying only health plans that make enrollees health information
available to their providers via the Provider Access API is generally in the interests of enrollees.
Giving providers access to their patients information supplied by QHP issuers on the FFEs will
ensure that providers are better positioned to provide enrollees with seamless and coordinated
care and ensure that QHP enrollees on the FFEs are not subject to duplicate testing and
procedures, and delays in care and diagnosis. Access to the patients more complete medical
information could also maximize the efficiency of an enrollees office visits. We encourage
SBEs, including SBE-FPs, to consider whether a similar requirement should be applicable to
QHP issuers participating in their Exchanges. C. Payer-to-Payer API
1. Background
Having a patient's data follow them when they change payers can have a multitude of
benefits for patient care. A payer receiving data when a new patient enrolls can better coordinate
care and make more informed decisions. For instance, a payer can use the patients data to
determine whether they have a chronic condition or is undergoing current care that needs to be
maintained. If necessary, patient data can give payers the information they need to assign a case
manager or help the patient find providers in their new network. Maintaining a corpus of data
ensures that the patient and their providers do not lose access to recent information that may be
relevant to ongoing or future care.
Furthermore, because payers usually maintain a relationship with individual patients over
time, they are uniquely positioned to collect and aggregate a patients record. Whereas patients
may have several providers who manage their care, they generally maintain a relationship with
only one or two concurrent payers for a full year or multiple years. However, when a patient
moves from one payer to another, both parties may lose access to that valuable data. Data
exchange among payers, specifically, sending patient data from a patients previous payer to
their new one, is a powerful way to ensure that data follow patients through the health care
system and improve care continuity. Electronic data exchange between payers will support payer
operations and a patients coverage transition to a new payer efficiently and accurately. Sharing
health care data between payers also helps care coordination, care continuity, and allows patients
to maintain access to their record over time.
In the CMS Interoperability and Patient Access final rule (85 FR 25565), we highlighted
numerous benefits of payers maintaining a longitudinal (meaning, long-term) record of their
current patients health information. If payers are at the center of the exchange, they can make
information available to patients and their providers and can help a patients information follow
them as they move from provider to provider and payer to payer. In the CMS Interoperability and Prior Authorization proposed rule, we proposed and, in
this rule are now finalizing regulations that require impacted payers (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 a FHIR API to facilitate payer to payer
data exchange. We are finalizing that proposal to require impacted payers to build a Payer-to-
Payer API, with certain standards (as further described in section II.F.), that will facilitate patient
data exchange at the start of coverage and with concurrentpayers. We proposed, and are
finalizing, a patient opt in policy for this data exchange. We proposed compliance dates in 2026
for the Payer-to-Payer API (by January 1, 2026, for MA organizations and state Medicaid and
CHIP FFS programs; by the rating period beginning on or after January 1, 2026, for Medicaid
managed care plans and CHIP managed care entities; and for plan years beginning on or after
January 1, 2026, for QHP issuers on the FFEs). However, in response to comments we are
finalizing a modification to that proposal for the Payer-to-Payer API to establish compliance
dates in 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027,
for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates
as in 2027 for the various payers. In addition, and also in response to comments, we are
finalizing a modification to ourproposal to only require impacted payers to exchange data with a
date of service within 5 years of the exchange request.
To support the implementation and maintenance of the Payer-to-Payer API, we are
requiring certain standards and recommending certain IGs, as further discussed and in section
II.G. With the publication of the HTI-1 final rule, our cross references to 45 CFR 170.215 have
been updated to reflect the updated citations as needed. Changes to the structure of 45 CFR
170.215 and versions of the API standards codified there are discussed further in section II.G.
and reflected throughout this final rule. For the Payer-to-Payer API, impacted payers must use the following standards: HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU
3.1.1 at 45 CFR 170.215(b)(1)(i), and Bulk Data Access IG v1.0.0: STU 1 at 45 CFR
170.215(d)(1). Impacted payers are permitted to use updated standards, specifications, or IGs
that are not yet adopted in regulation for the APIs required in this final rule, should certain
conditions be met. For the standards at 45 CFR 170.215, updated versions available for use under
our policy include, but are not limited to, US Core IGSTU 6.1.0 and the Bulk Data Access IG
v2.0.0: STU 2, which have been approved for the ONC Health IT Certification Program.76 We
refer readers to policies finalized for the Patient Access API in the Interoperability and Patient
Access final rule, as well as section II.G.2.c. of this final rule for a full discussion on using
updated standards. We also recommend payers use the CARIN IG for Blue Button STU 2.0.0,
PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend Services
Authorization. We refer readers to Table H3 for a full list of the required standards and
recommended IGs to support API implementation.
In this section, we talk about data exchange between payers. When we refer to a patients
new payer, we mean the payer that a patient is newly enrolled with and the party responsible for
requesting and receiving the patients data. When we refer to the patients concurrent payers, we
signify the parties (two or more) that are providing coverage at the same time and are responsible
for exchanging data with each other as discussed further in section II.C.3.c. When we refer to the
patients previous payer, we denote the payer that a patient has previously had coverage with and
thus the payer responsible for sending the data to the new payer.
Our payer to payer data exchange requirements discussed in this section involve
transactions and cooperation between payers, which may include payers that are notsubject to
the requirements in this rule. We emphasize that each impacted payer is responsible only for its
own side of the transaction. For instance, when an impacted payer is required to request patient
76OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap. data from another payer, it will have to do so regardless of whether the other payer is an
impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an
impacted payer receives a request for patient data that meets all the requirements, the impacted
payer must share those data, regardless of whether the requesting payer is an impacted payer
(which, again, may or may not be evident to the payer sharing the data). In this way, payers not
subject to this regulation that implement a Payer-to-Payer API (or other IT functionality to
request or receive information through the impacted payers API) and their patients can also
benefit from the data exchange.
We are exploring steps for Medicare FFS to participate in payer to payer data exchange
and we encourage other payers that are not subject to these requirements to do the same. We
intend to implement the Payer-to-Payer API capabilities for Medicare FFS in conformance with
the requirements for impacted payers, as feasible. In the proposed rule, we sought comment on
whether our proposals could be implemented as proposed for the Medicare FFS program, how
we could apply each of the proposals, and whether there would be any differences for
implementing the Payer-to-Payer API in the Medicare FFS program as a Federal payer. We
summarize the comments received and our responses in section I.D. of this final rule. We
strongly encourage all payers that are not subject to the requirements of this rule to consider the
value of implementing a Payer-to-Payer API, so that all patients, providers, and payers in the
U.S. health care system may experience the benefits of such data exchange.
Comment: Many commenters supported our proposal to require data exchange via a
Payer-to-Payer API. Commenters stressed the benefits to patients of maintaining an ongoing
record when they change payers, which could result in better patient outcomes, especially for
patients with chronic conditions. Commenters agreed that this API would improve
interoperability, data exchange, and reduce administrative burden. Multiple commenters stated
that the Payer-to-Payer API would be especially helpfulto patients with concurrent coverage. A
commenter stated that the assignment of primary care physicians could also be facilitated by the Payer-to-Payer API and that this could reduce care disruptions when changing payers. Another
commenter acknowledged that investments made in payer to payer data exchange would benefit
broader multi-payer alignment efforts, which are a key priority for improving quality, access, and
value in health care. Another commenter stated that exchanging patient data from previous and
concurrent payers would eliminate duplicative medical record requests from payers requiring
providers to reapprove medical necessity, retry step therapy requirements, and reauthorize
treatments.
Response: We appreciate commenters validating our statements in the proposed rule
regarding the benefits of payer to payer data exchange. We agree that the benefits of payer to
payer data exchange include both ensuring care continuity and that patients, providers, and future
payers do not lose access to important health information. We are finalizing, with modification,
the Payer-to-Payer API proposals as discussed in this section.
Comment: Multiple commenters opposed finalizing our Payer-to-Payer API proposals.
They disagreed with our justification that payers should be the maintainers of a patients
longitudinal data. Another commenter cautioned that, as proposed, the Payer-to-Payer API would
require payers to share a large amount of unnecessary data, which would make it difficult to
effectively coordinate care. Instead, they suggested that by leveraging the Patient Access API,
patients should have the responsibility to maintain their patient data using an app, or other
solution of their choice. A commenter recommended that CMS separate the goal of creating
longitudinal consumer health records from the goal of supporting consumer transitions between
payers.
Response: After reviewing comments, we agree that patients are in the best position to
manage their health information, especially with the growing ecosystem of health apps and the
availability of standardized Patient Access APIs. Some HIEs and health apps (which may also be
TEFCA Participants and Subparticipants) may be able to gather data from payers, providers, and
other sources to create a more comprehensive patient record than could be maintained by a payer. However, payers are uniquely positioned to collect and aggregate patient data, especially
during coverage transitions. As we noted, patients may have several providers who manage their
care, but they generally maintain a relationship with only one or two concurrent payers for a full
year or multiple years.A payer to payer data exchange can facilitate care continuity by providing
access to information about past treatments when a patient is moving from one payer to another.
For example, that information could show payers that a patient has already demonstrated medical
necessity or engaged in step therapy, which could ease the approval of a prior authorization
request. Ensuring that payers have timely access to newly enrolled patients data upon a patient
transitioning payers can have a multitude of benefits for patient care leading to better-
coordinated care, more informed decision-making, and minimize disruption in ongoing care.
Therefore, to mitigate potential burden on impacted payers, while still establishing the Payer-to-
Payer API as a means to support the creation and availability of a longitudinal record, as
discussed, we are finalizing a modification to our proposal to only require payers to exchange
data with a date of service within 5 years of the request. That modification means that payers will
not be responsible for exchanging and maintaining a patients entire health history dating to
January 1, 2016.
Comment: Multiple commenters did not support the proposed Payer-to-Payer API and
suggested alternatives to gain the intended benefits. A commenter noted that there are many
industry solutions already being developed to facilitate the coordination of benefits between
payers and recommended CMS continue to monitor and enable technical innovation in this area.
Another commenter cautioned CMS to not view FHIR as the sole solution to interoperability and
patient data exchange challenges. The commenter noted that as proposed, payers would
experience challenges if FHIR failed to reach widespread adoption and maturity. Another
commenter stated that requiring the FHIR standard eliminates choice and leads to bias and
further stated that other options may be better suited for a payer. Response: We thank the commenters for their suggestions, but FHIR APIs are the
standard that the industry indicated has the greatest maturity and hence has been adopted by
ONC. A variety of solutions will not lead to interoperability across the healthcare system. While
payers already have processes in place for coordinating benefits, that coordination does not
extend to transitions of care between payers, such as maintaining prior authorizations. Data
exchange between payers can ensure that valuable patient information is not lost, such as prior
authorization requests and approvals, which could make that transition more seamless. Requiring
FHIR will get the healthcare industry to a more interoperable state, as that standard supports
health data exchange in a standard, structured, but flexible format that can continue to advance
and mature. Impacted payers are already required to use the FHIR standard for the Patient
Access and Provider Directory APIs, and this final rule is meant to build on this existing policy.
Also, we are extending the compliance dates for the Payer-to-Payer API to 2027. This delay to
the compliance dates versus our proposal allows for additional time for implementation and IGs
to be refined and matured to support the policies in this final rule.
Comment: Multiple commenters expressed concern regarding payer access to patient
data.They worried that this could lead to patient risk profiling, increased prior authorization
requirements, increased premiums and limits on coverage and access to care. They recommended
that CMS prohibit impacted payers from using information sent from a previous payer to
discriminate against a patient. A commenter stated that CMS should implement safeguards to
ensure that the payer to payer data exchange does not encourage payers to make care decisions
based on the patients record. The commenter recommended that CMS explain that the provider
is the director of medical care, and payers support the patients care through payment and
coverage of services. They suggested that large-scale consumer data exchange should be
consumer-mediated and result in meaningful access to comprehensive data for care coordination
among payers. Response: We agree with the commenters that patient information should not be used in
an inappropriate manner. We remind payers that section 1852(b) of the Act states that an MA
plan may not deny, limit, or condition the coverage or provision of benefits based on any health
status-related factor described in section 2702(a)(1) of the Public Health Service Act.77 Section
2705(a)(1) of the Public Health Service Act, which applies to QHP issuers on the FFEs, prohibits
discrimination against individuals based on their health status-related factors. Similarly, section
2102(b)(1)(B)(ii) of the Act prohibits CHIP programs from denying eligibility for children with
preexisting conditions. Finally, the overarching regulations at 45 CFR part 92 implementing
section 1557 of the Affordable Care Act prohibit discrimination under any health program or
activity receiving Federal financial assistance on the basis of race, color, national origin, sex,
age, or disability.
Comment: Multiple commenters suggested that implementation of a Payer-to-Payer API
may increase provider burden with unintended downstream effects. A commenter discussed how
the Payer-to-Payer API could lead to a negative impact on providers who may be required to
ingest large amounts of data if payers maintain a longitudinal record back to January 1, 2016,
that is also shared via the Provider Access API.
Response: Our modification to require impacted payers to exchange only 5 years of data
via the Payer-to-Payer API will mitigate this possible issue for providers. By circumscribing the
data to be exchanged by payers to only more recent data, providers are less likely to receive
distant and irrelevant historical data via the Provider Access API. We acknowledge that not all of
a patients health information is going to be equally relevant to a particular provider. Therefore,
providers should look for clinically relevant information and work with their EHR vendors on
solutions to easily display the information most relevant to their practice. We discuss this issue is
greater depth in section II.B.2.c.
77Section2702ofthePublicHealthServiceActreferencedinsection1852(b)oftheActreferstowhatisnow
codifiedassection2705ofthePublicHealthServiceAct. Comment: A commenter questioned the utility of the Payer-to-Payer API if payers other
than impacted payers do not voluntarily adopt the technology and processes to share data.
Response: We appreciate commenters supporting Payer to Payer adoption by payers
other than impacted payers. We strongly encourage all payers not subject to these provisions to
consider the value of implementing a Payer-to-Payer API, so that all patients, providers, and
payers in the U.S. health care system may ultimately experience the benefits of such data
exchange. Even though not every payer may participate in it, our Payer-to-Payer API policy can
benefit the millions of Americans covered by impacted payers. We specifically encourage
impacted payers that have other lines of business to adopt the policies in this final rule for their
commercial plans that are not subject to the requirements of this rule.
Comment: A commenter recommended that CMS work with ONC and industry
stakeholders to develop a longer-term FHIR roadmap, including patient-centric data homes that
efficiently and effectively collect, storage, and integrate information from across the health
system on behalf of a patient. Another commenter recommended that CMS work with the DoD
and the VA to implement Payer-to-Payer APIs.
Response: We appreciate the support for our Payer-to-Payer API policies and will
continue to work with other Federalagencies to improve interoperability across the health care
system.
Comment: Many commenters recommended delaying the Payer-to-Payer API compliance
dates to give payers more time to design, develop, test and implement their systems. Some
commenters recommended a January 1, 2027, compliance date, and another commenter
recommended 4 years after the publication of the finalrule, to give industry time to align on a
standardized implementation approach. A few commenters suggested CMS delay compliance
dates until IGs are mature enough to adopt as required standards, or to allow payers to adopt
Payer-to-Payer API on a voluntary or pilot basis. Some commenters suggested CMS set rolling
compliance dates and the Payer-to-Payer API should be prioritized after the Prior Authorization API. Several commenters specifically recommended that CMS to delay the compliance dates for
state Medicaid agencies to implement a consistent solution at enrollment. A commenter
requested that CMS accelerate the compliance dates to 2024. Another commenter urged CMS to
consider the added cost and burden for payers to meet the proposed compliance dates.
Response: Because we understand that the payer implementation process is significant,
after reviewing the comments, we are finalizing a modification to our proposal for the Payer-to-
Payer API, to establish compliance dates in 2027 (by January 1, 2027, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs). However, as discussed in
section I.D.2., we decline to delay beyond that because of the importance of payer to payer data
exchange. Establishing regulatory compliance dates will provide greater urgency to test and
mature the evolving technical standards and IGs. When we proposed to require the relevant IGs
in our December 2020 CMS Interoperability proposed rule, we received many comments that
those standards were not mature enough to feasibly implement at that time. In response, we
proposed in this rulemaking to only recommend (rather than require) the IGs for standardized
implementation. After consideration of the comments we received in response to the CMS
Interoperability and Prior Authorization proposed rule, we are finalizing those IGs as
recommendations because it is prudent to move forward to attain the policy goals of the Payer-
to-Payer API, even while those standards are being developed to achieve true interoperability.
Moving to a 2027 compliance dates will give the industry an extra year to refine those IGs and
for payers to implement their technical solutions.
With regard to the requests for additional time for Medicaid programs specifically, we
refer readers to section II.E.2.a. of this final rule where we finalize our proposals to create a
process for Medicaid and CHIP FFS programs to request and be granted an extension to the
compliance dates for the Payer-to-Payer API. 2. Proposal to Rescind the CMS Interoperability and Patient Access Final Rule Payer to Payer
Data Exchange Policy
We strongly believe that data exchange among payers is a powerful way to improve
information sharing that would allow patients and providers to have more complete access to
health information, which can help to promote better patient care. Patients may wish for their
health information to follow with them when they change payers, in part so that they can track
the services they have received, and to ensure that a new payer has information to better assist
with continuity of that care. However, given the concerns raised by stakeholders regarding the
lack of technical specification in our previously finalized policy, we proposed to rescind the
payer to payer data exchange policy finalized in the CMS Interoperability and Patient Access
rule (85 FR 25568) at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR
156.221(f)(1). We did so to prevent industry from developing multiple systems, and to help
payers avoid the costs of developing non-standardized, non-API systems, and the challenges
associated with those systems. We proposed a new policy that would, instead, require impacted
payers to implement and maintain a Payer-to-Payer API using the FHIR standard. We stated that
using FHIR APIs would ensure greater uniformity and ultimately lead to payers having more
complete information available to share with patients and providers.
Comment: Commenters supported CMSs proposal to rescind and replace the Payer-to-
Payer API requirements finalized in the CMS Interoperability and Patient Access rule (85 FR
25568). They agreed that the proposals would help standardize data exchange and avoid
developing duplicative systems. Multiple commenters strongly supported the newly proposed
FHIR API approach and noted that this API would leverage the same standards as the Patient
Access and Provider Access APIs. A commenter highlighted how CMSs proposal to replace the
payer to payer data exchange addressed a key concern held by the industry about the lack of
specificity in the previous policy. Another commenter stated that they welcomed the elimination
of provider remittances and cost-sharing information from the required data content. Response: We appreciate commenters support and are finalizing our rescission of the
previous policy.
We note that we are correcting a technical error in this final rule for the Payer-to-Payer
API requirements in Medicaid managed care. When we proposed to remove the requirement at
42 CFR 438.62(b)(1)(vi) and (vii) and instead use a cross reference to 42 CFR 431.61(b)(1) at 
438.242(b)(7), we inadvertently neglected to properly revise 42 CFR 438.9 to continue excluding
NEMT PAHPs from the Payer-to-Payer API requirements. When the payer to payer data
exchange requirements were finalized in the CMS Interoperability and PatientAccess rule (85
FR 25568) at  438.62(b)(1)(vi) and (vii), NEMT PAHPs were automatically excluded as 42
CFR 438.62 is not applicable to NEMT PAHPs. However, by moving the Payer-to-Payer API
requirements to  438.242(b)(7), the requirements would apply to NEMT PAHPs (at 42 CFR
438.9(b)(7)). As we explained when we proposed to exclude NEMT PAHPs from the Provider
Access API (87 FR 76258), we believed 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,
justified their exclusion from the requirements of the Provider Access API. Similarly, we do not
believe that other payers have a routine need for NEMT data; therefore, requiring NEMT PAHPs
to implement and maintain a Payer-to-Payer API would be an undue burden on them. It would
also be a burden on other Medicaid payers concurrently covering a patient to receive NEMT data
quarterly as required at 42 CFR 431.61(b)(5). To correct this oversight, we are finalizing 42 CFR
438.9(b)(7) to exclude the requirement at  438.242(b)(7), which is to comply with  431.61(a)
and (b).
Comment: A commenter supported our proposal to rescind the previous requirements but
urged us not to finalize our new Payer-to-Payer API proposals, because many of the technical
standards are still undergoing development and refinement and operational processes have not
been established by payers. The commenter suggested that CMS should consider establishing a
voluntary payer to payer data exchange policy. Response: We acknowledge that any new requirement is going to have operational
challenges that need to be resolved. Technical standards have substantially developed over the
past 3 years since we issued the December 2020 CMS Interoperability proposed rule (85 FR
82586). We refer readers to sections II.G.3.a. and II.G.3.b. of this rule for additional discussion
on enhancements to both the required and recommended IGs published since the publication of
the CMS Interoperability and Prior Authorization proposed rule. For example, the recently
published PDex IG STU 2.0.0 specification now includes a Prior Authorization profile that
enables payers to communicate prior authorization requests and decisions. We are extending our
compliance dates for the Payer-to-Payer API from our proposed 2026 to 2027 in orderto provide
additional time for stakeholders, and specifically payers, to address those barriers to
implementation.
3. Payer to Payer Data Exchange on FHIR
a. Payer-to-Payer API Technical Standards
In the CMS Interoperability and Patient Access final rule we finalized a requirement that
impacted payers must implement, maintain, and use a Patient Access API conformant with 45
CFR 170.215. However, we did not require payers to use an API or specific standards for payer
to payerdata exchange in that final rule.
In the CMS Interoperability and Prior Authorization proposed rule, we proposed an API-
based payer to payer data exchange utilizing standards and technology similar to that of the
Patient Access API. The degree of overlap between the requirements for the Patient Access API
(discussed in section II.A.2.of the proposed rule) and the Provider Access API (discussed in
section II.B.2. of the proposed rule) should ease the development and implementation of the
Payer-to-Payer API for payers.
The Patient Access API will provide the foundation to share adjudicated claims and
encounter data, alldata classes and data elements included in a standard adopted at 45 CFR
170.213 (USCDI), as well as certain information about prior authorizations. Because, as of January 1, 2021, the same adjudicated claims and encounter data, and alldata classes and data
elements included in the standard at 45 CFR 170.213 are already required for the Patient Access
API, payers should have already formatted these categories of data and prepared their systems to
share these standardized data via a FHIR API. As a result, payers have already devoted the
development resources to stand up a FHIR API infrastructure when they implemented the Patient
Access API, which could be adapted for additional interoperability use cases.
We proposed 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 implement and maintain a Payer-to-Payer API that is conformant with the same technical
standards, documentation requirements, and denial or discontinuation policies as the Patient
Access API.
We proposed to require certain standards adopted under 45 CFR 170.215 that are
applicable to the Payer-to-Payer API. We are finalizing our proposals for the Payer-to-Payer API
with modifications, requiring impacted payers to use the following standards: HL7 FHIR Release
4.0.1 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR 170.215(b)(1)(i), and Bulk Data Access
IG at 45 CFR 170.215(d)(1). We also recommend payers use the CARIN IG for Blue Button
STU 2.0.0, PDex IG STU 2.0.0, and SMART App Launch IG Release 2.0.0 to support Backend
Services Authorization. We proposed but are not finalizing to require impacted payers to use
SMART App Launch IG and OpenID Connect Core for reasons discussed later in this section.
We refer readers to Table H3 for a full list of the required standards and recommended IGs to
support API implementation. We refer readers to section II.G. of this final rule for further
discussion of the required and recommended technical standards for the Payer-to-Payer API.
One operational difference between the Patient Access and Payer-to-Payer APIs is that
payers may find it more efficient to share data for multiple patients at a time. It is likely that
impacted payers with a fixed enrollment period will have many patients data to share at one time, especially if other payers share that enrollment period (such as QHPs offered on an FFE).
In such a situation, it could require significant time and resources for payers to send each
patients data individually through an API. The Bulk Data Access IG for exchanging multiple
patients data at once has been adopted by ONC at 45 CFR 170.215(d)(1),which is discussed
further in section II.F. of this final rule and is a standard we proposed to require for the Payer-to-
Payer API.
We requested comments on these proposals. We received multiple comments regarding
technical implementation challenges and the maturity of the recommended IGs, which are
addressed in section II.G. of this final rule. Here we respond to the comments specific to the
standards and IGs for implementing the Payer-to-Payer API.
Comment: Multiple commenters stated their support for the proposed FHIR standard and
recommended IGs for the Payer-to-Payer API. Multiple commenters stated that the FHIR
standard will ultimately prevent issues with data sharing across payers and allow information to
be shared accurately and timely. Many commenters gave their support for our proposal that the
Payer-to-Payer API must be conformant with the standards at 45 CFR 170.215, including
support for the Bulk Data Access IG and OpenID Connect Core. Some commenters agreed with
not requiring payers to use the CARIN IG for Blue Button or HL7 Da Vinci IGs. Additionally,
other commenters explained that universally implementing FHIR would define how health care
information is shared, but will have no impact on how data are collected or stored. Multiple
commenters stated their support for requiring Payer-to-Payer APIs to use the same standards as
the other interoperability APIs. A commenter stated that leveraging the same standards and IGs
will support efficient implementation. Another commenter stated that the lack of standards has
been one of the barriers to achieving data fluidity between payers.
Response: We thank commenters for their support of the proposed standards and
recommended IGs for the Payer-to-Payer API and agree that the using standards will support
more efficient data sharing. Requiring impacted payers to use the same standards and IGs will support consistent implementation and improve interoperability across health care. We note that
for the Payer-to-Payer API, we are finalizing a modification to our proposal by not requiring the
SMART App Launch IG at 45 CFR 170.215(c) and OpenID Connect Core at 45 CFR
170.215(e)(1), as discussed further in section II.C.3.d.iii. of this final rule. Protocols requiring
user level credentials managed by the payer, such as those used with OpenID Connect Core, are
generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API
where a particular individual may notbe directly initiating the exchange.
Comment: Some commenters who supported the proposal that the Payer-to-Payer API
must be conformant with FHIR at 45 CFR 170.215(a)(1) identified concerns with
implementation. Multiple commenters agreed with the approach to require the FHIR standard for
Payer-to-Payer APIs, but some commenters noted that the standard has not been widely
demonstrated in production by industry stakeholders. A commenter stated that payers will need
to create workflows to process exchanges, incorporate received data into local records, and
troubleshoot any issues. A commenter recommended that CMS allow 1 to 2 years to implement
new standards depending on complexity. The commenter encouraged data transfer standards be
backward compatible.
Response: We agree that implementing new standards takes time and appreciate the
commenter recommending we allow 1 to 2 years.However,technology and standards are ever
evolving and will never remain static for the period it would take the entire industry to
implement. To address comments about the time necessary for implementation, we are delaying
the compliance dates for the Payer-to-Payer API to 2027, which will give implementers
approximately 3 years from the publication of this final rule. Public comment has broadly
indicated that the proposed standards will be sufficiently mature for implementation by that
deadline. We will continue working with HL7, the FHIR accelerators, and industry stakeholders
to define, to participate in and convene testing events, and to develop and maintain the
specifications, which moves them towards greater maturity. Specifically, the PDex IG has been tested, implemented, and based on industry standard consensus,is ready for use. We
acknowledge that the standards discussed in this rule will continue to mature to enhance
functionality and meet additional use cases. We expect thatfuture rulemaking by CMS and ONC
will be necessary to keep pace with the latest technical innovations. While the technology may
never be done, commenters indicated that the standards available today are sufficiently mature
to facilitate 2027 compliance dates for the policies in this final rule that require API development
or enhancement.
We acknowledge that, as with any standard, potential compatibility issues could arise
through the further development of those specifications. We discuss IG maturity further in
section II.G.3.b. of this final rule. These standards are subject to a standards development
process where changes are reviewed and compatibility is an important consideration,
increasingly so with the level of adoption and use. As the IGs mature, the numberof potential
compatibility issues between versions is expected to decrease.
Comment: Multiple commenters recommended that CMS name specific IG versions and
standards as a baseline for the Payer-to-Payer API and create a formal standard version
advancement process similar to the ONC Standards Version Advancement Process (SVAP). A
commenter noted that an established SVAP would give the industry and HL7 the opportunity to
continue refining and testing standards and IGs to ensure consistent implementation. A
commenter recommended that CMS ensure that the applicable Payer-to-Payer API technical
standards remain current as new versions become available. Multiple commenters specifically
stated their concern for endpoint compatibility and recommended that CMS create required
standards so that payers do not need to make one-off modifications to accommodate slightly
different APIs.
Response: In the proposed rule, we stated that we believed the approach of
recommending, but not requiring, specific versions of the IGs would provide directional
guidance without locking implementers into the versions of the recommended IGs available at the time of the proposed rule. To not recommend any specific IGs would have meant a more
diverse set of proprietary solutions with little to no interoperability. Our recommendations have
allowed the IG authors and community to receive feedback from real-world use and to further
mature and refine the IGs. Certification and testing of these APIs could help avoid
implementation variation and will consider ways for CMS to support such testing in the future.
In addition, by using the recommended IGs, implementers can ensure that their APIs are
compatible and conformant to the requirements. As the standards continue to mature, we will
consider whether to propose requiring additional IGs through rulemaking.
Comment: A commenter stated that the proposed IGs are dependent on an outdated
network authentication protocol and recommended using the HL7 FHIR Da Vinci Health
Record Exchange (HRex) IG, which leverages UDAP for authentication. Another commenter
simply recommended utilizing UDAP for authentication. Another commenter recommended
CMS modify the standards and IGs to adequately capture the Payer-to-Payer API requirements.
The commenter stated that CMS should support the development of content and technical
standards for prior authorization decisions that can be incorporated into the appropriate IGs for
testing.
Response: We acknowledge that there is no single security protocol approach that will
address all use cases. Additionally, within a single API, implementers may need to utilize more
than one protocol to address specific population and trading partner needs. As discussed in
section II.C.3.d.iii. of this final rule, we are finalizing a modification to our proposal to not
require the OpenID Connect Core and SMART App Launch IG standards for the Payer-to-Payer
API. We recognize that methods such as SMART Backend Services (which is included in the
SMART App Launch IG v2), mTLS, UDAP, or other trust community specified means may be
appropriate depending on the needs. We refer readers to Table H3 in this final rule for an
updated finalized list of all required and recommended IGs for the Payer-to-Payer API. We will
continue to work with ONC to advance the versions of the standards that ONC adopts at 45 CFR 170.215. We will continue to monitor the development UDAP and other trust community
specified solutions that could support the Payer-to-Payer API authentication process. We also
note that ONC has adopted SMART Release 2.0.0 at 45 CFR 170.215(c)(2) and while we are not
requiring the SMART App Launch IG for the Payer-to-Payer API, we do recommend using
SMART Backend Services.
Comment: A commenter expressed support for maturing the PDex IG and noted that the
IG still needs more testing for specific use cases. Another commenter suggested that CMS not
finalize the Payer-to-Payer API until it works with HL7 to diminish the costs with the PDex IG.
The commenter noted that in the PDex IG, the patient would be responsible for manually
executing the data exchange using a third-party app and then transmitting that information to a
new payer. Another commenter stated that the IGs identified for the payer to payer data
exchange include the capability for two methods (member-mediated and member-directed),
which would cause confusion and redundancy. The commenter stated that the member-directed
solution would potentially give the new payer access to financial information meant to be
available only to the patient.
Response: The PDex IG provides multiple data exchange methods. One method allows a
member to directly authorize data being sent to a third party. While this method could be utilized
for payer to payer interactions, it is not the primary method defined by the PDex IG for that use
case. For the Payer-to-Payer API use case, the PDex IG provides guidance for supporting
exchanges that do not require direct member engagement. The PDex IG STU 2.0.0, which is
being recommended for the Payer-to-Payer API in this rule, can facilitate on the payer to payer
exchange by defining a means for the requesting payer to send a record of the patients opt in to
retrieve data from the other payer. This method does not require patient action through OAuth
and is the method we recommend for payer to payer data exchanges. While we recognize that the
PDex IG utilizes mTLS for payer authentication, we are not requiring that protocol and
recognize that other methods, such as SMART Backend Services, UDAP, or other trust community specified means, may be appropriate and easier to implement at scale. Payers will be
able to choose the protocols or combination of protocols they deem appropriate as long as they
meet the applicable security and privacy requirements.
Comment: Multiple commenters had concerns regarding FHIR due to the lack of mature
HL7 FHIR IGs and recommended that CMS instead advance payer to payerdata exchange by
leveraging the TEFCA QHINs. A few commenters recommended that CMS address the need for
a legal governance framework for payer to payerdata exchange. A commenter recommended
that CMS work with ONC and the TEFCA RCE to incorporate the payer to payer data exchange
use case into TEFCAs planned support for payment and operations exchange. The commenter
also recommended that CMS allow payers to comply with the Payer-to-Payer API requirements
by participating in TEFCA.
Response: We agree with the commenter that TEFCA can provide an efficient vehicle to
query, send, and receive standardized electronic health information (EHI) from a broad array of
participants enabling payer to payer data exchange. While standards and IGs for using FHIR
within a network like TEFCA are still maturing, the FHIR Roadmap for TEFCA Exchange
outlines the path for implementation. In addition, ONC and the RCE are currently developing the
requirements in Common Agreement Version 2.0 for FHIR-based exchange under TEFCA
across Exchange Purposes, including for Payment and Operations. ONC is aiming to publish
Common Agreement Version 2.0 in the first quarter of 2024. To the extent that the requirements
of this rule can be met through TEFCA exchange by the compliance dates, payers are permitted
to do so. However, as there are methods for exchanging data under TEFCA that do not comply
with the standards requirements we are finalizing (such as exchanging information using a
method other than a FHIR API), participation in TEFCA, including exchanging the required
data,does not necessarily mean that the payer is meeting the requirements of this rule.
We note that payer to payer data exchange is legally required under this final rule and as
such, legal agreements are not required. However, we understand that some payers may still request legal agreements. CMS is also working closely with ONC to explore how TEFCA could
potentially be leveraged to support scalable governance for payer to payer exchange.
Comment: Multiple commenters expressed support for CMS requiring the Bulk Data
Access IG. A commenter stated that this IG was designed to exchange population level data to
allow payers and providers to analyze care using the tools of big data analytics and for bulk
information exchange between payers and providers for populations covered under value-based
arrangements. A commenter stated it is critical to pace mandates with the development and
adoption of standards and that the Bulk Data Access IG is not finalized or adopted by HHS.
Another commenter stated that while the Bulk Data Access IG is the correct specification for
transferring large amounts of data between two payers, the IG is still evolving. A commenter
highlighted that the Bulk Data Access IG will require additional development efforts for their
organizations since it is new. Another commenter stated that the Bulk Data Access IG does not
include aspects that are relevantto the Payer-to-Payer API.
Response: In the ONC Cures Act final rule HHS adopted the Bulk Data Access IG at 45
CFR 170.215(d)(1). In the CMS Interoperability and Patient Access final rule (85 FR 25510), we
finalized a requirement to implement, maintain, and use API technology conformant with the
standards at 45 CFR 170.215, which includes the Bulk Data Access IG. In this final rule, we are
finalizing standards applicable for each API. Bulk data exchanges are usually used for system-to-
system use cases and allow large volumes of information on a group of individuals to be shared
in one exchange, which could be useful for sharing data between payers. Therefore, we feel that
the Bulk Data Access IG is relevant for the Payer-to-Payer API and is being finalized as
proposed.
Comment: Multiple commenters recommended blockchain based technologies be used
for the payer to payer data exchange. A commenter recommended that CMS support and
evaluate blockchain-based technologies for the payer to payer data exchange and recommended
that there needs to be confidence in the ability of blockchain-based technologies to leverage APIs for associated data movement. Another commenter recommended that CMS retain regulatory
flexibility to enable future data exchange opportunities, including the potential for permissioned
on-chain PHI access rather than an API call and response model.
Response: We acknowledge that there are a range of technologies that may facilitate
interoperability. In conjunction with ONC, we are working to establish standards that result from
the work of SDOs and have been generally agreed upon by the industry through consensus-based
processes. Blockchain technologies do not meet those criteria at this time, but we will continue
to monitor evolving technologies and their possible benefits for interoperability. In the
meantime, we are notprohibiting payers from using blockchain technology if they are doing so
in a way that meets their legal requirements.
Comment: Some commenters stated that payers, especially state Medicaid and CHIP
agencies, would need technical assistance with implementing the Payer-to-Payer API. Multiple
commenters stated that payers could use HIEs to implement the Payer-to-Payer API
requirements, including the opt in process, which would reduce the burden on payers.
Response: CMS has hosted, and intends to host in the future, CMS and HL7 FHIR
Connectathons, which are free for stakeholders to attend, as well as provide educational webinars
providing overviews of the technical requirements set forth in the interoperability rules.
Additional public resources also exist through HL7, such as HL7 FHIR Connectathons, HL7
website resources and HL7 FHIR workgroup meetings. We understand that some payers may
have implementation challenges and one of the reasons we are finalizing 2027 compliance dates
is to give impacted payers additionaltime to prepare and test any new processes they may need
to implement.
To the extent that it reduces burden, we encourage payers to partner with HIEs or HINs,
especially those operating under TEFCA, to facilitate payer to payer data exchange, subject any
other applicable laws governing privacy and disclosure of these data. Some HIEs may already
have the technical framework to manage patient consent or engage in standardized data exchange via FHIR APIs in ways that existing payer systems do not. Nothing in this rule would prohibit an
impacted payer from partnering with an HIE to meet its requirements. For instance, as HIEs may
have access to clinical data from providers that payers do not, some impacted payers may want
to contract with an HIE to host their required API, either as their repository for clinical data, or
as an intermediary with the payers own systems. The HIE could then augment payer data with
other clinical data they have access to in order to enhance the data available to via the Patient
Access, Provider Access, and Payer-to-Payer APIs, subject to other applicable law.
Comment: A commenter cautioned that CMSs proposals could result in each payer
building their own API, and each payer pulling data from every other payer within a state. A
commenter stated that it is not feasible for every clearinghouse to maintain so many non-standard
connections, and to do so would be costly and risky. The commenter stressed the urgency to
implement a National Data Warehouse Exchange Hub/Clearinghouse.
Response: Impacted payers will not have to maintain non-standard connections for this
payer to payer data exchange, as we are requiring impacted payers to use a FHIR API to support
interoperable implementations. We are requiring impacted payers to use the same standards
specifically so that connections between payers do not need to be hard coded but can rely on
the same technical standards to connect to any other payers endpoint. There is no requirement to
use a clearinghouse, but to the extent it could benefit payers, we encourage them to leverage
HIEs or HINs.
Comment: A commenter recommended that CMS resolve the technological infrastructure
dependencies by further investing in the HL7 FAST Accelerator and ONCs work to facilitate
patient matching and support implementation of the HL7 FAST Accelerator solutions to enable
scaled exchange through FHIR APIs. Another commenter recommended that CMS collaborate
with ONC to encourage industry adoption of the solutions outlined by the HL7 FAST
Accelerator, at minimum, identity resolution, security, and directory for the Payer-to-Payer API. Response: We will continue to work closely with ONC on the FAST Accelerator and will
seek to leverage any appropriate solutions being developed as part of this work.We are also
committed to continuing to work with HL7, the Accelerators, and interested parties within the
industry in defining, participating in, and convening testing events, as well as developing and
maintaining the specifications, thereby moving them toward greater maturity and will adopt
solutions as appropriate to our use cases as they mature.
b. Payer-to-Payer API Data Content Requirements
i. Data Content
We proposed to require impacted payers to implement and maintain a Payer-to-Payer API
to exchange claims and encounter data (excluding provider remittances and patient cost-sharing
information), all data classes and data elements included in a content standard at 45 CFR
170.213 (USCDI), and certain information about prior authorizations that the payer maintains
with a date of service on or after January 1, 2016. As stated in the proposed rule (87 FR 76255),
this set of data is consistent with requirements for the Patient Access API finalized in the CMS
Interoperability and Patient Access final rule (85 FR 2555) and our proposals for the Patient
Access and Provider Access APIs. Using the same data content standards across the APIs in this
final rule adds efficiencies for payers and maximizes the value of the work that has already been
done, reducing the overall burden for impacted payers.
In response to comments, we are finalizing our proposal, with modifications. We are
modifying the data content by excluding data related to denied prior authorizations. In addition,
we are also finalizing a modification by only requiring impacted payers to exchange data with a
date of service within 5 years of the request.
Comment: Many commenters expressed that using the same January 1, 2016, start date
for the set of data that must be exchanged via the Payer-to-Payer API would include significant
historical data that are unlikely to be relevant to a patients current health status and ongoing
care. Those commenters urged us to establish a rolling period of time to the date of the exchange for the data content that must be shared. Some commenters pointed out that the technical and
operational level of effort to integrate a patients full history would impose significant data
storage and archival costs on payers. Some commenters disagreed with CMSs justification for
the proposal that payers were the appropriate maintainer of a patients complete health history
and suggested that while payers had a role to play,patient apps could be a more efficient,
effective and reliable method to meet that objective.
Response: While we continue to support and emphasize the benefits of payer to payer
data exchange, we also recognize the burden of exchanging and storing large amounts of
complex patient data. There are two main benefits for Payer-to-Payer API data exchange: to
facilitate care continuity when a patient changes payers and to maintain the patients record so
that relevant information is not lost. After consideration of the comments, we agree that requiring
impacted payers to exchange a patients entire history back to the proposed January 1, 2016, date
would impose a significant burden on payers to integrate and maintain those data. In effort to
balance the benefits we described in the proposed rule, which were supported by commenters,
and the burden that some commenters raised, we are finalizing a modification to our proposal to
limit the payer to payer data exchange to only the previous 5 years of data.
As described previously, solutions are emerging in the marketplace for Personal Health
Records (PHR) that are better suited to keeping patient records for an indefinite period than
payers, which might themselves maintain limited clinical data. ONC defines a PHR as an
electronic application through which patients can maintain and manage their health information
(and that of others for whom they are authorized) in a private, secure, and confidential
environment.78 For instance, health apps can create a longitudinal record by gathering data both
from payers via the Patient Access API, and providers CEHRT. Even so, it is still important for
patient care and continuity for a patients new payer to receive and maintain some recent
78OfficeoftheNationalCoordinatorforHealthInformationTechnology(2016,May2).FrequentlyAsked
Questions.Retrievedfromhttps://www.healthit.gov/faq/what-personal-health-record. historical record of the patients care. When a patient changes payers, only the information that
the current payer maintains would be available via the Patient Access, Provider Access and
Payer-to-Payer APIs.
As payers and providers will have a more robust infrastructure for data exchange
(including via the FHIR APIs required in this final rule), they are better suited to enable data
exchange to providers and between payers than a patient would be with their PHR. A patient
could supplement information that their payer maintains with information from their PHR, but
should not have the primary responsibility for ensuring the technical capability to send their
records.
For continuity of ongoing care, we expect that the more recent data are, the more relevant
they generally would be. Therefore, it is important to establish a period of time that is reasonably
likely to include information relevant to foreseeable care after a patient changes payers. While
many commenters suggested shortening the timeframe for data to be exchanged, we did not
receive comments suggesting a specific period. Five years balances the needs to manage care
continuity and establish a patient record with their new payer while not being overly burdensome
on payers to exchange and maintain a large amount of data that may not be relevant. Being able
to keep the most recent 5 years of data when transitioning between payers will cover the vast
majority of a patients ongoing and future healthcare needs. Even for patients with chronic
conditions, data older than 5 years are unlikely to have significant relevance or value when more
recent information is available. This amount of data sharing strikes the right balance of limiting
the burden to payers, while still reaping the benefits of care coordination and continuity and
allowing patients to maintain a significant amount of data with their current payer.
However, we disagree with commenters who suggested limiting the data exchange to a
shorter period to focus only on current health conditions and ongoing care. We do not want to
narrow the scope of data to be exchanged to focus simply on care continuity. Health information
that is not relevant at the time a patient changes payers may later be important for the patient or their providers to have access to. Beyond the care continuity justification for payer to payer data
exchange, making a reasonable amount of patient data available, even if it is not the patients full
record, is still an important goal of this policy. For these reasons, and to better balance the
burden on payers and benefit to patients, we are finalizing a modification to our proposal to only
require the most recent 5 years of data be exchanged between impacted payers. We will monitor
the Payer-to-Payer API implementation and usage to determine whether to extend this timeframe
in the future.
For some patients, those 5 years of data may still comprise a significant quantity.
However, the data content requirements for the Payer-to-Payer API are built on structured data
standards, such asthe data classes and data elements included in a content standard at 45 CFR
170.213 (USCDI), which should be easily ingested using the recommended IGs. The exception
to that structured data is administrative and clinical documentation submitted by providers
related to prior authorization requests and decisions, as discussed laterin this section of this final
rule. We encourage impacted payers to review the PDex IG for guidance on ingesting patient
data in a structured manner that creates a useable patient record.79 We also note that CMS will
continue to work closely with ONC and other Federal agencies to improve data interoperability
through initiatives such as the USCDI+.
Comment: Multiple commenters recommended narrowing the scope of data that would be
exchanged via the Payer-to-Payer API. Some commenters suggested that CMS narrow the scope
of information required to be exchanged to specific data that would facilitate a change in
coverage. Other commenters recommended that CMS only require a minimum set of information
necessary to facilitate a patients transition and improve care coordination. Some commenters
recommended that CMS work with industry stakeholders to determine a subset of key coverage,
clinical, demographic, claims, and encounter information to share via the payerto payer data
79HealthLevelSevenInternational(2023,October28).DaVinciPayerDataExchange.Retrievedfrom
https://build.fhir.org/ig/HL7/davinci-epdx/. exchange to support coverage transitions. Another commenter expressed that the data exchange
should be limited to claims data and prior authorization decisions.
Response: We disagree with the view that the information sent via a Payer-to-Payer API
should be limited to a minimum set of data that would facilitate transition between payers and
continuity of ongoing care. While care continuity is one purpose of the Payer-to-Payer API, there
are use cases that benefit from additional information being sent. Specifically, we proposed to
include claims, encounter data and clinical data to maintain the availability of those data for the
Patient Access and Provider Access APIs after a patient changes payers. We acknowledge that a
patients historical data may notbe directly relevant to a patients care at the time of transition.
However, that does not mean thata patient or provider would never have a reason to access those
data.While the payer to payer data exchange has its use cases, the Patient Access and Provider
Access APIs have additional use cases. Therefore, it is important to consider not justhow a payer
would use data received from a previous payer, but how patients and providers may use it as
well. A patient should not lose access to their recent claims, encounter, or clinical data from their
payer because they are not strictly necessary to facilitate the transition to a new payer. As
discussed, we are finalizing a modification to our proposal to limit the data to be sent to that with
a date of service within 5 years of the request.
Comment: Multiple commenters provided recommendations regarding clinical data to be
exchanged. Some commenters stated that clinical information is not stored in a sharable format
for the Payer-to-Payer API. Specifically, a commenter discussed how current technology cannot
adequately parse through large, non-standardized files. The commenter noted that clinical
information sent by providers to payers is not received, structured, or stored in a way to be
shared, as the X12 275 transaction standard for healthcare claims attachments has not been
finalized (though a standard has been proposed in the HIPAA Standards for Healthcare
Attachments proposed rule (87 FR 78438)). In addition, a commenter recommended that CMS
work with ONC to implement a requirement that providers share comprehensive clinical data in a FHIR enabled format with patients and payers. Another commenter recommended that CMS
remove the requirement that impacted payers share all clinical information in USCDI and focus
on the clinical information that has been received in standard, electronic structured format related
to prior authorization. A commenter asked CMS to explain whether impacted payers only need
to make available via the API the USCDI data classes and data elements that they currently
maintain.
Response: We acknowledge that not all information that we are requiring to be made
available through the Payer-to-Payer API will be stored and maintained in a structured data
format within the payers systems. However, the benefits of ensuring that a patients data follow
them to a subsequent payer outweigh the burden of exchanging that information. In many
circumstances, clinical information can be significantly more informative than claims or
encounter information. For example, claims for laboratory tests will not provide the actual results
of those laboratory tests, which is more important than simply knowing that laboratory tests were
done without knowing what the results were. However, we know that many payers do not
maintain clinical data, or only maintain specific sets of clinical data and therefore claims and
encounter information can fill gaps that would otherwise be missing.
Our data content requirements for the Payer-to-Payer API are built on the existing
requirements for the Patient Access API. The set of clinical information that we have required to
be available via the Patient Access API since January 1, 2021, is defined by the USCDI standard
at 45 CFR 170.213. As discussed in section II.A.2.d. of this final rule, for clarity we are changing
the regulatory text to point directly to the USCDI standard at 45 CFR 170.213 for the Patient
Access API, as well as the new Provider Access and Payer-to-Payer APIs. Therefore, to the
extent a payer maintains those data, the data classes and data elements in USCDI should already
be in payerssystems in a form that makes them available via a FHIR API. Because payers
should already have experience making that set of information available, there should not be a
significant burden to make the same underlying data available through multiple APIs. Henceforth, with our revisions to directly reference the content standard at 45 CFR 170.213, the
Patient Access, Provider Access, and Payer-to-Payer APIs will all be required to include all data
classes and data elements within that content standard that are maintained by the payer.
We are not adding any requirements in this final rule that would require payers to parse
and convert unstructured files into structured data, either for their own records or to share via the
APIs. We also expect that as standards are adopted across the industry, an increasing percentage
of clinical data will be stored and transmitted in structured formats,which is a result we
encourage. We note, however, that unstructured administrative and clinical documentation
submitted by a provider to support a prior authorization request (excluding those for drugs and
those that were denied) are required to be sent through the Payer-to-Payer API.
Comment: A commenter recommended that the patients choice whether to opt into the
Payer-to-Payer API be part of the data exchanged.
Response: That piece of information is required as part of the attestation of patient opt in
and is discussed in more detail in section II.C.3.d.iv. of this final rule. If a patient does not opt in,
there would be no payer to payerdata exchange under these requirements.
Comment: A commenter recommended that CMS reduce the quantity of data that needs
to be exchanged by not requiring that denied claims be exchanged between payers.
Response: While some denied claims may be extraneous (such as a claim denied because
it is a duplicate), they may contain important information about a patient that would be beneficial
to their record. A claim, even if it is denied, can indicate that a patient received items or services,
even if the claim was not paid. Denied claims are also included in the information that is
currently required to be available via the Patient Access API (85 FR 25532). We did not propose,
nor are we finalizing, to exclude denied claims from the Payer-to-Payer API (or the Provider
Access API). However, as discussed in section II.C.3.b.iii., we are excluding denied prior
authorization requests from the set of information that must be exchanged between payers. Unlike claims, a denied prior authorization request does not indicate that the patient actually
received items or services and therefore an exclusion is justified, as discussed.
Comment: Multiple commenters stated that payers have already formatted the necessary
data elements and prepared their systems to share the standardized data through other FHIR
APIs. A commenter noted that this infrastructure can be adapted for expanded interoperability
use cases, such as the Payer-to-Payer API. However, another commenter believed that barriers to
implementing FHIR APIs exist in the way of process siloes in payer organizations.
Response: We appreciate the confirmation that payers have already formatted the
necessary data elements to be shared through other FHIR APIs, particularly the Patient Access
API. We agree that infrastructure can be adapted for this Payer-to-Payer API and are requiring
the same data classes and data elements already required for the Patient Access API. Payers have
already formatted these data elements and prepared their systems to share these standardized data
via a FHIR API. We note that the Payer-to-Payer API data content requirement also includes
both structured and unstructured administrative and clinical documentation submitted by
providers related to prior authorizations, of which the unstructured documentation is not required
to be shared through the Patient Access and Provider Access APIs. We also agree that payers
have already devoted the development resources to standing up a FHIR API infrastructure when
they implemented the Patient Access API, which could be adapted for expanded interoperability
use cases. Using the recommended IGs will reduce implementation barriers and we encourage
payers to getinvolved in the HL7 FHIR workgroups and to collaborate with other payer
organizations on these API implementations. In addition, we are delaying the compliance dates
to 2027 rather than the proposed 2026 not just to give payers time to implement the technical
requirements, but also to address any internal business process changes that may be necessary.
ii. Provider Remittances and Patient Cost-Sharing
We proposed to exclude provider remittances and patient cost-sharing information from
the Payer-to-Payer API because that information is often considered proprietary by payers. While there could be value to patients having provider remittances and patient cost-sharing
information available via the Patient Access API, exchanging those data between payers would
have only a limited beneficial impact on care. We believed that information about provider
remittances and patient cost-sharing under another payer would have no impact on a payers
ability to ensure care continuity when a patient changes payers. Furthermore, there are existing
processes for coordinating payment when a patient has concurrent payers that we did not wish to
affect. Sharing claims and encounter information, even without these cost details, would
complement the data classes and data elements included in a content standard at 45 CFR 170.213
(USCDI), by providing more information about the patients care history to support care
coordination and efficient operation.
Comment: Multiple commenters supported the exclusion of provider remittances and
patient cost-sharing information from the data shared through the payer to payer data exchange.
However, a few commenters noted that this policy could create additional development work if
payers need to segment data elements to make provider remittances and patientcost-sharing
information available via the Patient Access API, but not the Payer-to-Payer API (or Provider
Access API).
Response: We acknowledge that segmenting data could create additional burden for
payers. However, as discussed in the proposed rule, we proposed to not require provider
remittances and patient cost-sharing information be included in the data shared via the Payer-to-
Payer API because payers may consider that information proprietary. We agree that cost
information would have limited benefits to care continuity when a patient changes payers.
However, as our policy to exclude that information is intended to protect the payers proprietary
information, we are not prohibiting payers from sending it. Therefore, if a payer believes that
implementing their Payer-to-Payer API in such a way that includes provider remittances and
patient cost-sharing information would reduce burden, they are not prohibited from doing so.
iii. Prior Authorization Data We refer readers to section II.A.2.a. of this final rule where we discuss in more detail
how prior authorization data must be available through the Patient Access API  and therefore
through the other APIs as well. Our proposals to include prior authorization data in the Payer-to-
Payer API mirrored our proposals to include prior authorization data in the Patient Access and
Provider Access APIs. We stated that it would be valuable for payers to make certain
information about prior authorizations available via the Payer-to-Payer API, particularly when a
patient enrolls with a new payer. Prior authorization data can inform a payer about ongoing
treatments. Payers can use that information to determine whether a new patient needs a new prior
authorization, and, if so, whether the information from the previous payer is sufficient for them
to issue a decision without additional work by the patient or provider. Prior authorization is a
significant focus of this final rule as a whole, and information about these requests and decisions
could be beneficial to patients, providers, and payers. As discussed in more detail in section I.D.,
this finalrule does not apply to any prior authorization processes or standards related to any
drugs.
We discuss prior authorization and prior authorization processes in more depth in section
II.D. of this final rule. We proposed to add certain information about prior authorizations to the
set of data that impacted payers must make available via the Payer-to-Payer API upon request
from another payer. We proposed that the information must include:
 The status of the prior authorization;
 The date the prior authorization was approved;
 The date or circumstance under which the authorization ends;
 The items and services approved;
 The quantity used to date; and
 Related administrative and clinical documentation.
Comment: Many commenters generally supported including prior authorization
information in the Payer-to-Payer API and stated that this would increase transparency, improve care coordination, and reduce burden on providers, patients, and payers. Commenters stated that
including prior authorization data in the Payer-to-Payer API would protect beneficiaries access
to necessary items and services since information on prior authorization is not always transferred
when beneficiaries switch coverage today. A commenter stated that prior authorization
information would enable the new payer to provide continuous coverage for existing treatments
and highlighted that this is especially important for patients receiving cancer treatment and
specific medications after progressing through step therapies. Multiple commenters expressed
support for sharing historical data to increase payer knowledge of previous patient prior
authorization decisions and health care data, and to encourage continuity of care.
Response: We appreciate commenters concurring on the importance of previous payers
sharing authorization data. The prior authorization process is a priority area for us to reduce
patient and provider burden.
Comment: Multiple commenters recommended that some types of prior authorization
data should be excluded from the Payer-to-Payer API. A few commenters suggested that CMS
not require impacted payers to include information about prior authorizations without fully
understanding how payers could use that information. Commenters specifically recommended
that CMS exclude information about previously denied prior authorizations. A commenter noted
that this might be used to limit care for patients, even if they meet the new payers criteria for the
same service. Conversely, another commenter noted that there is some benefit to patients and
providers having a basic history of denied prior authorization requests.
Response: After considering the comments we received, we are removing the
requirement to include denied prior authorization decisions in the Payer-to-Payer API. However,
we note that supporting clinical information associated with such decision may be available
under the requirement to share all data classes and data elements included in the data content
standard at 45 CFR 170.213 (USCDI) that are maintained by the payer. As discussed previously,
we are focusing on the aspects of payerto payer data exchange that relate to care continuity when a patient changes payers. Because a previously denied prior authorization decision
generally would not reflect ongoing treatment, and thus the information may not support care
continuity, the value of including such information would likely be outweighed by the drawbacks
of doing so. A denied prior authorization decision does not provide information about the
patients ongoing care because it does not show that patients received any items or services. If a
patient did receive those items or services despite the denial of coverage, that information would
have to be gathered from elsewhere (such as clinical data), regardless of whether the payer
receives information about the denied prior authorization decision. However, we emphasize that
denied prior authorization decisions are required to be shared via the Patient Access and Provider
Access APIs because the benefits to those parties of accessing that information can be
significant, especially for resubmitting requests or appealing decisions.
However, this information could be used in ways that would negatively impact a patients
care or coverage. For example, information about a denied prior authorization decision could
potentially create bias in future prior authorization decisions with the new payer, and patients
could experience challenges to obtain coverage for a given service. Even if a previously denied
prior authorization does not in fact create bias with the new payer, some patients may fear that
result, which could lead to fewer patients opting in to payer to payer data exchange.
Comment: Severalcommenters recommended not including the quantity of services used
to date due to the concern that health plan claims data updates are often delayed and, therefore,
may notbe a reliable source to track the number of authorized services used to date. A
commenter recommended that CMS require only the authorized units of items and services for a
specific prior authorization, rather than the items and services used under the authorization.
Response: Upon reviewing comments, we agree with the many commenters who pointed
out that the authorized services used to date under a prior authorization may be more confusing
than useful for patients and providers. We heard that the quantity used to date would only be
available based on claims that have been submitted and adjudicated for those items or services. Because there can be a significant lag between the items or services being provided and the claim
being adjudicated, the information available through the APIs could be out-of-date and
inaccurate. Therefore, we are finalizing a modification to our proposal that will not require
payers to share the number of items or services used under the authorization. We are also
finalizing a modification to our proposals that this information does not need to be included in
the Patient Access API (discussed in section II.A.2.a.ii. of this final rule) or the Provider Access
API (discussed in section II.B.2.g. of this final rule).
Comment: Severalcommenters encouraged CMS to include unstructured documentation
and forms that were submitted as part of a prior authorization request. Some payers commented
that making that documentation available via the Payer-to-Payer API will facilitate their ability
to make prior authorization decisions for a new patients without requesting duplicative
information be submitted.Commenters stated that unlike in the Patient Access and Provider
Access APIs, sharing supporting documentation through the Payer-to-Payer API could allow the
new payer to use that information to make decisions about subsequent prior authorizations,if
required. A few commenters held the opposing view that CMS should not finalize requirements
to include clinical documentation and forms with prior authorization information via the Payer-
to-Payer API.
Response: We are finalizing a modification to our proposal for the Patient Access and
Provider Access APIs to remove the proposed requirement to make available unstructured
administrative and clinical documentation. We have concluded that for these APIs, the burden
outweighs the benefit. However, that is not the case forthe Payer-to-Payer API. One of the goals
of this regulation and the Payer-to-Payer API requirement is to promote greater continuity of
care when patients change payers, especially regarding prior authorization. In order for payers to
ease that transition, they need as much relevant data related to recent and ongoing care as
possible. For instance, current data can allow a payer to authorize coverage for ongoing treatment, without requiring repeat testing or needing a provider to resubmit clinical information
that the provider has already submitted to a previous payer.
In addition, the concerns regarding payers ability to quickly make the unstructured
administrative and clinical documentation available, via the Patient Access and Provider Access
APIs, do not apply to the Payer-to-Payer API. Under our Patient Access and Provider Access
API policies, payers have 1 business day from the time they receive the prior authorization
request or there is another status update to make prior authorization information available. For
the Payer-to-Payer API, absent a specific patient request, typically payers only have to exchange
data at the time a patient changes payers, or quarterly for concurrent payers. Therefore, unless a
prior authorization request is submitted within the last days of coverage, payers will have a
longer timeframe to ensure that unstructured documentation is included in the patients record
and can be transferred to another payer when the need or requirement to transfer data through the
Payer-to-Payer API arises. Furthermore, the concern about a patient app or providers EHR not
being able to read and display unstructured documentation does not apply to payers, which
regularly receive unstructured administrative and clinical documentation with prior authorization
requests.
Comment: A commenter suggested that given the complexity and variation across prior
authorizations, any pertinent data from peer-to-peer reviews should be included in Payer-to-
Payer API exchange.
Response: Based on comments and conversations with payers, we understand that many
payers consider the specific criteria they use to make prior authorization decisions to be
proprietary information. In addition, because payers have different criteria, information about
internal peer reviews of prior authorization requests from another payer has only limited
usefulness. Therefore, we are not requiring payers to exchange any documentation that the payer
itself generates regarding a peer-to-peer review of a prior authorization request. But we are
requiring impacted payers exchange structured and unstructured administrative and clinical documentation submitted by providers related to prior authorizations to assist care continuity and
allow payers to make their own decisions based on the patients specific needs without requiring
duplicative submissions from a provider.
iv. Duration of Prior Authorization Data to be Exchanged
We proposed that impacted payers would be required to make certain information about
prior authorizations available via the Payer-to-Payer API for the duration that the authorization is
active and for at least 1 year after the prior authorizations last status change. We proposed to
require the availability of prior authorization information for at least 1 year after any status
change across the Patient Access, Provider Access and Payer-to-Payer APIs, so that information
from denied and expired prior authorizations would not be lost when they were not approved or
no longer active.
Comment: Many commenters supported CMSs proposal that certain information about
prior authorizations be available for the duration of an active authorization and forat least 1 year
after the last status change. Some commenters were in favor of retaining a patients historical
prior authorization data indefinitely. Another commenter requested clarification on how the
proposal to make prior authorization data available for at least 1 year would align with the
requirement that impacted payers make available patient data with a date of service on or after
January 1, 2016.
Response: As discussed previously, we are finalizing a modification to our proposal that
will not require denied prior authorization requests to be shared via the Payer-to-Payer API at all.
Such information must be shared through the Patient Access and Provider Access APIs
beginning in 2027 (see sections II.A.2.ii. and II.B.2.g. of this final rule for more information).
We note that the requirement to share patient data with a data of service on or after January 1,
2016, comes from the CMS Interoperability and Patient Access final rule, which required claims,
encounter information and certain clinical data to be made available via the Patient Access API.
Prior authorization information was not included in that rule, and therefore, we do not have reason to believe that payers are generally maintaining prior authorization data back to that date.
In addition, the obligation to share encounter, claims, or other information from within 5 years of
the request is contingent on the payer maintaining those data; for payers that are not required to
maintain records past a certain point or that do not have internal policies for retaining records
past a certain time period, the data may not be available to be shared through the Patient Access
API. As discussed in the proposed rule, the availability of claims and clinical data are more
important to patient care than information about prior authorizations that have expired. Claims
and encounter data indicate items and services that the patient actually received in the course of
their care. Information from a prior authorization indicates whether certain items and services
were approved for coverage, and often the basis for that decision. While active or recent prior
authorization information is important because it can indicate current or recent medical
necessity, such information cannot be inferred from prior authorizations that have been expired
for more than 1 year as they would not indicate any sort of ongoing care. Claims and clinical
data maintained by the previous payer that are related to the treatment that occurred under an
expired prior authorization would replace the need for the expired prior authorization decision
itself. While claims and clinical data associated with an expired prior authorization can indicate
the type of care received, as discussed earlier in this section, the value to a new payer of prior
authorizations that were not acted upon, meaning they do not have a claim or any clinical data
associated with them and are not associated with any past treatment or active care for the patient,
is outweighed by the potential drawbacks of including such information. We also considered
comments summarized previously and also discussed in sections II.A. and II.B. of this final rule
regarding the inclusion of these data in the Patient Access and Provider Access APIs. While
some API content differences may be beneficial or practical (such as the exclusion of provider
remittances and patient cost-sharing information), we are keeping the API requirements as
similar as possible to reduce burden by standardizing data content. We emphasize that for
ongoing long-term care, any active prior authorizations mustbe included, even if they have been in that status for more than 1 year. Furthermore, our policy allows payers to make these prior
authorization data available for longer than 1 year, if they believe it adds value to patients,
providers, themselves or future payers.
v. Considering Prior Authorizations from Another Payer
While we did not propose to require payers to review, consider, or honor the active prior
authorization decision of a patients former payer, payers may gain efficiencies by doing so. We
sought comment on the benefits, burdens and considerations of imposing such a requirement.
However, we did not make any proposals and therefore are not finalizing any policies in this
area. We do note that since we published the proposed rule, the Medicare Program; Contract
Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare
Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive
Care for the Elderly final rule (CY 2024 MA and Part D final rule) was issued, which requires
MAcoordinated care plans to provide a minimum 90-day transition period when an enrollee
switches to a new MA organization, during which the new MA organization may not require
prior authorization for an active course of treatment.
Comment: A commenter requested clarification about the relationship between this final
rule and the provision for MA plans at 42 CFR 422.112(b)(8)(i)(B) added by the CY 2024 MA
and Part D final rule. That rule requires MA coordinated care plans to provide a minimum 90-
day transition period when an enrollee switches to a new MA organization during which the new
MA organization may not require prior authorization for an active course of treatment.
Response: The requirements at 42 CFR 422.112(b)(8) adopted in that recent final rule
apply to PartA and B benefits covered by an MA plan. An active course of treatment is
defined at 42 CFR422.112(b)(8)(ii) as a course of treatment in which a patient is actively seeing
a provider and following a course of treatment, which is defined as a prescribed order or
ordered course of treatment for a specific individual with a specific condition, outlined and
decided upon ahead of time with the patient and provider. A patient can have an active course of treatment to which 42 CFR 422.112(b)(8) will apply that did not require prior authorization by
their previous payer.
Per 42 CFR 422.112(b)(8)(i)(B), MA organizations offering coordinated care plans must
have, as part of their arrangements with contracted providers, policies for using prior
authorization that provide for a minimum 90-day transition period for any active course(s) of
treatment when an enrollee has enrolled in an MA coordinated care plan, even if the course of
treatment was for a service that commenced with an out-of-network provider. Further, the MA
plan cannot deny coverage of such active courses of treatment on the basis that the active course
of treatment did not receive prior authorization (or was furnished by an out-of-network provider)
but may review the services furnished against the MA plans coverage criteria when determining
payment. This includes enrollees who are new to an MA plan, an enrollee switching from
Traditional Medicare to MA, or enrollees new to Medicare and enrolling in an MA plan for the
first time.
In that final rule, we explained how we expect any active course of treatment to be
documented in the enrollees medical records so that the enrollee, provider, and MA plan can
track an active course of treatment to avoid disputes over the scope of the new requirement.
Therefore, an active course of treatment should be included in the data exchanged between
impacted payers, regardless of whether a previous payer required a prior authorization. Under
this finalrule, the data content that must be shared via the Payer-to-Payer API includes the
claims and encounter data (excluding provider remittances and cost-sharing data), all data classes
and data elements included in a content standard at 45 CFR 170.213 and certain information
about prior authorizations maintained by the payer with a date of service within 5 years of the
request. Almost any active course would be represented within that dataset. Any active course of
treatment covered by 42 CFR 422.112(b)(8)(i)(B) will thereby become part of the patients
record with their new payer. It is important, especially in light of 42 CFR 422.112(b)(8), that MA
enrollees are aware that their active course of treatment is being honored and for how long. That will allow MA enrollees in plans subject to this new requirement, and their providers, to plan for
a new prior authorization request, if necessary.
Although this particular need for access to information about active courses of treatment
is unique to MA enrollees in MA coordinated care plans, the data exchange and Payer-to-Payer
API requirements outlined here are applicable to any impacted payer. While we encourage other
payers to honor an active course of treatment similar to the requirements of42 CFR
422.112(b)(8) for MA coordinated care plans, we have not proposed to require that of any payers
not covered by that rule.
c. Identifying Previous and Concurrent Payers and Opt In
i. Process Timing
We proposed that all impacted payers develop and maintain processes to identify a
patients previous/concurrent payer(s) and to allow patients or their personal representatives to
opt into the payer to payer data exchange (both with previous and concurrent payers) prior to the
start of coverage. Additionally, we proposed that impacted payers would be required to establish
similar processes for current patients prior to the compliance dates, to ensure those patients have
the ability to opt in and have their data shared through the API. We are finalizing a modification
to this proposal, as discussed, to establish a deadline for these processes at 1 week after the start
of coverage (as that term is defined for each program).
We emphasized in the proposed rule that obtaining a patients opt in permission and
identifying the previous/concurrent payer(s) could not delay an applicants eligibility
determination or start of coverage with any impacted payer. We noted that the proposed
requirement to identify a patients previous/concurrent payer(s) and obtain a patients opt in may
not always be feasible before the start of coverage, for instance, if a patient does not provide
enough information to identify their previous payer. We emphasized that payers must begin this
process before the start of coverage, but realize that it may take longer than enrollment. In that
case, the impacted payer would be required to continue to engage with the patient to gather their permission and identify any previous/concurrent payer(s). Only once the impacted payer has
received permission and identified those other payers would they be required to request patient
data,as outlined in sections II.C.3.c.ii. and II.C.3.c.iv. of this final rule. Using Medicaid as an
example, if a state has all the information necessary to determine an individuals eligibility
before it has identified the previous payer, the state must determine the individuals eligibility
and enroll the individual in Medicaid coverage, if determined eligible, while continuing to follow
the Payer-to-Payer API requirements as expeditiously as possible post-enrollment.
For new patients enrolling on or after the compliance dates, we proposed to require
impacted payers to maintain a process forpatients to opt into the Payer-to-Payer API data
exchange and to identify their previous/concurrent payer(s) prior to the start of their coverage. In
section II.C.4.b. of this final rule, we discuss the possible incorporation of these requirements
into state applications for Medicaid or CHIP eligibility. In the proposed rule, we stated that
making this process available to patients during the enrollment process, or immediately
thereafter, would allow the proposed data exchange to take place as quickly as possible once the
patient is enrolled with the new payer. For example, where there may not be communication
during the enrollment process such as during the QHP enrollmenton the FFEs, this process
should be done immediately following enrollment. We solicited comment on incorporating the
proposed requirements into the FFE QHP enrollment process as described at 45 CFR 156.265.
Concurrent coverage means that an individual has coverage provided by two or more
payers at the same time. This could include, for example, individuals dually eligible for
Medicare and Medicaid who are enrolled in both an MA plan and a Medicaid managed care plan.
Another example of concurrent coverage is when different services are covered by different
Medicaid managed care plans for the same Medicaid beneficiary.
Several payer deadlines in this rule are based on a patients start of coverage. For
example, we proposed (and are finalizing) a requirement for impacted payers to request previous
and concurrent payer information and a patients opt in for Payer-to-Payer API data exchange (discussed in section II.C.3.c.iv. of this final rule) no later than 1 week after the start of coverage.
Throughout the preamble, we are using the term start of coverage to mean when coverage
begins or, if coverage begins retroactively, to refer to a later milestone, depending on the payer
type. However, to ensure feasible timeframes for new patients after the compliance dates, we are
finalizing deadlines based on whether coverage starts prospectively or retroactively. Where
coverage starts prospectively, the deadline will be based on the coverage start date (also known
as the coverage effective date). In the case of retroactive coverage, to avoid a deadline in the
past, the deadline for the payer to provide the required information about the Payer-to-Payer API,
request identifying information about previous/concurrent payer(s), and an opt in will be based
on the date that the payer gets patient information and makes the patients coverage effective.
Because the enrollment and coverage initiation processes for each program differ in their
specifics, in regulation text, the concept of start of coverage is described differently for each
type of impacted payer. That is, the regulatory text uses different, program-appropriate
terminology for each impacted payer.
For MA organizations, the start of coverage generally means the effective date of
coverage, as used at 42 CFR 422.68. In some instances, an individuals enrollment may be
accepted by CMS with a retroactive effective date of coverage, as discussed in the Medicare
Managed Care Manual, Chapter 2, section 60.4.80 In those cases, the start of coverage would
be the date that the individuals enrollment is accepted by CMS.81 Effectively, this means that
the start of coverage is whichever is the later of those two datesthe effective date of
coverage or the date that the individuals enrollment is accepted by CMS.
For example, an MA organization that receives an enrollment request from an individual
that is accepted by CMS in January for a February 1 effective date of coverage, would have 1
80CentersforMedicareandMedicaidServices(2011,August19).MedicareManagedCareManual.Retrievedfrom
https://www.cms.gov/files/document/cy-2024-ma-enrollment-and-disenrollment-guidance.pdf.
81SeealsoMedicareManagedCareManual,Chapter2,section40.4.2.forsimilarenrolleenotificationrequirements
tiedtothedatethattheindividualsenrollmentisacceptedbyCMS. week from February 1 to complete the applicable requirements. An MA organization that
receives an enrollment request from an individual in January that is accepted by CMS on
February 7 for a retroactive February 1 effective date of coverage, would have 1 week from
February 7 (not February 1) to complete the applicable requirements as finalized in this rule.
For Medicaid, a beneficiarys coverage is generally retroactive 3 months from the date
that they are enrolled in Medicaid. For CHIP, retroactive coverage varies among states.
Therefore, for Medicaid and CHIP FFS and managed care, the start of coverage is simply the
date the beneficiary is enrolled in the states MMIS (or equivalent process), not the date coverage
takes retroactive effect.
For QHP issuers on the FFEs, the start of coverage is generally the enrollees QHP
coverage start date. In some cases, a payer may provide coverage retroactively, that is, a payer
provides coverage starting on a date prior to enrollment, for instance due to the birth, adoption,
or foster care placement of a new child. In that case, the start of coverage would be the
effectuation of coverage, as described at 45 CFR 155.400(e)(1)(iii). Effectively, this means the
start of coverage is whichever is the later of those two dateseither the coverage start date or
the effectuation of coverage. We refer to the coverage start date as the first date for which the
enrollee has coverage and the term effectuation of coverage to refer to the date that the payer
takes the steps to implement coverage, even if that coverage starts retroactively.
For example, an FFE QHP issuer that receives enrollee information during an annual
open enrollment period for a consumer whose coverage will start on January 1 of the following
year would have 1 week from the enrollees coverage start date of January 1 to complete
applicable requirements. An issuer that receives information and effectuates coverage on March
6 for an enrollee whose coverage starts retroactively on February 1 would have a week from the
enrollees effectuation date, March 6 (not February 1), to complete the applicable requirements.
Comment: Multiple commenters expressed concern regarding processes for opting in and
collecting previous/concurrent payer data occurring at the start of coverage, noting logistical challenges to collecting data at the time of a patients enrollment, including document format and
regulatory challenges to updating existing enrollment forms. Multiple commenters provided
recommendations regarding actions for payers to take at the time of enrollment to facilitate
collecting this information, such as defining specific data and updating enrollment forms.
In addition, multiple commenters stated that payers should be permitted to collect a
patients opt in after enrollment. A commenter specifically recommended that collection should
be allowed during the first month of active enrollment. Some commenters urged CMS to not
require payers to collect data at enrollment to support the Payer-to-Payer API, and instead to
allow outreach to patients after enrollment through existing tools, such as payer portals. Another
commenter stated that requesting that information at the time of the patients application would
allow them to incorporate the process into their existing data collection processes. A commenter
noted that the inability to opt in after the enrollment start date could result in low participation
rates. Another commenter supported allowing patients to opt into data sharing during the open
enrollment period. A commenter supported allowing a payer to collect a patients opt in prior to
the compliance dates for state Medicaid and CHIP agencies and prior to enrollment of new
beneficiaries after the compliance dates.
Response: We note that the terms used in the preamble and regulation text of our
proposed rule were different. Our discussions in the proposed rule referred to prior to the start
of coverage, which we explained in preamble and fully discussed throughout the proposed rule,
but the proposed regulation text used the phrase at enrollment (except for QHP issuers on the
FFEs where we used no later than the effectuation of enrollment). We did not propose that new
payers collect previous payer information at the time of enrollment. We stated that payers must
begin the process of collecting the previous payer information and opt in prior to the start of
coverage, but that it may take longer than the enrollment process. We are modifying the
regulatory text to identify the start of coverage (rather than enrollment) as the milestone that tolls
these requirements, consistent with the preamble discussion in the proposed rule. However, in response to public comments, we are finalizing a modification to our
proposal by extending the deadline for both requesting identifying information about a patients
previous/concurrent payer(s) and seeking opt in from the patient to 1 week after the start of
coverage, with certain differences among payers. For MA organizations, we are modifying the
deadline to no later than 1 week after the coverage start date or no later than 1 week after
receiving acceptance of enrollment from CMS, whichever is later. In the case of Medicaid and
CHIP FFS, we are modifying both deadlines to refer to 1 week after enrollment, to avoid
confusion related to the retroactive eligibility rules in Medicaid. For QHP issuers on the FFEs,
we are modifying the requirement to no later than 1 week after the after the coverage start date or
no later than 1 week after the effectuation of coverage, whichever is later. Commenters were
clear that establishing the start of coverage as the deadline for these actions would result in
logistical challenges and compliance would be difficult for impacted payers. We understand that
while some types of impacted payers, such as MA organizations, may have contact with patients
before the start of coverage, in other cases, payers do not. Furthermore, while we are
recommending that state Medicaid and CHIP agencies incorporate these requirements into their
applications for coverage, states would have few other options for communicating with patients
before enrollment (which is how start of coverage is captured in the regulation text for
Medicaid and CHIP).
We emphasize that payers must begin the process of collecting the previous/concurrent
payer information and opt in no later than 1 week after the start of coverage but understand that it
may notbe completed within that timeframe. We believe it is important to gather this
information from patients as soon as possible when a patient enrolls with a new payer in order to
facilitate the timely exchange of patient data. Patients may take additional time to respond or
follow-up may be required. Impacted payers are encouraged to make a reasonable effort to
engage with patients to gather their permission and identify any previous/concurrent payer(s).
We rely on payers to develop reasonable processes to follow up with patients, and recommend payers follow-up one time before determining that the patient is choosing not to opt in. Though
not required, we encourage payers to build into their request process a method for patients to
indicate that they do not want to provide the requested information, so that payers need not
follow up with them. We note that the patient education requirements, discussed in section
II.C.3.g. of this final rule, will provide patients annual reminders of the payer to payer exchange
functionality. Under this final rule, patients must be able to opt in or withdraw permission at any
time.
The opt in and identifying previous/concurrent payers processes could include using
existing portals to gather this information from patients, as we are not being prescriptive on how
each payer implements this process. We also encourage stakeholders to participate in HL7 FHIR
workgroups to collaborate with other industry stakeholders on identifying best practices and
identifying possible processes.
ii. Gathering Previous and Concurrent Payer Information
We proposed that impacted payers would be required to gather information about
patients previous/concurrent payer(s) that would allow them to identify and request data from
those payers. That could include the payers name and a patient ID number or similar identifier.
Under our proposal, an impacted payer would be required to allow a patient to report multiple
previous/concurrent payers if they had (or continue to have) concurrent coverage. In this
circumstance, we proposed that impacted payers would be required to request the patients data
from allprevious/concurrent payers.
Comment: Multiple commenters expressed concern with the lack of a standardized
process to identify a patients previous/concurrent payer(s) and recommended that CMS either
establish a policy to identify the payers,provide technical assistance on how to crosswalk unique
identifiers, or standardize elements of the process. A commenter highlighted that the lack of
clarity on how payers are to identify a patients previous/concurrent payer makes the Payer-to-
Payer API difficult to operationalize and would likely introduce errors. Multiple commenters recommended additional changes to the enrollment process to support data exchange via the
Payer-to-Payer API. A few commenters recommended that CMS work with stakeholders to
develop a specific process to collect this information. A commenter urged CMS to reinforce to
payers that they should make the processes as easy as possible for patients by leveraging
touchpoints that the patient would already be engaged in to enroll and initiate new coverage.
Response: Because the requirements for a Payer-to-Payer API and the need to collect
information about previous or concurrent coverage forpatients crosses many payer programs
with variation between enrollment processes, we determined that being prescriptive on a specific
process would cause more implementation burden than necessary. In response to comments, we
are finalizing a modification to our proposal to require payers to request previous and concurrent
payer information no later than 1 week after the start of coverage. As discussed previously,
payers might not have contact with patients before enrollment. Therefore, this modification will
allow additional time for payers and broaden the range of options for payers to align with their
current processes. Initial implementation may be challenging; however, it is important that
patients data are shared as they transition care to a new payer, because the benefits for patients
outweigh the upfront implementation burden. Leaving the process open for payers to implement
in the least burdensome, most practical way to gather the information from patients makes the
most sense. Gathering previous payer information and an opportunity for the patient to opt in
ideally should take place through an already established point of contact with the patient.
Leveraging established points of contact will reduce patient burden and help impacted payers
meet the deadline of no later than 1 week after the start of coverage. In particular, payers often
have existing processes to identify concurrent payers to facilitate coordination of coverage and
Medicare Secondary Payer/Third Party Liability administration. For instance, per 42 CFR
422.108, MA organizations are required to identify payers that are primary to Medicare and
coordinate its benefits to Medicare enrollees with those primary payers. State Medicaid programs
are required to collect sufficient information to enable the state to pursue claims against such third parties when making an eligibility determination or redetermination per section 1902(a)(25)
of the Act (for beneficiaries enrolled in managed care, states generally make this the
responsibility of the MCO with state oversight). That requirement also applies to state CHIP
programs by cross reference at section 2107(e)(1)(B) of the Act. Nothing in this rule would
prevent payers from using that information for both that purpose and to identify concurrent
payers for Payer-to-Payer API data exchange. However, patients would still need to opt in for
payers to proceed with requesting patient data via the Payer-to-Payer API.
Comment: A few commenters requested clarification on whether the definition of
previous payer is limited to the immediately previous payer or to previous payers within a
specific time period, such as within the last5 years.
Response: The minimum requirement is only to request information from the
immediately previous payer, however if a patient does report multiple previous payers, impacted
payers are required to request that patients data from any previous/concurrent payers (identified
to or known by the impacted payer) within the required 5-year period. We are finalizing that
policy because patients may have been enrolled with payers that are not subject to the
requirements of this rule. Therefore, allowing patients to have their impacted payers requestdata
from payers other than their immediately previous payer within the 5-year timeframe could
maintain as much of their record as possible.
Comment: A commenter suggested that CMS include a process for new payers to inquire
whether the previous payer supported the Payer-to-Payer API described in this regulation, such
as a monitored email address, and that some type of consequence for non-compliance should be
levied.
Response: In section I.D. of this final rule we discuss an NDH that could serve as a
centralized place for payers to find other payers digital endpoints and identify payers that
support the Payer-to-Payer API. Without an NDH or similar source of information, payers would
likely be required to contact the previous payer directly to determine if they support the Payer-to- Payer API. We are also exploring other solutions, such as using TEFCA, that could be leveraged
to determine if the previous payer supports the Payer-to-Payer API. We have addressed program
enforcement and compliance mechanisms in section I.D.2. of this final rule, as well, and
appreciate public interest in mechanisms for provider and patient appeals and complaints,
oversight, and assurance of compliance.
Comment: A commenter noted that a payers ability to request data from a previous payer
would be dependent on the patient providing accurate information about the previous payer. The
commenter expressed concern regarding the accuracy of this information and the effort required
for necessary follow-up.
Response: As discussed previously, we acknowledge that the obligation to exchange data
is contingent on patients supplying the necessary information about previous/concurrent payers.
An impacted payer cannot comply with these requirements if the patient has not provided timely
or accurate information about their previous/concurrent payer. We emphasize that payers must
request this information no later than 1 week after the start of coverage, but that it may take
longer than that to obtain information from the patient. If the patient does not respond or
additional information is necessary, the impacted payer must make reasonable efforts to obtain
their response to the opt in request and to identify any previous/concurrent payer(s).
Comment: Severalcommenters suggested data elements that would be necessary or
extraneous to make that Payer-to-Payer API request. Multiple commenters encouraged including
the patients name, patients previous/concurrent payer name, member ID, date of birth, physical
address, and phone number in a payers data request to a previous payer. Multiple commenters
urged payers not to require patients to provide the specific plan name, which may be long and
unintuitive and because patients may have switched plans over time with that payer. A
commenter expressed security concerns with exchanging Social Security numbers (SSNs) and
suggested that their use be as limited as possible. Another commenter suggested that patients should be encouraged to provide the dates coverage started and ended or information about up to
three recent services covered by the previous plan and those dates of service.
Response: We agree with commenters that demographic information such as patients
name, member ID, date of birth, physical address and phone number are appropriate pieces of
information to identify patients. We also agree that SSNs should be used to identify patients only
when necessary (and permissible by law) due to that identifiers sensitivity. While start and end
dates of coverage may be useful in some instances, patients are unlikely to know or remember
those exact dates, nor are they likely easy to find. Therefore, we discourage their use for
identifying patients. Asking a patient to provide information about recent services covered by the
previous payer could be burdensome to a patient. Patients are unlikely to have that information
without gathering it from their previous payer. Therefore, there are less burdensome ways to
effectuate this process, such as by using the data elements mentioned previously. Payers should
implement these requirements in such a way that accomplishes the goal of identifying patients
previous/concurrent payer(s) with the least burden on patients.
The data elements that a payer may need to identify a patient and match that patient to
their record are included in the required and recommended standards for the Payer-to-Payer API.
Specifically, the required US Core IG and the recommended PDex IG have Must Support
fields (meaning that the system must be able to support those data elements) that could be used
for identifying a patient, such as patient name, addresses, birth sex,gender, birth date, member
and subscriber identifiers, and group number. Requesting payers should use those fields to
identify the patient whose data they are requesting. If the information provided is insufficient to
make a match, or it matches with more than one member, an error should be returned. Payers
will need to use a combination of data elements to support patient matching, as they do today
with any data exchange. We also will continue to work with ONC and share information on their
patient matching research/initiatives here:
https://www.healthit.gov/topic/interoperability/standards-and-technology/patient-identity-and- patient-record-matching. We encourage payers to leverage the appropriate patient matching data
elements of the IGs and we will continue to work on ONC on their patient matching research and
initiatives.82
Comment: A commenter suggested the need for a national Health Plan ID (HPID) to
identify a patients previous/concurrent payers. The commenter requested that CMS re-work and
re-issue required standards for a national HPID. A commenter also stated that the process would
benefit from establishing technical standards to ensure that all payers are using the same data
elements to verify a patients payer(s).
Response: We acknowledge industrys interest in a national standard for a payer
identifier. We are aware that there are a few alternative standards used in transactions today,
which are located on member ID cards and maintained in payer systems. For example,the Payer
ID, used in Electronic Data Interchange (EDI) transactions, is a unique ID assigned to insurance
companies to enable them to communicate with each other to verify eligibility, coverage,
benefits and submit claims. CMS also maintains a Plan ID for all QHPs on the FFEs, which are
14 alphanumeric characters. Until and unless a national standard is adopted, industry may wish
to collaborate with the SDOs on an appropriate payer identifier for the APIs.
Comment: Severalcommenters raised the concern that for QHPs, the X12 834 transaction
standard for health plan enrollment and disenrollment from the FFEs does not currently carry
previous payer information, complete information on concurrent payers, member IDs, or opt in
needed to support the payer to payer data exchange during QHP enrollment. A commenter also
raised concerns about situations where a patient begins the QHP enrollment process but does
make the binder payment, and therefore ultimately does not effectuate their coverage.
Response: Requiring payers to gather this information could result in a more streamlined
approach than incorporating it into the X12 834 transaction standard enrollmentprocess, given
82OfficeoftheNationalCoordinatorforHealthInformationTechnology(2022,September8).PatientIdentityand
PatientRecordMatching.Retrievedfromhttps://www.healthit.gov/topic/interoperability/standards-and-
technology/patient-identity-and-patient-record-matching. that FFEs are not otherwise required to use or retain the information. However, as discussed
previously, we are finalizing a modification to our proposal to account for the timing of QHP
coverage effectuation relative to plan selection, which impacts when a QHP can reasonably
obtain information from an enrollee. Specifically, QHP issuers on the FFEs will be required to
provide enrollees or their personal representatives with an opportunity to opt into the QHP
issuers Payer-to-Payer API data exchange no later than 1 week after the coverage start date or
the effectuation of coverage, whichever is later. This timeframe accounts for the date on which
an issuer has confirmation that an individual will be enrolled in QHP coverage with the issuer,
by receiving the binder payment that is required to effectuate coverage per 45 CFR 155.400(e),
as well as instances in which coverage takes effect retroactively.
iii. Currently Enrolled Patients
We proposed that no later than the compliance dates for the Payer-to-Payer API,
impacted payers must establish and maintain a process to gather permission and identify
previous/concurrent payer(s) from allpatients who are currently enrolled.
Some payers may want to have a soft launch, rolling implementation, or pilot for their
Payer-to-Payer API before the compliance dates. We therefore tied our proposal to require
impacted payers to gather permission from currently enrolled patients to the proposed 2026
compliance dates, rather than when a payer implements its API. We stated that this would allow
payers to sequentially target specific plans, populations, or enrollee categories for operational
rollout, as long as all currently enrolled patients are given the opportunity to opt into the payer to
payer data exchange by the compliance dates.
We received no comments on this proposal. In alignment with the modified compliance
dates discussed throughout this final rule, the requirements to request currently enrolled patients
opt in permission and previous/concurrent payer information will be tied to the 2027 compliance
dates we are finalizing for the Payer-to-Payer API.
iv. Opt In We proposed an opt in approach for the data exchange through the Payer-to-Payer API.
We stated that an opt in framework means that the patient or their personal representative would
need to affirmatively permit a payer to share data, and without that permission, the payer could
not engage in the proposed payer to payer data exchange for that patient. We noted that this
permission (or lack thereof) would apply only to the data exchange we proposed and would not
satisfy any other obligations required under the HIPAA Privacy Rule or other law. Additionally,
we stated that we believed patients themselves are the best source for sufficient and accurate
information necessary for the payer to make the request. Should a patient choose to provide this
information, it would require an affirmative act from the patient, so we stated that the burden of
asking a patient to opt in would not create a significant additionalbarrier to patient participation.
We also proposed to require impacted payers to have a process for patients to opt into this data
exchange at any time after the start of coverage, or if they have already opted in, to withdraw that
permission at any time.
As discussed in section II.C.4.c.of this final rule,this opt in requirement does not apply
to data exchanges between a state Medicaid or CHIP program and its contracted managed care
plans or entities. We also proposed that states, through their Medicaid and CHIP programs,
would be responsible for collecting a patients choice to opt into the payer to payer data
exchange, rather than their contracted managed care plans. We explained that a Medicaid or
CHIP beneficiary may switch between FFS and managed care delivery systems within the same
states Medicaid or CHIP program, but despite these shifts, an eligible beneficiary remains a
beneficiary of the state program. States may also change the managed care plans that they
contract with. Thus, we proposed that the patient permission for this data exchange, as a
Medicaid or CHIP beneficiary, would be obtained by the state and would apply regardless of the
delivery system in which the beneficiary is enrolled.
In contrast, our policy for the ProviderAccess API will allow payers to exchange patient
data with providers unless a patient has opted out. We proposed an opt out policy for the Provider Access API, in part, based on the existence of a treatment relationship between the
patient and provider, a contractual relationship between the payer and the provider, and a
coverage relationship between the payer and patient.Specifically, our policy to only require the
Provider Access API data exchange with providers in the payers network and require a process
to attribute a patient to that provider before data can be exchanged creates a level of assurance
for the payer that it is sending patient data to an appropriate party. Two payers exchanging
information may not have a direct relationship, but would be exchanging data based on a
patients separate relationship with each payer. Therefore, in the proposed rule, we stated that it
would make sense for the patient to have a larger gatekeeping role for the Payer-to-Payer API.
Comment: Many commenters expressed support for the proposed policy to require
patients to opt into the Payer-to-Payer API. Commenters provided various rationales for their
support. Multiple commenters stated that the opt in approach would give patients greater access
to and control over their information. Other commenters appreciated that the opt in approach
protects patient privacy. Some commenters noted that the opt in approach would be easy for a
payer to implement when a patient is a new beneficiary or enrollee because the payers
relationship with the patient is new and active and the payer can requesta patients opt in at the
same time as the payer requests the patients previous/concurrent payer information. A
commenter noted that the Payer-to-Payer API is particularly well suited for an opt in approach
because it is usually a one-time or time limited exchange (unless concurrent payers are
involved).
Response: We appreciate commenters feedback in support of an optin policy and are
finalizing this policy as proposed.
Comment: Some commenters voiced concerns about an opt in approach. Multiple
commenters expressed concern that an opt in approach will resultin lower rates of patient
participation in the payer to payer data exchange. Multiple commenters recommended that CMS
adopt an opt out approach for the Payer-to-Payer API instead of an opt in approach. Primarily, commenters agreed that an opt out framework would lead to more patient participation and more
data available for the new payer, any new network providers, and patients themselves. A
commenter was concerned that patients may be confused by the opt in process and recommended
providing clear directions to patients detailing how and when patients can optinto data sharing.
Response: We agree that an opt in approach often results in fewer data exchanges than an
opt out policy. However, increased data exchange is not necessarily the goal of our policy unto
itself, but a process to facilitate improved care. We believe that patients, as they are the owners
of theirdata, should have control over who has access to their data, especially when the two
parties exchanging patient data do not have a direct relationship with each other, as in the case
with payer to payer exchange versus the Provider Access API where the payer and provider have
a network contract. However, we know that the more data available, the more informed decisions
about care can be. Patients should see value in having their data exchanged between their
previous/current payer(s) and their new payer. As discussed in section II.C.3.g. of this final rule,
impacted payers will be required to provide plain language information to patients informing
them of the benefits of payer to payer data exchange and directions for opting in.
Comment: A commenter recommended that CMS better explain the length of time that an
opt in election is valid.
Response: The patients opt in election is valid indefinitely with that payer unless the
patient decides to withdraw their permission at a later time.
Comment: Multiple commenters requested clarification on the implications of a patient
choosing not to opt into the data exchange via the Payer-to-Payer API. Specifically, a commenter
agreed that the information proposed for the Payer-to-Payer API can be shared only if the patient
opts in, however, requested clarification on how payers could meet obligations to exchange these
patients data for other purposes.
Response: Patients have a choice about whether they want their data shared under this
policy as they transition between payers. If a patient chooses not to opt into the data sharing, data will not be exchanged between payers under the requirements in this final rule. However, payers
may exchange information without a patients authorization for other purposes, such as benefit
coordination in the case of concurrent payers, or for other permissible reasons under the HIPAA
Privacy Rule. There is nothing in this rule that would prohibit payers from using the Payer-to-
Payer API as the mechanism for data exchange permissible under other authority, even if the
patient has not opted into the payer to payer data exchange policy in this final rule.
Comment: Multiple commenters submitted responses relating the Payer-to-Payer API
data exchange to the HIPAA Privacy Rule exception for TPO disclosures, which do not require
patient authorization. Some commenters stated that the information CMS proposed to require be
made available falls under the scope of that exception and therefore opt in should not be
required. Other commenters believe that some of the data (such as prior authorization
information) would fall under that exception, but other data (such as claims information) would
not. A few commenters suggested that CMS should reduce the scope of the data exchange to
allow disclosure under the TPO exception. Furthermore, commenters stated that it may confuse
and upset patients who have opted out of sharing their data via the Payer-to-Payer API, but
whose PHI may otherwise be disclosed under the HIPAA Privacy Rule.
Response: We emphasize that our final requirements are not intended to change any
existing obligations under the HIPAA Privacy, Security, and Breach Notification regulations, the
regulations under 42 CFR part 2, or state privacy or other laws, but can and should be
implemented in accordance with those rules. To make a blanket determination that the Payer-to-
Payer API exchange that we are requiring always constitutes a TPO disclosure would go beyond
the scope of this rule and could overstate and conflict with existing HIPAA Privacy Rule
requirements and guidance. Making such a determination could have unintended effects on
covered entities ability to disclose PHI. Instead, for the reasons explained previously, it is
appropriate to require patients to opt in for payer to payer data exchange. Our payer to payer data
exchange requirements are disclosures permitted under the HIPAA Privacy Rule as uses or disclosures that are required by law, as defined at 45 CFR 164.103, rather than as a permitted
TPO disclosure. Required by law disclosures are limited to the relevant requirements of such
law, not to the HIPAA minimum necessary standard, thereby ensuring that all content required
by our Payer-to-Payer API policy may be disclosed. In addition, the data exchange must not be
prohibited by other law, such as restrictions on patient records related to substance use disorder
at 42 CFR part 2 or state privacy laws.
We emphasize that the opt in process described here applies only to the payerto payer
data exchange in this final rule. That is, it applies only to the requirement for impacted payers to
share individual claims and encounter data (excluding provider remittances and cost-sharing
data), all data classes and data elements included in a content standard at 45 CFR 170.213 and
certain information about prior authorizations maintained by the payer with a date of service
within 5 years of the request by a patients new or concurrent payer. Similar to the discussion in
section II.B.3.b.ii. regarding Provider Access API, a patients choice not to opt into the payer to
payer data exchange does not prohibit the payer from using the Payer-to-Payer API to exchange
patient data under another permissible authority. For instance, there may be other permissible
bases for payers to share data, without a patients authorization, such as under the HIPAA
Privacy Rules permitted uses and disclosures to carry out treatment, payment, or health care
operations.Patients do not have the ability to opt out of a payer using the API itself as a
mechanism for sharing data under such bases for disclosure. We urge payers to inform their
patients of this possibility in the educational resources discussed in section II.C.3.g. However,
we also note that the HIPAA Privacy Rule, at 45 CFR 164.520, has specific notice requirements
for covered entities to send to individuals. Payers should make clear the differences between the
payer to payer data exchange, which requires patients to opt in, and other permissible
disclosures, which may not require authorization.
We also note that the data that may be shared under other permissible bases, such as the
TPO exception, may overlap with the data required to be shared by our Payer-to-Payer API policy. For instance, a payer may be permitted to disclose PHI to another covered entity to
coordinate benefits or determine cost-sharing amounts for the covered entitys payment purposes
under 45 CFR 164.506(c)(3). If that disclosure is permissible, a patient declining to opt into the
payer to payer exchange policy in this final rule would not prohibit a payer from using the Payer-
to-Payer API to make that disclosure.In fact, we encourage payers to leverage the Payer-to-
Payer API as a standardized mode of transmitting this information. Payers may leverage a
variety of solutions for exchanging coverage data today and moving to a standard-based API
across the industry could benefit payers by reducing the types of connections they must maintain
to communicate with other payers.
Per 45 CFR 164.506(b), covered entities may create a process to obtain consent from an
individual to use or disclose PHI to carry out treatment, payment, or health care operations. Per
45 CFR 164.522(a), individuals also have the right to request restrictions on how a covered
entity will use and disclose PHI about them for TPO. Except in limited circumstances, a covered
entity is not required to agree to an individuals request for a restriction. Where covered entities
agree to a restriction, it is bound to the restriction to which it agrees unless the restriction is
subsequently terminated. We emphasize that the opt in process described in this final rule is
specific to the Payer-to-Payer API policy and is therefore not, on its own, a consent mechanism
per 45 CFR 164.506(b) or an agreed-upon restriction per 45 CFR 164.522(a).
These nuances are necessary for patients to understand that their personal health
information may still be shared in some instances, even if they do not opt into the payer to payer
data exchange. Where the requirements of this rule change how covered entities or their business
associates may use or disclose PHI, covered entities should consider their obligations under the
HIPAA Privacy Rule.
Comment: A commenter recommended that CMS assist states with implementing opt in
processes. Another commenter explained that the feasibility of an opt in approach depends on
how it would be implemented. A different commenter recommended that CMS to work with stakeholders to develop a standard approach for how an opt in requirement will work when the
patient is not the primary insurance holder, noting that a standard approach is necessary to reduce
confusion and ensure that patient information is protected.
Response: We agree that the feasibility of an opt in approach depends on how it is
implemented, which is why we are leaving the actual implementation process up to the payers.
We expect that payers will implement the most viable processes for themselves. Each of our
policies in this final rule is targeted toward individual patients, not any family members that may
be covered through the same benefits. We note that in some cases, applicable law may allow one
individual (such as a parent or guardian) to act as a personal representative for another individual
covered under the same benefits (such as a minor) and could therefore opt into the payer to payer
data exchange for that individual. Regardless, the opt in is patient-specific and a payermust
make the data request based on the individuals permission and the previous/concurrent payer
should respond in kind with the individual patients record. No data should be shared about any
patient that has not opted in (or whose personal representative has not opted in), regardless of
whether another patient covered under the same benefits has opted in.
Comment: Multiple commenters weighed in on whether patients opt in should be
collected electronically and specifically recommended that payers collect the opt in via a patient
portal or mobile device. A commenter explained that payers do not have the means to collect
patients opt in via multiple methods. A different commenter noted that payers should collect opt
in data electronically. Another commenter stated that patients should not be required to use a
patient portal or mobile device app to opt into data sharing. A commenter also requested
guidance on how to collect permission from patients who require assistance enrolling or
registering for the patient portal. Another commenter noted the importance of equitable access to
patient data and highlighted the current usage of patient portals as a method to authenticate
patients identities and obtain their opt in permission. They recommended a centralized identity
service for patient authentication, verification, or consent for patients who cannot, or prefer not to, access the patient portals. A commenter recommended that CMS provide a centralized
security verification through CMS. The commenter noted that a centralized security certification
validation would relieve burden on payers to manage connectivity with other payers and provide
assurances around self-signed certificates.
Response: We are finalizing that all impacted payers must develop and maintain
processes to identify a patients previous/concurrent payer(s) and to allow patients or their
personal representatives to opt into the payer to payer data exchange (both with previous and
concurrent payers) no later than 1 week after the start of coverage. As finalized in this rule, each
new payer will be responsible for gathering permission through an opt in process before
requesting data from any previous or concurrent payer. If payers believe that a patient portal or
mobile smart device with appropriate security protections is the best way to gather opt in, it is
permissible to use those methods. We are not being prescriptive about the process or procedures
used by impacted payers for the required opt in process. However, we strongly recommend that
there be a way for patients to record their permission telephonically or otherwise if they do not
have internet access or do not want to sign up for an electronic portal. We agree that equitable
access to patient data is of the utmost importance and emphasize that the Payer-to-Payer API
requirements are intended to allow for other solutions besides patient portals for authentication,
verification, or consent. For those patients who require assistance, a personal representative
would be allowed to assist. However, we do note that 45 CFR part 92 requires impacted payers
(as health programs or activities under that section) to provide meaningful access to individuals
with limited English proficiency and accessibility requirements for individuals with disabilities.
The requirements of that part apply to impacted payers, as described at 45 CFR 92.3.
We also are working closely with ONC on how the Individual Access Services exchange
under TEFCA could support patient access to their data on the network, which could include via
payer APIs. We appreciate the suggestion of a centralized security process and will consider our
authority in this area. Comment: Multiple commenters generally supported the proposed requirement for payers
to implement procedures to allow patients to withdraw permission for the payer to payer data
exchange after initially opting in. Several commenters requested clarification from CMS on what
action payers must take in such instances. Specifically, multiple commenters recommended that
CMS explain whether payers are expected to delete data that have already been received through
the Payer-to-Payer API if a patient withdraws their opt in permission after the data exchange has
occurred. Another commenter recommended that CMS explain whether patients with concurrent
payers will be able to withdraw their opt in permission to stop the quarterly concurrent payer
data exchange.
Response: Our opt in policy is only prospective. If a patient opts in, their impacted payers
would be required to exchange data via the Payer-to-Payer API, if all other requirements are met.
If that patient subsequently withdraws permission, payers will not need to take any additional
steps with regard to patient data that have already been received from another payer.
Specifically, there is no requirement in our regulations to delete those data from their records.
We acknowledge that it may not be possible in all cases to clearly delineate which entity created
each part of the patient record and trying to do so would put a burden on payers without benefit
to patients. Payers are permitted to identify the previous or concurrent payer as the source of
data,but are not required to do so. If a patient withdraws their permission for thepayer to payer
data exchange after first opting in, the payer will not be permitted to request that patients data
from another payer, including a concurrent payer, unless the patient subsequently opts in again.
As discussed previously, payers may exchange information for other purposes not related to the
policies described herein, such as for benefit coordination in the case of concurrent payers or
other permissible purposes under the HIPAA Privacy Rule, and may still use the Payer-to-Payer
API as the mechanism to exchange data for those purposes, even if a patient has not opted in.
Comment: Multiple commenters made recommendations related to CMS monitoring and
oversight of the opt in approach. A commenter suggested that CMS conduct oversight to ensure that payers implement the opt in process and provide appropriate messaging to patients. A
commenter recommended that CMS require payers to submit data on the number of patients who
opted into the data exchange and how they were educated to do so. The commenter stated that
this would help CMS understand if the API is meeting its intended goals. Another commenter
recommended that CMS consider including Payer-to-Payer API claims in the Healthcare
Effectiveness Data and Information Set (HEDIS) measure. Another commenter recommended
that CMS monitor the percentage of patients that do not opt into these data exchanges via the
Payer-to-Payer API and assess whether those patients are concentrated in certain populations and
whether there are equity issues that CMS should address in the future.
Response: We did not propose to require impacted payers to report any metrics regarding
the number of patients who opt into data sharing, but we appreciate the recommendation and will
consider it for future rulemaking. We note that the specifications of HEDIS measures are out of
scope for this rule. We received comments on many of our proposals about the need for specific
compliance and enforcement efforts pertaining to each API and we address these comments in
section I.D. of this final rule. Oversight and compliance procedures and processes vary among
these CMS programs and may have different implications based on a payers status in the
program, previous compliance actions, and corrective action plans.
Comment: Multiple commenters supported our proposal to require state Medicaid and
CHIP programs to collect patients permission for payer to payer data exchange in lieu of their
contracted managed care plans and managed care entities. Commenters stated that Medicaid and
CHIP agencies are in the best position to collect information from all beneficiaries during
eligibility and enrollment. However, commenters warned that if sister agencies within the state
perform eligibility and enrollment processes, there would be additional coordination required to
collect patients permission.
Response: We agree with commenters that state Medicaid and CHIP agencies are the
logical entity to hold Medicaid and CHIP beneficiaries permission for payer to payer data exchange. We note that MCOs, PIHPs, and PAHPs are still responsible for collecting
previous/concurrent payer information and requesting the data exchange. However, nothing in
this rule would prevent a Medicaid or CHIP agency from collecting that information and passing
it along to their MCOs. We also acknowledge the specific difficulties that states may face to
implement the requirements of this rule and refer readers to section II.E. of this final rule for
discussion about available extensions and Federal funding for IT expenditures related to these
requirements.
d. Requesting Data Exchange from a Patients Previous/Concurrent Payer(s) and Responding to
such a Request
i. Timeframe for Requesting Data
We proposed to require impacted payers to request a patients data from their
previous/concurrent payer(s) no later than 1 week after the start of coverage, as defined
previously. We stated that 1 week should be sufficient time for payers to complete their process
for identifying patients previous/concurrent coverage and to requestdata from the other
payer(s). We proposed that if, after the start of coverage, a patient opts into the data exchange or
provides previous/concurrent payer information or requests a payer to payer data exchange for
another reason, then the current payer would be required to request data from the
previous/concurrent payer(s) no later than 1 week after the payer received the
previous/concurrent payer information and the patient has opted in, or the patient makes the
request. We acknowledge that the obligation to request data is contingent on the patient
supplying the necessary information about a previous/concurrent payer to enable the new payer
to conduct the required exchange. An impacted payer cannot comply with these requirements if
the patient has not provided timely or accurate information about their previous/concurrent
payer. In that case, payers are required to make reasonable efforts to gather this information from
patients. For example, we recommend payers follow-up one time before determining that the
patient has not opted in. We are finalizing a modification to the proposed regulatory text to clearly establish that the 1-week timeframe for requesting patient data begins when the impacted
payer has sufficient identifying information about previous/concurrent payers and the patient has
opted in.
Comment: Many commenters supported our proposal to require impacted payers to
request data from a patients previous payer no later than 1 week after the start of coverage or
obtaining previous/concurrent payer information and opt in permission from the patient. Other
commenters suggested a variety of alternative timeframes for payers to request patient data from
previous/concurrent payers. A few commenters recommended that CMS allow 2 weeks after the
start of coverage to request the data. Other commenters recommended that CMS extend the
timeframe for a data exchange to be within 30 or 90 days after enrollment to allow payers time to
confirm the patients information, especially during peak volumes such as open enrollment. A
commenter highlighted that a 90-day timeframe would allow time for the previous payer to
process outstanding claims. Conversely, other commenters recommended a 3-day timeframe for
a new payer to request the patients data from their previous payer to expediate the data
exchange.
Response: We continue to believe that 1 week is the appropriate period to require payers
to make a request for patient data after they have sufficient identifying information about the
previous/concurrent payer and the patient has opted in. The longer the period between the time a
patient enrolls with a new payer and that payer receives patient data, the less relevant those data
could be. This is particularly true for patients who have chronic conditions or ongoing treatment
for life-threatening conditions. For these patients, it is more important that their new payer get
information as soon as possible. If necessary, additional information can be exchanged as it
becomes available. See our discussion in section II.C.3.d.i. of this final rule regarding optional
additional data exchanges between previous and new payers. For instance, the CY 2024 MA and
Part D final rule requires MA coordinated care plans to provide a minimum 90-day transition
period when an enrollee switches to a new MA plan. During that time, the new MA organization may not require prior authorization for an active course of treatment. Establishing a 90-day
timeline for payer to payer exchange could largely negate the utility of the data to comply with
that requirement. Even a shorter period, such as 2 weeks or 30 days, could require patients to
provide separate information about active courses of treatment, which would add burden to
patients rather than reducing it. Regardless of whether impacted payers are subject to that rule, it
is important to exchange data quickly so that patients can maintain a continuity of care.
However, we also determined that our proposed data request deadline was no longer
feasible with the modified deadline for requesting previous/concurrent payer information and the
patients opt in to be no later than 1 week after the start of coverage. Therefore, we are also
finalizing a modification to ourproposal to require impacted payers to request data from a
patients previous/concurrent payer(s) no later than 1 week after the payer has sufficient
identifying information and the patient has opted in, or within 1 week of a patients request. We
encourage payers to request these data as expeditiously as possible.Specifically in regard to
periods of peak volume for payers, we encourage payers to use the Bulk Data Access IG to send
bulk requests and responses for multiple patients at once. As discussed in section II.G. of this
final rule, we are finalizing our proposal to require payers to implement the Bulk Data Access IG
for the Payer-to-Payer API for this very purpose.
Comment: Multiple commenters suggested that CMS explain the meaning of within 1
week of the start of coverage. A commenter highlighted how Medicaid policy requires that they
grant eligibility retroactively up to 3 months and recommended that the data request within 1
week of the start of coverage be based on the date that the eligibility update is received into their
MMIS, not the effective date of coverage, which could be 3 months prior. Another commenter
recommended that only QHP policies that have been effectuated with a binder payment be
subject to the payer to payer data transfer requirement, which should leave 1 week after the date
that benefits begin for the new payer to request the data transfer. Response: As noted previously, we are changing the deadlines for payers to request
information from other payers by tying them more closely to the date when the payer has
sufficient information about a patients previous and concurrent payers and the patient has opted
in. As such, the data request deadline is no longer linked to the start of coverage or enrollment.
Further, as explained previously, the term start of coverage, as used in the preamble to this
rule, means when coverage begins or when the patient enrolls, as applicable. For cases when
there may be retroactive coverage, such as in Medicaid, the payer will be required to seek a
patients opt in for Payer-to-Payer API data exchange and to request information about a new
patients previous/concurrent payer(s) no later than 1 week after the patients enrollment. In
Medicaid, the patients enrollment is the date the beneficiary is enrolled in the states MMIS
(or equivalent process), not the date that coverage takes retroactive effect. For that reason, the
regulation text in Medicaid FFS reflects this by referring to enrollment instead of start of
coverage.
Comment: Multiple commenters requested clarification that timing requirements are
flexible to the extent reasonable and necessary to verify that privacy and security requirements
are met. A commenter emphasized that this timeframe could only be followed if it begins after
the member has provided sufficient information as determined by the impacted payer to identify
a concurrent payer (for example, payer name, member enrollment number, group number).
Response: We agree that the timeframe for sending a request only begins when a payer
has sufficient information to send a request to another payer and the patient whose data are being
requested has opted in. We are finalizing that the request must be made no later than 1 week after
the payer has sufficient identifying information and the patient has opted in. We note that, as
discussed previously, payers have an obligation to request that information from their patients no
later than 1 week after the start of coverage, as that term is defined previously specific to each
impacted payer type. Comment: A commenter suggested that if payer endpoints are not publicly available or
accurate information on a previous payer is notavailable, payers should only be required to make
reasonable efforts to complete the data exchange.
Response: Existing requirements require payers to make technical documentation about
their API, including digital endpoint information, on a publicly accessible section of their
website.83 In section I.D. of this rule we discuss an NDH that could serve as a centralized place
for impacted payers to find other payers digital endpoints. Commenters indicated that such a
directory would significantly improve the process for requesting patient data.
Payers are required to request patient information from previous and concurrent payers if
the conditions in the rule are met,and we encourage payers to make a reasonable effort to locate
information about a patients previous payer. If a payer is unable to obtain a valid endpoint or
accurate information for a previous or concurrent payer, we recommend they document the
efforts they took to gather the information from the other payer. Doing so could establish a
record for future oversight, or in case of a dispute, that the payer made a reasonable effort to
comply with the requirements of this rule and the patients desire for their data to be exchanged.
As discussed, payers are not responsible for determining whether the patients previous payer is
an impacted payer, but are required to request previous/concurrent payer information from the
patient and to make the data request to the other payer. We encourage payers that are not subject
to the requirements in this rule to participate in the Payer-to-Payer API exchange in order to
allow their patients to benefit from this policy. However, a payer not subject to this regulation
may nothave a FHIR API or want to exchange the required information, which would be outside
of the impacted payers control.
83See42CFR422.119(d)forMAorganizations,42CFR431.60(d)forMedicaidFFS,42CFR438.242(b)(5)for
Medicaidmanagedcare,42CFR457.730(d)forCHIPFFS,42CFR457.1233(d)forCHIPmanagedcare,and45
CFR156.221(d)forQHPissuersontheFFEs.Theserequirementsarecrossreferencedintheregulationsrequiring
impactedpayerstoapplythesametechnicalspecificationstoalltheAPIsrequiredunderthisfinalrule. Comment: Multiple commenters flagged that impacted payers will need time to establish
the necessary technology linkages, data use agreements, and security protocols to exchange
information with another payer in a manner compliant with the HIPAA standard transaction and
code setrequirements. A commenter noted that the data exchange would take longer than 1 week
if a payer needs to set up a new connection, as feeds may differ.
Response: We understand that a functional technological connection with other payers to
meet the requirements for the Payer-to-Payer API policy can and sometimes will take more than
a week to complete. However, there is no applicable HIPAA standard transaction or code set for
the payer to payer data exchange we are finalizing in this final rule. The required standards are
those being established in this final rule. Giving impacted payers sufficient time to coordinate
with other payers to establish the capability to exchange data is one rationale for delaying the
compliance dates from the proposed 2026 to 2027. We expect that payers will use that additional
time not only to build the requisite API technology, but to coordinate with other payers to
establish those linkages. We encourage payers to establish connections and perform testing with
other payers before the compliance dates for the Payer-to-Payer API to ensure that the data
exchange will work as expected. Payers should also set up a testing or sandbox instance of their
Payer-to-Payer API as early as possible for other payers to test against. We also encourage
payers to establish data use agreements and register with each others APIs prior to the
compliance dates in order to facilitate exchange as quickly as possible after the compliance
dates. We expect that those technological and legal requirements will be most burdensome when
one payer connects with another for the first time. Subsequent exchanges should rely on that
same foundation, and it should not be necessary to repeat those steps. Finally, we suggest payers
prioritize other payers that they are most likely to exchange with, such as those that overlap with
their geographical coverage area.
ii. Additional Data Exchange In the proposed rule, we solicited comments on whether additional data exchanges would
be warranted to account for data received or processed by the previous payer after the patients
coverage ends and, if so, what the appropriate parameters would be. Outside the context of
concurrent payers, we generally expect our policy to require a one-time data exchange between a
previous and new payer. Once the new payer has received the patients data from the previous
payer, we do not generally expect there to be additional exchanges with the previous payer.
However, we want to allow patients to request subsequent data exchanges to account for any
outlier situations. We are also aware that claims take time to process and may be processed after
patients have enrolled with a new payer, thus creating additional data within the patients record
for some time period after the patient has changed payers. We considered proposing a policy
where, if the patient opts in, a previous payers would be required to send any additional data
within the required dataset to the new payer no later than 1 week of receiving the additional data.
However, keeping in mind the burden this could impose on payers,we sought comment on such
a policy. We sought comment on whether additional data could be helpful for the new payer in
the weeks or months after enrollment, and which specific data could be most pertinent, or
whether additional data exchange would be overly burdensome and not provide value to the new
payer. We asked whether it would be appropriate to limit such a requirementto send updated
data to a certain period after the initial data exchange, for instance within 30 or 90 days.
Additionally, we asked whether impacted payers should be required to make an additional data
exchange within a week of receiving any new data or on a set cadence, such as monthly or
quarterly, to allow payers to streamline transactions for multiple patients.
Comment: We received varying comments around additional data exchanges with
multiple commenters supporting a one-time additional data exchange to promote continuity of
care. Some commenters thought it would not be feasible to share additional data within 1 week
of each update but supported a single exchange at 30-, 60- or 90-days after the patient has moved to a new payer. A commenter stated it would be difficult to track when additional data need to be
sent after the initial exchange.
Response: We agree that it could be helpful for payers to supplement the data exchange
required under this rule, to account for any claims or data that are received after the initial data
are sent to the new payer. While we are notrequiring it, we encourage payers to do so in order to
pass along a complete patient record. Likewise, we encourage the new payer to send an
additional request for data within 90 days of receiving the initial data response. The previous
impacted payer would be required to respond to such a request.
iii. Authorization and Authentication Protocols
We proposed that impacted payers would be required to use the OpenID Connect Core
authorization and authentication protocols at 45 CFR 170.215(e)(1) to authenticate the identity of
the requesting payer. We wanted to ensure payers would not have to send data unless they are
confident that the requesting payer is identified. TheONC Cures Act final rule adopted content
and vocabulary standards to provide the foundation needed and were finalized for use in the
CMS Interoperability and Prior Authorization final rule to support implementation of the policies
(85 FR 25521-25522). Thus, we proposed OpenID Connect Core in effort to align standards
across API implementations.
Comment: Multiple commenters sought clarification on the general authentication and
authorization process and flagged that requiring OpenID Connect Core will not be sufficient for
the Payer-to-Payer API. A commenter recommended that CMS consider UDAP or the PDex IG,
which uses a SMART framework instead. Another commenter flagged that the OpenID Connect
Core standard requires a log-in, whereas the proposal suggested that payers are required to
provide these APIs withouta user login or credential. A commenter highlighted that the Bulk
Data Access IG requirement relies on portal credentials and user logins created by the
individuals to be linked to their identity in the payer system. Response: Upon consideration, we agree that it would not be appropriate to require
OpenID Connect Core for the Payer-to-Payer API. OpenID Connect Core is a means to identify
individuals and because the Payer-to-Payer API is a business-to-business interaction, OpenID
Connect Core is not adequate to meet this use case. Although OpenID Connect Core can be
utilized for the Payer-to-Payer API, it is not a scalable approach because it requires user
credentials. For similar reasons, we are finalizing a modification to our proposal to not require
OpenID Connect Core for the Provider Access, Payer-to-Payer and Prior Authorization APIs.84
The SMART App Launch IG can also provide a method for authentication within the Payer-to-
Payer API; though we note that we are notfinalizing our proposal to require that IG, it remains
available to payers as an option. However, as part of the Payer-to-Payer API, payers still need to
authenticate bi-directionally using industry best practices to ensure that patient data are only
shared appropriately. We refer readers to Table H3 in section II.G. for an updated listed of
required and recommended standards and IGs. We also advise that the Bulk Data Access IG,
which is a required IG for the Payer-to-Payer API, contains a SHOULD (that is, strongly
recommended) conformance statement to use SMART Backend Services. We also note that
SMART Release 2.0.0, which has since been adopted in the HTI-1 finalrule at 45 CFR
170.215(c)(2) includes SMART backend services. Though in this final rule we are requiring
impacted payers to support the Bulk Data Access IG in their Provider Access and Payer-to-Payer
APIs, this requirement does not obligate them to use it for every data exchange if it is not
necessary.
Comment: A commenter recommended that CMS collaborate with industry stakeholders
to identify best practices for user authentication and authorization with the Payer-to-Payer API.
84Intheproposedrule,thatrequirementwasincludedforMAorganizationsat42CFR422.121(b)(1)(i),for
MedicaidFFSat42CFR431.61(b)(1)(i),forCHIPFFSat42CFR457.731(b)(1)(i),forMedicaidmanagedcare
plansthroughcrossreferenceat42CFR438.242(b)(7),forCHIPmanagedcareentitiesthroughcrossreferenceat
42CFR457.1233(d),andforQHPissuersontheFFEsat45CFR156.222(b)(1)(i). Another commenter highlighted that guidance on how to trust and verify inbound data requests
via the Payer-to-Payer API will be essential.
Response: We will continue to collaborate with industry stakeholders through HL7 FHIR
workgroups and through HL7 FHIR Connectathons as the standards to support the Payer-to-
Payer API continue to be refined to support these final policies. We also will continue to work
closely with ONC on the required authentication and authorization standards under 45 CFR
170.215. While we are not specifically requiring an IG or method be used for authentication and
authorization, as part of the Payer-to-Payer API payers still need to authenticate the other payer
they are exchanging data with.
iv. Attestation
We proposed to require the requesting impacted payer to include an attestation with the
request for data affirming that the patient 1) is enrolled with the requesting payer and 2) has
opted into the data exchange in a manner that meets the applicable legal requirements. As
explained in section II.G. of this final rule, we recommended certain HL7 FHIR IGs to support
the data exchange between payers. The recommended PDex IG has been developed to include
both the technical and business processes of capturing and sharing a patients permission for data
exchange with the payer to payer data request. Because that IG is recommended and not
required, impacted payers could also exchange an attestation regarding patient permission with
other implementations, which could meet or exceed the requirements of the PDex IG.
Comment: Multiple commenters supported the attestation proposals for the Payer-to-
Payer API. Multiple commenters provided recommendations for processes to share patients data
sharing permission. Multiple commenters suggested processes for payers to verify that a patient
opted into data sharing with another payer before giving that payer access to patient data. A
commenter requested clarification on whether patients must opt in for each subsequent payer. A
commenter recommended that patients data sharing permission be shared with secondary and
tertiary payers. Commenters requested clarification on which payer (the requestor or requestee) is responsible for obtaining patients permission. A commenter highlighted that an attestation
process will not resolve the risks of incorrectly matching data to the patient. Another commenter
asked whether FHIR can be used to send the attestation. Another commenter requested
clarification on using standards and IGs to facilitate the opt in process. A commenter sought
guidance on where a patients opt in would be indicated on the electronic transmission and how
they could verify that the payer provided educational information to the patient.
Response: We appreciate the recommendations for sharing a patients opt in but leave
that exact process up to payers. The impacted payer requesting the data from the
previous/concurrent payer is responsible for obtaining the patients opt in and must include an
attestation with that request for data affirming that the patient 1) is enrolled with the requesting
payer and 2) has opted into the data exchange in a manner that meets the necessary legal
requirements. Patients would have to opt in for each subsequent payer to request their data from
a previous/concurrent payer. The purpose of the attestation is not to match the data to the patient,
but to affirm that the patienthas enrolled with the requesting payer and has opted into the data
exchange in a manner that meets the necessary legal requirements. We highly recommend using
the IGs discussed in further detail in section II.G. of this final rule to support the Payer-to-Payer
API. The latest published version of the PDex IG (STU 2.0.0) includes a means for a payer to
communicate that the member has opted inthrough a FHIR Consent resourcewhen
requesting data from another payer. An attestation or verification that the requesting payer
provided educational information to the patient is not required to be sent with the request.
Comment: A commenter recommended that CMS more clearly explain the Payer-to-
Payer API process to ensure that prospective or potential payers are not requesting a patient's
data. Another commenter suggested that an attestation from another payer is not sufficient proof
to demonstrate a patients decision to opt in and suggested that some assignment of legal liability
be considered for the requesting payer, as it might assuage these concerns. Response: A prospective or potential payer should not request a patients data under this
rule. Under this rule, a payer must attest that the patient is enrolled with that payer as part of its
request for the patients data from a previous/concurrent payer. We emphasize that the impacted
payers must implementan authentication process (discussed previously) that verifies the
requesting payers identity as a legitimate health care coverage entity. If an entity includes a
fraudulent attestation that the patient is enrolled with the payer and has opted in to payer to payer
data exchange in its request for patient data, that entity could be subject to criminal or civil
penalties.
v. Timeframe for Responding to a Request
We proposed that impacted payers that are previous/concurrent payers would be required
to respond to a current payers request, if specified conditions are met, within 1 business day of
receiving the request. We explained that 1 business day would be the appropriate timeframe to
complete this process to send the data, as new payers need timely access to previous/concurrent
payer data to facilitate care coordination and make the information available to providers within
their new network. We noted that this timeframe also would align with the 1 business day
response time for the Patient Access and Provider Access APIs.
We sought comment on whether the proposed timeframes for the previous/concurrent
payer to send these data, are appropriate or whether other timeframes would better balance the
benefits and burdens. We sought comment on whether payers need more than 1 business day to
respond to a request and sought comments on whatmight be a more appropriate timeframe if
commenters thought a different timeframe was warranted. We explained that it is important for
patient data to move to the new payer as soon as possible to send their patient record and to
ensure care continuity.
Comment: Multiple commenters expressed support for the 1 business day response time
for the Payer-to-Payer API. A commenter recommended a modification that data should be
available within 1 calendar day. Another commenter stated that the purpose of standardized API data exchange is to have real-time data availability. A commenter requested that CMS provide at
least 24 hours for data from the Prior Authorization API to be available via the Payer-to-Payer
API. Some commenters expressed general concern with our proposed response timeframe and
suggested that payers may become overwhelmed, especially during open enrollment periods. A
commenter expressed concern that the proposed timeframe does not consider the degree of
manual effort required to ensure compliance with applicable state laws and regulations regarding
health privacy and confidentiality. Multiple commenters recommended that CMS require a
response time of 2 business days for the Payer-to-Payer API and another suggested 3 business
days.
Response: After reviewing the comments, we believe that keeping the response
timeframe at 1 business day is appropriate. This expedient data exchange will support care
continuity and still allow time for the processes for payers to appropriately send patient data. We
note that this timeframe also aligns with the finalized 1 business day response time for the
Patient Access and Provider Access APIs. We acknowledge that some periods may have
increased data exchange requests, such as during open enrollment period,and note that the
purpose of the required Bulk Data Access IG is to efficiently exchange large volumes of data for
multiple individuals and can be utilized for both requesting and sending data.
The data content we are finalizing that must be included in the payer to payer data
exchange is generally the same as the current requirements for the Patient Access API,
notwithstanding the addition of prior authorization information. Claims and encounter data and
alldata classes and data elements included in a content standard at 45 CFR 170.213 (USCDI) are
structured data, which will help payers identify particular items that are subject to additional
privacy requirements. We are also finalizing 2027 compliance dates,in part, to give payers
additional time to develop internal processes and train staff. That includes processes make the
necessary determinations as to which data are permitted to be shared via the Payer-to-Payer API.
For instance, payers may use this time to develop processes that flag certain data elements with metadata  as the payer receives them  if they require special permissions or are prohibited to
disclose under other law. We highly encourage payers to engage in this process as they receive
data to ease any manual review and decision-making that might be necessary when a payer
requests patient data.
Comment: A commenter recommended that CMS address the need for a legal governance
framework for the payer to payer data exchange because the technical standards proposed would
not enable the requesting payer to substantiate the patients authorization.The commenter stated
the need to provide legal assurances that the payer requesting a patients records has obtained
appropriate authorization to request the records and without a standardized governance
framework, payers would struggle to fulfill the requirement to respond within 1 business day of
receiving a request.
Response: We understand the importance of legal assurancebetween payers to ensure the
patient has provided appropriate authorization before sharing data across payers. The
recommended PDex IG STU 2.0.0, which has since been published since the publication of the
CMS Interoperability and Prior Authorization proposed rule, includes both the technical and
business processes to capture and share a patients permission as part of the payer to payer data
request. We believe 1 business day is sufficient to fulfill the request for data exchange because
the IG is a means for payers to electronically send a record of the patients permission to receive
data from the other payer. We are also working closely with ONC as to how TEFCA could
support scalable governance for payer to payer data exchange. We reiterate that we are requiring
that the new payer provide an attestation with the request for data affirming that the patient has
enrolled with that requesting payer and has opted into the data exchange.
vi. Payers Not Subjectto this Regulation
If a previous/concurrent payer is not an impacted payer, they are not subject to our final
requirements and, therefore, are not required to send or request data through the Payer-to-Payer
API. For example, an employer-based commercial plan would not be subject to this rulemaking. If the previous/concurrent payer is not an impacted payer, they are not subject to our
requirements to respond to the request. A new or concurrent impacted payer is not obligated to
determine whether the previous/concurrent payer is an impacted payer underthis final rule or to
limit its requests for a patients data (or its responses to requests for a patients data) to only
impacted payers. Therefore, we proposed that an impacted new payer would be required to
request the data from the patients previous/concurrent payer, regardless of whether the other
payer is an impacted payer. Conversely, we proposed that if an impacted payer receives a request
for patient data that meets the requirements of this rule, they would be required to respond by
making available the required data through their Payer-to-Payer API, regardless of whether the
requesting payer is an impacted payer (which the payer may or may not know).
If a payernot subject to this regulation does not have the capability or refuses to
exchange the required data with an impacted payer or is willing to exchange the data but is
unable or unwilling to do so through a FHIR API, the impacted payer will not be required to
exchange data with that payer. Payers that have not implemented the Payer-to-Payer API would
not have accessible digital endpoints to make the required request. We emphasized in the
proposed rule that impacted payers would not need to spend resources determining whether other
payers are subject to this rulemaking, but would be required to request patient data, if possible,
and respond to all requests that are made within the requirements. However, we encourage all
payers to implement a Payer-to-Payer API to support data exchange with other payers, even if
they are not subject to our final requirements to support care coordination and more efficient
operations.
Comment: Multiple commenters flagged concerns regarding interoperability with payers
not subject to this regulation. A commenter stated that it is unclear what value would be derived
from the investment if there is no response or reciprocation from payers not subject to this
regulation. Another commenter noted that payers need to build a connectivity system with other
payers, including payers not subject to this regulation. Response: We disagree that the burden of connecting with a payer not subject to this
regulation that has implemented a Payer-to-Payer API in conformance with our requirements is
any different than connecting with an impacted payer. Regardless of whether they are covered by
an impacted payer, there is value in maintaining a patients data and exchanging those data when
a patient transitions to a new payer or between concurrent payers. Furthermore, requiring
impacted payers to exchange data only with other impacted payers would require impacted
payers to expend effort to determine whether the other payer is an impacted payer. That effort
can be eliminated by simply treating any payer as a possible exchange partner. Furthermore, not
requiring impacted payers to exchange data with payers not subject to this regulation would
mean that there would be no incentive for those payers to adopt the requirements of payer to
payer data exchange. In addition, impacted payers are not required to exchange data outside of
the process finalized in this final rule, including using a standards-based API. If a payer not
subject to this regulation requests data in a format that is not compatible with the Payer-to-Payer
API and specific data formatting, content and vocabulary standards established in regulation,
impacted payers will not be required to send data via a different method, unless other law
requires them to do so.
We understand that impacted payers may have additional difficulty ascertaining that
another payer is not subject to this regulation (or not compliant), as that payer would not have
digital endpoints to discover. Payers are required to take reasonable steps to determine whether
they can exchange data with the other payer. We encourage payers to contact the previous payer
directly to determine whether they support the Payer-to-Payer API. Other solutions could also be
explored to help payers determine whether the previous payer supports the Payer-to-Payer API,
such as using TEFCA. In section I.D. of this final rule we discuss an NDH that could serve as a
centralized place for payers to find other payers digital endpoints and identify payers that
support the Payer-to-Payer API. Once a payer knows that another payer is not capable of payer
to payerdata exchange, they would not be required to inquire every time they receive a new patient who identifies that previous payer. However, it would be prudent to occasionally (such as
annually) check whether the other payer has implemented a Payer-to-Payer API and is now
capable of data exchange.
e. Ongoing Data Exchange Requirements for Concurrent Coverage
i. Concurrent Coverage Data Exchange
For individuals who have concurrent coverage with multiple payers, we proposed to
require impacted payers to collect identifying information about any concurrent payer(s) from
patients before the start of coverage with the impacted payer (consistent with how start of
coverage is explained previously). Because we believed it would be beneficial for all of a
patients current payers to maintain a complete record of the care that the patient has received,
we proposed to require impacted payers to request the same patient data described in section
II.C.3.b. of this final rule from all of a patients concurrent payers, and to send those data in
response to a request that meets all the requirements of this final rule. We stated that this would
ensure that the patients concurrent impacted payers maintain a complete patient record and can
provide all the information proposed to be required under the Patient Access and Provider
Access APIs.
Specifically, we proposed to require impacted payers, no later than 1 week after the start
of a patients coverage,85 to request data from any concurrent payers that the patient reports.
Because all payers will update patient records while a patient is enrolled with those payers, we
proposed that when a patient has concurrent coverage with two or more payers, the impacted
payers would be required to exchange with every other concurrent payer, at least quarterly. We
proposed that should an impacted payer receive a request for a current patients data from a
concurrent payer for that patient, the receiving payer would have to respond with the appropriate
data within 1 business day of receiving the request. Operationally, this proposed exchange would
function the same as the data exchange with a patients previous payer.
85ForQHPissuersontheFFEs,nolaterthan1weekaftertheeffectuationofenrollment. We also proposed that any impacted payerthat receives patient data from another payer
under these regulations must incorporate those data into the recipient payers records about the
patient. The required data content we proposed are the same claims and encounter data
(excluding provider remittances and cost-sharing information), all data classes and data elements
included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior
authorizations that the payer maintains with a date of service on or after January 1, 2016. We
stated that that proposal would require impacted payers to both request patients data from other
concurrent payers and to respond to requests from other payers to share patients data.
Comment: A commenter recommended that we only require concurrent payers making
quarterly data transmissions to send data that have been updated since the last data exchange.
The commenter stated that this would reduce burden by allowing them to exchange a smaller set
of data that can more easily be integrated into their patient records.
Response: We agree that this is a reasonable solution to reduce burden. We are finalizing
a modification to our proposalto allow concurrent payers to agree to exclude from ongoing
quarterly data exchange any data that were previously transferred to or originally received from
the other concurrent payer. We leave it to payers to determine the best process to effectuate this
option, as it is intended to reduce payer burden. If exchanging only new data would increase
burden on payers versus exchanging all patient data, they are not required to do so. Ultimately,
the exchange should result in both concurrent payers having a complete set of patient data to
support patient care and care coordination.
Comment: A commenter suggested that CMS require payers to clearly document, in the
payer systems, which payer is primary, and which is secondary to ensure providers receive
accurate and timely coordination of benefit information.
Response: Coordination of benefits is an established process (though the exact process
may vary by payer and jurisdiction) that we specifically did not propose to affect. As discussed
previously, if payers find it beneficial to use the Payer-to-Payer API for purposes other than the data exchange finalized in this rule, such as coordinating coverage, they are welcome to do so.
To the extent that such coordination information would benefit patients or providers by being
available via the Patient Access and Provider Access APIs, we encourage payers to do so.
Comment: Severalcommenters expressed opinions on the appropriate timeframe for
payers to request data from another concurrent payer and for payers to respond to such a request.
Multiple commenters stated their general support for timely information exchange between
concurrent payers to help minimize unnecessary administrative paperwork and other
inefficiencies. Several commenters supported our proposed timeframes. Other commenters
suggested that payers have up to 30 days to request patient information. A commenter stated that
the data should be available within 1 calendar day instead of 1 business day. A commenter
recommended CMS allow at least 3-5 business days for a response.
Response: There should be no procedural or technical difference between requesting data
from a previous payer or a concurrent payer, other than the requirement that concurrent payers
engage in ongoing quarterly exchange. Similarly, responding to such a request should be the
same process, using the same FHIR standards. Therefore, we believe it is prudent to establish the
same timeframes for the initial requests to and all responses from concurrent payers as for
previous payers. Therefore, we are finalizing that for concurrent payers, the initial request for
data must be made no later than 1 week after the payer has sufficient identifying information
about concurrent payers and the patient has opted in and quarterly thereafter. We are finalizing
our proposal that impacted payers must respond within 1 business day to a request for patient
data from a concurrent payer that meets all the requirements of this final rule.
ii. Concurrent Payer Exchange Timeframe
We also considered whether to propose more frequent exchanges (weekly or monthly), or
less frequent exchanges (semi-annually or annually) for the required data exchanges between
concurrent payers; however, we explained in the proposed rule that we believed a quarterly data
exchange would strike the right balance between providing accurate, timely data and payer burden. We believed that sharing data quarterly would be frequent enough to allow new health
data to accumulate and still be timely, but not so frequent that it causes unnecessary burden on
the payers. We requested comment on this proposal, including on the appropriate frequency for
this payer to payer exchange for patients with concurrent coverage.
Comment: A significant majority of commenters supported our proposal to require
quarterly data exchange between concurrent payers because it would facilitate care coordination.
Some commenters suggested that a more frequent data exchange could benefit patients. Some
commenters noted that even quarterly data exchange may miss key clinical events that would be
useful for care coordination and recommended that the data exchange should take place monthly.
On the other hand, a few commenters stated that impacted payers should only request additional
data from concurrent payers when initiated by a member.
Response: We agree with the majority of commenters that a quarterly cadence
appropriately balances the benefits and burdens on payers. Payers may make arrangements with
each other to exchange information more frequently, if they believe it would benefit their mutual
patients. The burden of initiating the exchange should not fall on the patient, especially at times
when they are dealing with specific health issues that would most benefit from care coordination.
As some commenters recommended more frequent data exchange, we will consider whether to
propose amendments to this policy in future rulemaking after the industry has experience
meeting the requirements of this finalrule.
We note that when a patient has concurrent coverage, the payers must communicate
regularly to ensure that the proper payer is responsible for that patients claims. Nothing in this
final rule, including a patientnot opting into the Payer-to-Payer API data exchange, is intended
to alter payers ability to exchange data as they do today for that purpose, in accordance with
applicable law.
f. Data Incorporation and Maintenance
i. Data Incorporation We proposed that data received by an impacted payer through this data exchange must be
incorporated into the patients record with the new payer. We stated that those data could then be
part of the patients record maintained by the new payer and should be included as appropriate in
the data available through the Patient Access, Provider Access, and Payer-to-Payer APIs. In this
way, a patients data could follow them between payers and be available to them and their
providers. We stated that this proposal would not obligate payers to review, utilize,update,
validate, or correct data received from another payer, but we encouraged impacted payers to do
so, at least to the extent it might benefit the patients ongoing care. We explained that payers
could choose to indicate which data were received from a previous payer so a payer, provider, or
the patient looking at the record, would know where to direct questions (such as how to address
contradictory or inaccurate information), but would not be required to do. Regardless, all data
received, maintained, used, or shared via the proposed Payer-to-Payer API would be required to
be received, maintained, used, or shared in a way that is consistent with all applicable laws and
regulations.
Comment: Multiple commenters supported our proposal to require payers to incorporate
data they receive from other payers via the Payer-to-Payer API into their own patient records in
order to ensure that a patients record is not lost. Other commenters stated that they do not
believe that payers are the appropriate holders of a patients full medical record and that
providers or patients themselves should be the maintainers of those data.
Response: We agree that in some cases a payer is not the best entity to hold a patients
longitudinal record and that there is other technology available forpatients to download their
data,for example, using the Patient Access API, and to store it independently of their payer. As
discussed previously, we are finalizing a policy that limits the payer to payer data exchange to
data with a date of service within 5 years of the request. After considering public comments, we
determined that a 5-year period balances the benefits of new payers having access to recent patient data and the patient not losing recent information against the burden of integrating and
maintaining historical data that may or may not be useful to care.
For patients who want to maintain their own information in a PHR, they have that option
through the Patient Access API. While in some cases, a patient may have a provider that can and
will aggregate their records from each other provider that the patient sees, we do not believe this
is a common scenario, as it would require a significant amount of work by the provider. As
discussed, because payers receive claims or encounter data from each provider that sees a
patient, they typically possess the most complete historical patient record. Requiring a payer to
send a patients data to their new payer will ensure that recent information that could be
important for care continuity is not lost.
Comment: A commenter cautioned that CMS should not assume that the information
received from a previous payer is whole and/or correct. The commenter noted that the difference
in health plans level of diligence could cause some discrepancies in patient coverage. Another
commenter suggested that payers would be incentivized to send incorrect information to another
payer rather than correcting the patients record.
Response: We acknowledge that any set of patient data may have errors or omissions.
However, we do not believe that the appropriate response to this issue is to discard data when a
patient moves between payers. As stated, we do not wish to burden payers to proactively verify
patient records when they receive them from another payer. However, under the HIPAA Privacy
Rule, at 45 CFR 164.526, individuals generally have the right to have a covered entity amend
PHI or a record about the individual in a designated record set for as long as the PHI is
maintained in the designated record set, with certain exceptions. That right exists regardless of
whether the covered entity created the PHI itself or received it from elsewhere. That requirement
is consistent with our policy, as it does not require proactive verification, but must be addressed
upon request by an individual. We also do not believe that there is any risk of payers intentionally proliferating
inaccurate information. There is no reason for a payer to maintain inaccurate records with the
ultimate goal of passing that information to another payer when the patient leaves their coverage.
Finally, payers are only responsible for maintaining their own records, including that which has
been received from another payer. If there is an error to be corrected in data received from a
previous payer, neither the patient nor their payer will need to contact the previous payer to
correct it and have the patients record resent. A patients current payer is required, by the
HIPAA right to amend and correct data in its records, even if that incorrect information was
initially received from a previous payer.
Comment: A few commenters recommended that all the APIs should support optional
provenance resources that could be added by either the sender or the receiver to indicate the
source of data. A commenter recommended that instead of CMS recommending payers to note
where the data originated, CMS instead propose that specific provenance resources be required
to indicate which data came from a previous payer, which could also be included in subsequent
data exchanges.
Response: When incorporating the data from an old or concurrent payer, payers are free
to indicate the provenance of that information, which would then be included in the data
available through the Patient Access or Provider Access APIs. As discussed in section II.G., we
are recommending, but not requiring, the PDex IG for the Payer-to-Payer API. The PDex IG
requires provenance information be included in outbound FHIR transactions and that a payer
receiving such a transaction must incorporate any included provenance information. There is also
a SHOULD recommendation within the IG that payers create provenance records when the
provenance is not included in a data set (for example, when it was received through non-FHIR
mechanisms). We highly recommend that payers use the IG for several reasons, including that it
would help address this issue and help payers, providers, and patients understand the source of data.We will considerwhether to propose to require provenance information through future
rulemaking.
Comment: Multiple commenters highlighted that our Payer-to-Payer API policy would
require extensive data translation and de-duplication. They suggested that CMS encourage
payers to work with HIEs to determine the best solutions to avoid data duplications and
associated errors. A commenter expressed concern regarding the potential for duplicate data to
be transmitted throughout the health care system.
Response: We appreciate commenters suggestions that there are existing marketplace
solutions to address some of the concerns about data duplication. We understand the concern
over duplicative information. There are IT solutions, such as EHR vendors and HIEs, available
that can make the data actionable and help payers avoid receiving duplicative information via the
Payer-to-Payer API. To the extent it would benefit payers, we encourage them to work with
HIEs and HINs to facilitate payer to payer data exchange. We note that nothing in our policies
prohibits a payer from using an intermediary to aid with various functions, such as patient
matching, data exchange, or data hygiene.
Comment: A commenter stated that they believe data acquired via Payer-to-Payer APIs
should be dated with the original date of service to prevent duplication in future Patient Access
or Provider Access API requests, if a patient or provider already had that information from the
previous payer.
Response: We agree that it is important to maintain the fidelity of data received via the
Payer-to-Payer API. While creating additionalmetadata is recommended to be able to track
where the data came from and when it was acquired, payers should not be changing the
underlying data itself. For example, the date of service or date claim processed should not be
updated to the date that the new payer receives the record of the claim from a previous payer. Comment: A commenter stated claims are not typically considered patient records and
suggested CMS define the patient record into which information from a previous/concurrent
payer must be incorporated.
Response: We do not need to define patient record as we are defining the set of data
that must be shared between payers, that is, claims and encounter data (excluding provider
remittances and patient cost-sharing information), all data classes and data elements included in a
content standard at 45 CFR 170.213 (USCDI), and certain information about prior authorizations
maintained by the payer with a date of service within 5 years of the request by a patients new or
concurrent payer. Furthermore, we have defined maintain in the Interoperability and Patient
Access final rule to mean the payer has access to the data, control over the data, and authority to
make the data available through the API (85 FR 255380). Payers must incorporate patient data
into the appropriate place where they maintain that type of information that they generate while
covering a patient. We understand that payers will store that information in a variety of ways,
depending on their own data infrastructure.
Comment: A commenter requested clarification as to how payers should integrate data
into a patient's records if the data from their previous payer includes information from other
individuals who were on the same coverage plan (for example, a family health plan).
Response: Each of our policies in this final rule are tailored toward individual patients,
not any family members that may be covered through the same benefits. In some cases,
applicable law may allow one individual (such as a parent or guardian) to act as a personal
representative for another individual covered under the same benefits (such as a minor) and
could therefore opt into the Payer-to-Payer API data exchange for that individual. Regardless,
the opt in is patient-specific and a payer must make the data request based on the individual
permission and the previous/concurrent payer should respond in kind with the individual
patients record. No data should be shared about any patient that has not opted in, regardless of
whether another patient covered under the same benefits has opted in. Comment: A commenter cautioned that when a new payer takes on another payers
information, this may cause a significantamount of risk for patients as they may get billed for
services that are not approved under their new payer.
Response: We are not requiring impacted payers to honor another payers prior
authorization decision, nor do our final rules require reprocessing claims submitted to previous
payers. If payers believe that sending these data will be confusing for patients, they should
include information in their educational resources that makes clear what the data exchange is and
is not used for.
ii. Data Retention
In the proposed rule, we noted that our proposals would not impact any payers data
retention requirements. Specifically, we did not propose to require impacted payers to maintain
data for unenrolled patients any longer or differently than they do today under current law,
regulation, or policy. We understand that if a patient is uninsured or moves to a payer not subject
to this regulation that does not request information from the previous payer, after a period of
time, the previous payer may discard information, which would make it unavailable to the patient
or other payers in the future.
We acknowledged that imposing requirements that would require payers to alter their
data retention policies based on the actions of other payers would be a significant burden that
would outweigh the benefits of such a policy. We considered proposing a minimum period
during which a payer must maintain patient records after disenrollment, such as 1 or 2 years.
However, we stated that most payers have policies in place that would maintain patient data for
at least that long, and thus, such a requirement would be unnecessary and duplicative. We
requested comment on whether our understanding is correct and whether there is a benefit to
considering a data retention requirement in the future.
Comment: Multiple commenters supported our decision not to propose or establish a data
retention requirement for patient records that would be different or longer than that required by current laws, regulations, and policies. Other commenters recommended that CMS set a
minimum data retention timeframe. A commenter suggested that a payer should have to retain
data until they are requested by a subsequent payer or after a minimum period of years,
whichever occurs first. Other commenters recommended data be maintained for 5 or 10 years
after a patient is unenrolled. Some commenters requested further guidance regarding the time for
which impacted payers should maintain the data received from previous/concurrent payers.
Response: We do not believe that additional data retention requirements are necessary at
this time, as we do not wish to change or create conflict with existing rules. For example, under
42 CFR 422.504(d), 438.3(u), and 457.1201(q), MA organizations, Medicaid managed care
plans, and CHIP managed care entities, respectively, must retain records for at least 10 years.
Similarly, most states require 5-10 years of data retention. Nothing in this final rule would
extend existing data retention requirements or create an obligation for perpetual maintenance.
We emphasize that once a payer receives patient data from another payer, it becomes part of the
patients record and should be treated the same as data in the patient record created by the
current payer. There should be no difference for data retention or data availability, as well as the
same obligation to update or correct the data. The only difference is that payers may attach
provenance information designating where the data originated.
Comment: A commenter noted that a patients previous payer should not be required to
respond to requests from the patients current payer more than 90 days after the patient has
disenrolled from the previous payer.
Response: We disagree with setting a 90-day limit on the initiation of a payer to payer
data exchange by a patients new payer. Patients should have access to their data for a
significantly longer period than that. Some patients may not learn about payer to payer exchange
for more than 90 days after the start of coverage. Others may move to payers that are not subject
to this rule and do not have a Payer-to-Payer API or become uninsured for a period before
moving back to an impacted payer. However, we do expect that a significant majority of the payer to payer data exchanges will be near the beginning of a patients new coverage,
particularly if the required patient educational resources clearly present the option at or shortly
after enrollment. Impacted payers are required toexchange the data they maintain on a patient,
with a date of service within 5 years of the request. We note that we discuss the timeframe for
data retention in this section, for which we are not changing any regulation or requirement. We
may consider, in future rulemaking, establishing a time period for the data to be available via
Payer-to-Payer API, but such a timeframe would likely be a matter of years, not days or months.
g. Patient Education Resources
Consistent with our proposals for the Provider Access API, we proposed that impacted
payers (excluding including Medicaid managed care plans and CHIP managed care entities)
would be required to provide patients with educational resources in non-technical, simple, and
easy-to-understand language, explaining at a minimum: the benefits of the Payer-to-Payer API
data exchange, patients ability to opt in or withdraw their permission, and instructions for doing
so. We proposed that state Medicaid and CHIP programs would provide this information to
beneficiaries to be consistent with our proposal that states would be responsible for collecting
beneficiaries permission for payer to payer exchange. We proposed that those impacted payers
would be required to provide these educational resources to patients at or before requesting
permission for the Payer-to-Payer API data exchange. As discussed previously, currently
enrolled patients must be given the opportunity to opt into the payer to payer data exchange and
to provide previous/concurrent payer information before the API compliance dates. We proposed
that impacted payers would be required to provide these educational resources to those currently
enrolled patients at or before requesting their opt in as well. In addition, we proposed that similar
resources would have to be provided annually to all covered patients in mechanisms that the
payer regularly uses to communicate with patients. Impacted payers would also be required to
post these resources in an easily accessible location on the payers public website. We requested
comment on whether it would reduce payers burden to only be required to provide these resources annually to any patients who have not opted in and those with known concurrent
payers.
Because we are finalizing a modification to our proposal and establishing Payer-to-Payer
API compliance dates in 2027 this requirement to provide educational resources is also being
moved from the proposed 2026.
Comment: Multiple commenters expressed support for CMSs proposed requirements
related to resources to educate patients about the benefits of data exchange between payers, the
patients right to opt in and to withdraw their permission, and instructions for doing so. Multiple
commenters supported CMSs proposals to require that patient educational resources be in non-
technical, simple, and easy to understand language. A commenter noted health literacy is the
single largest barrier to health care access for those with coverage. A commenter recommended
that CMS amend the patient resources requirements to require impacted payers to write resources
at the fourth to sixth grade reading level.
Response: We are slightly modifying the final regulation text to require that this
information be provided in plain language instead of using the longer, more cumbersome
phrase non-technical, simple, and easy-to-understand language. This modification does not
change the meaning of the requirement that the educational information be non-technical and
easy-to-use, but is intended to be more straightforward and to encourage impacted payers to
follow the Federal Governments plain language guidelines. Those guidelines were informed by
the Plain Writing Act of 2010, which requires Federal agencies use clear government
communication that the public can understand and use. That statute applies only to Federal
Government agencies, but we believe that the plain writing guidance developed for the Federal
Government will be useful for impacted payers when developing educational resources for patients. We also encourage payers to review and utilize the health literacy resources that the
AHRQ makes available on their website.86
We do not believe that it is prudent to establish a specific grade level requirement. A
grade level score is based on the average length of the words and sentences. Readability
formulae vary and the grade level scores for the same text can differ depending on how it is used.
Furthermore, edits that are done to make text score at a lower grade level can produce choppy
text that lacks cohesion.
However, we do note that 45 CFR part 92 requires impacted payers (such as health
programs or activities underthat section) to provide meaningful access to individuals with
limited English proficiency and accessibility requirements for individuals with disabilities. The
requirements of that part apply to impacted payers, as described at 45 CFR 92.3.
Comment: Multiple commenters recommended that CMS develop resources, such as
standardized language, tools, and delivery models, that payers could customize to ensure a
consistent message to patients on what will be a confusing and complicated topic. A commenter
noted that if CMS led the development, then the educational resources and programs for the
Payer-to-Payer API could be standardized across carriers, FFS program administrators,and
enrollment administrators to support consistent messaging and improve engagement with the
API.
Response: In an effort to assist payers in meeting these requirements, we intend to
provide templates or outlines for educational resources after this final rule is published and in
time for payers to review and use prior to the compliance dates. However, we do not expect
those resources to be fully sufficient to meet the requirements of this rule without additional
content and customization by payers to include their specific processes for patients to opt in or
withdraw their permission. To the extent possible, we encourage payers to collaborate on
86AgencyforHealthcareResearchandQuality(2023,May).PatientEducationandEngagement.Retrievedfrom
https://www.ahrq.gov/health-literacy/patient-education/index.html. standardized resources to ensure consistentmessaging to patients, regardless of the payer with
whom they are enrolled. However, we also expect each payer to have to customize their
resources with their own information and opt in process.
Comment: A commenter suggested that it would benefit both patients and providers for
us to allow third parties, such as an HIE or HIN, to provide educational resources to patients on
the payers behalf. The commenter stated that if multiple payers use the same third-party
resources, it could simplify the solution across the industry.
Response: Nothing in this rule will prevent a payer from working with a third party to
develop the educational resources discussed here or from using subcontractors or downstream
entities to the extent that program-specific laws permit that. As discussed in this section, payers
may use an HIE or HIN to facilitate the Payer-to-Payer API exchange. However, we encourage
payers to make it clear that any resources disseminated to patients under this requirement are
from the payer. Patients are unlikely to devote attention to resources they receive from entities
with which they are not familiar. While we expect that patients would recognize the name, logo,
and other markings of official correspondence from their payer, they are unlikely to recognize
their payers partners. Therefore, while a third party may develop (and send on the payers
behalf) the required educational resources, we strongly recommend that these resources be
clearly branded as communications from the patients payer.
Comment: Multiple commenters highlighted the need to educate patients specifically on
the opt in framework. Specifically, these commenters encouraged CMS to ensure that those
educational resources are easy for patients to find. Some commenters recommended including
that information in the patients enrollment resources, while others disagreed and believe that
that information may be easily missed within the larger quantity of information. A commenter
recommended that in addition to payers, Federal agencies should play a role in patient education
regarding data sharing. Another commenter recommended that CMS engage in testing patient
education and opt in notifications before the compliance dates. Response: We agree that it is particularly important for patients to understand what they
are opting in to. The educational information should highlight the benefits of API-based data
exchange and explain patients permission rights. Additionally, we emphasize that that
information should be communicated in a way that is conspicuous and makes clear to patients
that this policy provides them rights as consumers. However, each payer has different processes
and modalities for communicating with patients and we do not want to be prescriptive in a way
that may add unintended and unnecessary burden to payers.
As stated previously, we are committed to providing outlines or templates for these
educational resources. In developing those resources, we will prioritize using plain language for
patients. In addition, we have stated that Medicare FFS intends to conform to the requirements of
this rule,which includes patient educational resources. Beyond that, we will consider what role
CMS may play in patient education. However, we know that patients have a relationship with
their payers and expect to receive various communications from their payer relating to their
coverage. Therefore, patients are more likely to consider educational resources that come directly
from their payer. Further, these educational resources will need to include instructions for how
patients can opt into Payer-to-Payer API data exchange and withdraw their permission; such
instructions will need to be tailored to the specific procedures for each payer. While additional
education from Federal agencies may supplement information from payers, it is not a substitute.
Comment: Multiple commenters recommended that CMS limit the dissemination of
annual Payer-to-Payer API educational resources to only those patients who have not opted in
and those with known concurrent payers. A commenter recommended that making patient
educational resources available on a payers website should be sufficient and CMS should not
require payers to send that information on an annual basis.
Response: While we understand that there may be additionalburden to send all patients
educational resources annually, we believe that such a requirement is necessary. As discussed
previously, in section II.C.3.c.iv. of this final rule, patients must have the opportunity to withdraw their permission for payer to payer exchange at any time. While we generally expect
exchange between a previous and new payer to be a one-time transaction, we do allow for the
possibility of additional data exchanges, as discussed in section II.C.3.d.ii. of this final rule.
Therefore, the opportunity to withdraw permission needs to be offered to all patients at any time.
In order to be aware of this right, patients need to be informed of it. Payers are already required
to send information to patients annually and including information about payer to payer data
exchange should not be a significant burden to include with those resources. We do not believe
that it would serve patients to have resources and information about the Payer-to-Payer API data
exchanges and the patients rights to opt into and out of those data exchanges available only on a
payers website. That would require patients to affirmatively seek out that information on their
own, or to stumble across it by chance.
Comment: Multiple commenters encouraged CMS to use community outreach and
education campaigns to encourage patients to opt into sharing their data via the Payer-to-Payer
API.
Response: We will look into opportunities to educate patients on opting into data sharing.
As mentioned previously, we are committed to providing outlines or templates for these
educational resources. In developing those resources, we will prioritize patient comprehension.
Beyond that, we will consider what role CMS may play in patient education.
4. Payer to Payer Data Exchange in Medicaid and CHIP
a. Inclusion of Medicaid and CHIP Fee-for-Service
As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR
76267), we did not require state Medicaid and CHIP FFS programs to comply with the payer to
payer data exchange policies in the CMS Interoperability and Patient Access final rule (85 FR
25568).
We proposed to make the payer to payer data exchange policies in this rule applicable to
state Medicaid and CHIP FFS programs. We stated that requiring state Medicaid and CHIP FFS programs to implement the Payer-to-Payer API data exchange in this rule would not be as
burdensome as the non-API-based payer to payer data exchange that was finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25524), which we are now rescinding. That
is because this new API would be leveraging the same data and technical standards as the Patient
Access API. State programs should have already implemented Patient Access APIs and should
thus be able to leverage the work done for that API to make implementing this new API more
manageable. Additionally, in the proposed rule we discussed the various benefits that the Payer-
to-Payer API could produce for state Medicaid and CHIP programs, including creating
efficiencies, reducing burden, and improving health outcomes (87 FR 76276).
Comment: Commenters supported applying the proposed requirements to Medicaid and
CHIP FFS and agreed that such a policy would benefit Medicaid and CHIP beneficiaries who are
covered by FFS by improving care coordination and continuity of care. Other commenters stated
that the Payer-to-Payer API would reduce burden on patients and providers and allow state
Medicaid agencies to operate more efficiently.
Response: We appreciate the support for including state Medicaid and CHIP FFS as
impacted payers and are finalizing that proposal.
Comment: A commenter questioned the expected value of the Payer-to-Payer API to state
Medicaid agenciesand the return on investment for the time and effort to implement systems.
Response: Data exchange from one payer to another as patients transition between payers
is a powerful way to support care coordination and continuity of care during coverage
transitions, particularly in the Medicaid program where patients often churn in and out of the
program and between payers. Electronic data exchange between payers would support payer
operations and a patients coverage transition to a new payer efficiently and accurately.
b. Medicaid and CHIP  Seeking Permission Using an Opt In Approach in the Payer-to-Payer
API We proposed that state Medicaid and CHIP agencies, like other impacted payers,
establish a process to allow beneficiaries to optinto the payer to payer data exchange. We stated
that an opt in framework means that the beneficiary or their personal representative would need
to affirmatively permit state Medicaid and CHIP agencies to share their data, and without first
obtaining that permission, the agency could not engage in the payer to payer data exchange for
that beneficiary. In contrast, we proposed an opt out policy for the Provider Access API, in part,
based on the existence of a treatment relationship between the beneficiary and provider.
Specifically, our policy to only require the Provider Access API data exchange with enrolled
Medicaid and CHIP providers and require a process to attribute a patient to that provider before
data can be exchanged creates a level of assurance for the Medicaid or CHIP agency that it is
sending patient data to an appropriate party. Two payers exchanging information may not have a
direct relationship but would be exchanging data based on a patients separate relationship with
each payer. Therefore, in the proposed rule, we stated that it would make sense for the patient to
have a larger gatekeeping role and be required to provide affirmative permission for the Payer-
to-Payer API data exchange.
We proposed that state Medicaid and CHIP agencies, rather than their managed care
plans or managed care entities, would be responsible for obtaining the required permission. We
also proposed that the requirement to identify patients previous/concurrent payers would apply
to state Medicaid and CHIP agencies rather than managed care plans or managed care entities.
For clarity and consistency with existing Medicaid and CHIP rules, we also proposed that a
patients permission would not be necessary to exchange data between a state Medicaid or CHIP
agency and its contracted managed care plans or entities.
We explained in the proposed rule that the opportunity for newly enrolling patients to opt
in could take place through a single streamlined application, or at some later point of contact
with the beneficiary prior to enrollment, but in no instance would our proposals permit a delay in
the enrollment process or a beneficiarys coverage. We sought comments, specifically from states and contracted managed care plans and
entities, how we could establish standards for patientdata exchange for state Medicaid and CHIP
agencies and their contracted managed care plans and entities without creating additional barriers
or burden. We requested comment on the workflow and data exchanges that occur when a
Medicaid or CHIP beneficiary is enrolled into a managed care plan or entity and the feasibility of
sending patient permission during the enrollment process.
We considered proposing that the Payer-to-Payer API requirements would not apply for
beneficiaries moving between or with concurrent coverage with a state Medicaid or CHIP
agency and its contracted Medicaid or CHIP (as applicable) managed care plan or entity for the
reasons outlined previously. However, we are concerned that many states today do not exchange
data between their Medicaid or CHIP FFS programs and managed care programs. We requested
comments on whether there are other ways we can ensure patient data are exchanged in this case
in a manner that would reduce burden on states.
Comment: Multiple commenters recommended that CMS reexamine whether its
interpretation of 42 CFR 431.306(d) and 457.1110(b) would prohibit Medicaid agencies from
participating in HIEs. A commenter encouraged CMS to explain whether requirements at 42
CFR 431.306(d) and 457.1110(b) prohibits Medicaid and CHIP programs from sharing
beneficiary information with HIEs for the purposes of the Payer-to-Payer API. The commenters
advocated for CMS to make a change to privacy regulations to support an optout model
consistent with industry standards. Multiple commenters that agreed with the proposal
specifically recommended that state Medicaid and CHIP agencies leverage current solutions by
HIEs and HINs to implement the proposed opt in requirement.
Response: We do not agree that 42 CFR 431.306(d) and 457.1110(b) prohibit Medicaid
or CHIP agencies from contracting with an entity that offers the technology to allow for digital
access and transfer of a patient's medical records, often referred to as an HIE. Section 1902(a)(7)
of the Social Security Act (the Act), which our regulations at 42 CFR part 431, subpart F, implement, requires that a states Medicaid plan provide safeguards that restrict the use or
disclosure of information concerning Medicaid applicants and beneficiaries to purposes directly
connected with administration of the state plan. Our regulations at 42 CFR part 431, subpart F,
set forth requirements for states to safeguard Medicaid applicants and beneficiaries information
in accordance with section 1902(a)(7) of the Act, including requirements for safeguarding the
information, what types of information must be safeguarded, and when and how to release
otherwise safeguarded information. The same requirements also apply to separate CHIPs through
a cross reference at 42 CFR 457.1110(b). The disclosures of beneficiary data to an HIE
contracted to implement and maintain the required Payer-to-Payer API would be directly related
to the administration of the state plan because sharing beneficiary data through the Payer-to-
Payer API supports the provision of services for beneficiaries, as described at 42 CFR
431.302(c). States that share information about Medicaid beneficiaries or former beneficiaries
with their concurrent and new payers support opportunities for improved care coordination,
reduce time needed to evaluate beneficiaries current care plans, their health risks, and their
health conditions at the time they enroll with the Medicaid program, or another payer. Further,
under section 1902(a)(4) of the Act, Medicaid agencies may contract with organizations to
enhance the agency's capability for effective administration of the program.
The regulation at 42 CFR 431.306(d) generally requires states to obtain permission from
an individual Medicaid applicant or beneficiary, or their personal representative, before
responding to a request for information from an outside source to disclose that applicants or
beneficiarys data safeguarded under 42 CFR 431.305. State Medicaid and CHIP agencies may
share Medicaid and CHIP beneficiary information with entities with which the agency has
contracted to support the administration of its Medicaid or CHIP state plan. Such contractors
would not be considered outside sources because they are contracted to carry out functions
directly related to administration of the state Medicaid or CHIP plan. Thus, if a Medicaid or
CHIP agency contracts with an HIE to carry out administrative functions of the states Medicaid or CHIP program, including implementing and maintaining the required Payer-to-Payer API, the
HIE would not be considered an outside source and the state Medicaid or CHIP agency could
share Medicaid or CHIP beneficiary information with the HIE for purposes directly connected to
administration of the state plan without prior permission from the Medicaid or CHIP beneficiary
required by 42 CFR 431.306(d) and 457.1110(b), respectively. Regardless, whether a Medicaid
or CHIP agency contracts with an HIE to develop and maintain the required Payer-to-Payer API,
the Medicaid or CHIP agency is responsible for ensuring the contracted entity implements a
Payer-to-Payer API that meets allregulatory requirements, which includes that an individual or
their representative has provided permission (opted in) prior to their information being shared
with other payers via the Payer-to-Payer API.
In addition, to receive beneficiaries information from the Medicaid or CHIP agency,
Medicaid or CHIP providers, plans, or contractors must be subject to standards of confidentiality
comparable to those of the state Medicaid and CHIP agency in accordance with 42 CFR
431.306(b) and 457.1110(b) respectively. Furthermore, Medicaid regulation at 42 CFR
434.6(a)(8) requires that each of the state Medicaid agencys contracts must provide that the
contractor safeguards information about beneficiaries as required by 42 CFR part 431, subpart F.
Under these requirements, if a state Medicaid or CHIP agency contracted with an HIE or other
entity, the contractor would be required to meet the same standards of confidentiality as the state
Medicaid agency (as set forth in section 1902(a)(7) of the Act and our implementing regulations
at 42 CFR part 431, subpart F), including but not limited to:
 Providing safeguards that restrict the use or disclosure of information concerning
applicants and beneficiaries to purposes directly connected with the administration of the plan in
accordance with section 1902(a)(7) of the Act and 42 CFR 431.300 and 431.302; and
 Not disclosing data to an outside source, such as non-Medicaid or non-CHIP payers with
whom the HIE might exchange data, without prior permission from the individual in accordance
with 42 CFR 431.306(d). We did not propose any changes to Medicaid or CHIP confidentiality regulations at 42
CFR part 431, subpart F, and 42 CFR 457.1110(b), but we appreciate the comment and will
consider it for any future rulemaking.
Comment: A commenter stated that an opt in process implemented within its system
would not authorize another payer (particularly payers not subject to this regulation) to release
patient information to the commenter or for the commenter to release a patients data to a
patients subsequent payer.
Response: All data received, maintained, used, or shared via this proposed Payer-to-Payer
API must be received, maintained, used, or shared in a way that is consistent with all applicable
laws and regulations. As discussed previously, our regulation for Medicaid at 42 CFR 431.306
(incorporated via cross reference for CHIP at 42 CFR 457.1110(b)) sets forth certain
requirements for release of Medicaid and CHIP applicant and beneficiary data. Consistent with
our proposal, we are finalizing that when another payer (including a payer not subject to this
final rule) is requesting a former Medicaid or CHIP beneficiarys information from the state
Medicaid or CHIP agency, an attestation from a requesting payer that the patient or their
representative has opted into data exchange with the requesting payer (that is, given permission
for the Medicaid or CHIP agency to share the beneficiarys data) is sufficient to meet the
requirements at 42 CFR 431.306 and 457.111(b) to allow the state Medicaid or CHIP agency to
respond to the data request, though such permission must be received prior to the state Medicaid
or CHIP agency sharing any beneficiary data. For more information about how the HIPAA
Privacy Rule interacts with Payer-to-Payer API, see section II.C.3.c.iv.
Comment: Multiple commenters agreed with the proposal for state Medicaid and
CHIP agencies to collect and manage patient decisions to opt into the payer to payer data
exchange when beneficiaries are enrolled in Medicaid or CHIP managed care. Multiple
commenters agreed that collecting a beneficiarys choice to opt into the payer to payer data
exchanges as part of existing Medicaid and CHIP eligibility and enrollment processes would be the most effective and technically feasible approach for most states operating managed care
programs in Medicaid and CHIP and would streamline the process for beneficiaries.
Response: For many reasons, we agree that the state Medicaid or CHIP program is the
appropriate custodian of the patients permission record, rather than the particular managed care
plan or managed care entity through which a patient receives Medicaid or CHIP covered
services. A Medicaid or CHIP beneficiary may switch between FFS and managed care delivery
systems within the same states Medicaid or CHIP program. Despite these shifts, an eligible
beneficiary remains a beneficiary of the state program. States may also change the Medicaid or
CHIP managed care plans or entities with which they contract. Thus, a Medicaid or CHIP
beneficiarys opt into the payer to payer data exchange, should be obtained by the state and will
apply regardless of the delivery system in which the beneficiary is enrolled. Furthermore,we
understand that in many states, managed care plans may not have any contact with beneficiaries
prior to their enrollment in the Medicaid managed care plan or CHIP managed care entity.
We believe the ideal time to allow patients to opt into the payer to payer data exchange is
during their application for Medicaid or CHIP. As stated previously, obtaining a patients opt in
permission and identifying the previous/concurrentpayer(s) cannot delay an applicants
eligibility determination or start of coverage. If a state has all the information necessary to
determine an individuals eligibility before it obtains the individuals permission for the payer to
payer data exchange, the state must determine the individuals eligibility and enroll the
individual in Medicaid or CHIP coverage, if determined eligible, while continuing to follow the
Payer-to-Payer API requirements as expeditiously as possible post-enrollment.
Because we expect higher rates of patients to opt in when they are presented with the
option at a point when they are already providing information (such as at application or plan
selection), we highly encourage states to leverage any touchpoints before patients are enrolled in
Medicaid or CHIP rather than expecting patients to opt in through a separate process. We are finalizing our proposal to require the state to establish a process for obtaining opt
into the payer to payer data exchange prior to the state Medicaid or CHIP agencys Payer-to-
Payer API compliance dates, and prior to the enrollment of new beneficiaries after that date, and
that the state Medicaid and CHIP agencies will be responsible for obtaining the required
permission.
To the extent that doing so is consistent with Federal Medicaid and CHIP requirements,
including those at section 1902(a)(7) of the Act and implementing regulations at 42 CFR part
431, subpart F, and applied to separate CHIPs through a cross reference at 42 CFR 457.1110(b),
Medicaid and CHIP agencies are welcome to contract with HIEs or HINs, especially those
operating under TEFCA, to facilitate payer to payer data exchange. Some HIEs may already
have the technical framework to manage patient consent or engage in standardized data exchange
via FHIR APIs in ways that Medicaid or CHIP agencies systems do not. Nothing in this rule
would prohibit a Medicaid or CHIP agency from partnering with an HIE to meet its
requirements, but Medicaid and CHIP agencies must continue to comply with all other Federal
requirements applicable to the operation of Medicaid and CHIP.
Comment: Multiple commenters expressed concerns about state Medicaid and CHIP
agencies resources to collect and manage patient decisions to opt into the exchange of their data
via the Payer-to-Payer API. A commenter stated that it may need to build separate functionality
to support implementation of the opt in requirement if it is unable to support the requirement
within the states existing eligibility system. A commenter noted that it will require significant
work to implement an opt in process in states and territories where the Medicaid agency does not
complete eligibility and enrollment processes and recommended that CMS ensure an appropriate
implementation timeline in these instances. A commenter suggested that CMS work with states
to implement a consistent solution to avoid inconsistencies in what data are collected and how to
address the concern about resources. Another commenter specifically expressed that the process
to identify a previous/concurrent payer would be challenging for Medicaid. Response: We understand and appreciate that state Medicaid and CHIP agencies will
need to create new processes to request a patient's permission to exchange data and identifying
information about their previous/concurrent payer(s), and then to share that information with
their managed care plans and managed care entities. States have different eligibility and
enrollment processes, and a one-size-fits all approach may not be optimal. We are not being
prescriptive on this process, as we want each program to implement the requirements in the least
burdensome, most efficient way for them.
We also understand that making changes to applications can be a significant
administrative process, and for states where Medicaid or CHIP eligibility is determined by a state
or regional agency other than the Medicaid or CHIP agency, there will be additional
administrative steps to implementation. We are extending our compliance dates for the Payer-to-
Payer API from our proposed 2026 to 2027 in order to provide adequate time for payers to
implement these requirements. Further, there may be other places where a state could obtain a
patients data exchange permission for the Payer-to-Payer API data exchange. For instance, a
state could leverage an online portal or app, if beneficiaries frequently use those pathways for
other purposes, such as reporting a change in circumstance or providing information for
eligibility renewal. However, the option should be equally available for all beneficiaries and if
only a small portion of the Medicaid or CHIP population uses these tools to communicate with
the Medicaid or CHIP agency, that subset would be self-selected for greater technology literacy
and taking this approach could exacerbate inequality.
We note that the single streamlined application, which for Medicaid and CHIP purposes
is described at 42 CFR 435.907(b)(1) and 457.330, respectively, and is also used for applications
through the FFEs, includes questions about concurrent coverage information. We also expect that
some states that do not use the single streamlined application already ask for this information for
Coordination of Benefits and Third-Party Liability purposes. We believe that it would generally
make sense to gather permission for payer to payer data exchange at the point the state collects concurrent payer information. We note that the patient permission provisions in this rule will
apply only to the payer to payer data exchange discussed here and would notaffect states ability
to perform Coordination of Benefits or Third-Party Liability activities as they do today.
Comment: Multiple commenters stated that CMS should ensure that regulatory language
clearly makes the opt in requirement applicable to Medicaid managed care plans.
Response: We intentionally did not include regulatory text requiring Medicaid managed
care plans and CHIP managed care entities to meet the requirement to collect patient permission
for payer to payer data exchange. As discussed in section II.C.4.b. of this final rule, we are
finalizing that requirement for state Medicaid and CHIP agencies because we believe that they
are the proper entity to hold a patients opt in decision. State Medicaid and CHIP agencies may
work with their managed care plans and entities to gather that information, but ultimately the
requirement to gather and maintain that information is the responsibility of the state Medicaid or
CHIP agency. As proposed and discussed in section II.E.2.a. of this final rule, we are finalizing
that the responsibility to collect patient permission for the Payer-to-Payer API data exchange is
not eligible for exemption from the API requirements. Therefore, even if a state receives an
exemption from the Payer-to-Payer API, it is still responsible for collecting and maintaining a
record of patient opt in permission for this data exchange. We note that we are also finalizing
that state Medicaid and CHIP programs, rather than their managed care organizations, are
responsible for providing educational resources at the time of requesting permission for payer to
payer data exchange and for collecting identifying information about patients
previous/concurrent payer(s).
Comment: A commenter requested clarification on whether a patients opt in permission
is required to share data between impacted payers within the same state Medicaid program.
Another commenter asked us to explain what types of managed care plans are included in this
statement (for example, MCOs, PIHPs, PAHPs, Primary Care Case Managers (PCCMs),
integrated plans for patients dually eligible for Medicare and Medicaid). Response: As we explained in the preamble to the proposed rule (87 FR 76238), we know
that state Medicaid or CHIP agencies regularly exchange data with their managed care plans and
entities. We do not intend the opt in requirements for the Payer-to-Payer API to interfere with or
affect this permissible exchange. Medicaid managed care plans, and CHIP managed care entities
are not outside sources as described at 42 CFR 431.306(d), but are part of a states Medicaid
and/or CHIP programs as a whole, because these entities are contracted to support the agencys
administration of its Medicaid or CHIP state plan. Specifically, Medicaid managed care plans
and CHIP managed care entities are contracted with the Medicaid state agency to deliver
Medicaid program health care services to beneficiaries under the state plan.
Hence, we are finalizing our proposal that if a Medicaid or CHIP agency is exchanging
information per our Payer-to-Payer API proposals with a managed care plan or managed care
entity with which they have a contract, the requirement to obtain patient optin would not apply.
We consider any plan and entity that has a contract with the state Medicaid or CHIP agency to
deliver Medicaid program health care services to beneficiaries under the state plan, including
state Medicaid agency contracts with D-SNPs under 42 CFR 422.107, to be part of the states
Medicaid or CHIP programs, regardless of the coverage model. We note that this policy and opt
in requirement to share data between impacted payers would not replace regulatory requirements
as described at 42 CFR part 422, including as they relate to integrated D-SNPs.
We note that permissible data exchange only covers data that facilitate that plans
contracted services. For instance, it would be inappropriate to share patient data with a managed
care plan or entity other than the one with which the patient is enrolled. The other Payer-to-Payer
API requirements, such as the requirement to use a FHIR API and the authorization and
authentication protocols would apply to data exchange required in this final rule between state
Medicaid and CHIP agencies and their managed care plans or managed care entities. The
exchange must also not be prohibited by other law. c. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of
Payer to Payer Data Exchange
In section II.E. of this final rule, we discuss Federal matching funds for certain state
Medicaid and CHIP FFS programs expenditures related to implementation of the payer to payer
data exchange (this was also addressed in the proposed rule at 87 FR 76278).
d. Medicaid Expansion CHIP
In section II.E. of this final rule, we discuss implementation for states with Medicaid
Expansion CHIP programs (this was also addressed in the proposed rule at 86 FR 76279).
5. Extensions, Exemptions, and Exceptions
See section II.E. of this final rule for a discussion of extensions and exemptions and the
final policies for the Payer-to-Payer API for state Medicaid and CHIP FFS programs and
exceptions for the Payer-to-Payer API for QHP issuers on the FFEs (this was also addressed in
the proposed rule at 86 FR 76279). Es (ii) (v)
F ) ) ) ) ) ) ) )
F (1 (2 (3 (4 (4 (4 (6 (7
n b) b) b) b) b) b) b) b)
o ( ( ( ( ( ( ( (
HPs CFR6.222 CFR6.222 CFR6.222 CFR6.222d(5) CFR6.222 CFR6.222 CFR6.222 CFR6.222
Q 55 55 55 55n 55 55 55 55
41 41 41 41a 41 41 41 41
re 2at 2at 2at
LICIES CHIPgedCaManaThroughexistingcrossreferenceto4CFR438.24242CFR(d)457.1233N/A N/A Throughexistingcrossreferenceto4CFR438.24242CFR457.1233(d) Throughexistingcrossreferenceto4CFR438.24242CFR457.1233(d)
O
LPer S ) ) ) ) )(ii) )(v) ) )
y F 1 2 3 4 4 4 6 7
EFINAactedPa CHIPF CFR7.731(b)( CFR7.731(b)( CFR7.731(b)( CFR7.731(b)(d(5) CFR7.731(b)( CFR7.731(b)( CFR7.731(b)( CFR7.731(b)(
Gmp 4245 4245 4245 4245an 4245 4245 4245 4245
NI
ERDATAEXCHARegulationsforEach MedicaidManagedCareThroughcrossreferenceto42CFR431.61(b)(1)at42CFR438.242(b)(7) N/A N/A Throughcrossreferenceto42CFR431.61(b)(4)and(5)at42CFR438.242(b)(7)Throughcrossreferenceto42CFR431.61(b)(4)(ii)at42CFR438.242(b)(7) Throughcrossreferenceto42CFR431.61(b)(4)(v)at42CFR438.242(b)(7)Throughcrossreferenceto42CFR431.61(b)(6)at42CFR438.242(b)(7) Throughcrossreferenceto42CFR431.61(b)(7)at42CFR438.242(b)(7)
Y
A FS (ii) (v)
P F 1) 2) 3) 4) 4) 4) 6) 7)
ERTO Medicaid 2CFR31.61(b)( 2CFR31.61(b)( 2CFR31.61(b)( 2CFR31.61(b)(nd(5) 2CFR31.61(b)( 2CFR31.61(b)( 2CFR31.61(b)( 2CFR31.61(b)(
Y 44 44 44 44a 44 44 44 44
A
P d
LED1: edicaregevantaR1(b)(1) R1(b)(2) R1(b)(3) R1(b)(4)an R1(b)(4)(ii) R1(b)(4)(v) R1(b)(6) R1(b)(7)
AB MAdCF2.12 CF2.12 CF2.12 CF2.12 CF2.12 CF2.12 CF2.12 CF2.12
T 22 22 22 225) 22 22 22 22
44 44 44 44( 44 44 44 44
Requirement TechnicalStandards(CompliancedateJanuary1,2027) OptIn(CompliancedateJanuary1,2027)IdentifyPreviousandConcurrentPayers(CompliancedateJanuary1,)2027DataExchangeRequirement(CompliancedateJanuary1,2027)AccessibleContentandAPIRequirements(CompliancedateJanuary1,2027)DataIncorporation(CompliancedateJanuary1,2027) ConcurrentCoverageDataExchangeRequirements(CompliancedateJanuary1,2027) PatientEducationalResourcesRegardingAPI(CompliancedateJanuary1,2027)
ofal
ctioneFinRule C.3.a. C.3.c. C.3.c. C.3.d. C.3.b. C.3.f. C.3.e. C.3.g.
Seth II. II. II. II. II. II. II. II. s
E
F
F
n c)
o (
R2
Ps F22
H A A C6.
Q N/ N/ 4515
e
r
a
C
P
Id
He
g
Ca
n
aA A A
MN/ N/ N/
r
e S ) )
y F 1 2
Pa F c)( c)(
d IP R1( R1(
acte CH CF7.73 CF7.73 A
mp 4245 4245 N/
I
h
c d
a e
E g
a
or n
f a
ons dMCare
ti ai
a c
ul di
eg Me A A A
R N/ N/ N/
S
F
F ) )
1 2
d ( (
edicai CFR1.61(c) CFR1.61(c) A
M 4243 4243 N/
carentage
dia
ev
Md
A
A A A
N/ N/ N/
Requirement ExtensionforMedicaidandCHIPFFS(EffectiveDateoftheFinalRule)ExemptionforMedicaidandCHIPFFS(EffectiveDate)ofFinalRuleExceptionsforQHPIssuersontheFFEs(EffectiveDateof)theFinalRule
ofal
nne
ctioeFiRul C.5. C.5. C.5.
Seth II. II. II. 6. Final Action
After considering the comments received, and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule and our response to those comments (as
summarized previously), we are finalizing our proposal with the following modifications:
 Impacted payers must implement and maintain a Payer-to-Payer API beginning in
2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS programs; by
the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and
CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP
issuers on the FFEs) rather than in 2026.
 Impacted payers are not required to share the quantity of items or services used
under a priorauthorization via the Payer-to-Payer API.
 The data exchange between a previous payer and a new payer is limited to data
with a date of service within the previous 5 years.
 Impacted payers are required to request patients permission for payer to payer
data exchange and identifying information about patients previous/concurrent payers no later
than 1 week after the start of coverage, as that term is defined for each type of impacted payer,
rather than at enrollment.
See further discussion for the exact details of the final requirements for impacted payers.
We are finalizing the rescission of the payer to payer data exchange policy previously
finalized in the CMS Interoperability and Patient Access rule (85 FR 25568) at 42 CFR
422.119(f)(1) and 438.62(b)(1)(vi) and (vii) and 45 CFR 156.221(f)(1).
We are finalizing a requirement that, beginning in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers
must implement and maintain a Payer-to-Payer API that is conformant with certain technical standards, documentation requirements, and denial or discontinuation policies. Specifically,
those technical standards are HL7 FHIR R4 at 45 CFR 170.215(a)(1), US Core IG at 45 CFR
170.215(b)(1)(i), and Bulk Data Access IG at 45 CFR 170.215(d)(1).
We are also finalizing a requirement that, by the deadlines, impacted payers (except
Medicaid managed care plans and CHIP managed care entities) must establish and maintain a
process to gather patient permission for payer to payer data exchange no later than 1 week after
the start of coverage. We are finalizing an opt in framework whereby a patient or personal
representative must affirmatively agree to allow that data exchange. Impacted payers must also
have a process for patients to change their permission at any time.
We are finalizing a requirement that, by the deadlines, impacted payers mustestablish
and maintain a process to identify a patients previous/concurrent payer(s) no later than 1 week
after the start of coverage. As part of this process, impacted payers are required to allow a patient
to report multiple previous/concurrent payers if they had (or continue to have) concurrent
coverage. If a patient does report multiple previous payers, impacted payers are required to
request that patients data from all previous/concurrent payers. If a patient does not respond or
additional information is necessary, the impacted payer must make reasonable efforts to engage
with the enrollee to collect this information.
We are also finalizing a requirement that, no later than the compliance dates, impacted
payers must establish and maintain a process to gather permission and previous/concurrent
payer(s) information from patients who are already enrolled.
We are finalizing a requirement that, by the deadlines, impacted payers mustrequest a
patients data from a patients previous/concurrent payer(s) no later than 1 week after the payer
has sufficient identifying information and the patienthas opted in. Impacted payers must also
request data from a patients previous/concurrent payers(s) within 1 week of that patients
request to do so. Impacted payers must include an attestation with this request for data affirming that the patient is enrolled with the requesting payer and has opted into the data exchange in a
manner that meets the legal requirements.
Additionally, we are finalizing a requirement that, by the deadlines, when an impacted
payer has sufficient identifying information and the patient has opted in, they must request data
from any concurrent payers at least quarterly. Impacted payers who receive a request for a
patients data from a known concurrent payer must respond with the required data within 1
business day of receiving the request.
We are finalizing a requirement that, by the deadlines, upon receiving a request that
meets the legal requirements, impacted payers must make any of the required information that
they maintain available to new payers no later than 1 business day after receiving the request.
We are finalizing a requirement that, by the deadlines, impacted payers mustmake
available via the Payer-to-Payer API, by request from payer that meets certain requirements,
claims and encounter data (excluding provider remittances and patient cost-sharing information),
alldata classes and data elements included in a content standard at 45 CFR 170.213, and certain
information about prior authorization requests and decisions (excluding those for drugs and those
that were denied) that the payer maintains with a date of service within 5 years of the request.
The required information is--
 The prior authorization status;
 The date the prior authorization was approved;
 The date or circumstance under which the prior authorization ends;
 The items and services approved; and
 Structured and unstructured administrative and clinical documentation submitted by a
provider.
We are finalizing a requirement that impacted payers are required to make this
information about prior authorizations available for the duration that the authorization is active
and for at least 1 year after the prior authorizations last status change. We are finalizing a requirement that, by the deadlines, information received by an
impacted payer through the payer to payer data exchange must be incorporated into the payers
patient record.
We are finalizing a requirement that, by the deadlines, impacted payers (except Medicaid
managed care plans and CHIP managed care entities) must provide educational resources to their
patients about the Payer-to-Payer API in plain language. These resources must include
information about the benefits of Payer-to-Payer API data exchange, the patients ability to opt
in or withdraw that permission, and instructions for doing so. Impacted payers must make this
information available to patients when requesting the opt in decision. Thereafter, impacted
payers must provide this information to patients annually, in mechanisms the payer ordinarily
uses to communicate with patients. These resources must also be available in an easily accessible
location on payers public websites.
These final policies apply to MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities (excluding NEMT PAHPs), and QHP
issuers on the FFEs at the CFR sections listed in Table D1. 7. Statutory Authorities for Payer to Payer Data Exchange Proposals
We note that we received no public comments on the statutory authorities for our Payer-
to-Payer API policies.
a. MA Organizations
For MA organizations, we are finalizing these Payer-to-Payer API requirements under
our authority at section 1856(b) of the Act to adopt by regulation standards consistent with and to
carry out Part C of Title XVIII of the Act (such as section 1852(d)(1)(A) of the Act). In addition,
section 1857(e)(1) of the Act authorizes the Secretary to adopt contract terms and conditions for
MA organizations that are necessary, appropriate, and not inconsistent with the statute.In total,
the regulations we are adopting in this final rule for MA organizations and MA plans are
necessary and appropriate because they address and facilitate continued access to enrollees
medical records and health information when they change payers, which will support consistent
and appropriate coordination of coverage when enrollees have concurrent payers and will
support coordination of care and continuation of active courses of treatment when enrollees
change payers.
In regulations establishing the MA program,87 CMS described it as a program designed
to: provide for private plan options available to Medicare beneficiaries, especially those in rural
areas, enrich the range of benefit choices, provide incentives to plans and add specialized plans
to coordinate and manage care in ways that comprehensively serve those with complex and
disabling diseases and conditions, use competition to improve service and benefits, invest in
preventive care, hold costs down in ways that attract enrollees, and advance the goal of
improving quality and increasing efficiency in the overall health care system. This final rule
supports these goals and enables the MA program to advance services for its enrollees by
87MedicareProgram:EstablishmentoftheMedicareAdvantageProgram,70FR4588(January28,2005)(tobe
codifiedat42CFRpart417). providing greater access to information in a way that will improve care management for payers,
providers, and the patient.
Section 1856(b)of the Act requires the Secretary to establish regulatory standards for
MA organizations and plans that are consistent with, and carry out, Part C of the Medicare
statute, Title XVIII of the Act. The Payer-to-Payer API proposals support MA organizations
sharing certain claims, encounter, and clinical data, as well as priorauthorization requests and
decisions, with another payer that, as identified by the enrollee, has or does cover the enrollee.
Such exchanges of data about patients could facilitate continuity of care and enhance care
coordination. As discussed forthe Provider Access API in section II.B. of this final rule,
allowing payers to share health information for one or more patients at once could increase
efficiency and simplicity of administration. Though we are not requiring payers to share data for
more than one patient at a time, there are efficiencies to doing so, both for communicating
information and for leveraging available technology.
Further, providing MA organizations with additional data about their enrollees through
these data exchanges will increase the scope of data that the MA organizations must make
available to enrollees through the Patient Access API. It will give payers access to alltheir
enrollees information with limited effort and enable the payer to then make that information
available to providers and to enrollees through the Provider Access and Patient Access APIs. It
may reduce the amount of time needed to evaluate a patients current care plan and possible
implications for care continuity, which may introduce efficiencies and improve care. As
discussed earlier, if a new payer receives information and documentation aboutprior
authorization requests from a previous payer, the new payer can review this information and
determine that a new prior authorization may not be necessary for an item or service that was
previously approved. Instead, the same care may be continued, reducing burden on both payers
and providers, and improving patient care. While the statutory provisions governing the MA
program do not explicitly address sharing data with other payers that cover or have covered an enrollee, the benefits to be gained by sharing data make adoption of Payer-to-Payer API policies
necessary and appropriate for the MA program. Further, requiring use of the API and the
specifications for the data to be shared provides a step toward greater interoperability among
payers. Ultimately, using the Payer-to-Payer API is anticipated to ensure that payers receive
patient information in a timely manner, which could lead to more appropriate service utilization
and higher patient satisfaction. Such goals are consistent with the MA statute.
Section 1852(h)of the Act requires MA organizations to provide their enrollees with
timely access to medical records and health information as far as MA organizations maintain
such information. As technology evolves to allow for faster, more efficient methods of
information transfer, so do expectations as to what is generally considered timely. Currently,
consumers across public and private sectors have become increasingly accustomed to accessing a
broad range of personal records, such as bank statements, credit scores, and voter registrations,
immediately through electronic means and with updates received in near real-time. Thus, we to
align our standards with current demands, we must take steps for MA enrollees to have
immediate, electronic access to their health information and plan information. The information
exchanged via the Payer-to-Payer API will ultimately be accessible to enrollees via the Patient
Access API and will therefore improve timeliness to medical records and health information as
enrollees will no longer have to spend time contacting previous payers to access their
information. These data will be accessible as needed by the enrollees current payer and would
therefore support timely access.
Section 1852(d)(1)(A) of the Act requires MA organizations to, as a condition of using a
network of providers, make covered benefits available and accessible to enrollees in a manner
which assures continuity in the provision of benefits. In implementing section 1852(d)(1)(A) of
the Act, we adopted a regulation, at 42 CFR 422.112(b), that requires MA organizations to
ensure the continuity of care and integration of services through arrangements with providers
that include procedures to ensure that the MA organization and the contracted providers have access to the information necessary for effective and continuous patient care. Consistent with
section 1852(d)(1)(A) of the Act, the final requirement here for MA organizations to implement
and maintain a Payer-to-Payer API will facilitate exchanges of information about enrollees that
are necessary for effective and continuous patient care. Under this final rule, the data received
from other impacted payers will become part of the data the MA organization maintains and will
therefore be available (subject to other law authorizing the disclosure) to providers via the
Provider Access API discussed in section II.B. of this final rule; the data could then be used for
treatment and coordination of care purposes.
The finalized policies in this rule are necessary, appropriate, and consistent with Part C of
Title XVIII of the Act. Overall, establishing these regulatory requirements for MA organizations
will improve enrollees quality of care by ensuring that they do not lose their patient records
when they change payers.
b. Medicaid and Childrens Health Insurance Program
Our provisions in this section fall generally under our authority in the following
provisions of the Act.
 Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such
methods of administration as are found by the Secretary to be necessary for the proper and
efficient operation of the state Medicaid plan.
 Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services
are furnished with reasonable promptness to all eligible individuals.
 Section 1902(a)(19) of the Act, which requires states to ensure that care and services
are provided in a manner consistent with simplicity of administration and the best interests of the
recipients.
The final requirements related to the Payer-to-Payer API are authorized by sections
1902(a)(4), (a)(8), and (a)(19) of the Act for the following reasons. First, because the Payer-to-
Payer API is designed to enable efficient exchange of data between payers, we anticipate that it will help state Medicaid programs improve the efficiencies and simplicity of their own
operations under a Medicaid state plan, consistent with sections 1902(a)(4) and (a)(19) of the
Act. It will give Medicaid agencies and their managed care plans access to their beneficiaries
information in a standardized manner and enable states to then make that information available
to providers and patients through the Patient Access and Provider Access APIs. It may also
reduce the amount of time needed to evaluate a patients current care plan and have possible
implications for care continuity, which may introduce efficiencies and improve care. Receiving
patient information at the start of coverage will lead to more appropriate service utilization and
higher beneficiary satisfaction by Medicaid agencies and those managed care plans considered
impacted payers under this final rule by supporting efficient care coordination and continuity of
care, which could lead to better health outcomes.
As discussed in section II.C.3.b. of this final rule, when a state Medicaid program has
access to a previous payers prior authorization decisions, the Medicaid program may choose to
accept the existing decision and support continued patient care without requiring a new prior
authorization or duplicate tests. This information exchange might also improve care continuity
for beneficiaries who have concurrent coverage in addition to Medicaid by improving the
coordination of health coverage they receive, reducing gaps, or duplication of coverage.
Our final rule is expected to help states and managed care plans furnish Medicaid
services with reasonable promptness and in a manner consistent with beneficiaries best interests,
consistent with sections 1902(a)(8) and (a)(19) of the Act. A significant portion of Medicaid
beneficiaries experience coverage changes and churn in a given year.88 Therefore, exchanging
this information with a beneficiarys next payer may also better support care continuity for
Medicaid beneficiaries. When states share information about Medicaid beneficiaries or former
88ChurningoccurswhenpeopleloseMedicaidcoverageandthenre-enrollwithinashortperiodoftime.Medicaid
beneficiariesfrequentlyexperiencechurning.SeeU.S.DepartmentofHealthandHumanServices,Assistant
SecretaryforPlanningandEvaluation(2021,April12).Medicaidchurningandcontinuityofcare:Evidenceand
policyconsiderationsbeforeandaftertheCOVID-19pandemic(issuedApril12,2021).Availableat:
https://aspe.hhs.gov/reports/medicaid-churning-continuity-care. beneficiaries with their concurrent and next payers, they can support opportunities for improved
care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information
about Medicaid beneficiaries and former beneficiaries between payers might also reduce the
amount of time needed to evaluate beneficiaries current care plans, their health risks, and their
health conditions at the time they enroll with the Medicaid program, as well as with another
payer. This information exchange might be of particular value to improve care continuity for
beneficiaries who might churn into and out of Medicaid coverage. The final rule may also
improve the provision of Medicaid services, by potentially helping to ensure that Medicaid
beneficiaries who may require coordinated services with concurrentpayers can be identified and
provided case management services, reduce duplication of services, and improve the
coordination of care, as appropriate.
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
purposes that are directly connected with the administration of the Medicaid state plan. The
implementing regulations at 42 CFR part 431, subpart F, for section 1902(a)(7) of the Act list
purposes that CMS has determined are directly connected with administration of Medicaid state
plans (42 CFR 431.302) and require states to provide safeguards meeting certain requirements to
restrict uses and disclosures of Medicaid beneficiary data, including requirements aboutreleasing
applicant and beneficiary information at 42 CFR 431.306.
Requiring the data described in this section to be shared via the Payer-to-Payer API is
consistent with states requirements to provide safeguards meeting certain requirements to share
these data since it is related to providing services for beneficiaries, a purpose listed at 42 CFR
431.302(c). As described previously in sections II.A.5.b. and II.B.6.b. of this final rule related to
authority under sections 1902(a)(8) and 1902(a)(19) of the Act, states that share information
about Medicaid beneficiaries or former beneficiaries with their concurrent and next payers, may
support opportunities for improved care coordination, reduction in the amount of time needed to evaluate beneficiaries current care plans, their health risks, and their health conditions at the
time they enroll with the Medicaid program, as well as with another payer. This information
exchange might be of particular value to improve care continuity for beneficiaries who churn
into and outof Medicaid coverage, described in more detail previously. When state Medicaid
agencies share medical records or any other health or enrollment information pertaining to
individual beneficiaries, they must comply with the requirements of 42 CFR part 431, subpart F,
including 42 CFR 431.306.
For Medicaid managed care,and in addition to the general authorities cited previously
regarding Medicaid programs, the finalized exchange of adjudicated claims and encounter data,
alldata classes and data elements included in a content standard at 45 CFR 170.213 (USCDI),
and certain information about prior authorizations maintained by the payer with a date of service
within 5 years of the request by a patients new or concurrent payer will greatly enhance an
MCOs, PIHPs, or PAHPs ability to fulfill its obligations under 42 CFR 438.208(b), which
require them to: implement procedures to deliver care to and coordinate services including
ensuring that each enrollee has an ongoing source of appropriate care; coordinate services
between settings of care, among Medicaid programs, and with community and social support
providers; make a best effort to conduct an initial screening of each enrollee's needs; and share
with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any
identification and assessment of that enrollee's needs to prevent duplication of those activities.
The data provided via the Payer-to-Payer API in this final rule will give managed care plans the
information needed to perform these required functions much more easily, thus enhancing the
effectiveness of the care coordination, and helping enrollees receive the most appropriate care in
an effective and timely manner.
For CHIP, we finalized these requirements under our 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. The provisions in this final
rule can strengthen our ability to fulfill these statutory obligations in a way that recognizes and
accommodates using electronic information exchange in the health care industry today and will
facilitate a significant improvement in the delivery of quality health care to our beneficiaries.
As with the Medicaid FFS and Medicaid managed care programs, the provisions in this
section of the final rule for CHIP FFS and CHIP managed care entities require using a Payer-to-
Payer API to exchange claims, encounter, clinical and prior authorization data at a beneficiarys
request, or any time a beneficiary changes payers, using a FHIR API. The current payer can use
data from the previous payer to respond to a request for a prior authorization more effectively or
accurately, because under this final rule, a new payer will have historical claims or clinical data
upon which they may review a request with more background data. Access to information about
new patients will enable appropriate staff within the CHIP program to coordinate care and
conduct care management more effectively because they will have better data available to make
decisions for planning. In many cases, patients do not remember what services they have had, or
other possibly relevant encounters that could help payers manage their care. This final rule is
consistent with the goal of providing more informed and effective care coordination, which will
help to ensure that CHIP services are provided in a way that supports quality care, which aligns
with section 2101(a) of the Act.
Finally, the safeguards for applicant and beneficiary information at 42 CFR part 431,
subpart F, are also applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As
discussed previously for Medicaid, CHIP agencies data exchange through the Payer-to-Payer
API is related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as
a purpose directly related to state plan administration. We remind states that when they share
medical records or any other health or enrollment information pertaining to individual
beneficiaries, they must comply with the privacy protections at 42 CFR 457.1110 and the release
of information provisions at 42 CFR 431.306. c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we finalized 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.
Requiring QHP issuers on the FFEs to implement and maintain a Payer-to-Payer API will
allow the seamless flow from payer to payer of adjudicated claims, and encounter data, all data
classes and data elements included in a standard at 45 CFR 170.213 (USCDI), and certain
information about prior authorizations, that are maintained by the payer with a date of service
within 5 years of the request by a patients new or concurrent payer. Ensuring a means for an
enrollees new issuer to electronically obtain the enrollees claims, encounter, and other data, as
well as prior authorization information with corresponding medical records, from the previous
issuer will reduce administrative burden and result in more timely and efficient care coordination
and responses to prior authorization requests.
We believe that it is in the interest of qualified individuals that QHP issuers on the FFEs
have systems in place to send information important to care coordination to a departing
enrollees new payer, and that QHP issuers on FFEs also have systems in place to receive such
information from other payers on behalf of new and concurrent enrollees, as appropriate and
consistent with the provisions in this section. Having patient information at the beginning of a
new plan may assist the new payer in identifying patients who need care management services,
which could reduce the cost of care. We encourage SBEs to consider whether a similar
requirement should be applicable to QHP issuers participating in their Exchange.
Though we are not requiring the exchange of all enrollees data at one time between
impacted payers, we encourage QHP issuers on the FFEs to use the Bulk Data Access IG for the
Payer-to-Payer API once it is available, as it will improve the efficiency and simplicity of data
transfers between issuers by enabling the exchange of all data for all patients at once. The opportunity to supportthe exchange of data from multiple patient records at once, rather than
data for one patient at a time, may be cost effective for the issuers. D. Prior Authorization API and Improving Prior Authorization Processes
1. Background
This section of the final rule addresses the topic of prior authorization and includes both
technical and operational requirements intended to improve the prior authorization process for
payers, providers, and patients. Here, we finalize our proposals for payers to implement and
maintain an API to support and streamline prior authorization processes; respond to prior
authorization requests within certain timeframes; provide a specific reason for prior authorization
denials; and publicly report on prior authorization approvals, denials, and appeals.
In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76286) we
provided a comprehensive review of the work HHS conducted regarding prior authorization
processes and their associated burden to identify the primary issues that needed to be addressed
to alleviate the burdens of these processes on patients, providers, and payers. We cited studies
from ONC89 which highlighted the burdens associated with prior authorization including
difficulty determining payer-specific requirements for items and services that require prior
authorization; inefficient use of provider and staff time processing prior authorization requests
and information (sending and receiving) through fax, telephone, and web portals; and
unpredictable wait times to receive payer decisions.
We referenced American Medical Association (AMA) physician surveys from 2018,
2020, and 202290 which noted issues with prior authorization, and we used these studies to
estimate the costs and savings for this final rule. Please see the CMS Interoperability and Prior
Authorization proposed rule (87 FR 76286 - 76287) for the detailed context of these industry
surveys as well as the reports from the 2019 meetings of the two Federal advisory committees,
89OfficeoftheNationalCoordinatorforHealthInformationTechnology(2020).StrategyonReducingBurden
RelatingtotheUseofHealthITandEHRs.Retrievedfromhttps://www.healthit.gov/topic/usability-and-provider-
burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.
90AmericanMedicalAssociation(2022).AMApriorauthorization(PA)physiciansurvey.Retrievedfrom
https://www.ama-assn.org/system/files/prior-authorization-survey.pdf. the Health Information Technology Advisory Committee (HITAC)91 and the National
Committee on Vitaland Health Statistics (NCVHS),92 which conducted joint hearings to discuss
persistent challenges with prior authorization workflows and standards; and the follow up 2020
task force on the Intersection of Clinical and Administrative Data (ICAD) Task Force at 87 FR
76287.
We use the term prior authorization to refer to the process by which a provider must
obtain approval from a payer before providing certain covered items and services to receive
payment for delivering those items or services to a covered individual. As we stated in the CMS
Interoperability and Prior Authorization proposed rule, prior authorization has an important place
in the health care system, but the process of obtaining prior authorization can be challenging for
patients, providers, and payers. Interested parties, including payers and providers, say that
dissimilar payer policies, inconsistent use of electronic standards, and other technical barriers
have created provider workflow challenges and an environment in which the prior authorization
process is a primary source of burden for both providers and payers, a major source of burnout
for providers, and can create a health risk for patients if inefficiencies in the process cause delays
in medically necessary care. The prior authorization policies in this final rule apply to any formal
decision-making process through which impacted payers render an approval or denial
determination in response to prior authorization requests based on the payers coverage
guidelines and policies before services or items are rendered or provided.
As discussed in section I.D. of this final rule, we exclude drugs from the provisions in
this section, meaning any drugs that could be covered by the impacted payers affected by these
provisions. Thus, the policies herein do not apply to prescription drugs that may be self-
administered, administered by a provider, or that may be dispensed or administered in a
91OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023).HealthInformationTechnology
AdvisoryCommittee(HITAC).Retrievedfromhttps://www.healthit.gov/topic/federal-advisory-committees/health-
information-technology-advisory-committee-hitac-history.
92NationalCommitteeonVitalandHealthStatistics(2022).Charter.Retrievedfrom
https://ncvhs.hhs.gov/about/charter/. pharmacy or hospital, or OTC drugs that may be covered by an impacted payer. We include a
definition of drugs for purposes of this exclusion for each impacted payer in the CFR where
applicable to provisions for implementation of the Prior Authorization API. For MA
organizations, the definition of drugs also includes any products that constitute a Part D drug, as
defined by 42 CFR 423.100, and are covered under the Medicare Part D benefit by MA-PDs; this
part of the definition specific to MA organizations provides a clear dividing line for MA-PD
plans that must comply with this new rule. However, payers may voluntarily incorporate their
business rules for prior authorizations for drugs using the Prior Authorization API now being
finalized in this rule.
As noted in section I.D., although Medicare FFS is not directly affected by this final rule,
we will evaluate opportunities to improve automation of prior authorization processes in the
Medicare FFS program as feasible.
We received nearly 900 letters in response to the CMS Interoperability and Prior
Authorization proposed rule, with hundreds of individual comments specific to the importance of
the topic of prior authorization and the critical timing of addressing this issue. Most of the
comments were relevant to the proposals and others were out of scope. The majority of
commenters supported our proposals which are intended to mitigate longstanding issues with
prior authorization processes and many commenters stressed the importance of finalizing the
policies in this final rule as soon as practicable to resolve patient access to care issues. Some
commenters identified concerns with the timing of compliance for the policies (too soon or too
late), with prior authorization decision timeframes (too short or too long), and with reporting of
metrics (too little or too much). We carefully reviewed each comment and considered the input
to inform the policies now being described in this final rule. To be fully responsive to the public
comment process, yet avoid creating an overwhelming final rule, we have consolidated input
from allof the comments and summarized the contents with our responses for each provision.
We value the diverse commentary provided by all interested parties as the volume and scope helped shape our approach to these final policies which advance our commitment to
interoperability, burden reduction, process improvement for prior authorization, and transparent
rulemaking. Comments that were out of scope for this final rule are not addressed here.
Comment: Multiple commenters stated that, while prior authorizations may improve the
safety or efficiency of care in some circumstances, they can lead to negative effects for patients
and providers. A commenter suggested that CMS implementa broader set of changes to prior
authorization processes to correct current abuses, specifically noting that improving the speed of
prior authorizations without addressing the content of prior authorization requests will not
improve outcomes of inappropriate use of prior authorizations. Another commenter
recommended that CMS further evaluate priorauthorization burdens and make additional
proposals.
Response: We appreciate that there are still concerns about the general use of prior
authorization in the health care system. However, prior authorization continues to have a place in
the health care system and can support functions such as utilization management, cost-effective
care delivery, patient safety, and preventing unnecessary treatment. The policies we are
finalizing in this rule are intended to improve the transparency and efficiency of the process.
Regarding suggestions for us to implement broader policy changes for prior
authorization, we acknowledge that Federal policies alone cannot control all payer specific
processes or patient health outcomes. Policies must be applied with good medicaljudgment and
review, and we reiterate that we, in the administration of its programs93 and implementation of
programmatic authority, continue to evaluate opportunities for future rulemaking to alleviate
burdens, mitigate harm, and improve patient care. For example, in the CY 2024 MA and Part D
final rule (88 FR 22120), we finalized several provisions to ensure that utilization management
tools, including prior authorization requirements, are used in ways that ensure timely and
93CMSsoversightandadministrationauthorityandrolesforMA,Medicaid,CHIP,andtheFFEsvarywitheach
program. appropriate access to medically necessary care for beneficiaries enrolled in MA plans.94
Specifically, we explained current rules related to acceptable coverage criteria for basic benefits
that require MA organizations to comply with national coverage determinations (NCDs), local
coverage determinations (LCDs), and general coverage and benefit conditions included in
Traditional Medicare regulations. In addition, under new regulations adopted in that final rule,
when coverage criteria are not fully established, MA organizations may create internal coverage
criteria based on current evidence in widely used treatment guidelines or clinical literature made
publicly available to us, enrollees, and providers. The CY 2024 MA and Part D final rule also
streamlines prior authorization requirements, including adding continuity of care requirements
and reducing disruptions for beneficiaries. First, we finalized that prior authorization policies for
coordinated care plans may only be used to confirm the presence of diagnoses or other medical
criteria that are the basis for coverage determinations and/or ensure that an item or service is
medically necessary based on standards specified in that final rule (see 42 CFR 422.138(b)).
Second, we finalized that for MA coordinated care plans,95 an approval granted through prior
authorization processes must be valid for as long as medically necessary to avoid disruptions in
care in accordance with applicable coverage criteria, the patients medical history, and the
treating providers recommendation, and that plans provide a minimum 90-day transition period
when an enrollee who is currently undergoing an active course of treatment switches to a new
MA plan or is new to MA (see 42 CFR 422.112(b)(8)). Finally, to ensure prior authorization and
other utilization management policies are consistent with CMS rules, we finalized a requirement
that all MA plans that use utilization management policies mustestablish a Utilization
Management Committee to review all utilization management policies, including prior
94NationalArchives(2022,December27).FederalRegister.Retrievedfrom
https://www.federalregister.gov/documents/2022/12/27/2022-26956/medicare-program-contract-year-2024-
policy-and-technical-changes-to-the-medicare-advantage-program.
95AnMAcoordinatedcareplanisaplanthatincludesanetworkofprovidersthatareundercontractor
arrangementwiththeorganizationtodeliverthebenefitpackageapprovedbyCMS;thisincludesMAplansthat
areHMOs,PPOs,andMAplansforspecialneedsindividuals. authorization, annually and ensure they are consistent with regulatory standards for MA plan
coverage, including compliance with current, Traditional Medicares NCDs and LCDs (see 42
CFR 422.137).
a. Compliance Dates
We proposed compliance dates for most impacted payers in 2026 (by January 1, 2026, for
MA organizations and state Medicaid and CHIP FFS programs; by the rating period beginning
on or after January 1, 2026, for Medicaid managed care plans and CHIP managed care entities;
and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). There
was one exception for some of the Medicaid FFS fair hearing and notice requirements, as
discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76299 and
76300), which would take effect upon the effective date of this final rule.
Based on commenter feedback, we are extending the compliance dates for the Prior
Authorization API for all impacted payers consistentwith the compliance dates for the Provider
Access and Payer-to-Payer APIs to 2027 (by January 1, 2027, for MA organizations and state
Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1, 2027,
for Medicaid managed care plans and CHIP managed care entities; and for plan years beginning
on or after January 1, 2027, for QHP issuers on the FFEs). Throughout this rule, we generally
refer to these compliance dates as in 2027 for the various payers. The prior authorization
business process improvements, or those provisions that do notrequire API development or
enhancement, including the requirement to communicate a specific reason for a denial, reduced
decision timeframes for standard and expedited prior authorization decisions, and public
reporting of certain prior authorization metrics are being finalized as proposed with a compliance
dates in 2026 (by January 1, 2026, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2026, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers on the FFEs). Throughout this rule, we generally refer to these compliance dates
as in 2026 forthe various payers.
We received comments on the compliance dates for both the Prior Authorization API and
process improvement proposals that do not require API development or enhancement. Overall
compliance timeline comments are addressed in greater detail in section I.B. of this final rule. In
this section, we discuss comments more specifically related to the Prior Authorization API and
process improvement policies.
Comment: Multiple commenters recommended that CMS require the shortened prior
authorization decision timeframes earlier than 2026, with some noting that payers, specifically
MA organizations, already have the technological capability to implement these new decision
timeframes in 2024. These commenters did notprovide additional context for the reference to
technological capabilities. Other commenters recommended that CMS should require compliance
with all requirements that are not contingent on implementation of the Prior Authorization API
by January 2025 (for example, decision timeframes, providing specific denial reasons, and
reporting of metrics). Commenters said payers should not have trouble adapting their processes
to meet the requirements related to decision timeframes and communication with patients and
providers by that date, and that patients and providers should not have to wait any longer to
benefit from the proposals in this rule. Other commenters cited reasons for implementing the
Prior Authorization API proposal as soon as possible or in 2024 or 2025, such as to ensure that
bidirectional flow of electronic prior authorization information is fully operational by January 1,
2026 and to protect patients from delays in, and restricted access to, cancer care.
Other commenters indicated that transitioning to use the API-facilitated process for prior
authorization will require significantdevelopment and implementation efforts. A commenter
explained that developers would need 12 to 18 months following publication of the final rule to
design, develop, test, and release updated software. The commenter went on to state that payers
would likely need this same amount of time following publication of the final rule to build their specific coverage and prior authorization criteria and rules into the system for each of their
impacted health plans for the Prior Authorization API. This commenter explained that providers
and payers will also need time to work together to reconcile variances in the FHIR
implementations to ensure that they can engage in accurate exchange of prior authorization
information.
Response: We appreciate the comments in support of the proposed compliance dates in
2026 for the business process improvement provisions of the CMS Interoperability and Prior
Authorization proposed rule that do not require API development or enhancement, specifically
the requirement to communicate a specific reason for a denial, reduced decision timeframes for
standard and expedited prior authorization decisions, and public reporting of certain prior
authorization metrics. We are finalizing those compliance dates for those new requirements in
this finalrule. We agree that those prior authorization process improvements will initiate burden
reductions and support both payers and providers.
Although there are several early implementations and pilots of the Prior Authorization
API in place today, it is important to take into accountthe capabilities of all payer types and
sizes to implement the requirements of the Prior Authorization API, including internal resource
allocation for implementation and testing. All payers must identify relevant prior authorization
coverage criteria and rules and program these criteria and rules into the appropriate format for
the API in accordance with the IG. Subsequent programming and testing for the questionnaires
within the API must take place to ensure functionality. To accommodate these development
efforts, CMS is finalizing 2027 compliance dates for the Prior Authorization API. The
compliance timeframe should enable the industry to establish a strong technical framework to
support the development and scalability of the API-based solution. We anticipate that this
timeframe will provide more time for development and testing to enable the integration of the
Prior Authorization API between payers, providers, and EHR developers. Additional time for the
API implementation also supports state efforts to process the extraordinarily high volume of renewals and other eligibility and enrollment actions that need to be conducted following the end
of the Medicaid continuous enrollment condition at section 6008(b)(3) of the Families First
Coronavirus Response Act (FFCRA),96 which has consumed both staff and technical resources.
2. Requirement to Implement an API for Prior Authorization
a. Prior Authorization API
To help address prior authorization process challenges and continue our roadmap to
interoperability, we proposed that certain payers implement and maintain a PARDD API to be
used by providers to facilitate the prior authorization process. As we explained in section I.B. of
this finalrule, for consistency with the naming conventions of the other APIs, we have elected to
finalize the name of this API to the Prior Authorization API rather than the PARDD API. The
purpose of the API is to support the full prior authorization process, as described in the CMS
Interoperability and Prior Authorization proposed rule. We believe this revised name best
reflects that purpose in this final rule.
In this section, we are finalizing policies to improve the prior authorization process
between payers and providers using a Prior Authorization API. The purpose of the API is to
streamline the process and ensure that payers use technology to provide more useful information
about when and how to obtain a prior authorization and the status of an approved or denied prior
authorization.
In the CMS Interoperability and Prior Authorization proposed rule, we discussed the
anticipated benefits of the Prior Authorization API and explained how this API would automate
certain tasks, thereby mitigating some of the obstacles of the existing process. We stated thatthe
API would allow a provider to query the payers system to determine whether prior authorization
was required for certain items and services and identify documentation requirements. The Prior
96AsdescribedinpriorCMSguidance,stateshaveupto12monthstoinitiate,and14monthstocomplete,a
renewalforallindividualsenrolledinMedicaid,CHIP,andtheBasicHealthProgram(BHP)followingtheendofthe
MedicaidcontinuousenrollmentconditionthatendedonMarch31,2023thisprocesshascommonlybeen
referredtoastheunwindingperiod.FormoredetailsseeCMS(2023,January27).StateHealthOfficialletter
#23-002.Retrievedfromhttps://www.medicaid.gov/sites/default/files/2023-08/sho23002.pdf. Authorization API would send the prior authorization request from the providers EHR or
practice management system to the payer. In this final rule, we are finalizing the requirement to
use certain standards and making recommendations to use certain IGs to support development of
the FHIR API. Use of the Prior Authorization API will enable automation for the prior
authorization request and response within the clinical workflow of the provider. The IGs and
relevant standards, which are discussed in section II.G. of this finalrule, serve as the
instructional manuals for the functional capability of the API. When operational, the API enables
a provider to submit a request about a medical item or service, determine if additional
information is required, submit that information, and additionally assemble the necessary
information to submit a prior authorization request. The response from the payer must indicate
whether the payer approves (and for how long) or denies the prior authorization request or
requests more information from the provider to support the request.
To support the implementation and maintenance of the Prior Authorization API, we are
requiring certain standards and recommending certain IGs, as discussed elsewhere and in section
II.G. of this final rule. With the publication of the HTI-1 final rule (89 FR 1192), our cross
references to 45 CFR 170.215 have been updated to reflect the updated citations as needed.
Changes to the structure of 45 CFR 170.215 and versions of the API standards codified there are
discussed further in section II.G. of this final rule and reflected throughout this final rule. For the
Prior Authorization API, impacted payers must use the following standards: HL7 FHIR Release
4.0.1 at 45 CFR 170.215(a)(1), US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i), and SMART
App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1). Impacted payers are permitted to
voluntarily use updated standards, specifications, or IGs that are not yet adopted in regulation for
the APIs discussed in this final rule, should certain conditions be met. For the standards at 45
CFR 170.215 required for the Prior Authorization API, updated versions available for use under
our policy include, but are not limited to, US Core IG STU 6.1.0 and the SMART App Launch
IG Release 2.0.0, which have been approved for use in the ONC Health IT Certification Program.97 We refer readers to section II.G.2.c. of this final rule for a full discussion on using
updated standards. We are also recommending payers use the CRD IG STU 2.0.1, HL7 FHIR
Da Vinci Documentation Templates and Rules (DTR) IG STU 2.0.0, and PAS IG STU 2.0.1. We
refer readers to Table H3 for a full list of the required standards and recommended IGs to
support API implementation.
Comment: Many commenters supported the proposal to require impacted payers to
implement and maintain a Prior Authorization API to improve automation of the prior
authorization process. Many commenters stated that the API has the potential to support the
needed transition to electronic prior authorization. Commenters also stated that the Prior
Authorization API would reduce the burden for providers and speed up the prior authorization
process for patients to improve care and access treatment options. A commenter stated that the
API would offer much-needed transparency for ruralproviders around the prior authorization
process. Other commenters stated that the API would potentially replace old ways of conducting
the prior authorization process and give way to new ways of conducting prior authorization and
explained that the prior authorization provisions laid out in the CMS Interoperability and Prior
Authorization proposed rule could provide a good return on investment for payers. Multiple
commenters supported CMSs efforts to implement a standardized API that makes payers prior
authorization and other documentation requirements electronically accessible to providers and
that supports a more streamlined prior authorization request and response process. Multiple
commenters believe this change will offer many benefits for patients and providers, including
increasing access to care for patients and increasing providers understanding of prior
authorization requirements by providing upfront information about which services require prior
authorization and what type of documentation is required to support approval of a prior
authorization request; and increasing automation in the submission, receipt, and processing of
97OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap. requests, which could support more timely responses. Commenters also stated that this
automation will help decrease administrative costs and that the Prior Authorization API would
improve the efficiency of providing services to patients due to the request and response being
automated and in real-time, as well as the quality of patient care. A large group of commenters
expressed their supportfor the proposed requirement for payers to implement the Prior
Authorization API because it will make their physical therapy businesses more efficient and
allow them to focus on treating patients.
Response: We agree that these policies will serve to mitigate some of the burdens that
exist in the prior authorization process today. This is the reason we are finalizing a modification
to the compliance dates. Our proposal did not include a requirement for the Prior Authorization
API to provide real-time processing of the prior authorization request, but we agree that
incorporating a level of automation and facilitating electronic prior authorization processing
could improve processing timelines in the future. Though we anticipate that some of the
responses or decisions potentially may be made in real-time, other decisions will continue to
necessitate review and evaluation by clinical staff. The complete automation of a complex
process such as prior authorization is an ongoing process of continuous improvement.
Comment: Multiple commenters stated that the Prior Authorization API would not do
enough to resolve existing issues surrounding prior authorization burden and turnaround times. A
commenter stated that the amount of data to be transmitted and used by payers and providers
through the API is burdensome and impractical. This commenter wrote that the continued
transmission of medical information from non-FHIR systems (for example, administrative
transactions) will require payers to translate such information into a format that is useable for the
Prior Authorization API, which would only shift the manual prior authorization burden, not
alleviate it. The commenter stated it is important to maintain industry flexibility around prior
authorization to continue industry innovation in interactive decision-making processes with
providers to ensure the best care experience possible for patients. Multiple commenters expressed concern that the required implementation of the Prior Authorization API might
increase the burden for both providers and payers. A commenter expressed concerns that what
time may be saved through the API may end up being redirected to maintain the API, field
questions from patients and providers, and support external development when requests are
incomplete, which may even require a dedicated team to answer provider questions throughout
the electronic prior authorization lifecycle. This commenter provided insight into their
experience with their current online portal and provider submissions of prior authorizations, and
continued reliance on electronic faxes. A commenter expressed concerns that the maintenance of
the API will also place significant burdens on payers to translate all coverage criteria to
questions suitable for the electronic prior authorization process and to keep such information up
to date. Another commenter also stated that the work involved in identifying all policies and
authorization processes that would be included in the Prior Authorization API will be a
significant effort as it will require significant resources, staff, and time.
Response: We acknowledge concerns about the new technology and processes associated
with the Prior Authorization API, including implementation challenges, potential conflicts with
existing workflows, and increased workload for initially implementing the Prior Authorization
API. Payers will need to identify the policies, conduct the analysis, and do the necessary
programming for the next few years.Providers will also experience an initial implementation and
data collection burden associated with translating records into FHIR-compatible formats. It is in
part based on these considerations that we decided to modify our proposed compliance dates so
that the impacted payers and providers alike will have sufficient time to conduct testing on the
newly structured prior authorization process. We disagree with commenters who indicated that
the Prior Authorization API would not do enough to resolve existing issues surrounding prior
authorization burden and turnaround times, and with those who were concerned that the
transmission of medical information from systems would shift the prior authorization burden to
manual processes rather than alleviate it. The benefits of using an electronic prior authorization process improve the manual and burdensome process used today. Making the prior authorization
process electronic will reduce the time and burden associated with the current process, allowing
providers to put time back into direct patient care, and ultimately will reduce provider burnout.
Once the Prior Authorization API is in place and a provider can connectto a payers system
using that API, the manual effort for both payers and providers should decrease because clinical
and administrative staff will be able to leverage the technology to conduct a more streamlined
process for submitting prior authorization requests. Payers should be able to shift resources to
review the requests more efficiently. While payers may have their policies documented, these are
not in any standard formats, nor are they readable in any structured way. Providers must often
download documents from different portals and then interpret them individually. The API will
centralize and automate this process for both payers and providers. Further, we have included
several significant policies that do not require API development or enhancement in this final
rule, one of which relates to shortening the deadline by which impacted payers must respond to
prior authorization requests from providers. The policies being finalized in this rule have been
developed over time with input from providers, payers, and patients to address the technical and
operational issues described to us as the most significant issues in the prior authorization process.
b. FHIR Implementation Guides
In the CMS Interoperability and Prior Authorization proposed rule, we proposed to
require the use of certain technical specifications (that is, IGs adopted as implementation
standards) adopted at 45 CFR 170.215 (87 FR 76239). We also proposed that the same
documentation requirements and discontinuation and denial of access standards as we proposed
for the Patient Access API (discussed in section II.A.2. of this rule), the Provider Access API
(discussed in section II.B.2. of this rule), and the Payer-to-Payer API (discussed in section II.C.3.
of this rule) would apply to the Prior Authorization API. Additionally, for the Prior
Authorization API, we specifically recommended using certain FHIR IGs that have been
developed to support the functionality of the Prior Authorization API. These IGs are as follows:  The CRD IG
 The DTR IG
 The PAS IG
These three IGs are designed to be used by the payer, or implementer, to develop and
implement the Prior Authorization API. The IGs undergo regular development and testing to
support implementation and use of the Prior Authorization API and to improve the APIs
functionality in support of an improved prior authorization process. Technical information and
website access are provided in section II.G. of this final rule.
The first IG recommended for use to develop the Prior Authorization API is the CRD IG.
As described on the HL7 webpage, the CRD IG defines a workflow to allow payers to provide
information about coverage requirements to providers through their clinical systems.98 Use of
this IG improves the transparency of specific coverage rules specific to the patient and the
provider based on the payers prior authorization policies, and, when implemented, provides
decision support to providers when they are ordering services. This is the first stage of the
process for determining whether authorization is required for certain items or services. The CRD
IG provides the functionality to enable the API to inform the provider if a prior authorization is
required, and information about the payers prior authorization coverage rules, so the provider
knows what information is necessary to support a request. The functionality of the CRD may
return a decision to the provider if there is sufficient information and the payer supports early
determinations.
The second IG recommended for use by payers to develop the Prior Authorization API is
the DTR IG. On the HL7 IG webpage, the description explains how this IG specifies how payer
rules can be executed in a provider context to ensure that documentation requirements are met.99
98HealthLevelSevenInternational(2024,January8).DaVinciCoverageRequirementsDiscovery.Retrievedfrom
https://www.hl7.org/fhir/us/davinci-crd/.
99HealthLevelSevenInternational(2023,November7).DaVinciDocumentationTemplatesandRules.Retrieved
fromhttps://www.hl7.org/fhir/us/davinci-dtr/. This IG is a companion to the CRD IG. Its purpose is to automate the process of assembling
documentation to support a prior authorization request for a specific payer. The instructions will
allow the provider to download questionnaires and populate them automatically with information
from the EHR or other systems for the completion of documentation requirements needed to
demonstrate medical necessity for a proposed item or service, based on payer rules. The DTR IG
enables the return of completed templates with specific FHIR resources identified as required to
support the medical necessity of the service or item that is being requested for a prior
authorization. This process replaces the need to manually request, gather, and submit
documentation.
The third IG recommended for the Prior Authorization API is the PAS IG. On the HL7
webpage, the description explains that the PAS IG enables direct transmission of prior
authorization requests (and can request/receive immediate authorization) from within EHR
systems using the FHIR standard and that it can create the mapping between FHIR and HIPAA
compliant X12 transactions.100 The PAS IG ensures that the API takes the information from the
CRD and DTR and allows provider systems to send (and payer systems to receive) requests
using FHIR. Providers and payers can still meet separate regulatory requirements, where
required, to use the X12 278 transaction standard for prior authorization(s) to transport the prior
authorization request and response. The PAS IG is the basis for: (1) assembling the information
necessary to substantiate the clinical need for a particular treatment; and (2) submitting the
assembled information and prior authorization request to an intermediary before it is sent to the
intended recipient. As these IGs have been expanded and improved, the workgroup has enhanced
the graphic display depicting the workflow and made it available on the HL7 website.101
100HealthLevelSevenInternational(2023,December1).DaVinciDocumentationTemplatesandRules.Retrieved
fromhttps://www.hl7.org/fhir/us/davinci-pas/.
101HealthLevelSevenInternational(2023,November20).DaVinciCoverageRequirements:TechnicalBackground.
Retrievedfromhttps://build.fhir.org/ig/HL7/davinci-crd/background.html. Most importantly, use of the instructions from the IG and the API provides the necessary
information about the status of the prior authorization request- the response indicates whether
the payer approves (and for how long) or denies (and the reason) the prior authorization request,
or requests more information from the provider to support the prior authorization request. The
PAS IG also defines capabilities around the management of prior authorization requests,
including checking on the status of a previously submitted request, revising a previously
submitted request, and canceling a request. Section II.G. of this final rule provides additional
discussion of both the required and recommended standards and IGs to support the Prior
Authorization API.
Comments regarding requiring versus recommending the IGs, maturity of the IGs, and
technical implementation challenges are addressed in section II.G.of this final rule. For example,
commenters recommended that the FHIR IGs should be required rather than recommended, as
merely recommending the IGs would lead to an additional burden for both payers and providers
as they may use varied implementations of the required APIs that would ultimately reduce
interoperability. We also received multiple comments about technical implementation challenges
and the maturity of the recommended IGs. Technical comments such as these are addressed in
section II.G. Here we respond to the comments specific to the standards and IGs for
implementation of the Prior Authorization API.
Comment: Multiple commenters recommended that CMS and HL7 ensure the
recommended CRD, DTR, and PAS IGs are fully tested before the effective date of the final
rule, as the IGs have not been adequately or widely tested in real-time clinical settings. The
commenter noted that these IGs have data elements and processes that are listed as optional
despite their utility for automation. Another commenter cautioned that the IGs have several data
elements and processes that are optional, which means payers could meet decision requirements
with vague responses, hence jeopardizing CMSs prior authorization reform goal. Multiple
commenters supported using the PAS IG and stated that the IG is well-positioned to support the development of the proposed Prior Authorization API. A commenter noted that many of the
proposed requirements are covered in the PAS IG STU 2.0.0, which is targeted for publication in
calendar year 2023. The commenter continued by stating that based on functional requirements,
additional updates can be made to the IG to ensure it fully supports the proposed Prior
Authorization API once finalized in preparation for compliance in 2026. However, other
commenters expressed some concerns about recommending these IGs. Multiple commenters
noted that hospitals and insurers may need to use more than one technology solution to
participate and track activity using the Prior Authorization API. A commenter expressed concern
with the proposed IGs, which seem to require fast responses, within 5 seconds, and encouraged
CMS to monitor technical standards as they are developed to avoid excessive burdens that the
agency did not intend to create.
Response: CMS is recommending the three IGs to implement the Prior Authorization
API. These IGs, the CRD, DTR, and PAS IGs, were created to be used together to provide
implementation flexibility. Several optional or situational elements were included in these
guides as a means to connectthem in a single workflow while allowing for the decoupling of
these processes where necessary. For example, the CRD IG might be used to develop an API
specific to prior authorization coverage requirements, and a separate API, linked to that one,
built using the DTR IG. Some hospitals and providers will need more than one technology
solution to connect to the payers Prior Authorization API endpoint based on the architectures
and systems of the provider organization. Impacted payers and providers may have separate and
unconnected systems that address coverage and eligibility, documentation, and prior
authorization. Since publication of the CMS Interoperability and Prior Authorization proposed
rule, updated versions of the CRD, DTR, and PAS IGs have all been published. We refer readers
to Table H3 for the required standards and recommended IGs to support API implementation.
In response to the specific comment about implementation strategies, we refer
implementers to the HL7 Da Vinci workgroups for technical guidance; however, we understand that payers may need to pull multiple technology solutions together to meet the overall Prior
Authorization API requirements. Concerning the response time of 5 seconds, which is near real-
time, we anticipate that most systems can accommodate this communication exchange when the
information is available. The PAS IG has a recommended synchronous response time of 15
seconds. Instructions are available in the IG for how systems should respond in a timeframe with
the best possible information.For further technical details, we encourage interested parties to
reach out to the appropriate HL7 workgroups.
Comment: Multiple commenters stated that there are potential technological challenges
for the implementation of the Prior Authorization API. A commenter noted that the proposed
rule does notspecify what technology hospitals need to support or implement the API, nor what
technology is needed to track participation or be required to participate in the API once finalized.
This commenter noted that providers will be using the Prior Authorization API without any
meaningful testing. Another commenter noted that they currently offer providers an option to
submit electronic prior authorizations through an online portal, but utilization is low as most
providers still favor fax as their preferred method to send prior authorizations, and portal prior
authorizations often require corrections to incorrect data entries.
Multiple commenters said CMS should do more to support the implementation of the
Prior Authorization API. A commenter supported regulatory efforts to require payers to build
APIs to automate prior authorization, but questioned whether the CMS Interoperability and Prior
Authorization proposed rule goes far enough to accomplish that goal. Another commenter noted
that the Prior Authorization API will require payers, providers, and vendors to connect but noted
that multiple infrastructure challenges will have to be resolved to ensure API implementation
success and cited the work of the HL7 FAST Accelerator to identify and address scalability
issues to avoid duplication of efforts, including security and authentication.
Response: The regulations we are finalizing in this rule require impacted payers to
implement a Prior Authorization API, and providers are encouraged to use the technology in their CEHRT to take advantage of the improvements in prior authorization processes that will be
available through use of the Prior Authorization API. As we noted in the proposed rule, HL7
launched an implementation division in 2021, specifically to provide support for implementers,
including education and technical support. This division will provide payers, providers, and
vendors with access to information about the types of technology and software that will address
implementation, education, and testing of the standards, IGs, and APIs. Furthermore, the HL7
workgroups, which are open to the public, continue to be the best resources to learn about
implementation. We will continue to work with associations, developers, and HL7 on identifying
or supporting the development of appropriate resources for education.
The HL7 FAST Accelerator is addressing the scalability issues of the FHIR standard
through its work on security and the directory IGs. We and ONC participate in the HL7 FAST
Accelerator and will monitor progress on the IGs being developed by that project.
The policies in this final rule are an important component of the overall CMS strategic
plan to reduce burden, advance interoperability, and improve patient care. This rule finalizes
significant changes to improve the patient experience and alleviate some of the administrative
burden by applying policies which address both technical and process barriers. These policies
represent foundational regulatory steps toward addressing the longstanding challenges of prior
authorization.
Comment: A commenter, writing from the provider perspective, stated that the Prior
Authorization API would complicate clinical and administrative workflows by requiring some
combination of staff time and additional technological advances and recommended the FHIR
API be combined with the HIPAA transaction standard.
Response: We do not agree that using the Prior Authorization API will complicate
clinical work. Rather, time will be saved across all personnel tasks, including researching the
requirements for prior authorization across multiple payers, entering information into systems,
submitting requests, processing approvals, or determining next steps if a denial is received. The Prior Authorization API is capable of conducting the prior authorization request as a FHIR only
data exchange, or in combination with the HIPAA transaction standard.
Comment: Multiple commenters urged CMS to name the CDex IG as one of the
recommended IGs to use in support of the Prior Authorization API and stated that it is a critical
part of burden reduction and plays an important role in supporting FHIR prior authorization
transactions as proposed. To support the attachments for the Patient Access, Provider Access,
and Payer-to-Payer APIs, as well as the supporting documentation requirements for the Prior
Authorization API, this IG provides the instructions to enable the exchange of structured
documents102  meaning those which could be read and interpreted by a computer. This
functionality to attach documents to support a prior authorization is currently missing from the
other FHIR IGs and standards. A commenter stated that the PAS IG could support existing
Federal and state requirements to exchange attachments if implementers also added the
functionality of using the CDex IG. Use of this IG would further supportefficiencies in the prior
authorization process.
Response: We are aware that early adopters have begun testing with the CDex IG for
attachments to advance additional use cases for the Prior Authorization API. This final rule does
not address standards for attachments and does not prohibit using the CDex IG or other
attachment standards.
c. Implementation, Automation, and Other General Considerations forthe Prior Authorization
API and Processes
We proposed and are finalizing requirements for impacted payers to implement a Prior
Authorization API to improve the prior authorization process. The policy would require use of
new standards for some impacted payers and some changes in procedures. We received
102Generalcomparisonofstructuredversusunstructureddocuments:Structureddocumentsareorganizedandfit
intospreadsheetsandrelationaldatabases.Structureddocumentsoftencontainnumbersandfitintocolumnsand
rowsandareeasilysearchable.ExamplesareICD-codes,StarRatings,andotherdiscretedataelements.
Unstructureddocumentsincludetraditionalbusinessfiles,wordprocessingdocuments,presentations,notes,and
PDFs. comments on the use of new standards, technology, and automation with considerations for
implementation and have grouped them here.
Comment: A commenter stated that they support the proposed requirements for the Prior
Authorization API; however, they believe much more needs to be done to achieve the CMS
objectives for this policy. Multiple commenters shared potential concerns and challenges with
the implementation of a Prior Authorization API. A commenter wrote that the Prior
Authorization API use case will not work without provider participation, as the API requires
bidirectional exchange between impacted payers and providers. A commenter expressed concern
regarding the resource development needed for providers and noted this needs to be more widely
understood before the implementation of the Prior Authorization API. The commenter
recommended CMS work with interested parties to ensure practices can utilize and leverage this
API. The commenter encouraged CMS to work with ONC to extend the applicability of the Prior
Authorization API requirements to providers and EHR vendors to ensure technical readiness and
enable greater adoption of the Prior Authorization API and electronic prior authorization. A
commenter suggested that CMS require plans to provide to each contracted physician, upon
request and regardless of their use of the API, the references to the clinical research evidence that
underlie medical policy determinations when they approve or deny a service. The commenter
noted that some physicians may not be able to adopt these systems by the compliance dates.
Response: We are finalizing compliance dates in 2027 for payers to implement the Prior
Authorization API which should provide sufficient time for payers to implement the APIs,
collaborate with EHR vendors to support appropriate connections for their providers, and
develop outreach materials. Ongoing pilots demonstrate that payers and providers can implement
the necessary infrastructure by those compliance dates. While providers are not required by this
final rule to use the Prior Authorization API, in section II.F. of this final rule we are incentivizing
providers to use this API by finalizing new electronic prior authorization measures for MIPS
eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. To
promote Prior Authorization API adoption, implementation, and use among MIPS eligible
clinicians, eligible hospitals, and CAHs, we are adding a new measure titled Electronic Prior
Authorization under the HIE objective in the MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program, beginning with the calendar year
(CY) 2027 performance period/2029 MIPS payment year and CY 2027 EHR reporting period.
There could be many benefits for providers for improvements in the prior authorization process,
and we encourage all providers to evaluate whether use of the Prior Authorization API could
benefit their practices. Payers should also encourage providers in their network to use the Prior
Authorization API, given that it could be timesaving for both parties, and we anticipate that
many payers will begin education and awareness campaigns as more pilots are launched and/or
payer APIs are readied for testing. We are monitoring the activities of existing pilots and
receiving positive reports from participants. ONC may consider developing and making available
additional criteria for EHR certification for electronic prior authorization in future rulemaking.
We did not propose to specifically require payers to make available the references to the
clinical research evidence that underlie medical policy determinations when they approve or
deny a service, but we did propose that when an impacted payer denies a prior authorization
request, the payer must include a specific reason for that denial in a notice to the provider who
requested the prior authorization. See section II.D.3. regarding that proposal and the final policy.
While we do not oversee contract provisions between payers and providers, the CY 2024 MA
and Part D final rule (88 FR 22120)103 finalized a new requirement at 42 CFR 422.101(b)(6) for
MA plans to make certain information about their internal coverage policies publicly accessible,
including a list of the evidence considered in developing the internal coverage criteria; that final
103See88FR22120through22345(April12,2023).MedicareProgram;ContractYear2024PolicyandTechnical
ChangestotheMedicareAdvantageProgram,MedicarePrescriptionDrugBenefitProgram,MedicareCostPlan
Program,andProgramsofAll-InclusiveCarefortheElderly.Retrievedfrom
https://www.federalregister.gov/documents/2023/04/12/2023-07115/medicare-program-contract-year-2024-
policy-and-technical-changes-to-the-medicare-advantage-program. rule also limits using internal coverage criteria for Part A and Part B benefits to when coverage
criteria are not fully established in Medicare statute, regulation, NCD, or LCD. We anticipate
this information, along with the requirement that MA plans provide a reason for denying a
request for prior authorization (at 42 CFR 422.122 as adopted here and currently in existing 42
CFR 422.568(e)) will address the commenters concern about access to clinical research and
evidence supporting denials of coverage in the MA program. In addition, the CY 2024 MA and
Part D final rule adopted a new regulation, at 42 CFR 422.137, that requires a Utilization
Management Committee to annually review the policies and procedures for all utilization
management, including prior authorization, used by the MA plan, and a new regulation at 42
CFR 422.138 that limits how prior authorization may be used by certain MA plans. Per 42 CFR
422.138, coordinated care MA plans (for example, Health Maintenance Organization [HMO],
Preferred Provider Organization [PPO], and point-of-service [POS] plans) may only use prior
authorization to confirm the presence of diagnoses or other medical criteria that are the basis for
coverage determinations for the specific item or service and to ensure that the requested item or
service is medically necessary (for Part A and B benefits) or clinically appropriate (for
supplemental benefits). Finally, we remind readers that MA regulations at 42 CFR 422.202(b)
and 422.136(a) require MA organizations to provide education and outreach about utilization
management policies and engage in consultation with contracted providers.
Comment: Multiple commenters discussed automating prior authorizations, and many
were in support of automation, providing technological suggestions for automation of the prior
authorization process. A commenter stated that, for prior authorization forms, specific clinical
questions require answer formats that are easily understood and automated by a computer.
Another commenter described how payers might automate the prior authorization process by
utilizing existing matrices to create algorithms that would be able to review a large proportion of
their prior authorization requests. A commenter noted that deep learning AI methods for submitted clinical data could be used to inform the review and electronic prior authorization
approval process to expedite a decision that simulates a consensus of expert human judgment.
Multiple commenters recommended that CMS explore automating service bundle prior
authorizations for instances where one episode of care needs multiple prior authorizations (for
example, a knee replacement surgery), as this would help ease administrative burden and reduce
delays in patient care.
Response: We are closely following the level of interest in the types of automation that
might be brought to bear on the prior authorization process, particularly around the infrastructure
for communications, and the innovative thinking shared in the public comments. While CMS did
not directly address using AI for purposes of implementing the prior authorization policies, or
any provisions of this final rule, we encourage innovation that is secure; includes medical
professional judgment for coverage decisions being considered; reduces unnecessary
administrative burden for patients, providers, and payers; and involves oversight by an
overarching governance structure for responsible use, including transparency, evaluation, and
ongoing monitoring. We also reiterate that impacted payers must comply with Federal and state
policies and the requirements of the standards and recommended IGs in implementing these
APIs. We encourage these and other individuals to participate in the HL7 IG development
groups to share these ideas with the drafters of the IGs to further refine their functionality.
Comment: Multiple commenters recommended that CMS include additional requirements
for payers. A commenter recommended that CMS require payers to offer their electronic prior
authorization system at no cost to providers. Multiple commenters stated that health plans should
be required to provide a web-based interface for providers and patients with a standardized, easy-
to-use web page with an up-to-date database that quickly indicates whether prior authorization is
required. The commenter stated that this web page should include prior authorization rules and
medical policies. A commenter requested that the required response to the query on the online
database include the following data points: transaction ID, group or member ID, date of service, prior authorization required, instructions, and a medical policy link. A commenter recommended
that, in the case of a technicalglitch with the prior authorization process, insurance plans should
develop a backup system.
Response: We did not specifically address whether payers could charge providers for use
of or access to the Prior Authorization API. We would encourage payers not to charge additional
costs beyond those that may exist to conduct prior authorization business functions today,
including the costs of conducting transactions. We do not anticipate that fees would be charged
for use of the API or other services required by this final rule, but are aware that payers will be
funding their own development and vendor related costs.
Concerning the specific functionalities commenters requested be available through
portals, online systems, or the API, such as easy-to-use web pages with an up-to-date database
that quickly indicates whether prior authorization is required or what the medical policies are, we
reiterate that payers are required to implement a Prior Authorization API that allows a provider
to query a payers system to determine whether a prior authorization is required, to identify
documentation requirements, and to receive information about whether a specific prior
authorization request has been approved or denied. As part of fulfilling these required functions,
information about the policies and how they have been developed may be available, but we
understand that the level of additional information and detailabout the development of prior
authorization and coverage policies could vary by payer. There may be other connected systems
and resources available with information aboutthe medical policies that are associated with the
Prior Authorization API to which the provider will be able to refer to understand how decisions
are being made for certain items and services. Furthermore, under existing Federal and state
laws, such as the HIPAA Privacy and Security Rules, administrative, technical, and physical
safeguards policies and procedures must be in place to ensure that systems have effective backup
controls to protect access to patient data during planned and unplanned downtime. We would
expect impacted payers to already have such procedures in place for reliable backup systems. Comment: Multiple commenters noted that payers will have to digitize their prior
authorization policies to meet the Prior Authorization API requirements, which will be difficult
and time-consuming. Multiple commenters noted that payers may be concerned that if a
significant amount of their providers do not adopt the new prior authorization API process, the
payer will not receive the full benefit of their investment.
Response: We acknowledge that payers will have to digitize their prior authorization
policies to meet the API requirements. Several organizations have implemented the Prior
Authorization API as pilot projects or as part of the Da Vinci Exception Project, and we are
aware that implementation of the API requires a significant investment of resources. We also
recognize that the full benefit of the API will be achieved when providers use the API to request
information about prior authorization requirements and change existing workflow patterns. The
changes for both payers and providers will maximize the return on investment from the new
electronic exchange. We encourage other impacted payers to engage with these early
implementers to learn from their experience and to begin evaluating their policies to understand
the level of effort that will be required within their organizations. To supportthe analysis,
implementation, and testing, we are also finalizing compliance dates that are a year later than we
proposed to provide additional time for the necessary work to implement the Prior Authorization
API and to conduct outreach and education to the provider community.
Comment: A commenter recommended that CMS include a Prior Authorization API opt
out policy and another commenter recommended that CMS explain providers responsibilities
related to communicating patients right to opt out of the Prior Authorization API and their
responsibility to notify the payer of that decision.
Response: Prior authorization is an administrative process between a payer and provider
that is conducted almost completely electronically today with no direct burden on the patient. We
would anticipate that an individual who wishes to obtain medical services expediently might
wish for their provider to use the most efficient resource available to them. The opt out/opt in rules that we are finalizing in this rule are for the Provider Access and Payer-to-Payer APIs data
exchange requirements, discussed in sections II.B. and II.C., and do not apply to the Prior
Authorization API. While this final rule does require impacted payers to develop and implement
the Prior Authorization API, this rule does not require providers to use the API. As discussed in
section II.F., this final rule does include policies regarding using the Prior Authorization API for
the Promoting Interoperability performance category of MIPS and the Medicare Promoting
Interoperability Program. As many providers are currently conducting these processes through
EHRs in the office, with the patient present, we would encourage providers to explain any
activity to the patient, as is being done for any electronic transaction, including electronic
prescribing, lab orders, and scheduling. We also anticipate that providers would want to use a
process in which their EHR or other medical record systems are capable of connecting with the
APIs and exchanging certain data and documents using FHIR standards. At a minimum, the Prior
Authorization API will provide a means for providers to identify the prior authorization
requirements for the impacted payers, which will save time and burden associated with having to
research those requirements manually. We do not believe it is necessary to add a new opt out
process for patients regarding prior authorization. These are administrative tasks already in place
in provider offices. We reiterate that providers are not required by this rule to use the Prior
Authorization API.
Comment: Multiple commenters discussed prior authorization criteria and specifically
referenced the CY 2024 MA and Part D final rule for the enhancements it provides for prior
authorization requirements. A commenter requested that CMS require payers to make their prior
authorization criteria public in advance of the publication of this final rule and to ensure that
physicians with expertise in the services are involved in their development. Other commenters
requested that CMS ensure that prior authorization criteria be peer-reviewed. A commenter
wrote that the Prior Authorization API will increase transparency into payer prior authorization
criteria, and another noted that using an electronic data exchange could improve the accuracy of prior authorization determinations. A few commenters wrote that the solution to prior
authorizations must include both an expedited prior authorization process as well as appropriate
clinical decision-making, particularly with treatment guidelines supported by clinical evidence.
Another commenter stated that the Prior Authorization API could specifically speed up the
process of prior authorization for key treatments of gynecologic cancers. Commenters noted that
the increased transparency will include better timing for responses and accuracy for treatment
protocols subject to prior authorization.
Response: We agree that if the API can enhance provider understanding of the
requirements for requesting a prior authorization, a providers ability to submit a complete and
accurate request electronically will be improved and the manual intervention needed to collect
additional information reduced. This transparency in requirements and criteria should improve
communication between payers and providers during the prior authorization process, which is a
core element of the functionality of the Prior Authorization API. We also appreciate comments
suggesting that prior authorization criteria should be peer-reviewed and include appropriate
clinical decision-making information with treatment guidelines that are supported by clinical
evidence. Use of such clinical evidence is helpful to reviewers when creating care treatment
plans and evaluating prior authorization requests. We have also heard from many payer
organizations that aligning with clinical guidelines is part of their process when establishing
prior authorization criteria and we encourage this practice for all payers. We did not make
specific proposals related to developing prior authorization criteria, but acknowledge the value of
such clinical involvement.
We also note that the provisions in this final rule on prior authorization will work with
several of the utilization management and prior authorization policies in the CY 2024 MA and
Part D final rule to further CMSs overall goals of improving prior authorization processes to
serve the needs of payers, providers, and patients. We encourage readers to review that rule as well (88 FR 22120) to have a greater understanding of the limits on how MA organizations may
use and implement prior authorization.
Comment: Multiple commenters discussed the need for APIs to be integrated with EHR
systems. A commenter expressed concern that current EHR systems will not be set up to
accommodate the requirements of this rule. Another commenter noted that an obstacle to the
effective implementation of the Prior Authorization API is the lack of standardized coding and
structured data in provider EHRs to support adjudication of a prior authorization request. The
commenter stated that it will be important for EHR clinical data to be standardized to
successfully adjudicate prior authorization requests through API interfaces.
Response: We appreciate comments about standardization and the need for providers and
EHR system vendors to address consistency in the coding of medical records for interoperable
data exchange. Such comments do not reflect a technical readiness issue for the Prior
Authorization API or the standards but rather an industry readiness to meet the requirements to
enable and automate prior authorization processes. Over the next few years, both provider
management systems, as well as certified EHRs, will advance in their use of standards, data
exchange, and connectivity. Implementation of a content standard at 42 CFR 170.213 (USCDI)
for all data classes and data elements will support communication aboutmedical records will
reduce the variation in medical record coding, increase structured data, and support the ability for
interoperable data exchange. The IGs that support the Prior Authorization API provide the
framework for exchanging standard information between the payer and provider systems.
We note that ONC previously sought comment on how updates to the ONC Health IT
Certification Program could support electronic prior authorization through an RFI titled
Electronic Prior Authorization Standards, Implementation Specifications, and Certification
Criteria (87 FR 3475), which appeared in the January 24, 2022, issue of the Federal Register.
The Unified Agenda, current at the time of this final rules publication, includes an entry for a
proposed rule from ONC entitled Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (RIN 0955-AA06). The
description indicates that this proposed rule aims to advance interoperability, including proposals
to expand the use of certified APIs for electronic prior authorization.104
Comment: A few commenters recommended that CMS work with states to resolve
conflicts between this rule and existing state regulations. A commenter noted that Arizona has
recently enacted legislation and published guidance establishing a uniform prior authorization
request form. The commenter expressed concern that potentially conflicting policies would
create confusion and operational process challenges for QHP issuers on the FFEs and providers.
Response:We are aware that many states are also attempting to improve prior
authorization processes and have read the Arizona legislation HB 2621 from 2022105 regarding
using standard paper forms and electronic portals. We do not believe there is a conflict between
those requirements and this final rule as the Prior Authorization API required by this final rule
can support the various state required standardized forms forelectronic submission of the prior
authorization request. The AMA also provides a list of other state legislation designed to
improve prior authorization processes, many of which support or enhance the provisions in this
final rule, for example, by supporting the establishment of an electronic prior authorization
process.106 Should a conflict present between state and Federal requirements, the generalrule is
that the regulated entity must comply with both requirements unless compliance with one makes
compliance with the other impossible; in such a situation, Federal law generally preempts state
law in the absence of statutory direction otherwise.
d. Implementation Timing Considerations
104OfficeofInformationandRegulatoryAffairs,OfficeofManagementandBudget,ExecutiveOfficeofthe
President.Reginfo.gov.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06.
105OfficeoftheDirectorArizonaDepartmentofInsuranceandFinancialInstitutions(2022,January3).Regulatory
Bulletin2022-01(INS).Retrievedfrom
https://difi.az.gov/sites/default/files/Prior%20Authorization%20Bulletin%20with%20forms%202022-01.pdf.
106AmericanMedicalAssociation(2022).2022PriorAuthorization(PA)StateLawChart.Retrievedfrom
https://fixpriorauth.org/sites/default/files/2022-
12/2022%20Prior%20Authorization%20State%20Law%20Chart.pdf. In the proposed rule (87 FR 76290), we stated that we had considered proposing that the
Prior Authorization API be implemented in a phased approach. However, we explained that we
did not think a phased implementation strategy would reduce the burden on impacted payers or
providers, but rather could increase burden during the initial implementation. We also explained
that a phased approach could delay the availability of electronic prior authorization for certain
items and services, which could in turn reduce the overall adoption of the Prior Authorization
API by providers who do not see their specialties and services represented in the initial rollout of
the available Prior Authorization API. We sought comment on whether to require payers to make
prior authorization rules and documentation requirements available through the API
incrementally, beginning in 2026. Additional comments and responses regarding the timing and
deadlines for compliance with the Prior Authorization API and those policies that do not require
API developmentor enhancement are discussed in sections I.B. and II.D.1.
Comment: Some commenters supported a phased implementation of the Prior
Authorization API to allow impacted payers sufficient time to build the API and recommended
processes that would use the IGs in a staggered fashion rather than implementing the entire
process for prior authorizations. Other commenters recommended a phased implementation
based on the following order for the IGs: CRD IG first, DTR IG second, and PAS IG third. A
commenter stated there are already states making plans to implement an electronic prior
authorization process and suggested that a staggered approach could help to avoid unnecessary
variation in implementations. A commenter stated that if CMS does not provide an explanation
of terminology (such as documentation) and specify IGs and common standards on time for
the Prior Authorization API there may need to be a staggered approach for implementing the
API. A commenter agreed with CMSs observation that a phased implementation approach
would still result in having to request and process prior authorization requests in at least two
different manners for a provider working with the same impacted payer, which makes little sense
given the difficulties in the current state to even get the HIPAA Referral Certification and Prior Authorization transaction adopted under HIPAA Administrative Simplification. Multiple
commenters recommended a 3-year timeframe for phased implementation based on the
specific/common services approach. A commenter recommended that instead of using a
percentage criterion, CMS should use a 3-year timeframe with year 1 requiring authorization
rules, year 2 adding rules to different specialty facilities, and year 3 adding the Prior
Authorization API to specific services and care sectors.
Response: As stated at the beginning of this section, we are finalizing a modification to
our proposed compliance dates for the Prior Authorization API in 2027. We continue to believe,
for the reasons outlined in the CMS Interoperability and Prior Authorization proposed rule and in
our responses to comments on this issue, that mandating a phased approach is not necessary.
Payers may choose to implement the IGs in a phased approach within their operations, as long as
the API is fully functional by the compliance date. Each payer will evaluate the scope of work
required to program their prior authorization requirements, build the rules and questionnaires,
and develop appropriate testing. For those payers with extensive prior authorization requirements
and less structured documentation policies for different benefit packages, the scope will be more
significant. However, a phased approach will not change the scope of this work; the IGs provide
the road map or instructions for implementation. Use of these guides will help payers determine
the scope and level of effort required for the work that must be completed for system changes, as
well as operational changes for their organizations.
Comment: Multiple commenters stated the phased approach may result in inconsistent
implementation and/or fragmentation when it comes to leveraging the Prior Authorization API,
as different payers and providers may be at different stages of implementation. Multiple
commenters stated that a phased approach could reduce adoption of Prior Authorization API by
providers, particularly if certain items or services are listed in the initial rollout and others are
not. A commenter noted that the slow and delayed rollout of the Prior Authorization API is
unlikely to result in standardized, streamlined, electronic prior authorization experiences for physicians, clinicians, providers, and health IT vendors. Therefore, multiple commenters
supported the full implementation of Prior Authorization API on January 1, 2026.
Response: We thank commenters for affirming that a phased approach could result in
inconsistent and fragmented implementation of the Prior Authorization API and reiterate that the
decision to provide an additional year for implementation for all impacted payers was made to
ensure that the organizations would have sufficient time for training, development, testing, and
outreach to providers.
e. Existing Prior Authorization Standards: HIPAA Exceptions for Testing New Standards
In the CMS Interoperability and Prior Authorization proposed rule, we explained that the
X12 278 transaction standard (Version 5010) and NCPDP D.0 are the current standards for
electronic prior authorization transactions, adopted by HHS under provisions of HIPAA. Many
payers and providers do not use the HIPAA transaction standards, and instead use proprietary
payer interfaces and web portals through which providers submit their requests, as well as phone
calls or faxes to complete the process for a response. The prior authorization process remains
inefficient and burdensome and creates service issues for patients. We provided findings from
industry surveys and HHS reports about gaps in the current processes and standards for prior
authorization.
The Council for Affordable and Quality Health Care (CAQH) Committee on Operating
Rules for Information Exchange (CORE) annual report, the CAQH CORE Index, includes data
on health plan and provider use of HIPAA standard transactions, and as noted in the proposed
rule (at87 FR 76288),shows that prior authorization using the X12 278 transaction standard was
the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services.107 The 2021 report108 showed an incremental increase in using the X12
278 transaction standard for prior authorization of 26 percent. CAQH CORE published its 2022
report109 in November 2022 with data showing that while medical plans adoption of the X12
278 transaction standard increased by two percentage points (to 28 percent), it was still low as
compared to the other HIPAA transactions.
We received many comments about the adopted HIPAA transaction standard and its
intersection with the proposed rule and address applicable comments here.
The provisions of this final rule will provide enhancements to the electronic prior
authorization process overall. We are finalizing our proposal to require impacted payers to
implement a Prior Authorization API that can provide the necessary data to support a payers use
of electronic prior authorization processes.
In the proposed rule, we referenced section 1104 of the Affordable Care Act, which
amended HIPAA to require that HHS adopt operating rules for HIPAA standard transactions.
Operating rules are defined at 45 CFR 162.103 as the necessary business rules and guidelines
for the electronic exchange of information that are not defined by a standard, or its
implementation specifications as adopted for purposes of HIPAA Administrative
Simplification. Operating rules have not been adopted for the X12 278 transaction standard.
The NCVHS reviews operating rules and advises the Secretary as to whether HHS should
adopt them (section 1173(g) of the Act). The Secretary adopts operating rules through regulation
in accordance with section 1173(g)(4) of the Act. In June 2022, CAQH CORE submitted revised
and new operating rules to NCVHS for consideration. In June 2023, NCVHS sent a letter to HHS
recommending adoption of revised operating rules for Eligibility & Benefits, Claim Status, and
107CouncilforAffordableandQualityHealthCare(2019).2019CAQHIndex:ConductingElectronicBusiness
Transactions:WhyGreaterHarmonizationAcrosstheIndustryisNeeded.Retrievedfrom
https://www.caqh.org/sites/default/files/explorations/index/report/2019-caqh-index.pdf?token=SP6YxT4u.
108CouncilforAffordableandQualityHealthCare(2021).2021CAQHIndex:WorkingTogether:Advancesin
AutomationDuringUnprecedentedTimes.Retrievedfrom
https://www.caqh.org/sites/default/files/explorations/index/2021-caqh-index.pdf.
109CouncilforAffordableandQualityHealthCare(2022).2022CAQHIndex:ADecadeofProgress.Retrievedfrom
https://www.caqh.org/sites/default/files/2022-caqh-index-report%20FINAL%20SPREAD%20VERSION.pdf. Payment & Remittance Advice transaction standards, as well as a Connectivity operating rule. In
that letter, NCVHS recommended that HHS not adopt the proposed CAQH CORE Attachments
Prior Authorization Infrastructure operating rule or the CAQH CORE Attachments Health Care
Claims Infrastructure operating rule. NCVHS wrote that [t]he need for these operating rules
should be considered only after publication of a final rule adopting a health care attachments
transaction standard under HIPAA.110 Should a future proposal or recommendation for adoption
be submitted to HHS, we would evaluate the effect, if any, on the policies included in this final
rule. After the publication of this final rule, CMS will continue to evaluate the impact of any
NCVHS recommendation and any separate actions by HHS in that regard.
We also noted in the CMS Interoperability and Prior Authorization proposed rule (87 FR
76289), that in March 2021, HHS approved an application111 from an industry group of payers,
providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction
standards to allow testing of an alternative to the adopted HIPAA standard for prior
authorization.112 The purpose of this exception is to test an automated exchange of a prior
authorization request and response using only the FHIR standard and the FHIR IGs
recommended in the proposed rule and included in this final rule. Under this exception,
participants are testing the prior authorization exchange using a FHIR-to-FHIR exchange using
the FHIR standard without using the X12 278 transaction standard. Preliminary findings suggest
that this alternative standard can be used successfully to conduct the prior authorization request
and response as end-to-end FHIR in a cost-effective, efficient way. Payer and provider groups
have presented these preliminary findings in public forums.
110NationalCommitteeonVitalandHealthStatistics(2023,June30).NCVHSRecommendationsonUpdatedand
NewCAQHCOREOperatingRulestoSupportAdoptedHIPAAStandards.Retrievedfromhttps://ncvhs.hhs.gov/wp-
content/uploads/2023/07/Recommendation-Letter-Updated-and-New-CAQH-CORE-Operating-Rules-June-30-
2023_Redacted-508.pdf.
111DaVinciProject(2021,May26).DaVinciHIPAAException.Retrievedfrom
https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception.
112HHSprovidesinformationaboutrequestsforexceptionsfromstandardstopermittestingofproposed
modificationsontheHIPAAadministrativesimplificationwebsite.CentersforMedicareandMedicaidServices
(2023,September6).Go-to-Guidance,GuidanceLetters.Retrievedfromhttps://www.cms.gov/Regulations-and-
Guidance/Administrative-Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters. HHS provides information about requests for exceptions from standards to permit testing
of proposed modifications on the HIPAA administrative simplification website.113
Comment: Multiple commenters made statements about the HIPAA exceptions process
(45 CFR 162.940) and described various burdens associated with it, including the application
process, lack of clarity for the evaluation criteria, and the time for approval. Commenters noted
the current exceptions process may serve as a barrier for the industry to take advantage of the
opportunity to move interoperability forward and urged CMS to make it less burdensome to
accelerate opportunities for entities to beta test new standards and approaches to more efficient
data exchange. A commenter recommended that CMS work with HHS or other agencies to
improve the HIPAA exceptions process such that it is less onerous and more flexible to facilitate
innovation. Another commenter strongly urged CMS to eliminate the requirement forpayers to
request an exception to any of the HIPAA transaction and code standards. This commenter stated
that Da Vinci member exceptions should be discontinued, and CMS should work with other
government entities as needed to eliminate the requirement to obtain an exception from the
HIPAA standard for organizations seeking to directly exchange data using the FHIR standard
without X12 translation. A commenter requested that HHS develop an administrative process or
onramp for states to request a HIPAA exception for this specific transaction that individual
states could utilize at their discretion.
Response: The opportunity to apply for an exception to test an alternative to an adopted
standard is established in the HIPAA statute and implemented in regulation at 45 CFR 162.940.
Although we appreciate these comments regarding the HIPAA exceptions process, they are out
of scope of this rule.
113HHSwebsitewithinformationabout164.940(ExceptionsProcessandGuidanceLetters):HHSprovides
informationaboutrequestsforexceptionsfromstandardstopermittestingofproposedmodificationsonthe
HIPAAadministrativesimplificationwebsite.CentersforMedicareandMedicaidServices(2023,September6).Go-
to-Guidance,GuidanceLetters.Retrievedfromhttps://www.cms.gov/Regulations-and-Guidance/Administrative-
Simplification/Subregulatory-Guidance/Go-to-Guidance-Guidance-Letters. Comment: Many commenters stated that the CMS Interoperability and Prior
Authorization proposed rule failed to address the limitations of the X12 278 transaction standard.
Many others noted that current industry use of the X12 278 transaction standard is very low,
noting it is complex and outdated, and thus mandating the conversion of FHIR to the X12 278
transaction standard serves no realvalue beyond compliance. A commenter discussed how the
CAQH CORE Index report consistently reports that full automation for X12 standards for prior
authorization lags far behind payment-related use cases. A commenter noted that because of the
low use of the X12 278 transaction standard, entities would have to develop an implementation
process to complete a FHIR exchange just to convert it to an X12 278 transaction standard.
Another commenter noted the industry will continue to have interoperability challenges around
the Prior Authorization API capability due to a lack of uniformity if existing issues with the X12
278 transaction standard are not addressed. Multiple commenters requested that CMS consider
certain flexibilities in implementation. A commenter recommended that CMS consider a floor
versus ceiling approach in which the X12 standard is seen as the floor and a standard FHIR
approach using the PAS IG is the ceiling. Multiple commenters recommended that CMS provide
a waiver for the X12 278 transaction standard for payers that can implement end-to-end FHIR
data exchange. A commenter requested that CMS grant such payers a safe harbor that provides
an automatic waiver of the X12 278 transaction standard requirement. A commenter noted these
waivers would preferably be automatic or minimally burdensome to obtain. Another commenter
recommended CMS allow for exceptions to the requirement of converting Prior Authorization
API messages to the X12 278 transaction standard in scenarios where there is no need for the
receiving entity to pass along the prior authorization transaction to another system. A commenter
sought guidance on whether CMS will consider payers that are not currently covered under the
HIPAA administrative simplification exception of having prior authorizations sent through the
PAS phase of the Prior Authorization API, translated into and out of the X12 278 transaction
standard for an exception. A commenter requested clarification on whether CMS proposed that the Prior Authorization API can be used to transform the provision of a health care attachment
into a valid X12 278 transaction standard for meeting HIPAA requirements or is suggesting that
the Prior Authorization API provides an alternative basis to the proposed X12 278 transaction
standard.
Response: We appreciate stakeholder interest in using the FHIR standard to implement
the Prior Authorization API. Unless an impacted payer is included in the current Da Vinci pilot
to test an exception to the HIPAA transaction, that payer may be required to use the adopted
HIPAA standard when implementing the API. Information on the Da Vinci pilot is available on
the HL7 Da Vinci website.114 The participants in the pilot are testing the prior authorization API
over 3 years and will report to HHS at the end of that time on such metrics as response time,
ability to exchange supporting clinical information, integration into the providers workflow,
reducing total provider/staff time to obtain prior authorization, flexibility of the standard, ability
to provide a timely response, and more. The Prior Authorization API can support the submission
of a prior authorization request itself, or provide data that can support the HIPAA-compliant X12
278 transaction standard, if used, for prior authorizations,which is then sent as a separate
transmission between the providers and payers, either through a clearinghouse or through the
providers practice management system. HL7 provides detailed workflows and graphical
depictions of the API and the HIPAA transaction process.115 Finally, this final rule does not
address health care attachments.
Comment: A commenter noted that the lack of requirements for specific data elements
with the X12 278 transaction standard forprior authorizations limits the value of that transaction
standard and would affect the adoption of the API because providers would lack an efficient way
to identify what critical information to include in a prior authorization request. Multiple
114DaVinciProject(2021,May26).DaVinciHIPAAException.Retrievedfrom
https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception.
115HealthLevelSevenInternational(2023,December1).DaVinciPriorAuthorizationSupport(PAS)FHIR:Use
CasesandOverview.Retrievedfromhttps://build.fhir.org/ig/HL7/davinci-pas/usecases.html. commenters expressed concern regarding the functionality of the proposal to use the X12 278
transaction standard with the API, and another commenter noted that the X12 275 transaction
standard for health care claims attachments does not allow for using FHIR, which creates
concerns about the implementation of the Prior Authorization API. Another commenter stated
that certain CAQH CORE operating rules to support HIPAA transactions were submitted to
NCVHS for review and recommendation to HHS in 2023. These operating rules were specific to
certain HIPAA transactions and included required documentation requirements. The commenter
noted that the operating rules do not name an API documentation requirement, which is key to
locating data in various formats. Finally, another commenter noted that the X12 and FHIR
standards do not currently share compatible coding for all the information that would need to be
translated.
Response: We appreciate the concerns commenters expressed regarding the ability to use
the adopted X12 prior authorization transaction with the Prior Authorization API. Code mapping
between the X12 standard and the FHIR IGs contains X12 standard proprietary information and
will require a license for its use to support the X12 transaction. This mapping is available on the
X12 website through the Glass online viewer116 as HL7 does not publish an X12 mapping
artifact.
We also note that we did not propose in this rulemaking that the X12 275 transaction
standard be required for use with the Prior Authorization API. That transaction was proposed for
use in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438),117 which
has not yet been finalized. We reiterate that there are no operating rule requirements in the
HIPAA Administrative Simplification rules (45 CFR part 162) applicable to the API required for
116X12.X12(2023).Retrievedfromwww.X12.org.
117NationalArchives(2022,December21).AdministrativeSimplification:AdoptionofStandardsforHealthCare
AttachmentsTransactionsandElectronicSignatures,andModificationtoReferralCertificationandAuthorization
TransactionStandard.Retrievedfromhttps://www.federalregister.gov/documents/2022/12/21/2022-
27437/administrative-simplification-adoption-of-standards-for-health-care-attachments-transactions-and. use in this final rule, or, at this time, to the required HIPAA-compliant X12 278 transaction
standard.
Comment: Multiple commenters expressed support to CMS for proposing an electronic
Prior Authorization API that uses the FHIR standard and IGs in addition to the adopted X12 278
transaction standard to conduct electronic prior authorization.
Response: We appreciate commenter support for the policy that utilizes both FHIR and
X12 transaction standards. The FHIR standard and IGs will be used to implement the Prior
Authorization API while supporting compliance with the HIPAA administrative transaction
standard.
Comment: Multiple commenters requested support for their organizations that are ready
and willing to exchange data using FHIR data and process standards instead of X12 standards.
Other commenters recommended that CMS recognize FHIR data and process standards as a
permitted option for standard transactions (that is, adopted in place of the X12 standards). These
commenters noted that FHIR has increasingly become the de facto standard in health care since
it was mandated as a standard in the implementation of the Cures Act. To further accelerate the
FHIR standard and exchange of data via FHIR, commenters recommended that CMS work with
other government entities to eliminate the need for the HIPAA exception requirement for
organizations seeking to exchange data via FHIR directly without X12 transaction standard
translation. Some commenters stressed the costs involved in having to comply with both a new
set of standards and maintain a system for an outdated standard they were not using and for
which they had already developed workarounds. Others suggested that CMS support both X12
and FHIR to meet market needs and innovation. The SDOs supported this approach, noting that
the FHIR IG is written in such a way that if the requirement to use the HIPAA standard is
removed, the structure is in place for a FHIR-only transaction.
Response: We appreciate industry interest in moving towards using the FHIR standard
and reiterate that the HIPAA standards are adopted by HHS. HIPAA covered entities may consider submitting comments regarding updates to those standards to the Secretary of HHS for
consideration.
Comment: Multiple commenters emphasized the importance of exploring the integration
of real-time electronic prior authorization transactions into workflows as these could reduce
payer costs. A commenter noted that this was also recommended in the 2020 ONC report:
Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT
and EHRs. A commenter noted these could be used for medical services and medications that
do not typically require large amounts of supporting documentation. Another commenter
recommended that CMS adopt policies that support integration of electronic prior authorization
into physicians practice workflows such as direct financial support for investments in compliant
IT platforms, allowing physicians to access insurer APIs as they work towards full capability,
and supporting flexible sources of documentation for prior authorization requests within the
established framework. A commenter recommended the electronic prior authorization system be
universal across all payers with information displayed in real-time, with no cost to clinicians or
health systems. The commenter stated that research showed that switching to real-time electronic
prior authorization could save more money and reduce the time a provider takes to complete a
transaction by 15 minutes on average. The commenter stated that improving prior authorization
processes would benefit every actor in this transaction. Another commenter expressed the
importance for CMS to acknowledge that real-time prior authorization should be the goal and
that the standards and technology currently exist to implement real-time prior authorization for
certain use cases. A commenter recommended that payers implement real-time determination by
January 1, 2026, for Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs.
Response: Many commenters discussed the potential the Prior Authorization API and
policies in this final rule have for payers to make real-time decisions, particularly when
integrated into both the payer and provider workflows; however, we did not propose a real-time decision requirement and are not finalizing such a requirement in this final rule. Though we
anticipate that some of the responses or decisions may be made in real-time, we anticipate others
will continue to necessitate review and evaluation by clinical staff. We agree that the automation
of a complex process such as prior authorization will require continuous improvement.
Furthermore, some cases will require manual review because of their complexity. Nonetheless,
the overarching improvements in automation will be an improvement in what exists today.
f. Federal Matching Funds for State Medicaid and CHIP Fee-for-Service Programs
Expenditures on Implementation of the Prior Authorization API
In section II.E. of this final rule, we discuss Federal matching funds for certain state
Medicaid and CHIP FFS programs expenditures related to implementation of the Prior
Authorization API (this was also addressed in the proposed rule at 87 FR 76291 and 76292).
g. Medicaid Expansion CHIP
In section II.E. of this final rule, we discuss implementation for states with Medicaid
Expansion CHIP programs (this was also addressed in the proposed rule at 87 FR 76292).
3. Requirement for Payers to Provide Reason for Denial of Prior Authorizations and
Notifications
Throughout the Interoperability and Prior Authorization proposed rule at 87 FR 76292,
we described opportunities for improvement with the prior authorization process, specifically
where better communication between payers and providers could mitigate confusion about the
status of a prior authorization, particularly if it was not approved. This section addresses issues
about the proposed and final policy for communication about prior authorization denials and
existing requirements for notifications from impacted payers.
a. Background on Providing a Reason for Denial of Prior Authorization
Payers deny prior authorizations for different reasons, including because the payer does
not consider the items or services to be medically necessary, the patient exceeded limits on
allowable covered care for a given type of item or service, or documentation to support the request was missing or inadequate. When a payer provides a specific reason for a denial, a
provider can take appropriate actions such as re-submitting the request with updated information,
identifying alternatives for the patient, appealing the decision, or communicating the decision to
the patient to enable the patient to consider other options or to appeal as well. Today, impacted
payers send denials either electronically or through the mail, and the information provided varies
substantially between payers. For denials sent using the X12 278 transaction standard, payers
must use the codes from the external code set maintained by X12. For responses sent through
portals, fax, or other means, payers may use proprietary codes or text to communicate denial
reasons. The process is inefficient and unsatisfactory; and in general, providers do not have
consistent direction on the next steps for a denied authorization. Our proposal for impacted
payers to send a specific denial reason was one approach to address current inefficiencies.
We proposed, and are finalizing in this final rule, that, beginning in 2026, impacted
payers must provide a specific reason for denied prior authorization decisions, regardless of the
method used to send the prior authorization request. As with all policies in this final rule, this
provision does not apply to prior authorization decisions for drugs. This final policy is an effort
to improve the communication about denials from an impacted payer in response to a request for
a prior authorization through existing mechanisms, such as electronic portals, telephone calls,
email, standard transactions, or other means.
b. Denial Reason and Denial/Decision Codes
Some payers subject to this requirement to provide a specific reason for denied prior
authorization decisions will also remain subject to existing requirements to provide notice to
patients, providers, or both, with the specific reasons for the denial. In addition, for certain
payers impacted by this final rule, existing communication requirements related to coverage
decisions, notices of coverage decisions, and appeal processes, remain in effect for coverage
decisions that are made as part of a prior authorization denial or approval. These requirements
are not changed under this final rule. For example, before an MA plan may issue a prior authorization denial (or any other organization determination that is a denial) based on medical
necessity, the decision must be reviewed by a physician or other appropriate health care
professional with expertise in the field of medicine or health care that is appropriate for the
services being requested, including knowledge of Medicare coverage criteria, per 42 CFR
422.566(d); this will apply to any denial of a prior authorization request, regardless of whether
the Prior Authorization API has been used to request, check the status of, or communicate the
decision on the prior authorization. Nothing in this final rule limits the scope of the MA
regulation at 42 CFR 422.566(d) and it continues to apply to any prior authorization request and
decision that is also subject to the policies being finalized in this final rule.
Comment: Some commenters recommended that CMS define and provide examples for
terms such as approval, denial, and specific reason concerning prior authorization denials
in the final rule.
Response: We are not adding regulatory definitions for these terms in this rule, as these
terms are clear, frequently used in many contexts, and commonly used. For this final rule, these
terms mean the following:
 Approvals are when the payer authorizes coverage of items or services for which prior
authorization has been requested.
 Denials are the refusal by a payer to approve the prior authorization for a health care
item or service. Denials, or rejection of a prior authorization, may result because the service was
not considered medically necessary under the payers medical guidelines or the provider did not
provide complete or accurate documentation to support the request.
 A specific reason for denial could include reference to the specific plan provisions on
which the denial is based; information about or a citation to coverage criteria; how
documentation did not support a plan of care for the therapy or service; a narrative explanation of
why the request was denied, and specifically, why the service is not deemed necessary or that
claim history demonstrated that the patient had already received a similar service or item. Comment: Multiple commenters expressed their support for CMSs proposal to require
impacted payers to provide specific reasons for prior authorization denials, regardless of the
mechanism used to submit the prior authorization request. Multiple commenters also specifically
expressed support for requiring impacted payers to provide the reasons for denial as part of the
information included in the Prior Authorization and Patient Access APIs. Similarly, commenters
expressed support for CMSs proposal to require impacted payers, particularly MA
organizations, to give providers specific reasons for their prior authorization denials. Many
commenters supported the proposal to require payers to include in the Prior Authorization API
specific information about prior authorization requests, including the determination of approval
(and for how long), determination of denial (with a specific reason), and a request for more
information from a provider.
Response: We appreciate the general support for the proposal to improve this aspect of
the prior authorization process, specifically communication about priorauthorization decisions
and information about denials.
Comment: Multiple commenters noted that requiring a reason for denials and public
reporting of prior authorization metrics could help providers, patients, policymakers, and other
interested parties understand the prior authorization process better. These commenters asserted
that this increased transparency could improve providers submissions of prior authorization
requests, ensure prior authorizations are based on the best medical evidence and guidelines, and
allow patients to be better informed regarding their health care purchasing decisions.
Response: We appreciate the many other comments we received in support of the
proposals to require a reason for denials and public reporting and discuss other comments
specific to those provisions later in this section. Specifically, we concur that the transparency of
information will support communication between payers, providers, and patients.
Comment: Multiple commenters recommended that CMS be more specific about which
prior authorization decision information payers should include as well as how they should provide this information. Specifically, multiple commenters recommended that CMS further
specify the level of detail that impacted payers must provide about their reasons for denial. Other
commenters recommended that the information payers provide regarding reasons for prior
authorization denials include the policy on which the decision was based and the requirements
for coverage assessed, including the standards used to determine medical necessity. The
commenters recommended that CMS require that the reason for denial provided by payers
include the clinical rationale and patient-specific evidence supporting the denialdecision (that is,
which specific criteria the patient did not meet). A commenter recommended that CMS require
payers to provide the following with each prior authorization decision: whether the prior
authorization adjudication was automatically adjudicated; whether statistical methods such as AI,
machine learning, or other algorithms were used; and whether a human decision-maker was
involved and the name and credentials of the employee. This commenter noted algorithms should
be publicly accessible so that they can be examined for implicit bias. Another commenter
recommended that CMS require impacted payers to provide a clinical rationale for prior
authorization denials according to the nationalmedical specialty society guidelines for peer-
reviewed clinical literature. Multiple commenters recommended that CMS specify that impacted
health plans must provide all the prior authorization decision and denial information in a form
that is understandable and outlines specific steps for the provider, including any additional
information the provider needs to provide to further supportthe request, a list of covered
alternative treatments, and details regarding their right to appeal and the process for appeals.
Response: In this final rule, we are requiring impacted payers to provide a specific reason
to the provider when denying a prior authorization. The volume of comments in this area, as in
other areas of these proposals, was indicative of the challenges providers face in obtaining
specific information about prior authorization decisions and denials, and that payers face in
providing adequate detail for the decisions they give back to a provider about a prior
authorization denial, such that the provider can take appropriate action. The CMS Interoperability and Prior Authorization proposed rule and this final rule do not directly address
how prior authorization decisions are made, such as using AI, statistical methods, requirements
for clinical decisions, or other algorithms, which are out of scope of this specific rulemaking.
However, prior authorization decisions involving AI or other algorithmic systems must still
comply with applicable requirements, including requirements around clinical decision-making
and the finalized policy requiring communication of the specific reason for denial. This rule
intends to ensure that payers provide better communication about denials than has been available
to date.
There are existing programmatic rules for some of the impacted payers that also address
the content of a denial decision. MA organizations118 are required to provide the specific reasons
for the denial to their enrollees when an item or service is denied, along with certain other
information (such as the ability to appeal the decision and how). CMS provides a standard form
for MA organization use, which captures a specific and detailed explanation of why the medical
services were denied, including a description of the applicable coverage rule or applicable plan
policy (for example, Evidence of Coverage provision) upon which the action was based, and a
specific explanation about what information is needed to approve coverage if applicable. For
Medicaid managed care prior authorization decisions, 42 CFR 438.210(b) requires the MCO,
PIHP, or PAHP contract with the state to include provisions requiring the Medicaid managed
care plan to consult with the requesting provider when appropriate and that any decision to deny
a service authorization request or to authorize a service in an amount, duration, or scope that is
less than requested, be made by an individual who has appropriate expertise in addressing the
enrollees medical, behavioral health, or long-term services and supports needs. The regulation at
42 CFR 438.210(c) requires notice (albeit not necessarily written notice) to the provider of the
Medicaid managed care plans denial of a service authorization request, or decision to authorize
a service in an amount, duration, or scope that is less than requested. For Medicaid FFS, 42 CFR
118See42CFR422.568(e). 435.917(a) requires state Medicaid agencies to provide the beneficiary with timely and adequate
written notice of any decision regarding the beneficiarys prior authorization request, as any such
decision would cause a denial or change in benefits and services.119 When a state denies the
prior authorization request in whole or in part, the beneficiary notice must include, in addition to
the content described at 42 CFR 435.917, the notice content described at 42 CFR part 431,
subpart E, including the requirement at 42 CFR 431.210 that notices contain a clear statement of
the specific reasons supporting the intended action. Notices must be written in plain language
and be accessible to individuals who have limited English proficiency and individuals with
disabilities consistent with 42 CFR 435.905(b). These existing provisions, which include a
requirement for enrollees to be provided written notice about an adverse decision, could be
useful examples for the level of specificity that could be given to a provider, including the
applicable medical necessity criteria. Likewise, for CHIP managed care entities prior
authorization decisions, 42 CFR 457.1230(d) cross references to 42 CFR 438.210 to apply
Medicaid managed care plans prior authorization decision requirements to CHIP managed care
entities. Additionally, for QHP issuers on the FFEs, 45 CFR 147.136(b)(2)(ii)(E) and 29 CFR
2560.503-1(g) and (j) require group health plans and issuers of group and individual health
insurance coverage to provide notice to individuals, in a culturally and linguistically appropriate
manner, of adverse benefit determination or final internal adverse benefit determination and
specifies information that this notice must include, such as a description of the plan's or issuer's
standard, if any, that was used in denying the claim.
When denial information is sent to a provider by any communication method, including
existing notices, the content of a denial should be sufficiently specific to enable a provider to
understand why a prior authorization has been denied and what actions must be taken to re-
submit or appeal. This requirement would improve the current processes and reduce manual
effort and costs. When implemented, the Prior Authorization API could mitigate some denials by
119See42CFR435.917(a). providing information about the documentation and information or data necessary to support a
prior authorization request for the service or item.
Comment: Multiple commenters recommended that CMS work with X12 and other
appropriate industry organizations to update the X12 278 Service Decision Reason Code Set
with additional codes for scenarios not yet covered by the existing code set or for use of the X12
Service Decision Reason Codes as the code set for communicating reasons for the denial. The
X12 Service Decision Reason Code List is a code set maintained by X12 used by HIPAA
covered entities with the HIPAA standard transaction for electronic prior authorization decisions.
A commenter supported using denial codes under the condition that CMS continue to work with
SDOs, NCVHS, and other relevant organizations to expand the denial reasons and add support
for more specific options. Another commenter requested clarification on whether the specific
reason for the denial requirement must be met by using the X12 code list of denial reasons. The
commenter added that this code list allows varying interpretations which would result in
ambiguity. Other commenters recommended that CMS establish a clearly defined standardized
set of specific reasons for the denial and require payers to use them for communicating prior
authorization decisions for all items and services. A commenter recommended that CMS align
the FHIR Certification Action Codes and the X12 Service Decision Reason Codes. Another
commenter stated that the HCR 03 Decision Reason Code is an optional field in the X12 278
transaction standard and recommended that CMS refer to denial reasons as decision reason
codes.
Response: We confirm that the X12 Service Decision Reason Code List is a code set
maintained by X12 for electronic prior authorization decisions. Updates to this code set must be
requested through the X12 code maintenance workgroup. We strongly encourage both impacted
payers and providers to evaluate the X12 Decision Reason Code List and make
recommendations to X12 for necessary updated or new codes as appropriate. We encourage
interested organizations and SDOs to continue their collaboration efforts on crosswalks needed for the IGs supporting the Prior Authorization API and maintenance of code sets that could be
used with the API. We decline to change the terminology in this final rule from reason for the
denial to decision reasons or decision reason codes. The obligation under this final rule for
impacted payers to provide a specific reason for the denial of a prior authorization request goes
beyond using a single code set and means that payers must provide sufficient detail in the denial
response to enable the provider to know whataction to take as the follow-up to the denial to
obtain coverage  that is whether to appeal, submit additional documentation, or identify
alternative treatment options. Impacted payers may send additional information through the API
which could provide additional clarity. Finally, though the Medicare FFS program has a list of
decision reason codes in use for its program, and these could be considered for inclusion in the
X12 code set, we did not propose these for use by allpayers as part of this policy. However, the
industry could submit similar text to X12 as additions to that external code set. We affirm that all
denial reasons must be specific.
Comment: Multiple commenters shared concerns about and made recommendations
related to MA organizations utilization management policies as these pertain to the denial of
prior authorizations.
Response: This rulemaking does not address requirements or limitations for all utilization
management guidelines or policies used by MA organizations. This rulemaking adopts certain
procedural and timing requirements for prior authorizations and several API requirements for
MA organizations and other impacted payers, including implementation of a Prior Authorization
API, new reporting to CMS, and new requirements to provide to the applicable provider a
specific reason for the denial of a request for prior authorization. However, in separate
rulemaking for MA organizations, we addressed standards and requirements for how MA
organizations develop and use clinical criteria and prior authorization policies to help ensure MA
beneficiaries receive the same medically necessary care they would receive under Traditional Medicare in the CY 2024 MA and Part D final rule (88 FR 22120).120 We recommend interested
readers review the CY 2024 MA and Part D final rule for more information on these other
requirements for MA organizations.
Comment: Many commenters described challenges with denials, including the burdens
they faced when attempting to appeal those denials on behalf of their patients and delays created
in access to care when they did not have information about the reason for the denial, and
therefore little information to include in the response back to the payer. Multiple commenters
wrote that requiring impacted payers to provide reasons for prior authorization denials would
have positive impacts on the health care system. Multiple commenters stated that this
requirement would facilitate better transparency and communication between providers and
payers. Commenters noted that this requirement would: (1) allow providers to better
communicate the reason for denial and reasons for potential treatment plan changes to their
patients; (2) provide patients with more insight into how decisions are made relating to access to
care;(3) decrease the number of arbitrary prior authorization denials and minimize the number of
denials that are overturned on appeal;and 4) reduce unnecessary delays in patient care.
Response: We appreciate the many letters from commenters indicating support for the
provisions of this rule and including in those letters descriptions of the process challenges that
they believe could be mitigated by the policies being finalized. We concur with the information
in many of the letters that the requirement to provide the specific reason for the denial in a
response to the provider has the potential to improve communication between payers and
providers for the prior authorization process.
c. Existing Notice Requirements to Communicate Prior Authorization Denial Information  By
Program
Some of the impacted payers are required by existing Federal and state laws and
regulations to notify providers or patients when the payer makes an adverse decision on a prior
120Seealso42CFR422.101(b)(6),422.112(b)(8),422.137,and422.138. authorization request. Our proposals to impose requirements on payers to communicate certain
information to providers about prior authorization denials were intended to reinforce and
supplement existing Federal and state requirements and do not alter or replace existing
requirements to provide notice to patients, providers, or both. Further, the requirements include
implementation of a Prior Authorization API that can provide responses about whether an
authorization request has been approved (and for how long) or denied, a specific reason for the
denial, or request more information from the provider to support the prior authorization.
Communicating denial reasons with specific information,in addition to the existing program
notification requirements, will increase transparency, reduce burden, and improve efficiencies
for both payers and providers. The API requirements have compliance dates in 2027.
i. Denial Notice Requirements
This section of the final rule addresses denial notice requirements which will remain in
place for MA organizations, CHIP FFS, Medicaid managed care plans, and CHIP managed care
entities.
Under the MA program, the actions that constitute an organization determination
include a prior authorization decision (as well as a decision in response to a voluntary pre-service
request for a decision on coverage), as it is defined as including an MA organizations refusal to
provide or pay for services, in whole or in part, including the type or level of services that the
enrollee believes should be furnished or arranged by the MA organization as well as other types
of decisions about coverage and payment.121 Existing MA program regulations impose
requirements as to the form and content of the written notice to enrollees in the event of a partial
or full denial. For example, existing regulations regarding written notices for enrollees for
standard organization determinations require that notice for any denial by the plan of coverage of
an otherwise covered service or item must--
 Use approved notice language in a readable and understandable form;
121See42CFR422.566(b).  State the specific reasons for the denial;
 Inform the enrollee of their right to a reconsideration;
 Describe both the standard and expedited reconsideration processes, including the
enrollees right to, and conditions for, obtaining an expedited reconsideration and the rest of the
appeal process; and
 Comply with any other notice requirements specified by CMS.122
Under existing requirements,123 if the MA organization expedites an organization determination,
the MA organization must notify the enrollee (or the enrollees representative) and the physician
involved, as appropriate, of its decision, whether adverse or favorable, as expeditiously as the
enrollee's health condition requires, but no later than 72 hours after receiving the request. Either
an enrollee or a physician, regardless of whether the physician is affiliated with the MA
organization, may request that an MA organization expedite an organization determination.124
The notice of expedited determination must state the specific reasons for the determination in
understandable language and if the determination is not completely favorable to the enrollee, the
notice must also--
 Inform the enrollee of their right to a reconsideration;
 Describe both the standard and expedited reconsideration processes, including the
enrollees right to request, and conditions for obtaining an expedited reconsideration, and the rest
of the appeal process; and
 Comply with any other requirements specified by CMS as to the content of the
notice.125
Because applicable integrated plans (D-SNPs that have exclusively aligned enrollment
with an affiliated Medicaid MCO) are a type of MA plan, the regulations regarding prior
122See42CFR422.568(e).
123See42CFR422.572.
124See42CFR422.570.
125See42CFR422.572. authorization processes that we are finalizing apply to them. The final rule revises the specific
timeframes for prior authorization decisions by applicable integrated plans. Applicable integrated
plans cover both Medicaid long term services and supports and MA benefits in ten states.
Existing requirements already govern denial notices issued by applicable integrated plans to their
enrollees and are similar to the Medicaid managed care and MA rules described in the prior
paragraphs.126 Integrated organization determination notices mustbe written in plain language,
available in a language and format that is accessible to the enrollee, and explain--
 The applicable integrated plans determination;
 The date the determination was made;
 The date the determination will take effect;
 The reasons for the determination;
 The enrollees right to file an integrated reconsideration and the ability for someone
else to file an appeal on the enrollees behalf;
 Procedures for exercising an enrollees rights to an integrated reconsideration;
 The circumstances under which expedited resolution is available and how to request it;
and
 If applicable, the enrollees rights to have benefits continue pending the resolution of
the integrated appeal process.
As with the notices required from MA plans, our finalized policies do not change the
content requirements for these written denial notices to enrollees but will supplement these
notices by requiring applicable integrated plans to notify the provider of the reason for a denial
of a prior authorization request.
For Medicaid managed care plans and CHIP managed care entities, existing regulations
at 42 CFR 438.210(c) require notice to the provider without specifying the format or method,
while 42 CFR 438.210(c) and 438.404(a) require written notice to the enrollee of an adverse
126See42CFR422.631. benefit determination. In addition, 42 CFR 438.210(c) requires notice (albeit not necessarily
written notice) to the provider as well of the Medicaid managed care plans denial of a service
authorization request or decision to authorize a service in an amount, duration, or scope that is
less than requested. CHIP managed care entities are required to comply with similar standards at
42 CFR 457.1230(d) (referencing 42 CFR 438.210) and 457.1260(c) (referencing 42 CFR
438.404). Nothing in this final rule will limit the existing enrollee notification requirements at 42
CFR part 438 for Medicaid managed care plans and at 42 CFR part 457 for CHIP managed care
entities as these requirements will remain in full effect. This final rule fills a potentialgap
concerning the information communicated to providers regarding a denial of a prior
authorization request. We proposed and are finalizing that the response  whether the
authorization request has been approved (and for how long), denied (with the reason for the
denial), or a request for more information to support the prior authorization  if transmitted to
providers via the Prior Authorization API workflow process or other means, will be sufficient to
satisfy the current requirement for notice to providers at 42 CFR 438.210(c) and 457.1230(d).
We are finalizing a slight modification to the regulatory language to use the date or
circumstance under which the authorization ends instead of how long as the scope of
information that must be provided by the payer. The payer will not be required to send the
response to the provider via both the Prior Authorization API (which is required to furnish
certain information, including denial reason) and a separate, additional manner (for example,
separate written notice or phone call) with duplicate information. However, given that providers
are not required to use the Prior Authorization API, the payer must ensure that the response to
the provider with the reason for the denial must be furnished to the provider through some
means.
We also remind all Medicaid managed care plans and CHIP managed care entities subject
to this final rule that their existing obligations to provide these required notices to patients are not changed by the final policies in this rule. These payers will still have to provide a separate
written notice to the enrollee.
QHP issuers on the FFEs that offer individual health insurance must provide the specific
reason for an adverse benefit determination, which includes denial of prior authorization.127
Furthermore, plans and issuers must ensure that notice is made to individuals in a culturally and
linguistically appropriate manner that complies with existing requirements.128
Finally, impacted payers may be required to provide this information in languages other
than English, which requires impacted payers (as health programs or activities under that section)
to provide meaningful access to individuals with limited English proficiency and accessibility
requirements for individuals with disabilities.129
ii. Notice and Payer Communications
We received comments on the current processes for notice and payer communications
and summarize those and our responses here. Generally, such processes exist for MA
organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on
the FFEs.
Comment: Multiple commenters expressed frustration with the variation of prior
authorization requirements across MA plans, inconsistencies in access to care and coverage, and
painful interactions during lengthy peer-to-peer review of medical necessity assessments with
MA organizations. A commenter expressed support for the proposal in the CY 2024 MA and
Part D proposed rule (87 FR 79452) to prohibit MA plans from diverting a patient to a different
level of care than recommended by the patients physician when the patient otherwise meets all
the clinical criteria appropriate for the setting requested by the physician. Commenters noted
these factors have contributed to a more complicated prior authorization process, extended wait
times, duplicate or inaccurate prior authorization denials and post-claim denials, and a shifting
127See45CFR147.136(b)(3)(ii)(E).
128SeeCFR147.136(b)(2)(ii)(E)and29CFR2560.503-1(g)and(j).
129See45CFR92.3and92.101. focus from patient care. Multiple commenters recommended CMS implement increased
oversight policies to address MAs challenging prior authorization landscape. Multiple
commenters recommended that CMS continue to oversee MA plans use of prior authorization
and advance policies that ensure that MA enrollees have the same access to covered services as
those enrolled in Traditional Medicare and that MA organizations cannot use more stringent
criteria than Traditional Medicare.
Response: As finalized in the CY 2024 MA and Part D final rule, 42 CFR 422.138
provides that coordinated care plan prior authorization policies may only be used to confirm the
presence of diagnoses or other medical criteria and/or ensure that an item or service is medically
necessary. Second, the CY 2024 MA and Part D final rule requires coordinated care plans to
provide a minimum 90-day transition period when an enrollee currently undergoing treatment
switches to a new MA plan,during which the new MA plan may not require prior authorization
for the active course of treatment (42 CFR 422.112(b)(8)(ii)(B)). Third, to ensure prior
authorization is being used appropriately, we are requiring all MA plans that use utilization
management policies (like prior authorization) to establish a Utilization Management Committee
to review policies annually and ensure consistency with Traditional Medicares NCDs, LCDs,
and guidelines; compliance with limits on how prior authorization can be used; compliance with
other MA regulations on determining medical necessity (42 CFR 422.101(c)); and consultation
with network providers (42 CFR 422.202(b) and 422.137). Finally, to address concerns that the
CY 2024 MA and Part D proposed rule did not sufficiently define the expected duration of
course of treatment, a newly adopted regulation at 42 CFR 422.112(b)(8) requires that a
coordinated care MA plans approval of a prior authorization request for a course of treatment
must be valid for as long as medically necessary to avoid disruptions in care in accordance with
applicable coverage criteria, the patients medical history, and the treating providers
recommendation. The CY 2024 MA and Part D final rule and this final rule taken together provide significant guardrails for prior authorization in the MA program and supporta more
streamlined process, which will ultimately lead to reduced burden in health care.
Comment: A commenter was concerned that without specific guidance for MA plans
regarding certain benefits, the proposed rule will negatively impact the already existing barriers
to electronic exchange of information between MA organizations and religious nonmedical
health care institution (RNHCI) providers. This commenter supported the concept of the Prior
Authorization API because it makes possible the electronic exchange of certain prior
authorization information between payers and providers, which RNHCIs have long desired.
However, the organization was concerned about the requirement at 42 CFR 422.122(b) because
of concerns about its applicability to nonmedical benefits. This commenter proposed
amendments to the regulatory text regarding the obligation to accept and exchange information.
Response: The requirements proposed at 42 CFR 422.122(b) apply to all covered
Medicare services, including covered items and services furnished by a RNHCI, and all MA
supplemental benefits covered by an MA plan, excluding all drugs, as defined at 42 CFR
422.119(b)(1)(v). See section I.D. for more information about the exclusion of drugs from the
scope of the prior authorization policies in this rule.
We are finalizing that the prior authorization requirements adopted in this final rule
supplement and do not replace requirements in other applicable laws, including existing
requirements for MA plans, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs regarding decisions made on requests for prior authorization of covered
benefits. For additional explanation on the continued applicability of existing standards in this
final rule, we are adding paragraph (b)(5) to 42 CFR 422.122 to explain that prior authorization
decisions made under 42 CFR 422.122 must meet all other applicable MA requirements in
subpart M of part 422, such as the adjudication timeframes and notice requirements. Under
existing standards for Medicaid managed care plans, all prior authorization decisions by Medicaid managed care plans must comply with 42 CFR 438.210 as well as notice requirements
at 42 CFR 438.404.
4. Requirements for Prior Authorization Decision Timeframes and Communications
a. Impact of Delays in Prior Authorization Decisions: Background of Decision Timeframes
As discussed in the CMS Interoperability and Prior Authorization proposed rule (87 FR
76294), CMS learned through listening sessions and other public meetings that excessive wait
time for prior authorization decisions could cause delays to patient care and create medical risks
in some cases. Providers face delays for the approval of the initial request, or, secondarily, for
the resolution of a request in process, often meaning the payer is reviewing requested
documentation. In 2019, CMS conducted outreach to external entities (87 FR 76294) and
received many comments about timeframes for processing prior authorizations, where
commenters explained that the process of securing approvals for prior authorization directly
affects patient care by delaying access to services, including transfers between hospitals and
post-acute care facilities, treatment, medication, and supplies. Commenters believed that these
delays occur partly because payers have different policies and review processes, do not use
available technologies consistently, and continue to rely on manual systems such as phone, fax,
and mail, which are more labor-intensive.
b. Standard and Expedited Prior Authorization Requests and Decision Timeframes
In the CMS Interoperability and Prior Authorization proposed rule we used the terms
standard and expedited prior authorizations to refer to two types of prior authorizations for which
we are now finalizing our policies  in this finalrule, we affirm that the term standard prior
authorization refers to non-expedited, non-urgent requests and the term expedited prior
authorization indicates an urgent request. These terms continue to be used in CMS regulations.130
We received a few comments on these terms and respond to those here.
130See42CFR422.568,422.570,422.572,and422.631forMAorganizationsandapplicableintegratedplansand
42CFR438.210(d)and438.404forMedicaidmanagedcareplans. Comment: Multiple commenters stated that there was a lack of clarity and guidance on
the definition of a standard versus an expedited prior authorization. A commenter recommended
that CMS create additional specificity around what expedited means, especially for mental
health and substance use disorder conditions. Another commenter stated that what one provider
may deem an expedited request may not be considered one by the payer. A commenter noted that
the lack of a standard definition leads to discrepancies on what a payer considers urgent and
sometimes leaves some discretion up to the provider. This lack of standardization can adversely
affect a patient. If a payer has a stricter definition of what constitutes an expedited prior
authorization, this could lead to the patient waiting up to 7 days for a decision and delay access
to care further if prior authorization is denied. Commenters stated that CMS should release
guidance on definitions of these terms to facilitate more alignment for payers and strengthen
patient access by minimizing variation between network standards on what is considered
"urgent" versus "normal. Another commenter requested that CMS provide clarification on
timeframes in emergencies and if emergency care would override prior authorization rules.
Response: We decline to create a new definition for standard and expedited, as the
definitions for standard and expedited requests provide a foundation upon which both payers and
providers can rely for making professional judgments. These terms are used in the provisions at
42 CFR 422.568, 422.570, 422.572, and 422.631 for MA organizations and applicable integrated
plans. Similar terms are used at 42 CFR 438.210(d) for Medicaid managed care plans, at 42 CFR
457.1230(d) for CHIP managed care entities (87 FR 76294), and we are adding requirements at
42 CR 440.230 for Medicaid FFS and at 42 CFR 457.495 for CHIP FFS to meet these timelines
 specifically, as expeditiously as a beneficiarys health condition requires, that may not exceed
either 7 calendar days or 72 hours after receiving the request for standard or expedited requests
respectively.
A standard for when expedited determinations are required currently exists for MA
organizations at 42 CFR 422.566(a), which requires MA organizations to have an expedited procedure for situations in which applying the standard procedure could seriously jeopardize the
enrollee's life, health, or ability to regain maximum function.131 This long-standing medical
exigency standard is familiar to MA plans and providers and affords sufficient guidance on when
an expedited decision is necessary. There is adequate guidance on these standards for the MA
appeals and organization determination deadlines already. For Medicaid managed care and (by
cross reference) CHIP managed care, 42 CFR 438.210(d)(2)(i) specifies an expedited
authorization is required when following the standard timeframe could seriously jeopardize the
enrollees life or health or ability to attain, maintain, or regain maximum function. Standard
prior authorization requests are used when the enrollees life or health or ability to attain,
maintain, or regain maximum function are not seriously jeopardized by the managed care plan
using the longer, standard authorization timeframes. These policies are intended to ensure that
impacted payers, including Medicaid FFS, Medicaid managed care plans, and CHIP managed
care entities will evaluate expedited prior authorization review procedures that will minimize
patient risk. We confirm that MA plans, Medicaid managed care plans, and CHIP managed care
entities are prohibited from applying prior authorization requirements to evaluation and
stabilization services for emergency medical conditions.132
Comment: A commenter asserted that eliminating the need for a provider to reach out to a
payer and notify them of a request that requires an expedited response would reduce a provider's
administrative burden and further the efficiency of the prior authorization process. The
commenter recommended CMS request that payers be required to have systems that enable
providers to electronically differentiate between standard and expedited prior authorization
requests.
Response: While this final rule addresses several important prior authorization processes,
it does not specifically dictate all payer operational procedures. Existing regulations in the
131See42CFR422.570and422.572.
132Seesections1852(d),1932(b)(2),and2103(f)(3)oftheActand42CFR422.113,438.114,and457.1228. applicable programs covered by this final rule may address the circumstances under which a
payer must make a coverage decision, such as a prior authorization request on an expedited
basis. For example, under the MA rules at 42 CFR 422.570, an enrollee or a physician
(regardless of whether the physician is affiliated with the MA organization) may request that an
MA organization expedite an organization determination involving a request for an item or
service. The MA organization must promptly decide whether to expedite an organization
determination. Under the rules at 42 CFR 422.570(c)(2), if a request is made by an enrollee, the
MA organization must provide an expedited determination if it determines that applying the
standard timeframe for making a determination could seriously jeopardize the life or health of
the enrollee or the enrollee's ability to regain maximum function. If a request for an expedited
decision is made or supported by a physician, the MA organization must provide an expedited
determination if the physician indicates that applying the standard timeframe for making a
determination could seriously jeopardize the life or health of the enrollee or the enrollee's ability
to regain maximum function. The existing medical exigency standard related to expedited
requests will continue to apply to organization determinations that involve prior authorization.
The recommended PAS IG may not currently have the instructions to provide the
capability to differentiate between standard and expedited prior authorization requests. However,
this data element could be a helpful addition for the next version, and interested parties are
encouraged to discuss this at an HL7 workgroup meeting. There may be other means through the
payers Prior Authorization API to determine how an indicator for the type of prior authorization
request might be incorporated. The current version of FHIR includes a required data element to
indicate the urgency of a request. In FHIR technical terminology, this required data element is
named claim.priority. However, there is no equivalent value in the HIPAA X12 278
transaction standard or the X12 external code lists because that data element is not required in
that standard. The PAS IG does not provide any mapping to X12. For those entities conducting
the end-to-end FHIR exchange, the information about expedited and standard prior authorization requests is available to them through the FHIR claim.priority data element. As noted, the X12
278 transaction standard does not include this information because the current version of the X12
278 transaction standard for prior authorizations does not support this concept. An alternative to
using the claim.priority data element when using the X12 278 transaction standard for expedited
requests would be to include a service date, to indicate urgency.
c. Decision Timeframes for Standard and Expedited Prior Authorization Requests
To improve patient care outcomes and ensure that patients have more timely access to
services, we are finalizing our proposals to create, improve, or shorten prior authorization
timeframes for certain payers to respond to prior authorization requests for covered items and
services, excluding drugs. Specifically, we are finalizing that these timeframes would be 72
hours for expedited requests, unless a shorter minimum timeframe is established under
applicable state law,133 and 7 calendar days for standard requests with the possibility of an
extension to up to 14 days in certain circumstances. We acknowledged that some of the payers
affected by this final rule had different requirements for prior authorization decision notice and
appeal timeframes, and we are aligning the prior authorization decision timeframes across those
payers except for QHPs on the FFEs, as further discussed. For some payers, the existing
regulation already uses the timeframe we are adopting in this final rule for standard or expedited
requests for prior authorization; those regulations will continue to apply while amendments to
adopt the new timeframes for other payers will apply to their prior authorization decisions,
beginning in 2026.
In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76295), we
provided a chart identifying which regulations we proposed to modify the decision timeframes
for standard prior authorization decisions made by MA organizations and applicable integrated
133ThefinalpoliciesadoptedhereforstateMedicaidandCHIPFFSprogramsandMedicaidmanagedcareplans
andCHIPmanagedcareentitiesat42CFR438.210and457.495(d)(2),respectively,includethatastatemayseta
shortertimeframeforthesedecisions.However,suchstateauthoritydoesnotapplytoMAplansoperatingin
thesestates. plans, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities.134
Table E1 at the end of this section provides the final Federal requirements for prior authorization
decision timeframes that will apply to each payer beginning in 2026.
We did not propose to change any existing timeframes that might apply to expedited
authorization decisions made by any of the impacted payers, especially given that many of these
payers already apply a 72-hour maximum timeframe for such requests. To ensure consistency
and correctly describe the new timeframes being finalized for these payers to provide notice of
standard determinations, we proposed and are finalizing certain conforming amendments to the
CFR sections listed in Table E2.
QHPs are not included in the policy on timeframes for the reasons described at the end of
this section. Note that these timeframes do not apply to any drugs, as discussed in section I.D. of
this finalrule.
We proposed that beginning January 1, 2026, MA organizations and applicable integrated
plans must provide notice of prior authorization decisions as expeditiously as a patients health
condition requires, but no later than 7 calendar days for standard requests. For MA organizations,
on or after January 1, 2026, prior authorization requests for items and services covered by the
finalized requirements at 42 CFR 422.122 will be affected by this final rule; for all other items
and services, existing timeframes under the MA regulations for other pre-service requests for an
organization determination would remain applicable. These deadlines are reflected in
amendments to 42 CFR 422.568(b)(1) (for MA plans) and 422.631(d)(2)(i) (for applicable
integrated plans).
We proposed and are finalizing conforming amendments to certain regulations that
reference or describe the timeframes that are being amended in this final rule. Specifically, we
proposed and are finalizing an amendment to the MA program regulation at 42 CFR 422.570; the
revision replaces references to the specific length of the timeframe for standard decisions with a
134See42CFR422.570,422.572,422.631(c)and(d)(2)(iv)(A),438.210(d)(2),and457.1230(d). general reference to 42 CFR 422.568 which we are also amending to include the new
timeframe(s) for prior authorization decisions for items and services.
In addition, this final rule does not change existing Federal timeframes for expedited and
standard determinations on requests for Part B drugs for MA organizations and applicable
integrated plans; current regulations require notice to the enrollee as expeditiously as the
enrollees health condition requires, but no later than 72 hours after receiving the request for a
standard determination and as expeditiously as the enrollees health condition requires, but no
later than 24 hours after receiving an expedited request.135 Due to the finalized revisions to 42
CFR 422.568(b), we are redesignating existing 42 CFR 422.568(b)(2) related to requests for Part
B drugs for MA organizations to 42 CFR 422.568(b)(3).
Furthermore, an MA plan must automatically transfer a request to the standard timeframe
if the MA plan denies a request for an expedited organization determination or an applicable
integrated plan denies a request for an expedited integrated organization determination.136 This
step to automatically transfer expedited requests to the standard timeframe is consistent with
Medicaid and CHIP managed care provisions listed in Tables E2, E3, and E4.
As there are no existing CMS regulations imposing timeframes for state Medicaid FFS
programs to provide notice of priorauthorization decisions, in the proposed rule we specified
that these programs must provide notice of such decisions as expeditiously as a patients health
condition requires, but no later than 72 hours for expedited requests and 7 calendar days for
standard requests unless a shorter minimum timeframe is established under state law. For CHIP
FFS, existing regulations require states to provide prior authorizations within 14 days or
according to existing state law, in accordance with the medical needs of the beneficiary. Also, a
possible extension of up to 14 days may be permitted if the beneficiary requests the extension or
if the physician or health plan determines that additional information is needed.137 To align with
135See42CFR422.568(b)(3),422.572(a)(2),and422.631(a).
136See42CFR422.570(d)(1)and422.631(d)(2)(iv).
137See42CFR457.495(d). Medicaid, we are finalizing for CHIP FFS that beginning in 2026, states must provide notice of
prior authorization decisions in accordance with the medical needs of the beneficiary, but no
later than 7 calendar days after receiving the request for a standard determination and by no later
than 72 hours after receiving the request for an expedited determination.
For Medicaid managed care plans and CHIP managed care entities, we proposed, and are
now finalizing, to change the maximum permitted timeframe for the payer to send notices of
prior authorization decisions as expeditiously as a patients health condition requires, but no later
than 7 calendar days for standard requests beginning with the first rating period that starts on or
after January 1, 2026. We are also finalizing requirements for Medicaid managed care plans and
CHIP managed care entities concerning the timeframes for prior authorization of services (under
42 CFR 438.210 and 457.1230) but not the timeframes for issuing notices of other adverse
benefit determinations and appeals under 42 CFR 438.404(c)(1) and (2) and 457.1260.
The provisions at 42 CFR 438.210(d)(2)(i) and 457.1230(d) require Medicaid managed
care plans and CHIP managed care entities to make an expedited authorization decision no later
than 72 hours after receipt of the request if the provider requesting the authorization indicates
that following the standard timeframe could seriously jeopardize the beneficiary's life or health
or ability to attain, maintain, or regain maximum function. If Medicaid managed care plans or
CHIP managed care entities deny an expedited request, that request becomes standard and must
be reviewed within 7 days.
State law or managed care plan contracts may impose a shorter timeframe for these
decisions in Medicaid and CHIP; the shorter timeframe would govern for state Medicaid and
CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities, as
applicable.138 If state law imposes a longer timeframe, payers must comply with Federal
regulations within the shorter Federal timeframe  which will automatically make them
138Inaddition,Statesmay,bycontract,requireapplicableintegratedplanstouseshorterdecisiontimeframes.See
42CFR422.629(c). compliant with their state regulations. For this reason, we are adding to the Medicaid managed
care regulations at 42 CFR 438.210(d)(2)(i) and (d)(1), respectively, and CHIP managed care
regulations at 42 CFR 457.1230(d), respectively, that the decision must be made as expeditiously
as the enrollees condition requires but no later than 72 hours in the case of expedited requests or
7 calendar days in the case of standard requests unless a shorter minimum timeframe is
established under state law.
State laws do not apply to MA plans, based on the preemption provision in section
1856(b) of the Act and at 42 CFR 422.402, which provides that the Federalstandards established
for MA plans supersede any state law or regulation, other than state licensing laws or state laws
relating to plan solvency, with respect to the MA plans that are offered by MA organizations.
This final rule does not change the 72-hour timeframe required by current Federal
regulations, or the authority for an extension of that timeframe, for expedited decisions made by
MA organizations and applicable integrated plans, Medicaid managed care plans, and CHIP
managed care entities.
For the reasons discussed in the CMS Interoperability and Prior Authorization proposed
rule, we are not requiring that impacted payers approve a request for prior authorization if that
payer did not meet the required standard or expedited decision timeframe (87 FR 76297). If a
payer fails to meet the timeline for approval or other decision, providers should contact the payer
to obtain the status of the request and determine if supporting documentation is needed to
complete the processing of the authorization or if there are other reasons for the delay in a
decision. Some programs, such as the MA program (and including applicable integrated plans)
and the Medicaid and CHIP managed care programs, have regulations that include provisions for
the failure to provide timely notice of an organization determination;generally, such a failure to
meet the timeframe constitutes an adverse decision that may be appealed.139
139See42CFR422.568(f),422.631(d)(1)(ii),438.404(c)(5),and457.1260(b)(3). The final rule does not change timeframes for prior authorization processes for QHP
issuers on the FFEs, in part because existing regulations at 45 CFR 147.136 establish internal
claims and appeals processes, external review processes, and pre-service claims requirements for
allnon-grandfathered group and individual market plans or coverage. Specifically, individual
health insurance issuers are required to meet minimum internal claims and appeals standards.140
The current regulations for group health plans and group and individual market health insurance
issuers adequately protect patient interests. QHP issuers on the FFEs are required to provide
notification of a plans benefit determination within 15 days for standard authorization decisions
and within 72 hours for expedited requests, which is consistent with the other CMS payers
affected by this provision.
We requested comments on the timeframe proposals and provide the summarized
comments and responses here.
Comment: Multiple commenters disagreed with the proposal to exclude QHP issuers on
the FFEs from prior authorization shortened decision timeframe requirements and recommended
that CMS reconsider the exclusion of these payers. Some commenters expressed concern that
excluding QHP issuers on the FFEs from shorter prior authorization decision timeframe
requirements would result in a negative effect on patient care. Commenters asserted that patients
under these plans should be entitled to the same protections as others under this regulation. A
commenter stated that they did not believe that shortening a QHP issuer on the FFEs decision
timeframe from the current 15-day response time for standard requests to 7 days would pose an
undue burden. Another commenter encouraged CMS to work to align priorauthorization
notification requirements across all impacted payers as this could avoid confusion amongst
patients and providers regarding whether a patient is covered by a QHP. Multiple commenters
wrote that CMS should include QHP issuers on the FFEs in regulations requiring even shorter
prior authorization decision timeframes: 24 hours for urgent or expedited requests and 72 hours
140See45CFR147.136(b)(3). for standard requests. A commenter recommended CMS impose a standard of 24 hours for
expedited requests and 48 hours for standard requests and specified that this standard should
apply to all payers, including those on the Exchanges. However, multiple commenters supported
the proposal to leave in place the current prior authorization decision timeframes applicable to
QHP issuers on the FFEs. These commenters raised general concerns about payer burden due to
expedited timeframes and agreed specifically that applying expedited timeframes to QHP issuers
on the FFEs could harm consumers by reducing participation by QHP issuers on the FFEs. A
commenter recommended that timeframes be measured with business days as opposed to
calendar days.
Response: We discussed in the CMS Interoperability and Prior Authorization proposed
rule the reasons why we did not propose to change timeframes for prior authorization processes
for QHP issuers on the FFEs. We did not propose and are not finalizing, any changes to prior
authorization timeframes for QHP issuers on the FFEs, in part because existing regulations at 45
CFR 147.136 establish internal claims and appeals processes,external review processes, and pre-
service claims requirements for all non-grandfathered group and individual market plans or
coverage. Specifically, individual health insurance issuers are required to meet minimum internal
claims and appeals standards.141We believe the current standard adequately protects patient
interests. QHP issuers on the FFEs are required to provide notification of a plan's benefit
determination within 15 days for standard authorization decisions and within 72 hours for
expedited requests; thus, QHP issuers on the FFEs have the same timeframe for expedited
authorization decisions as other impacted payers in this final rule. For reasons discussed in this
section, we are not finalizing any timeframes shorter than 72 hours for expedited requests for any
impacted payers at this time. Additionally, the benefits for the patient of a shorter timeframe for
standard prior authorization decisions should outweigh the additional burden that QHP issuers on
the FFEs might experience, as compared to off-Exchange plans. Aligning timeframe
141SeeCFR147.136(b)(3). requirements for prior authorization decisions across individual and group market plans would
reduce the burden of compliance for QHP issuers on the FFEs for the proposed prior
authorization requirements while continuing to protect consumer interests. Finally, making
changes to regulations applicable to all non-grandfathered group and individual market plans or
coverage for consistency with the proposed approach was outside the scope of the proposed
rulemaking. While we are finalizing this rule as proposed, the prior authorization information
that this final rule requires QHP issuers on the FFEs to publicly report per 45 CFR 156.223(c)
will help provide insight into prior authorization timelines and practices that may support further
improvements in the future.
Comment: Multiple commenters supported the revised standard prior authorization
decision timeframe of 7 calendar days, and many commenters supported the 72-hour decision
timeframe for expedited prior authorization requests. Additionally, a commenter requested
clarification on whether the 7-day standard decision timeframe would be calendar days or
business days. A commenter recommended counting the turnaround time in business days rather
than calendar days because processing prior authorization requests requires careful evaluation by
payers and a review process that is dependent on working days as opposed to calendar days.
Defining the turnaround timeframe by calendar days limits the time needed by payers to
accurately reach a decision and is further reduced during holidays. This commenter suggested
providing a timeframe that aligns with the number of working hours a payer has to evaluate a
request and suggested CMS provide 7 business days. The commenter indicated that such an
approach aligns with turnaround times for HIPAA transactions and would therefore prevent
confusion over using both calendar days and business days. Another commenter recommended
that the proposed standard be reduced from 7 days to 72 hours, stating that tracking timelines
using hours instead of days will preclude any confusion or ambiguity regarding calendar days or
business days. Response: We reiterate that currentregulations are specific to using hours for expedited
requests and we are not modifying the terminology for that requirement of 72 hours for
expedited requests. For example, if a prior authorization request is submitted at 1:00 a.m. on
Sunday, a response within 72 hours would mean by 1:00 a.m. on Wednesday. The regulations do
not contemplate delays based on business hours or business days. For standard prior
authorization requests, the current regulations (that is, before the amendments made by this final
rule) for MA plans and Medicaid and CHIP managed care programs use the term calendar
days, in recognition of health care services being agnostic of business days. The amendment we
proposed and are finalizing for standard prior authorization decisions is 7 calendar days. This
final rule applies to the business process of the prior authorization request and decision, and not
the transmission of the HIPAA standards when used for the request.
Comment: Multiple commenters recommended having shorter decision timeframes that
are less than 7 calendar days for standard prior authorization requests, ranging from 5 days, 72
hours, 48 hours, and 24 hours. Some commenters also suggested that decisions be made in real-
time. In general, commenters recommended that CMS create faster prior authorization response
timelines to improve the patient experience and access to care.
Response: We are finalizing a requirement that prior authorization decisions be rendered
as expeditiously as the patient's condition requires, but no later than 7 calendar days requires
impacted payers to render their decision based on patient-specific information within 7 calendar
days (or shorter if otherwise required via contract or state law) being the maximum. Further, as
discussed in the proposed rule, we did not propose to change timeframes for prior authorization
processes for QHP issuers on the FFEs, in part because existing regulations at 45 CFR 147.136
establish internal claims and appeals processes, external review processes, and we believe the
current standard adequately protects patient interests.142 We will continue to review these
comments and the supporting information to determine how we might incorporate such policies
142See87FR76297. in future rulemaking as part of our ongoing mission to improve the patient and provider
experience.
Comment: Another commenter indicated that timely approvals for discharge to an
appropriate setting of care are paramount to delivering high-quality care. The commenter
explained that inappropriate and lengthy delays in payer responses to requests for transfers to
post-acute care settings putpatient care at risk. Specifically, the commenter explained that in
nine percent of cases, the delay is caused by an untimely response from a payer. The commenter
stated that while that percentage may seem low, it accounted for over 20,500 patient encounters
across the commenters system in 2022.
Response: We agree that timely response to such requests can impact patient care, and
thus we are finalizing policies to reduce prior authorization decision timeframes. We also
encourage payers to review their procedures for this and other similar cases to determine where
process improvements would be appropriate to prevent such delays within their own
organizations and provider relationships.
Comment: A commenter stated that ensuring appropriate review timeframes to make
decisions for patients is critical to avoiding mistakes in care and that accelerated review
timeframes increase the risk of failed or non-optimal therapies. A commenter wanted CMS to
maintain the current 14-day decision timeframes for standard requests in Medicaid managed
care. Another commenter suggested that CMS remove the proposal to shorten prior authorization
turnaround timeframes until the Prior Authorization API is implemented and the agency can re-
evaluate whether the policy is necessary and then re-issue a proposal. Multiple commenters had
concerns about shortening the prior authorization timeframes. Several state commenters
expressed concern that they will neither have the staffing capacity nor the operational
efficiencies to implement the prior authorization timeframes by the compliance date. Some
commenters noted that state legislative approval will be needed to increase state staffing or
adjust vendor contracts, requiring additional time to implement. Some commenters also noted that states will need to evaluate and overhaul their entire prior authorization processes to attain
the operational efficiencies needed to achieve the shortened decision timeframes.
Response: We thank the commenters for their concerns about accuracy in making
decisions about prior authorizations, but that utilization management techniques and other
professional safeguards are in place to mitigate such concerns. As we stated in the CMS
Interoperability and Prior Authorization proposed rule, shorter prior authorization timeframes
will improve patient care, reduce burden, and improve equity (87 FR 76297). The volume and
substance of other comments support our proposals to shorten certain existing timeframes, and
thus we are finalizing our proposal as described in this final rule. When the Prior Authorization
API is implemented in 2027, this resource should further improve efficiencies in the process. We
recognize the unique challenges some state commenters shared concerning the practical ability to
implement the new prior authorization timeframes in state Medicaid and CHIP FFS by January
1, 2026. We understand that states often require longer timeframes to create new positions,
adjust procurement arrangements, and rework system processes. We are willing to work with
state Medicaid and CHIP FFS programs that may be unable to meet the new compliance date for
the prior authorization timeframes. States should contact their Medicaid state lead or CHIP
project officer before April 1, 2025, to discuss their extenuating circumstances. Any flexibility
granted to a state Medicaid or CHIP FFS program for the implementation of the new prior
authorization decision timeframe requirements will be temporary and limited to the unique
circumstances of the program.
Comment: A commenter stated that providers and health plans have multiple exchanges
of information back and forth, including additional medical documentation and patient-specific
information before a final determination. The commenter noted that the currently proposed
decision timeframes do notaccount for these situations as most requests often require additional
information from providers. The commenter also stated that these requirements, in combination
with a lack of required information about the data content, could unintentionally increase the number of denials. Multiple commenters stated that shorter timeframes would mean an increase
in staff and administrative resources and that without enough time there could be an increase in
denials.
Response: We also acknowledge that additional staff resources may be necessary. Firstly,
the Prior Authorization API could mitigate communication and staffing issues, once it is fully
implemented, but acknowledge that additionalstaff may be necessary during the implementation
process. Also, the focus on process improvement overall may lead to improved efficiencies as
payers address opportunities to reduce inefficiencies and meet the requirements of the final rule.
Furthermore, the requirement to provide a specific reason for denials, regardless of the method of
the prior authorization, should also support improvements in communication between health
plans and providers. By making the documentation requirements clearer through the API,
providers should submit more complete and appropriate documentation in the first submission,
thus enabling quicker processing and fewer denials. Additionally, for Medicaid managed care
plans at 42 CFR 438.210(d)(1) and for CHIP managed care entities through an existing cross
reference at 42 CFR 457.1230(d), we are finalizing (with slight redesignations from current
regulations) a provision that permits standard authorization decisions to have an extension of up
to 14 additional calendar days (to the 7-calendar day timeframe) if the enrollee or the provider
requests the extension or if the managed care plan justifies a need for additional information and
how the extension is in the enrollee's interest. Medicaid managed care plans have been able to
utilize a 14-calendar day extension since 42 CFR 438.210(d)(1) was first promulgated in 2001
(66 FR 43670). We believe this provides sufficient time for managed care plans and providers to
complete the needed information exchange and enable the managed care plan to render its
decision. Similarly for CHIP FFS, we are finalizing our policy at 42 CFR 457.495 to allow for a
possible extension of up to 14 days if the enrollee requests the extension or if the physician or
health plan determines that additional information is needed to furnish a prior authorization
decision. Comment: A commenter suggested that CMS convene a multi-stakeholder panel of health
professionals and payer representatives to determine an appropriate timeframe for prior
authorizations.
Response: We do not agree that a multi-stakeholder panel of health professionals and
payer representatives is necessary to determine an appropriate timeframe for prior authorizations.
CMS has conducted surveys and listening sessions for nearly a decade, as have professional
associations. Results are consistent for challenges of timeframes, with the consensus that this
issue must be addressed. While some states have additional requirements for decision
timeframes, they are not the same across the country. This final rule establishes policies for most
of the programs over which CMS has authority to provide consistent and aligned structure for
providers and payer communications on this important matter. To continue the conversation with
another panel would further delay implementing these important changes that provide the
opportunity for improving access to care and ensure that the industry collaborates on a solution
to a critical problem that has widespread consensus. CMS will evaluate these reduced timeframes
over time to see if future changes are needed, and may at that time conduct additional
stakeholder meetings, but at this time we do not believe this is a necessary step to finalizing this
policy, which will reduce timeframes and improve prior authorization processes across impacted
payers.
Comment: Multiple commenters requested clarification regarding the consequences and
the available appeals process if payers do not meet decision timeframes. For example, a
commenter stated that for cancer treatments, there should be no extensions unless a peer-to-peer
review is needed, and if so, it should only be for 48 hours from the originalrequest. Another
commenter stated that policies should be implemented for payer oversight and dispute
resolutions like targeted audits and penalties for violations. Multiple commenters highlighted that
if decision timeframes are not met there should be a presumption of coverage for standard and
pre-service determinations for providers and expedited appeal rights. A commenter noted that payers should be required to provide more information for denials when they do not meet
decision timeframes and there should be civil monetary penalties on entities that demonstrate a
statistical pattern of unnecessary documentation requests.
Response: We agree that data will be useful for oversight activities. The impacted payers
are subject to the oversight and enforcement of the respective programs, in accordance with
annual reporting, certification, and/or auditing. We have addressed program enforcement and
compliance mechanisms in response to other similar comments in section I.D.2. of this final rule.
For Medicaid managed care, 42 CFR 438.66(a) through (c) requires states to have a monitoring
system for allof their managed care programs that addresses all aspects of the program and
requires that data collected from these monitoring activities are used to improve program
performance. Further, 42 CFR 438.66(e) requires states to complete an annual report on the
performance of each of its managed care programs, submit that report to CMS, and post it on the
states website. CMS reviews these reports and can take enforcement action when needed. Along
with the metrics published under 42 CFR 438.210(f), we will have broad visibility into the
timeliness of Medicaid managed care plans prior authorization decisions. For QHP issuers on
the FFEs, penalties associated with failure to comply with deadlines or other provisions of 45
CFR 147.136 are generally within the purview of state regulators.143 The AMA published a
summary of some state initiatives regarding prior authorization practices.144
For the reasons discussed in the CMS Interoperability and Prior Authorization proposed
rule at 87 FR 76297, we are not requiring that impacted payers approve a request for prior
authorization if that payer did not meet the required standard or expedited decision timeframe. If
a payer fails to meet the timeline for approval or other decision, providers should contact the
143ExcepttotheextentthatastatehasdeferredtoCMSastheprimaryenforceroftheseprovisionsorastatehas
enteredintoaCollaborativeEnforcementAgreement(CEA)withCMSwherebythestateattemptstoobtain
voluntarycompliancebutifunsuccessful,deferstoCMStohandleenforcement.
144AmericanMedicalAssociation(2023,May10).Billsin30statesshowmomentumtofixpriorauthorization.
Retrievedfromhttps://www.ama-assn.org/practice-management/prior-authorization/bills-30-states-show-
momentum-fix-prior-authorization. payer to obtain the status of the request and determine if supporting documentation is needed to
complete the processing of the authorization or if there are other reasons for the delay in a
decision. We do not believe it is practical to require payers to default to approval for prior
authorization requests for which a timely response has not been provided. Therefore, impacted
payers may choose to evaluate process improvements to meet the proposed timeframes and API
in this final rule, and consider how to efficiently support provider inquiries on status should
responses or timeframes be missed. Some programs, such as the MA program (and including
applicable integrated plans) and the Medicaid and CHIP managed care programs, have
regulations that include provisions for the failure to provide timely notice of an organization
determination; generally, such a failure to meet the deadline constitutes an adverse decision on
the prior authorization request that may be appealed.145
d. Operational Topics
We solicited comments on what administrative, regulatory, technical, governance,
operational, and workflow solutions would need to be addressed, for and by payers, to comply
with the proposed timeframes for handling prior authorization review and approval activities. We
also solicited comments on what operational or procedural changes payers or providers would
need to make in their workflows or systems to reduce decision timeframes from 14 calendar days
to 7 calendar days (for standard prior authorization requests) and from 72 hours to 1 day or 24
hours (for expedited prior authorization requests). We indicated that we wished to learn more
about barriers that prevent payers from meeting shorter timeframes than those we proposed and
requested input on whether MA organizations and applicable integrated plans, state Medicaid
and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities could
provide notice of standard and expedited prior authorization decisions within shorter timeframes
(for example, 5 calendar days and 48 hours, respectively), and if not, what issues and obstacles
prevent that. We solicited comments on whether implementation of the Prior Authorization API
145See42CFR422.568(f),422.631(d)(1)(ii),438.404(c)(5),and457.1260(b)(3). could yield process improvements to support shorter decision timeframe requirements for prior
authorization requests and on anticipated operational challenges of implementing the API that
might affect a payers ability to meet the proposed timeframes. Finally, we requested comments
regarding the costs, benefits, and operational impact on providers and payers, as well as the
impact on patients, of making and communicating prior authorization decisions on a shorter
timeframe than those in the proposed rule. We received a substantial number of comments on
these topics which will be useful as we consider future policies and guidance on these issues.
These policies for the impacted payers are being finalized in this final rule in the CFR
sections listed in Table E4. TABLE E1: PRIOR AUTHORIZATION DECISION TIMEFRAMES FOR IMPACTED
PAYERS BEGINNING IN 2026 (EXCLUDING DRUGS)
FinalExpeditedPrior FinalStandardPriorAuthorizationDecision
Payer
AuthorizationDecision Timeframes
Timeframes
MAOrganizations Asexpeditiouslyasthe Asexpeditiouslyastheenrollee'shealthcondition
andApplicable enrollee'shealthcondition requiresbutnolaterthan7calendardaysafterreceiving
IntegratedPlans requires,butnolaterthan72 therequestforthestandardorganizationdetermination*
hoursafterreceivingthe andstandardintegratedorganizationdecision.
request.* 42CFR422.568(b)(1)
42CFR422.572(a) 42CFR422.631(d)(2)(i)(B)
42CFR422.631(d)(2)(iv)
MedicaidManaged Asexpeditiouslyasthe Asexpeditiouslyastheenrolleesconditionrequiresand
CarePlans enrolleeshealthcondition withinStateestablishedtimeframesthatmaynotexceed
requiresandnolaterthan72 7calendardaysafterreceivingtherequestforservice.
hoursafterreceiptofthe 42CFR438.210(d)(1)
requestforservice.
42CFR438.210(d)(2)
CHIPManaged Asexpeditiouslyasthe Asexpeditiouslyastheenrolleesconditionrequiresbut
CareEntities enrolleeshealthcondition nolaterthan7calendardaysafterreceivingtherequest
requiresbutnolaterthan72 forservice,unlessashorterminimumtimeframeis
hoursafterreceiptofthe establishedunderstatelaw.
requestforservice,unlessa 42CFR457.1230(d)
shorterminimumtimeframe
isestablishedunderstatelaw.
42CFR457.1230(d)
MedicaidFFS Asexpeditiouslyasa Asexpeditiouslyasabeneficiaryshealthcondition
beneficiaryshealthcondition requires,butinnocaselaterthan7calendardaysafter
requires,butinnocaselater receivingtherequest,unlessashorterminimum
than72hoursafterreceiving timeframeisestablishedunderstatelaw.
therequest,unlessashorter 42CFR440.230(e)(1)(i)
minimumtimeframeis
establishedunderstatelaw.
42CFR440.230(e)(1)(ii)
CHIPFFS Inaccordancewiththe Inaccordancewiththemedicalneedsofthepatient,but
medicalneedsofthepatient, nolaterthan7calendardaysafterreceivingtherequest
butnolaterthan72hours forastandarddetermination.
afterreceivingtherequestfor 42CFR457.495(d)(1)
anexpediteddetermination.
42CFR457.495(d)(1)
QHPIssuersonthe Assoonaspossible,taking Areasonableperiodoftimeappropriatetothemedical
FFEs intoaccountthemedical circumstancesbutnotlaterthan15daysafterreceiptof
exigencies,butnotlaterthan theclaim.
72hoursafterreceiptofthe 45CFR147.136(b)(3)(i)
claim.
45CFR147.136(b)(3)(i)
*Applicableintegratedplansmayhaveshortertimeframesasrequiredbyastate(42CFR422.629(c)
allowsstatestoimplementshortertimeframes).
The timeframe for standard prior authorization requests and expedited organization
determinations for certain programs may be extended for either 14 or 15146 days for reasons
146QHPissuersontheFFEsfollow29CFR2560.503-1(f)(2)(iii)(A)forcertainextensions.See29CFR2560.503-
1(f)(2)(iii)(A). specified and permitted under existing or new policies. The specific citations are provided here
for reference.
 Medicaid FFS at 42 CFR 440.230(e)(1)(i). Timeframes for prior authorization
decisions under the Medicaid FFS program have been newly established with this final rule. The
timeframe for standard authorization decisions can be extended by up to 14 calendar days if the
beneficiary or provider requests an extension or if the state agency determines that additional
information from the provider is needed to make a decision.
 MA expedited organization determinations at 42 CFR 422.572(b) and MA standard
organization determinations at 42 CFR 422.568(b)(1)(i). Extensions are permitted for expedited
and standard integrated organization determinations by applicable integrated plans (see 42 CFR
422.631(d)(2)(ii)).
 Medicaid managed care plan expedited authorization decisions at 42 CFR
438.210(d)(2)(ii) and Medicaid managed care plan standard authorization decisions at 42 CFR
438.210(d)(1)(ii). Extensions are permitted for expedited and standard prior authorization
requests by up to 14 calendar days under certain circumstances.
 QHP issuers on the FFEs are permitted additional time on expedited requests under
certain circumstances when a claimant does not provide sufficient information. See 29 CFR
2560.503-1(f)(2)(i). Limited extensions of the timeframe for standard requests are also allowed
under certain circumstances. See 29 CFR 2560.503-1(f)(2)(iii)(A).
5. Requirements for Timing of Notifications Related to Prior Authorization Decisions
This section outlines the regulatory amendments adopted in this rule as applicable based
on other laws for the timing of notifications sent by certain payers to patients regarding prior
authorization decisions. These requirements also apply to most impacted payers. However,we
did not address notifications from the QHP issuers on the FFEs for the same reasons we
explained in section II.D.4. of this final rule.
a. Medicare Advantage Organizations MA organizations are currently required to provide notifications to enrollees of decisions
regarding coverage, called organization determinations, which include decisions regarding prior
authorizations. To support more timely decisions and communication of those decisions, we
proposed to amend 42 CFR 422.568(b)(1) to require MA organizations to notify the enrollee of
its prior authorization determination as expeditiously as the enrollees health condition requires,
but no later than 7 calendar days after the organization receives the request for a standard
organization determination for a medical item or service subject to the prior authorization rules at
42 CFR 422.122. We also proposed to move the existing language at 42 CFR 422.568(b)(1)(i)
and (ii) (regarding extensions of the adjudication timeframe for standard organization
determinations) to 42 CFR 422.568(b)(2). We proposed to move the language previously at 42
CFR 422.568(b)(2) to a new paragraph (b)(3). We emphasized that this change to the regulation
text structure would not change current requirements and that the proposed new 7-calendar day
timeframe would remain subject to the existing standards and limits (currently at 42 CFR
422.568(b)(1)(i), proposed to be at 42 CFR 422.568(b)(2)) related to when an MA organization
may extend the adjudication timeframe by up to 14 additional calendar days. For additional
explanation on the continued applicability of existing standards, in this final rule, we are adding
paragraph (a)(3) to 42 CFR 422.122 to explain that prior authorization decisions made under 42
CFR 422.122 must meet all other applicable requirements in subpartM of part 422, such as the
adjudication timeframes and notice requirements. In this final rule we are also adding
explanatory language to the beginning of paragraph (b)(1)(i) of 42 CFR 422.568; specifically, we
are adding the phrase For a service or item not subject to the prior authorization rules at 
422.122 to the beginning of the sentence to be clear that those requests not subject to the prior
authorization rules at 42 CFR 422.122 will be adjudicated under the existing 14-calendar day
timeframe, such as a request for a supplemental benefit that involves an OTC drug or a pre-
service request made by an enrollee who is seeking an advance determination on an item or
service that is not subject to prior authorization under the rules at 42 CFR 422.122. In contrast, 42 CFR 422.568(b)(1)(ii) sets forth the 7-calendar day timeframe for those requests for a service
or item that are subject to the prior authorization rules at 42 CFR 422.122.
We proposed similar amendments to the integrated organization determination
requirements at 42 CFR 422.631 for applicable integrated plans. We are making in this final rule
explanatory revisions to the regulation text at 42 CFR 422.631 consistent with the revisions
made at 42 CFR 422.568 and amended 42 CFR 422.631(d)(2)(i)(B) to state that when a provider
makes a request for an item or service, the applicable integrated plan must notify the enrollee of
its determination as expeditiously as the enrollees health condition requires, but no later than 7
calendar days after the organization receives the request for a standard pre-service organization
determination that is subject to 42 CFR 422.122. We also proposed an amendment to 42 CFR
422.631(d)(2)(iv)(B) to state that when an applicable integrated plan denies a request for an
expedited determination and automatically transfers the request to the standard timeframe, it
must make its determination within the applicable timeframe established at 42 CFR
422.631(d)(2)(i)(B). This means that for prior authorization requests within the scope of 42 CFR
422.122, the 7-calendar day timeframe applies, rather than the current 14-calendar day timeframe
for an integrated organization determination. These changes also apply to applicable integrated
plans that are MCOs as defined at 42 CFR 438.2, because per 42 CFR 438.210(d)(4), 42 CFR
422.631 also applies to these Medicaid plans. These amendments are consistent with changes for
other Medicaid managed care plans being finalized at 42 CFR 438.210(d)(1) and (2). Concerning
MA organizations (including applicable integrated plans), our proposalwas limited to the
timeframes for standard determinations involving prior authorization, and there are no changes to
the timeline for expedited integrated organization determinations, extensions, or the requirements
for notice to enrollees.
Comment: A commenter urged CMS to require that any failure by an MA plan or
applicable integrated plan to provide notice of an organization determination within the same timeframes (and without having requested an extension) constitute a deemed denial for which the
provider may request a reconsideration by an independent reviewer.
Response: We acknowledge this commenters concern about the failure of MA plans to
provide notice within the required timeframes. Under the existing MA rules, a failure to meet the
deadline by which an organization determination, including a request forprior authorization,
constitutes a denial that can be appealed to the next level (reconsideration by the MA
organization). See 42 CFR 422.568(f) and 422.631(d)(1)(ii). The MA program regulations (42
CFR 422.592 through 422.596 and 422.634) provide for review by an Independent Review
Entity (IRE) after an MA organizations adverse reconsidered organization determination,
including where the MA organization fails to issue a reconsidered organization determination in
a timely fashion. We did not propose, and are therefore not finalizing here, an amendment to
those rules to escalate prior authorization denials to the IRE. However, the existing regulations at
42 CFR 422.590(h)(1) and 422.629(k)(4) provide that for reconsiderations by MA plans and
applicable integrated plans, the individuals who make the reconsideration determination must not
have been involved in the organization determination. We also reiterate that providers should
follow up on the status of a request with the payer. Failure to respond to a request for the status
of the pending prior authorization request does not constitute a denial (unless the lack of
response continues beyond the deadline for response) but may indicate other issues in the process
such that an appeal may not be necessary. We acknowledge that issues in communication
between payers and providers may continue to exist, and encourage providers to notify payers or
CMS of any patterns for poor communication and untimely issuance of prior authorization
decisions.
b. Medicaid Fee-for-Service, Including Beneficiary Notice and Fair Hearings
For the Medicaid FFS program, we proposed, in the CFR sections listed in Table E2,
regulatory timeframes to provide notice of decisions on both expedited and standard prior authorization requests. We stated that the new requirements would apply to prior authorization
decisions beginning January 1, 2026. We are finalizing that policy in this final rule.
Under the new requirement for Medicaid FFS, which appears at 42 CFR 440.230(e)(1),
notice of the state Medicaid programs decision regarding an expedited request for prior
authorization will have to be communicated as expeditiously as a beneficiarys health condition
requires, but no later than 72 hours after receiving a providers request for an expedited
determination, unless a shorter minimum timeframe is established under state law. Notice of a
decision on a standard request for prior authorization will have to be communicated to the
requesting provider as expeditiously as a beneficiarys health condition requires, but no later than
7 calendar days after receiving the request, unless a shorter minimum timeframe is established
under state law. If the state determines that it needs additional information from a provider to
make a decision, or if the beneficiary or provider requests an extension, the proposed decision-
making and communication timeframe for a standard request may be extended by up to 14
calendar days if the beneficiary or provider requests an extension, or if the state agency
determines that additional information from the provider is needed to make a decision. Such
extensions may be justified and in the beneficiarys interest if medical evidence from outside
providers is needed to support the request, or if there are other circumstances identified by either
the provider or the beneficiary.
Independent of this final rules API proposals and their application to Medicaid prior
authorization requests, Medicaid has longstanding beneficiary notice and fair hearing
regulations. CMS has interpreted these existing regulations to apply to prior authorization
requests for Medicaid FFS and will continue to do so in the future. These existing Medicaid
beneficiary notice and fair hearing requirements will remain in full effect without change, in
concert with other provisions of this final rule, including the Prior Authorization API. As discussed in detail in the proposed rule (87 FR 76299 and 76300),the current
Medicaid notice and fair hearing regulations at 42 CFR 435.917 and 42 CFR part 431, subpartE,
apply to all prior authorization decisions. Therefore, states are required to--
 Provide the beneficiary with timely and adequate written notice of any decision
regarding the beneficiarys prior authorization request;
 Include the content described at 42 CFR 435.917 and at 42 CFR part 431, subpart E,
including information about the beneficiarys right to request a fair hearing to appeal the partial
or totaldenial, in the beneficiary notice when a state denies the prior authorization request in
whole or in part;
 Provide beneficiaries the opportunity to requesta fair hearing if the state fails to acton
a claim, which includes prior authorization requests, with reasonable promptness; and
 Provide at least 10-day advance notice to beneficiaries of any termination, suspension
of, or reduction in benefits or services for which there is a current approved prior authorization,
including information regarding the beneficiarys right to request a fair hearing.
These notice and fair hearing requirements are not affected by any of the changes made
elsewhere in this final rule. As noted in the CMS Interoperability and Prior Authorization
proposed rule, the Medicaid notice requirements are separate from and independent of, the new
timeline for provider notice that is finalized at 42 CFR 440.230(e)(1).
To make it explicit that existing Medicaid beneficiary notice and fair hearing rights apply
to Medicaid FFS prior authorization decisions, we proposed several updates to the existing
regulations at 42 CFR 431.201, 431.220, and 435.917, and a new 42 CFR 440.230(e)(2). The
proposed changes are intended to further explain, but not change, Medicaid notice or fair hearing
policy or operational requirements for states. We proposed and are finalizing, with one exception
discussed below, that the changes referenced in this paragraph take effect on the effective date of
the final rule. Please see 87 FR 76300 for the detailed text. The regulations and amendments are
listed in Table E3. The proposed changes for 42 CFR 431.201 included replacing the term beneficiary
with enrollee in the revised definition of Action. This change was proposed in error, and the
preamble to the CMS Interoperability and Prior Authorization proposed rule did not discuss the
potential impact of changing beneficiary to enrollee on the definition of Action. In this
final rule, we are reverting to the term beneficiary in the definition of Action at 42 CFR
431.201, consistent with the current definition and with our stated intent in the proposed rule that
the changes would not change Medicaid notice or fair hearing policy or operational requirements
for states.
We received comments on fair hearings and provide those and our responses here.
Comment: Multiple commenters expressed support for our proposal to further explain the
application of Medicaid notice and fair hearing requirements to Medicaid FFS prior authorization
decisions and recommended that the proposed changes be codified. A few commenters noted that
states already apply notice and fair hearing requirements to Medicaid FFS prior authorizations.
Multiple commenters noted that Medicaid agencies already have provider hearing rights for prior
authorization decisions in place.
Response: We appreciate commenters support for the proposed updates to the Medicaid
notice and fair hearing regulations, which we are finalizing as proposed.
Comment: A few commenters noted that patients should receive equitable fair hearing
rights for their prior authorizations, regardless of whether they are enrolled in a Medicaid FFS or
a managed care plan. A few commenters expressed support for the proposed changes which
would explain that Medicaid FFS notice and fair hearing requirements are consistent with current
regulations for notice and appeal rights for managed care prior authorization decisions.
Response: We agree that comparable and aligned notice and fair hearing rights should
apply across delivery systems. As discussed in the CMS Interoperability and Prior Authorization
proposed rule, we have historically interpreted the existing Medicaid notice and fair hearing
regulations to apply to prior authorization requests for Medicaid FFS. Given the alignment between these state-level requirements and the managed care plan-level requirements, equitable
notice and appeal rights have been and will continue to be available to Medicaid FFS and
managed care beneficiaries and that the updates, which we are finalizing as proposed, will
further strengthen the existing alignment between delivery systems regarding notices and fair
hearings/appeals.
Comment: A commenter stated that there needs to be more clarification in the rule that
existing Medicaid beneficiary notice and fair hearing rights apply to prior authorization decisions
for Medicaid FFS beneficiaries. Another commenter recommended CMS mandate more details
on the hearing process to ensure that a hearing can be conducted expeditiously and objectively. A
commenter recommended that the language in the regulation be strengthened to explicitly state
that failure to act on a request for prior authorization will give rise to notice and hearing rights.
Response: The updates we are making to these regulations, which we are finalizing as
proposed, provide additional details regarding how Medicaid beneficiary notice and fair hearing
rights apply to prior authorization decisions for Medicaid FFS beneficiaries. These changes
provide further detail about, but do not change, the current application of these regulations to
Medicaid FFS prior authorization decisions. Therefore, the existing requirements for the fair
hearing process at 42 CFR part 431, subpart E, apply to Medicaid FFS prior authorization fair
hearings. These include a requirement that fair hearings must be conducted by an impartial
person who was not directly involved in the initial decision (42 CFR 431.240(a)(3)) and
requirements for when the state must take final administrative action on a fair hearing request
(42 CFR 431.244(f)). These regulations also require the state to provide notice to a beneficiary
(42 CFR 431.206(c)(2)) whenever a hearing is required in accordance with 42 CFR 431.220(a),
which includes when the state fails to act upon a claim,including a prior authorization decision,
with reasonable promptness. Comment: A commenter recommended that CMS expand on proposed 42 CFR
440.230(e)(2) to require written notice of a prior authorization decision be provided to the
provider as well as the beneficiary.
Response: The Medicaid notice and fair hearing provisions at 42 CFR 435.917 and 42
CFR part 431, subpart E, which are cross referenced at 42 CFR 440.230(e)(2), apply to
applicants and beneficiaries, not providers. Therefore, we decline this recommendation and will
finalize 42 CFR 440.230(e)(2) as proposed. There are separate requirements regarding provider
notification of prior authorization decisions. As stated in this final rule, we are finalizing
requirements for payers to provide a specific reason for denials, as well as the status of a prior
authorization, either through the Prior Authorization API as specified, or through existing
processes. When providing a status for a prior authorization, the response must indicate whether
the payer approves (and for how long) or denies (and the reason) the prior authorization request,
or the payer may request more information from the provider to support the prior authorization
request.
Comment: A commenter raised concerns about whether and how notice and appeal rights
can be provided electronically and noted that lower-income consumers may have inconsistent
access to electronic communications. This commenter recommended that HHS continue to
require a redundant written notice for all important Medicaid notices, including those related to
prior authorization.
Response: The provision of electronic notices to Medicaid applicants and beneficiaries is
addressed at 42 CFR 435.918. Individuals must be provided a choice to receive notices in
electronic format or by regular mail and have the option to request that all electronic notices also
be provided by regular mail. Changes to 42 CFR 435.918 are outside the scope of this rule. The
Medicaid notice requirements, which include the provision of fair hearing rights, will continue to
apply unchanged when API-based notifications begin. Therefore, low-income beneficiaries enrolled in Medicaid will continue to receive notices by mail, electronically, or both, even after
the API-based notifications begin.
Comment: A commenter expressed that CMS's proposal to make explicit the requirement
for a fair hearing to appeal prior authorization non-compliance is inadequate to address prevalent
and profitable wrongful denials of prior authorization. This commenter stated that very few
patients can appeal wrongfuldenials and rarely do appeal and noted that medical practices aren't
compensated for prior authorizations or appeals, which harms patients as well.
Response: Fair hearings are an important part of a beneficiarys due process rights. While
fair hearings cannot directly prevent inappropriate denials of prior authorization requests, they do
provide a pathway for a beneficiary to remedy an inappropriate prior authorization denial,
termination, or reduction and provide data to states to help them identify problems with the prior
authorization process. We believe that improvements in the process overall will occur by using
the API once that is in place, as providers will have additional information on which to base the
submission of an initial prior authorization request.
c. Medicaid Managed Care
For Medicaid managed care, we proposed new timeframes for notice of decisions on
standard (non-expedited) prior authorization requests which would apply beginning with the
rating period that starts on or after January 1, 2026, and proposed to revise 42 CFR
438.210(d)(1) and (2) to accomplish this. Specifically, we proposed to revise 42 CFR
438.210(d)(1) to reflect that, beginning with the rating period that starts on or after January 1,
2026, managed care plans must provide notice of standard authorization decisions as
expeditiously as the enrollees health condition requires and within state-established timeframes
that may not exceed 7 calendar days following the plans receipt of the request for service. Our
proposed amendment provided that for rating periods that begin before January 1, 2026, the
current rule would remain in effect. We proposed to specify the standard authorization
requirements by the compliance dates by leaving the section header Standard authorization decisions as 42 CFR 438.210(d)(1) and redesignating standard authorization timeframes as 42
CFR 438.210(d)(1)(i)(A) and (B). We also proposed to move the current regulation text on
extending the prior authorization decision timeframe from 42 CFR 438.210(d)(1)(i) and (ii) to 42
CFR 438.210(d)(1)(ii)(A) and (B) and proposed to make slight revisions to the text for
readability. We explained that our proposal would not change the current provisions for how
failure to issue a decision within the required timeframe constitutes an adverse benefit
determination that can be appealed under 42 CFR 438.404(c)(5). The regulations at 42 CFR
438.404 and other regulations governing appeal rights at 42 CFR part 438, subpart F, would
continue to apply and we did not propose to amend those regulations. We note that 42 CFR
438.404(c)(3) through (6) provide that certain adverse benefit determinations must be issued on
the timing specified at 42 CFR 422.210(d); the new timeframes proposed (and finalized) in this
rulemaking will apply to those specific adverse benefit determinations. In addition, under current
regulations at 42 CFR 438.3(s)(1) and (6) and 438.210(d)(3), Medicaid managed care plans must
also comply with the requirements in section 1927 of the Act regarding coverage and prior
authorization of covered outpatient drugs; nothing in this rulemaking would change these
requirements. Finally, because some Medicaid MCOs are applicable integrated plans as defined
at 42 CFR 438.2, our proposal related to 42 CFR 422.631(d) applied to those plans.
We received a few comments on this subject and provide our responses to those here.
Comment: A commenter agreed with the proposal to provide notice of decisions for
standard prior authorization requests within state established timeframes not exceeding 7
calendar days, and another commenter disagreed with the proposal to shorten the maximum
amount of time for Medicaid managed care plans to respond with a decision from 14 to 7 days.
Another commenter proposed that the standard should be 24 hours or less for standard requests.
A commenter stated that Medicaid and CHIP managed care programs already have requirements
to issue prior authorization decisions within a certain timeframe established by the state and that
those standards provide adequate protection for enrollees and providers. Response: As we stated in the proposed rule, and based on CMS and other industry
studies on the impact of delays to patient health or access to care from extended authorizations,
reducing standard prior authorization decision timeframes from 14 calendar days to 7 calendar
days should improve patient care outcomes and ensure that patients have more timely access to
services (87 FR 76296).
d. CHIP Fee-for-Service and Managed Care
To implement the proposed prior authorization timeframes for CHIP, we proposed to
revise certain policies affecting the timing for making decisions on prior authorization requests
under the CHIP FFS and managed care programs. These changes are listed in Table E2. We
proposed that beginning on January 1, 2026, decisions related to prior authorization of health
services would be required to be completed in accordance with the medical needs of the patient,
but no later than 7 calendar days after receiving the request for a standard determination and 72
hours after receiving the request for an expedited determination, unless an alternative option is
preferred by industry based on public comments. Further, we stated that if a beneficiary requests
an extension of a prior authorization review, or if the provider or health plan determines that
additional information is needed for such review, an extension of up to 14 calendar days may be
granted.We proposed to remove the option for states to follow existing state law regarding prior
authorization of health services, requiring states to instead follow these updated timeframes.
However, if state laws are more stringent than our proposal, states would be allowed to apply and
enforce those shorter timeframes for prior authorization responses. Timely prior authorization
decisions are important patient protections, and CHIP patients should be afforded the same
decision timeframes as Medicaid and Medicare patients.
Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that a
beneficiary has an opportunity for external review of health services matters, including a delay,
denial, reduction, suspension, or termination of health services, in whole or in part, including a
determination about the type or level of service. Under this regulation, CHIP beneficiaries must have an opportunity for external review of prior authorization decisions. We did not propose any
changes to this requirement, as it already applies to decisions related to the prior authorization of
services.
In the CMS Interoperability and Prior Authorization proposed rule we explained that
overall, we believed that the decision and notification timeframes proposed for certain impacted
payers would help ensure that prior authorization processes do notinappropriately delay patient
access to necessary services. Introducing prior authorization decision timeframes that are the
same across these impacted payers for items and services that require prior authorization would
also help providers better organize and manage administrative resources and thus may make
more time available for providers to render patient-centered care.
Currently, CHIP managed care program regulations reference the Medicaid managed care
regulations for the timelines and requirements for CHIP managed care entities as to prior
authorization decisions and notices as well as appeal processes. We explained in the proposed
rule that the proposal to amend 42 CFR 438.210(d) for timeframes would also apply to standard
and expedited decisions made by CHIP managed care entities because of the cross reference to
42 CFR 438.210 in current 42 CFR 457.1230(d). We did not propose to change the required
timeframes for expedited decisions at 42 CFR 438.210(d)(2), but we proposed to amend 42 CFR
438.210(d)(2)(i) to explain that the MCO, PIHP, or PAHP must make these decisions on shorter
timeframes if the state requires shorter timeframes. We did not propose any changes to the
authority for a 14-calendar day decision timeframe provided at 42 CFR 438.210(d)(2)(ii).
We received the following comments related to CHIP FFS and managed care and include
our responses to those comments here.
Comment: A commenter disagreed with CMSs proposal to shorten the maximum amount
of time for CHIP FFS and managed care to respond with a decision from 14 to 7 days.The
commenter proposed that the standard should be 24 hours or less. Another commenter
recommended CMS provide equal protection for children enrolled in CHIP FFS against unnecessary delays in accessing necessary services due to prior authorization procedures. The
commenter also recommended that state CHIP agencies follow the same rules as state Medicaid
agencies, including specific timelines for prior authorization responses for outpatient prescription
drugs. Another commenter expressed their support for aligning the beneficiary protections in
CHIP and Medicaid managed care and recommended CMS maintain 42 CFR 457.1230(d) as
proposed, applying 42 CFR 438.210 to CHIP managed care entities with the proposed shorter
timelines for responses to standard requests for prior authorization, characterizing these as
stronger beneficiary protections.
Response: Though we anticipate the Prior Authorization API will introduce additional
efficiencies into the prior authorization process, we are uncertain that such a truncated standard
decision timeframe would be possible until we have completed further data collection and
analysis after the implementation of the API. The recommendation concerning CHIP prior
authorization decision timeframes for outpatient prescription drugs is outside the scope of the
final rule. We agree with comments that recommend CHIP prior authorization decision
timeframes be in alignment with Medicaid.
We are finalizing the proposals to adopt the timeframes we proposed for responses by
MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and
CHIP managed care entities to prior authorization requests. We are not requiring that impacted
payers approve a request for prior authorization if that payer fails to meet the required standard
or expedited decision timeframe. If a payer fails to meet the timeline for approval or other
decision, providers should contact the payer to obtain the status of the request and determine if
supporting documentation is needed to complete the processing of the authorization or if there
are other reasons for the delay in a decision. The 72-hour requirement for expedited requests is
measured in hours, whereas the 7-day requirement for standard requests is measured in calendar
days. In the case of expedited and standard requests, the timeframes are 72 hours and 7 days,
respectively, unless a shorter minimum timeframe is established under state law. Tables E2 and E3 provide a list of some, but not all of the final policies for decision
notification timelines for the impacted payers. The full list of final policies and citations is
included in Table E4 at the end of this section. We included these tables for ease of reference for
the narrative on the discussion of notifications and timeframes.
Table E3 is specific to the Medicaid FFS notice and fair hearings provisions, which
provide an important service to beneficiaries and providers alike. This rule finalizes
modifications to those provisions, and this table and accompanying narrative provide the reader
with citations to new and existing provisions.
TABLE E2: NEW OR MODIFIED PRIOR AUTHORIZATION NOTIFICATION
REQUIREMENTS FOR MEDICARE ADVANTAGE ORGANIZATIONS, STATE
MEDICAID AND CHIP FEE-FOR-SERVICE, MEDICAID MANAGED CARE PLANS,
AND CHIP MANAGED CARE ENTITIES
ImpactedPayer Final CFRCitation
MAOrganizations NotificationRequirementtoEnrollees 42CFR422.568(b)(1)
ApplicableIntegrated NotificationRequirementtoEnrollees-Standard 42CFR422.631(d)(2)(i)(B)
Plans Decision
ApplicableIntegrated NotificationRequirementtoEnrollees-Expedited 42CFR422.631(d)(2)(iv)
Plans Decision
MedicaidFFS NoticetoProvidersofDecisionsonExpeditedand 42CFR440.230(e)(1)
StandardPriorAuthorizationRequests
MedicaidManagedCare StandardPriorAuthorizationDecisionNotification 42CFR438.210(d)(1)(i)
Plans
MedicaidManagedCare ExpeditedPriorAuthorizationDecision 42CFR438.210(d)(2)(i)
Plans Notification
CHIPManagedCare PriorAuthorizationDecisions Throughcrossreferenceto42
Entities CFR438.210at42CFR
457.1230(d)
CHIPFFS PriorAuthorizationDecisions 42CFR457.495(d)(1)
TABLE E3: FINAL MEDICAID FFS PRIOR AUTHORIZATION BENEFICIARY
NOTICE AND FAIR HEARING REGULATORY AND AMENDATORY CHANGES
ImpactedPayer Final CFRCitation
MedicaidFFS ModificationtoHeaders 42CFR435.917(a)
42CFR435.917(b)
MedicaidFFS ReviseDefinitionofAction 42CFR431.201
MedicaidFFS AdditionofPriorAuthorizationDecisionto 42CFR431.220(a)(1)(vi)
SituationsforFairHearing
MedicaidFFS AddaNoticeofDenialorChangeinBenefitsor 42CFR435.917(b)(2)
ServicestoNotices
MedicaidFFS BeneficiaryNoticeofPriorAuthorizationDecision 42CFR440.230(e)(2)
andFairHearingRights
6. Extensions, Exemptions, and Exceptions See section II.E. of this final rule for a discussion of extensions and exemptions and the
final policies for the Prior Authorization API for state Medicaid and CHIP FFS programs and
exceptions for the Prior Authorization API for QHP issuers on the FFEs (this was also addressed
in the proposed rule at 87 FR 76279).
7. Public Reporting Requirements for Prior Authorization Metrics
In the CMS Interoperability and Prior Authorization proposed rule we discussed the
importance of accountability for payer prior authorization practices and proposed that certain
data be made publicly available for patients and providers to better understand the types of items
and services which required prior authorization and how each payer performed over time for
approvals and denials. We are finalizing our proposal to require impacted payers to report certain
aggregated metrics about prior authorization by posting them on the payers website. This
requirement underscores the importance of transparency and accountability in the health care
system. Public disclosure of the items and services which are subject to priorauthorization, as
well as organizational performance, offers useful information to providers, patients, and other
interested parties. Performance data could allow for objective evaluation of the efficiency of
prior authorization practices of each organization, and it enables payers to assess trends, identify
areas for improvement, and work towards continuous process improvement while maintaining
necessary quality checks for quality and appropriateness of care.
We are finalizing as proposed that state Medicaid and CHIP FFS programs will report at
the state level, Medicaid managed care plans and CHIP managed care entities will report at the
plan level, and QHP issuers on the FFEs will report at the issuer level.We are finalizing a
modification to our proposal forreporting to be at the organization level to require that reporting
be at the contract level for MA organizations as discussed in this section (section II.D.7. of this
final rule). Additionally, we explain that integrated plans will reportitems and services covered
by MA organizations at the MA contractlevel and items and services covered by Medicaid managed care plans at the plan level as the separate requirements for MA organizations and
Medicaid managed care plans will apply under the respective contracts.
We described how payers might use the information for process improvements and
performance analysis in the proposed rule (87 FR 76304). For example, an impacted payer could
use these data to examine its performance trends. In addition, we explained how providing this
information publicly would benefit patients (who could use the information when selecting
among plan or organization options) and providers (in when and whether to contract with an
impacted payer). The legal authority for requiring such public reporting is discussed in section
II.D.10. of this final rule.
We are finalizing our proposal that for each metric listed, data would be reported in
aggregate for all items and services. We received many comments on the proposed public
reporting of metrics, the timing, and the level of reporting. The suggestions were detailed and
represented diverse issues and concerns from interested parties about prior authorization
challenges and potential uses for the data. CMS will use the comments received as CMS
considers future policy development. We intend to support transparency and accountability and
enable patients to access data that are meaningful and easy to use for decision-making and
understanding the prior authorization processes. The metrics we are finalizing represent the most
significant issues for both patients and providers identified over the past decade on a national
level, including the CMS listening sessions referenced at the beginning of this section.
Furthermore, payers can supplement the information they report with additionalmetrics on prior
authorization. We may consider additional reporting options in the future. We reiterate that the
prior authorization reporting metrics are on medical items and services, excluding drugs covered
by the impacted payers.
We are finalizing the requirement for impacted payers to make reports available annually
on allof the following:
 A list of all items and services that require prior authorization.  The percentage of standard prior authorization requests that were approved,
aggregated for all items and services.
 The percentage of standard prior authorization requests that were denied, aggregated
for all items and services.
 The percentage of standard prior authorization requests that were approved after
appeal, aggregated for all items and services.
 The percentage of prior authorization requests for which the timeframe for review was
extended, and the request was approved, aggregated for all items and services.
 The percentage of expedited prior authorization requests that were approved,
aggregated for all items and services.
 The percentage of expedited prior authorization requests that were denied, aggregated
for all items and services.
 The average and median time that elapsed between the submission of a request and a
determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all
items and services.
 The average and median time that elapsed between the submission of a request and a
decision by the payer, plan, or issuer, for expedited prior authorizations, aggregated for all items
and services.
a. Reporting Prior Authorization Metrics
As described previously, we proposed to require impacted payers to report certain metrics
to support a level of accountability for the requirements in this final rule. As discussed
previously, public disclosure of information for each audience  patients, providers, and the
general public  supports the intent of this final rule to improve the prior authorization process,
patient care, and burden reduction.
Comment: Many commenters supported CMSs efforts to promote transparency through
public reporting of these aggregated metrics. These commenters believe such reporting will increase transparency from payers related to the volume of prior authorizations. For example, a
commenter wrote to encourage CMS to propose in future rulemaking to use the prior
authorization data the agency would collect from impacted payers to help develop quality
measures to incorporate into quality ratings across certain payer programs, specifically for MA
organizations. This would ensure that such data are incorporated more directly into a consumer-
friendly comparison tool so that payers prior authorization practices are available to physicians
and practitioners, including gastroenterologists, to ensure transparency and accountability in the
prior authorization process. Multiple commenters stated that reporting metrics could be
informative to providers in the context of what they submit to payers for prior authorization
requests, as the data might provide insights about the types of services that are approved or
denied. A commenter noted that prior authorization metrics could be useful to patients as they
decide which health plans to select, and another commenter appreciated that CMSs proposal
aimed to strike a balance between data reporting burden and providing meaningful data to
consumers and providers. Another commenter supported reporting prior authorization metrics on
the payers website by March 31, 2026. Some commenters believed that CMS should require
public reporting of the metrics sooner than proposed, and multiple commenters recommended
that CMS require the public reporting requirement immediately upon finalizing the rule.
Response: We thank commenters for their support of our proposed priorauthorization
reporting metrics, including those commenters who recommended that CMS consider additional
future uses for the data for other program purposes and require compliance as soon as the rule is
finalized. We agree that payers have the data available now, as they are currently conducting the
prior authorization process, and that the data would provide a baseline for reporting. As proposed
and finalized, CMS is not collecting these data, but instead requiring impacted payers to post
such data on the payers website. We encourage payers to consider developing and posting
reports of these metrics at the earliest date feasible. We are finalizing the requirements for public
reporting as well as the compliance dates in 2026, as proposed. Comment: Multiple commenters recommended that CMS require payers to report prior
authorization data at a more granular level.Specifically, multiple commenters recommended that
CMS require MA organizations to report prior authorization metrics at the plan level or state
level. Commenters stated that the organization level for MA organizations was a higher level of
aggregation than the plan level for Medicaid managed care plans and CHIP managed care
entities and therefore would not present the same level of detail. Those commenters pointed out
that MA organization metrics reported at the organization level would not be useful to consumers
choosing plans in their area. Other commenters suggested more discrete reporting levels,
including county level, specialty/benefit level, or service level.
Response: Upon further consideration and taking the comments into account, we
determined that contract level is the more appropriate reporting level for MA organizations. MA
organizations generally have multiple plans under the same contract as it is common throughout
the industry to offer a variety of plans within a service area. Contract-level data are aggregated
data that are collected from the plan benefit packages (PBPs) (that is, the various MA plans)
offered under an individual contract; these data are specific to the contract to which they
correspond. CMS already requires MA organizations to report some contract-level data about
their organization determinations to the agency on an annual basis and Star Ratings are assigned
at the contract level. While this particular provision does not require MA organizations to submit
data to CMS, a consistent approach of contract-level reporting in the MA program will give
consumers useful information while limiting plan burden. By requiring contract-level reporting
for these data, we ensure that the format of this reported data remains consistent with that of
other similar data that MA organizations are required to report.
We agree that requiring Medicaid managed care plans and CHIP managed care entities to
report at the plan level will allow beneficiaries and states to compare plans within the state.
Requiring QHP issuers on the FFEs to report at the issuer level, aggregating plans under their
purview, is consistent with their reporting on quality improvementstrategies as described in section 1311(g) of the Affordable Care Act(45 CFR 156.1130), which provides consistency with
other QHP reporting requirements.
While we understand the desire from some commenters to increase the level of
granularity for reporting, we have concerns about data overload, patient understanding, and
usability of the data. For example, reporting at the specialty level and service level could be
overwhelming because of the volume of information presented. A patient might not be able to
relate to the data and would not refer to the reports as intended. There can and should be both
transparency and accountability in the information that is presented to the public and we will
continue to explore opportunities to strike the appropriate balance with impacted payers. We are
finalizing a modification to ourproposal for MA organizations to reportat the contract level. We
are finalizing, as proposed, that state Medicaid and CHIP FFS programs will report at the state
level, Medicaid managed care plans and CHIP managed care entities will report at the plan level,
and QHP issuers on the FFEs will report at the issuer level.
We may assess whether to collect more detailed metrics than we are finalizing here in
program-specific rulemaking in the future. For instance, we may consider requiring in future
rulemaking that MA plans report at a more discrete level. Similarly, should a state Medicaid or
CHIP agency believe it would be beneficial to require more detailed data, the state may require
additional metrics in its managed care contracts.
Comment: A commenter requested clarification on whether integrated care plans for
dually eligible individuals, such as FIDE SNPs, should report these data consistent with MA
organizations, at the contract level, or consistent with Medicaid managed care plans, at the plan
level.
Response: Integrated care plans generally combine D-SNPs, which include FIDE SNPs
and HIDE SNPs  both as defined at 42 CFR 422.2  and Medicaid managed care plans offered
by the same parent organization. D-SNPs are a type of MA plan designed to meet the needs of
individuals who are dually eligible for Medicare and Medicaid, also known as dually eligible individuals. In these arrangements, there is an MA organization with a contract with CMS for the
MA D-SNP and an organization with a contact with the state for the Medicaid managed care
plan.
For items and services that require prior authorization under an integrated plans MA
benefit package, data must be reported in a manner consistent with the requirements for MA
organizations, which we are finalizing at the contract level. In the case of integrated care, the
affiliated Medicaid managed care plan will report prior authorizations of items and services
covered under the plan's Medicaid benefit package at the plan level. Where there is not a clear
delineation between whether items or services are covered under Medicare or Medicaid (for
example, home health services), we will accept any reasonable methodology for attributing the
prior authorization reporting to one payer versus the other.
Comment: Multiple commenters recommended a more phased-in approach to the
reporting of prior authorization metrics. A commenter stated that while prior authorization
metrics should not be publicly reported until after the electronic FHIR APIs have been
implemented, the prior authorization metrics should still be reported to CMS beginning March
2026. A commenter recommended that CMS begin to phase in reporting requirements before the
2026 implementation period (for example, require payers to report some, but not all, metrics
soon after the rule is finalized) to help identify any issues with the reporting process so that they
can be addressed timely.
Response: We disagree that a phased-in approach to reporting metrics is necessary given
that payers already conduct prior authorization processes and likely already track data for many
of the metrics for their usual business operations. We are finalizing compliance dates in 2026, as
stated previously. We agree that reporting prior authorization metrics conducted using the Prior
Authorization API will not be reported until after the Prior Authorization API has been
implemented, and that the technology could be capable of supporting automated reporting on its
use. The metrics to be included in the reports beginning in March 2026 will be based on an impacted payers currentprior authorization processes, in advance of implementation of the Prior
Authorization API. Reporting information about performance data in advance of implementation
could provide valuable data in the years post-implementation.
Comment: Multiple commenters expressed concerns about how the prior authorization
metrics could be used by payers in inappropriate or harmful ways to providers. A commenter
flagged that the publicly reported metrics could lead to plans self-selecting patients by
implementing other burdensome prior authorization processes to avoid approving services,
which could lead to patients who need those services enrolling in other plans. Another
commenter recommended that CMS address steps it will take to protect against adverse
selection. This commenter urged CMS to consider how it will mitigate unintended consequences
that may occur as competing payers decide to analyze each others data once it becomes public.
The commenter wrote that CMS should make clear that any such practices would be against the
spirit and intent of the reporting requirements.
Response: We acknowledge concerns by a few commenters that prior authorization
policies and information on the publicly reported metrics could technically be used
inappropriately for improper decision-making purposes or other reasons. Public reporting does
not in and of itself create such behavior. However, we believe requiring that public availability
of prior authorization metrics will have the opposite effect; that is, payers will use the data to try
to improve their performance to improve their competitive standing in a program.
In addition, there are some safeguards in place to help address the concerns raised by
commenters about inappropriate efforts to discourage enrollment by individuals who need
certain covered services. Medicaid managed care regulations also provide significant patient
protections for access to covered services at 42 CFR 438.206 through 438.210. For example, 42
CFR 438.210(a) requires states contracts with Medicaid managed care plans to identify, define,
and specify the amount, duration, and scope of each service covered by the plan and such
amount, duration, and scope must be no less than that furnished to Medicaid FFS beneficiaries. Existing regulations at 42 CFR 438.66 require states to have a monitoring system that addresses
all aspects of each Medicaid managed care program and to use the data collected from their
monitoring activities to improve the performance of their managed care program,including at a
minimum enrollment and disenrollment trends in each managed care plan. Additionally, 42 CFR
438.66(e) requires states to submit to CMS a report on each of their Medicaid managed care
programs that provides information on and an assessment of the operation of the managed care
program.
Further, section 1852(b)(1) of the Act prohibits discrimination by MA organizations on
the basis of health status-related factors and directs that CMS may not approve an MA plan if
CMS determines that the design of the plan and its benefits are likely to substantially discourage
enrollment by certain MA eligible individuals. In addition, MA organizations must comply with
applicable Federalcivil rights laws that prohibit discrimination on the basis of race, color,
national origin, sex, age, or disability, including section 1557 of the Affordable Care Act, Title
VI of the Civil Rights Act of 1964, section 504 of the Rehabilitation Act of 1973, and the Age
Discrimination Act of 1975. The regulation at 42 CFR 422.110 provides that an MA organization
may notdeny, limit, or condition the coverage or furnishing of benefits to individuals eligible to
enroll in an MA plan offered by the organization on the basis of any factor that is related to
health status. MA organizations discouraging or preventing enrollment in an MA plan by
beneficiaries by implementing burdensome prior authorization processes to avoid approving
services would be prohibited by 42 CFR 422.110. CMS relies on the MA anti-discrimination
provision; the agencys authority under section 1856(b) of the Act to adopt standards for MA
organizations; and the agencys authority under section 1857(e) of the Act to add terms and
conditions that are necessary, appropriate, and not inconsistent with the Medicare statute. CMS
does not collect detailed information on prior authorization policies as part of the bid. However,
CMS will continue to monitor for potential discrimination by plans through prior authorization
and other utilization management programs in our review of complaints received from beneficiaries and providers and will take action, as necessary. CMS may also consider future
sub-regulatory guidance based on a review of complaints.
We also believe that MA and other managed care plans will use the published data to
drive performance improvement to facilitate provider network development and that providers
will use the prior authorization metrics to evaluate managed care plans and make decisions on
whether to join or remain part of a plans network.
Comment: A commenter recommended that if CMS intends to require public reporting in
the final rule, CMS should explain how the data would benefit interested parties and conduct
education and outreach to prevent confusion or misinterpretation of data. Multiple commenters
stated their hesitation to require public reporting of prior authorization data without
understanding the purpose of the reporting, and another recommended that CMS reevaluate the
need and value of payers reporting the prior authorization metrics versus its costs and resource
burden. Multiple commenters highlighted the significant new administrative burden that
reporting prior authorization metrics would cause. Other commenters recommended that CMS
remove the proposed requirement for payers to publicly report prior authorization metrics.
Response: We are aware that payers have many reporting requirements for state and
Federal programs and that preparing these public disclosures may require additional effort.
Payers also provide educational resources to patients and providers for enrollment, directories,
and other health care reminders  all to explain benefits and services and improve the health care
experience. We are finalizing policies in this final rule to address longstanding, important
process challenges related to prior authorization. Reporting on these metrics, including, for
example, the services that require prior authorizations, the number of denials, those approved,
and those overturned after appeal, will give the patients and providers a better understanding of
payer performance in those categories  and over time  of the changes in performance in those
categories. These data will demonstrate the intended impact of these policies. Public reporting is
one of the most universal, effective means to demonstrate improvement or change. This public reporting has value because it can provide a benchmark for patients or providers to understand, at
a high level, the volume of services a payer approves or denies, the types of services it
authorizes, or changes in those decisions over time. Not all patients will use or necessarily
understand all of the data, but it may help support the beginning of a conversation between either
the patient and the payer, or the patient and the provider. We anticipate payers will identify the
most appropriate locations on their website for the information to be public. We additionally note
that the Medicare FFS program currently publicly reports prior authorization metrics on its
website and invites payers to reference the presentation of those metrics as they develop their
public reporting strategy.147
Comment: A commenter recommended that a voluntary consensus SDO should develop
standardized codes that could be used to document prior authorization denial reasons. Then,
CMS could revise the metrics to include information on the reason for denial to provide a more
complete picture of a plans prior authorization process.
Response: As discussed previously in the section on providing a reason for denial, the
standard codes for denial reasons are an external code set maintained by X12, which is a
voluntary SDO. Any organization or individual interested in providing updates to this code set
may do so by submitting a request to X12. At this time, we are not requiring payers to publicly
report the reason for denial in these reporting metrics; that information is only provided to the
requesting provider and the patient.
Comment: Another commenter recommended that state Medicaid agency reporting
requirements be changed to begin 1 year following the implementation of the APIs (by March 31
of each year). Another commenter stated that the proposed metrics do not align with the data
elements required to be reported for appeal for the Managed Care Annual Care Program Report
(MCPAR) that states are required to report. The commenter stated that alignment is necessary to
147CentersforMedicareandMedicaidServices(2023,September15).PriorAuthorizationandPre-ClaimReview
Initiatives.Retrievedfromhttps://www.cms.gov/data-research/monitoring-programs/medicare-fee-service-
compliance-programs/prior-authorization-and-pre-claim-review-initiatives. assess the impact of an MCO, PHIP, or PAHPs prior authorization determinations on
beneficiary access to requested services.
Response: We disagree that any payer should begin their reporting period substantially
after any other payer, as all payers already have data to supporttheir prior authorization
activities. Even if a state Medicaid agency were granted an exception or extension, their prior
authorization processes are already in effect and they have data regarding their current prior
authorization activities. The final action statement in this section of the final rule includes the
compliance dates and reporting requirements for impacted payers, which remains March 31,
2026, for reporting data for the prior year. Concerning the MCPAR, alignment is neither
necessary nor feasible. The MCPAR collects information specifically on appeals, and we are
requiring information specifically on prior authorization. While it is true that a denied prior
authorization could generate an appeal, that is not relevant to these two reporting vehicles. We
may revise the data collected in the MCPAR in the future and will use the existing data from the
MCPAR and this reporting to inform any such revisions.
Comment: Multiple commenters recommended that CMS develop standard guidance or
IGs for payers to have a set format and consistent calculation of the metrics. A commenter
flagged that the lack of guidance on report formatting could lead to a wide variation across
impacted payers. Another commenter stated that CMS should issue the guidance and allow
adequate time for impacted payers and vendors to make the appropriate modification to their
system before public reporting begins. A commenter sought clarification as to whether the public
reporting of prior authorization metrics would only apply to prior authorization requests that are
received on or after the compliance dates. Another commenter recommended that rule language
specify the data required, ensure the data are placed prominently on the payers websites, and
indicate the cadence at which payers must refresh the publicly reported data. Many other
commenters suggested various dissemination mechanisms for the prior authorization metrics. A
commenter stated that they support an active distribution method for the prior authorization metrics, like a newsletter. Another commenter recommended that prior authorization metrics be
available to be downloaded in Excel and PDF.
Response: The Medicare FFS program currently publicly reports prior authorization
metrics on its website and invites payers to reference the presentation of those metrics as they
develop their public reporting strategy. We will consider what additionalsupport we can provide
to impacted payers before the compliance date of the final rule regarding recommended content
and format for use in their public reports. The requirement for data in the first report for prior
authorization metrics to include information about prior authorization activity for the prior year
will provide a baseline for impacted payers as well as the public. The reporting requirement
applies to prior authorization requests that were received the year before the compliance date.
Comment: Multiple commenters recommended that CMS report the required prior
authorization information on the CMS website. A commenter stated that this will enable easy
retrieval of data by physicians and patients, especially forplan comparison. Another commenter
stated that CMS should also make sure it publishes this information on pages of its website that
correlate to a particular payer. A commenter stated that CMS should report on the impact prior
authorization has on the quality of care patients receive, potential delays in care, and associated
cost savings due to the prior authorization process. The commenter suggested that reporting these
data can help policymakers, researchers, providers, and patients make more informed decisions
about the prior authorization process, ensuring that patient care remains central. Multiple
commenters recommended that instead of payers publicly reporting metrics, there should be
confidential reporting to CMS so it can track outliers and avoid misleading patients on data that
are not comparable across plans. Another commenter recommended that CMS consider
confidential payer reporting to CMS until the Prior Authorization API experiences significant
uptake by providers.
Response: We considered requiring that payers submit their reports to a central website
for publication. However, as we explained in the CMS Interoperability and Prior Authorization proposed rule (87 FR 76347), we did notselect this alternative because we believe patients likely
would view their health plan and payer as the resource for information about their plan. While
CMS does provide comparative data for plans in certain programs (for example, the MA
program) and may use such information in future public reports, we are not finalizing such an
approach in this rule. Patients should be able to find information about their plan or payer from
those websites to minimize burden and confusion. For Medicaid and CHIP, patients generally
associate their coverage with their state or managed care plan, not CMS. While having the prior
authorization data posted on each payers website is the most appropriate place, we also
encourage state Medicaid agencies to include the data on their websites (which are required by
42 CFR 438.10(c)(3)) to improve the value of information available to their patients. Similarly,
MA patients look to their MA organization websites for information and resources about those
plans and their performance. Payers must already include significant patient resource information
on their websites, and CMS will conduct outreach to payers, patients, and providers to help
provide guidance on best practices about the website locations for such public reporting of prior
authorization information. In our oversight role, we may begin to look at data after the
compliance date to evaluate compliance with these new reporting requirements. CMS may
consider additional reporting requirements as well as publication of comparative information in
the future.
Comment: Multiple commenters stated it would be helpful for additional context to
explain metrics in the event of an outlier, such as explaining denial or approval rates for services-
related data. Multiple commenters suggested including the total number of requests
approved/denied, rather than only aggregate percentages. A commenter stated that they also
would like to see specific data for common services to show a direct comparison across different
payers and plans as certain prior authorization requests are more complex than others.
Multiple commenters stated that service-specific reporting will aid in identifying services
for which there is a high rate of approval and for which priorauthorization requirements may no longer be necessary, or for identifying critical services or items being routinely denied. A
commenter recommended CMS require payers to provide more detailed information by item or
service including Healthcare Common Procedure Coding System (HCPCS) code, Current
Procedural Terminology (CPT) code, and International Classification of Diseases, Tenth
Revision (ICD-10) code.Other suggestions included requiring payers to report disaggregated
data by diagnosis, race and ethnicity, gender, and age. A commenter warned that without item-
and service-level reporting, it will be impossible for CMS and the public to understand some data
and to hold impacted payers accountable for excessive denials and delays in responding to prior
authorization requests. Other commenters recommended CMS require payers to report data with
setting-specific data or by type of provider (for example, physician, short-term care, long-term
care, rehabilitation, psychiatric, and skilled nursing services). A commenter stated that only with
this setting level of specificity will patients and providers be able to assess which services are
routinely denied, appealed, and overturned in favor of patients and providers. Another
commenter warned that segmentation by the provider should encompass short-term acute care,
long-term care, rehabilitation, psychiatric, and skilled nursing services to allow consumers,
providers, and regulators to gain a better understanding of prior authorization processes and
where there is a need for improvement. A commenter recommended that CMS should require
metrics be broken down at the Health Care Provider Taxonomy code set Level II, Classification,
which is a code set used in HIPAA standard transactions. Another commenter recommended that
the metrics be reported by the payer based on service type, site of care, and whether the service is
inpatient or outpatient. Another commenter wanted CMS to compare the metrics for MA
organization plans to Medicare FFS and commercial health plans.
Response: Service-specific and demographic reporting may be very usefulto the
impacted payers in evaluating their programs and expect that they use such data today and will
continue to do so as they implement the policies of this final rule. While we agree that there
could be many more reporting requirements, and at more granular levels, and data are an important tool for different evaluation purposes, reporting should serve its intended purposes and
not become a burden to the users. Too much data can also become overwhelming. We anticipate
patient and provider feedback following implementation and will review opportunities after that
time.
We agree that it would be appropriate to compare the metrics for all payers several years
after the policies of this final rule have been implemented to determine its impact on the prior
authorization barriers and burdens. However, commercial plans other than QHPs on the FFEs are
not subject to the provisions of this rule, and CMS does not have access to performance data for
those organizations. If states are collecting such data, they might be able to analyze the data at
the state level.
b. Publication of Prior Authorization Metrics
We requested comments on how the information might be displayed on payer websites in
a useful and meaningful manner for patients and providers, including which data would be most
useful. The summarized comments and our responses follow.
Comment: Multiple commenters recommended that the prior authorization metrics be
presented in a readable and accessible format, particularly for individuals with disabilities,
individuals with limited or low health and data literacy, and individuals with limited English
proficiency. Other commenters recommended that CMS require plans to write publicly reported
data at a sixth grade reading level, conduct consumer-focused testing on data readability, and
provide translations in multiple languages. Multiple commenters recommended that CMS should
require payers to provide access to prior authorization data in multiple languages (based on the
most common languages in a community) and in a format that is comprehensible to the average
consumer. A commenter recommended CMS should make the reported payer data patient-
friendly and public to enable comparison of metrics.
Response: We appreciate commenter suggestions that payer data be patient-friendly,
easy to understand, and in an accessible format. We may consider how best to provide guidance to encourage impacted payers to develop their reports with these factors in mind, as the intent of
these public reports is to ensure that individuals can use and interpret the information.
c. Types of Prior Authorization Metrics
Impacted payers are required to post a general set of prior authorization metrics on their
public websites to support process improvement, as well as patient and provider insight into
trends for different payers. While the data will not be submitted to CMS at this time, it will be
available for public review and evaluation and may be informative as experience with the new
policies evolves.
Comment: Some commenters wrote that CMS should include more data on use of the
Prior Authorization API. A commenter suggested certain metrics be considered for adoption: the
number of requests initiated using the Prior Authorization API, average response time for
requests not requiring a prior authorization, the number of requests initiated using the Prior
Authorization API requiring a prior authorization, the number of requests initiated using the
Prior Authorization API requiring a prior authorization that had all of the required
documentation available automatically, the percentage of Prior Authorization API requests
requiring a prior authorization with allrequired documentation available processed
automatically, the number of requests initiated using the Prior Authorization API requiring a
prior authorization that were unable to automatically supply required documentation, and a list of
allSMART on FHIR app/EHR combinations or equivalent technology used for Prior
Authorization API requests at provider organizations. A commenter encouraged CMS to
consider breaking reporting out by prior authorization transactions supported by a FHIR API
transaction and those otherwise conducted.
Response: The intended goal of publicly reporting these metrics is to help providers and
patients gain insights into the payers prior authorization practices and performance, and to assist
payers in evaluating their prior authorization practices. While the performance and utilization of
the Prior Authorization API is valuable information forassessing the adoption and use of the API itself, it may not adequately represent the full scope of a payers prior authorization practices. As
noted in a prior response, we may consider issuing guidance before the compliance date with
more specifics on the recommended format and content; however, the lack of regulations or
guidance on the format and content does not prevent payers from including additional
information that could be of value to patients and providers.
8. Gold-Carding Programs for Prior Authorization
We solicited comments on the potential for gold-carding or prior authorization exemption
programs and how they might reduce provider and payer burden and improve services to
patients. We also solicited comments on the incorporation of such a measure into Star Ratings
for these organizations. We received several comments on this topic and appreciate the input.
Since no policies were proposed, we are not finalizing policies in this area at this time. We thank
commenters for their feedback and will consider all comments for possible future rulemaking. rsEs
PIssueheFFFR223(b) FR223(b) FR223(a)
QHont45C156. 45C156.(4) 45C156. N/A N/A N/A N/A
S d g g
e n n
LPOLICIE CHIPManagCareThroughexisticrossreferenceto42CFR438.242at42CFR457.1233(d) Throughexisticrossreferenceto42CFR438.210at42CFR457.1230(d) N/A N/A N/A
A
N
I er S 4) 1) 1) 1) 2)
F y F ( ( ( ( (
SES edPa HIPFFR732(b) FR732(b) FR732(a) FR495(d) FR495(d) FR732(d) FR732(d)
S ct CC7. C7. C7. C7. C7. C7. C7.
E a 25 25 25 25 25 25 25
C mp 44 44 44 44 44 44 44
O I
ZATIONPR ationsforEach MedicaidManagedCareThroughcrossreferenceto42CFR431.80(b)at42CFR438.242(b)(7)Throughcrossreferenceto42CFR431.80(b)at42CFR438.242(b)(7) Throughcrossreferenceto42CFR431.80(a)at42CFR438.242(b)(8)42CFR438.210(d)(1) 42CFR438.210(d)(2) N/A N/A
I ul
R g
O Re FS )(i )(i
H F 4) (1 (1 1) 2)
AUT edicaidCFR1.80(b) CFR1.80(b)( CFR1.80(a) CFR0.230(e) CFR0.230(e) CFR1.80(c)( CFR1.80(c)(
R M23 23 23 24 24 23 23
O 44 44 44 44) 44i) 44 44
I
R ) )
ed 2 2
NGP plicablegratePlans FR122(a) FR631(d)() FR631(d)(
OVI ApInt N/A N/A 42C422. 42C422.(i)(B 42C422.(iv) N/A N/A
R
P
LEE4:IM MedicareAdvantage42CFR422.122(b) 42CFR422.122(b)(4) 42CFR422.122(a) 42CFR422.568(b)(1) Nochangetoexistingrulesonthetiming. N/A N/A
B
TA RequirementPriorAuthorizationAPI(CompliancedateJanuary1,2027)InformationAbouttheStatusofPriorAuthorization(Compliancedatey1,2027)JanuarDenialReasonforPriorAuthorization(CompliancedateJanuary1,2026)StandardPriorAuthorizationDecisionTimeframe(CompliancedateJanuary1,2026) ExpeditedPriorAuthorizationDecisionTimeframe(CompliancedateJanuary1,2026)ExtensionforStateMedicaidandCHIPFFS(EffectiveDateoftheFinalRule)ExemptionforStateMedicaidandCHIPFFS(EffectiveDateoftheFinalRule)
SectionoftheFinalRuleI.D.2.a. I.D.3.a. I.D.3.b. I.D.4.c. I.D.4.c. I.D.6. I.D.6.
I I I I I I I rsEs
QHPIssueontheFF45CFR156.223(d) 45CFR156.223(c) 45CFR156.223(c) nalpriorrtthesenew
oo
CHIPManagedCareN/A Throughexistingcrossreferenceto42CFR438.210at42CFR457.1230(d) dE3containadditigulationsthatsupp
ne
ar
mpactedPayer CHIPFFSN/A 42CFR457.732(c) N/A only.TablesE2ationonexisting
I sm
forEach dicaidgedCare R0(f) R0(f) ycitationForinfor
ulations MeManaN/A 42CF438.21 42CF438.21 regulatorulations.
eg S weg
R F ) er
MedicaidFN/A 42CFR440.230(e)(3 N/A ferencestothenviouslyexistingnthistable.
ApplicableIntegratedPlansN/A 42CFR422.122(c) 42CFR422.122(c) sandcrossredmentstoprectionslistedi
nne
oes
MedicaregeAdvantaN/A 42CFR422.122(c) 42CFR422.122(c) egulatorycitatireflectedinameineachofthe
wrarembl
RequirementExceptionsforQHPIssuersontheFFEs(EffectiveDateof)theFinalRulePublicReportingforPriorAuthorizationMetrics(Compliancedate)March31,2026PriorAuthorizationMetricsComplianceDate(CompliancedateMarch31,2026)histablecontainsnenrequirementsthatasereviewtheprea
Toe
SectionoftheFinalRuleII.D.6. II.D.7. II.D.7. *uthorizatiolicies,pl
ap 9. Final Action
After considering the comments received, and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule and our response to those comments (as
summarized previously), we are finalizing our proposals with the following modifications:
 Impacted payers must implement and maintain a Prior Authorization API
beginning 2027 (by January 1, 2027, for MA organizations and state Medicaid and CHIP FFS
programs; by the rating period beginning on or after January 1, 2027, for Medicaid managed care
plans and CHIP managed care entities; and for plan years beginning on or after January 1, 2027,
for QHP issuers on the FFEs) rather than in 2026.
 MA organizations must report prior authorization metrics at the contract level
rather than at the proposed organization level.
See further discussion for exact details of the final requirements for impacted payers.
We are finalizing that, beginning 2027 (by January 1, 2027, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1,
2027, for Medicaid managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2027, for QHP issuers on the FFEs), impacted payers must
implement and maintain a Prior Authorization API that is compliant with certain technical
standards, documentation requirements, and denial or discontinuation policies. Specifically,
those technical standards are HL7 FHIR at 45 CFR 170.215(a)(1), US Core IG at 45 CFR
170.215(b)(1)(i), and SMART App Launch IG at 45 CFR 170.215(c)(1).
We are finalizing that, by the compliance dates, impacted payers must implement a Prior
Authorization API that:
 Is populated with the payers list of covered items and services (excluding drugs)
that require prior authorization;
 Can identify all documentation required for approval of any items or services that
require prior authorization;  Supports a HIPAA-compliant prior authorization request and response; and
 Communicates whether the payer approves the prior authorization request (and
the date or circumstance under which the authorization ends), denies the prior authorization
request (with a specific reason), or requests more information.
We are finalizing that, beginning 2026 (by January 1, 2026, for MA organizations and
state Medicaid and CHIP FFS programs; by the rating period beginning on or after January 1,
2026, for Medicaid managed care plans and CHIP managed care entities; and for plan years
beginning on or after January 1, 2026, for QHP issuers on the FFEs), impacted payers must
provide a specific reason for a denial within their decision timeframe regardless of the method
that was used to send the prior authorization request or decision.
We are finalizing that, beginning in 2026, MA organizations, including applicable
integrated plans, state Medicaid and CHIP FFS programs, and Medicaid managed care plans and
CHIP managed care entities must provide notice to providers and patients of prior authorization
decisions as expeditiously as a patients health condition requires, but no later than 7 calendar
days for standard requests, unless a shorter minimum timeframe is established under applicable
state law.
We are finalizing that, beginning in 2026, MA organizations, including applicable
integrated plans, and state Medicaid and CHIP FFS programs, must provide notice to providers
and patients of prior authorization decisions as expeditiously as a patients health condition
requires, but no later than 72 hours for expedited requests, unless a shorter minimum timeframe
is established under applicable state law. That requirement already exists for Medicaid managed
care plans and CHIP managed care entities, but for consistency with Medicaid FFS, we are
finalizing that those payers must also send notices to patients and comply with a shorter
timeframe, if established by state.
In response to public comments, CMS will work with state Medicaid and CHIP FFS
programs that may be unable to meet the new prior authorization decision timeframes compliance date in 2026. States should contact their Medicaid state lead or CHIP project officer
before April 1, 2025, to discuss their extenuating circumstances. Any flexibility granted to a state
Medicaid or CHIP FFS program for the implementation of the new prior authorization decision
timeframes requirements will be temporary and limited to the unique circumstances of the
program.
We are finalizing that, as of the effective date of this final rule, existing Medicaid
beneficiary notice and fair hearing regulations apply to Medicaid FFS prior authorization
decisions.
We are finalizing that, beginning in 2026, impacted payers must annually report certain
aggregated prior authorization metrics. Specifically, by March 31, MA organizations at the
contract level, state Medicaid and CHIP FFS programs at the state level, Medicaid managed care
plans and CHIP managed care entities at the plan level, and QHP issuers on the FFEs at the
issuer level must post the required metrics on their websites. Impacted payers must publicly
report the previous calendar years metrics by March 31 following any year that they offered that
type of plan.
These policies apply to 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 listed in Table E4.
10. Statutory Authorities to Require Improvements in Prior Authorization Processes, Decision
and Notification Timeframe Policies
We did not receive any public comments on the statutory authorities for the Prior
Authorization API and prior authorization process policies discussed in this section.
a. Medicare Advantage
Section 1856(b)of the Act directs the Secretary to establish regulatory standards for MA
organizations that are consistent with, and carry out, Part C of the Medicare statute, including the
provisions in section 1852 of the Act. Section 1852(a) and (d) of the Act provide for MA plans to cover medically necessary Part A and Part B benefits, including by making benefits available
and accessible with reasonable promptness. Section 1852(c)(1)(G) of the Act requires that MA
organizations disclose to their enrollees any rules regarding prior authorization or other review
requirements that could result in nonpayment. Section 1852(g)(1)(A) of the Act requires an MA
plan to have a procedure for making determinations about whether an enrollee is entitled to
receive a health service, how much the enrollee is required to pay for such service, and to
provide an enrollee with a written notice if the plan denies coverage. Section 1852(g)(1)(A) of
the Act also requires that coverage determinations be made on a timely basis. Section
1852(g)(3)(B)(iii) of the Act requires that the organization notify the enrollee (and physician
involved, as appropriate) of an expedited determination (and reconsideration) under time
limitations established by the Secretary, but not later than 72 hours after the time of receipt of the
request. The prior authorization requirements in this final rule ensure that MA organizations
carry out their responsibilities under section 1852 of the Act in a consistent and standardized
fashion and in compliance with standards that carry out and serve the purposes of the MA
program.
Under the authorities referenced previously, we are finalizing certain requirements for
MA organizations. These requirements are to ensure that MA organizations provide enrollees
with appropriate access to care and information by using certain standards, technologies, and
business processes. The requirements include implementing certain APIs thatprovide
information about the coverage and documentation requirements for prior authorization,
responding to prior authorization requests with the status of that request, and meeting certain
timeframes for making decisions on prior authorization requests.
We are requiring that MA organizations implement the Prior Authorization API using
certain implementation specifications as discussed in section II.G. of this final rule. These
implementation specifications are expected to improve the overall prior authorization process by
addressing deficiencies that exist in the process today concerning providers access to information about the prior authorization rules and documentation requirements. The Prior
Authorization API will communicate the coverage and documentation requirements for prior
authorization, indicating if authorization is required for a specific item or service and what
documentation is required to support an authorization request. Use of the Prior Authorization
API is consistent with the disclosure obligation on MA organizations in section 1852(c)(1)(G) of
the Act by disclosing to providers the same information that generally must be provided to
enrollees about which covered benefits are subject to prior authorization and serves the same
larger purpose of ensuring access to coverage by communicating the limits and rules for covered
services.
Additionally, the Prior Authorization API is a mechanism for receiving and responding to
requests for coverage determinations before the services are rendered or items furnished;
therefore, the requirement to adopt and use the Prior Authorization API is an additional standard
for implementing and complying with section 1852(g) of the Act regarding an MA
organizations obligation to make coverage determinations. The Prior Authorization API will
enable the provider to submit a HIPAA-compliant prior authorization request through their
existing workflow and receive a timely response to that request. In concert with these APIs, we
are requiring the payer to provide the status of the request, such as whether it was approved or
denied, along with a specific denial reason, so that the provider knows what steps to take next 
whether to request a different service for the patient, to submit additional information,or to
appeal the decision. These final requirements will improve patient care and reduce redundancies
in administrative processes between providers and payers because they give providers clearer
instructions, both for submitting the original request and, if necessary, providing additional
information. The required API has the potential to improve the efficiency of the prior
authorization process because it enables providers to submit accurate information with the
request, which could reduce the number of appeals or denials, and possibly eliminate requests for
additional documentation. We expect the prior authorization policies in this final rule to improve timely access to
care for beneficiaries by mitigating delays that sometimes occurwhen a provider is trying to
determine coverage requirements or does not know what documents to submit to obtain approval
for a service. Improvements in the timeliness of payer operations and provider services will
contribute to program efficiency, and effective operations and will be in the best interest of the
enrollees. The requirement for MA organizations to make certain changes to the timeframes in
which they provide notice for prior authorization has the potential to improve patient access to
care in program operations as discussed in section II.D.5. of this final rule. This could prevent
some patients from abandoning care while waiting for authorization, and it could improve
efficiencies by avoiding repeat phone calls from providers who must check on the status of
authorization over several days, or sometimes weeks. We finalized requirements to improve
some timeframes for expedited and standard decisions under the premise that these changes are
overdue, feasible, and would benefit patients and providers. Furthermore, by establishing more
certainty in the process for providers, there may be a reduction in unnecessary repeat requests for
services. More responsive timeframes will also enhance enrollee access to timely and appropriate
care. A shorter timeframe for both standard and expedited decisions may reduce administrative
time and expense for providers and payers, as they would spend fewer resources on follow-up
inquiries. As such, these requirements are consistent with our authorities to adopt standards to
carry out and implement the requirements in section 1852 of the Act for MA organizations to
have a procedure for making timely determinations and to make benefits available and accessible
with reasonable promptness.
Finally, section 1857(e)(1) of the Act explicitly authorizes the adoption of additional
reporting requirements by MA organizations where necessary and appropriate. The requirement
for MA plans to publicly report prior authorization metrics will enable CMS to assess the
implementation of the policies and attempt to determine the impact of these new requirements on
payers and providers. A review of these metrics may help CMS and the plans understand the impact of the requirements, including the impact of using the APIs and improved decision
timeframes. The data may also help plans evaluate operations, implement new policies and the
API, and determine what changes may be appropriate.
b. Medicaid
For Medicaid, most of the requirements finalized in this section are authorized by
sections 1902(a)(4), (8), and (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, and section 1902(a)(19) of the Actrequires states to ensure that care
and services under a Medicaid state plan are provided in a manner consistent with the simplicity
of administration and the best interests of the recipients. Some requirements finalized in this
section are also authorized by additional sections of the Act as discussed in this section of the
final rule.
Additionally, 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 purposes that are directly connected with the administration of the program or
plan. The implementing regulations at 42 CFR part 431, subpart F, for this section 1902(a)(7) of
the Act list purposes that CMS has determined are directly connected with the administration of
Medicaid state plans (42 CFR 431.302) and require states to provide safeguards meeting certain
requirements to restrictuses and disclosures of Medicaid beneficiary data. CHIP programs are
subject to the same requirements through a cross reference at 42 CFR 457.1110(b).
Our finalized policy that the data described in this section be shared via the Prior
Authorization API is consistent with the requirement at section 1902(a)(7) of the Act, providing
that states may share these data only for purposes directly connected with the administration of
the Medicaid state plan. This data sharing policy for the Prior Authorization API is related to providing services for beneficiaries, a purpose listed at 42 CFR 431.302(c). The services include
those for which the state requires that a provider submit a prior authorization request, and thus
needs to communicate about that prior authorization with other providers enrolled with or
authorized by the state to provide care to its beneficiaries. Prior authorization can be an integral
part of the Medicaid program and facilitates access to care as well as provider payment
processes.
We remind states that to meet the requirements of the regulations at 42 CFR part 431,
subpart F, states must have consistent criteria for the release and use of information (which
should comply with the proposed Prior Authorization API requirements), 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 state Medicaid
agency, in accordance with 42 CFR 431.306(b). Similar to the Provider Access API discussed
previously, the permission requirement at 42 CFR 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 the Prior Authorization API,
because any request for beneficiary information would be from an enrolled Medicaid or CHIP
provider and thus would not be from an outside source. While the beneficiarys permission is not
required under 42 CFR 431.306(d) for the Prior Authorization API, state or other laws may
require such permission. When requesting approval to provide certain services from the state
using the states Prior Authorization API as described in section II.D.2.a. of this final rule, the
provider will be able to determine if prior authorization is required and what supporting
documentation is necessary to obtain approval for that care.
i. Prior Authorization API
The requirement for state Medicaid FFS programs and Medicaid managed care plans to
implement the Prior Authorization API is expected to improve the efficiency and timeliness of
the prior authorization process for Medicaid beneficiaries, providers,state Medicaid agencies, and Medicaid managed care plans by addressing inefficiencies that might exist in the process
today. As discussed in section II.D.2.a. of this final rule, the Prior Authorization API will allow a
provider to determine whether a prior authorization is required and the documentation
requirements for that prior authorization request. The Prior Authorization API will:
 Enable providers to submit a complete prior authorization request faster and easier;
 Support more timely notice to the provider and beneficiary of the disposition of the
prior authorization request; and
 Permit improved scheduling of services or filing appeals, depending on the decision.
The Prior Authorization API has the potential to improve the prior authorization process by
making it more efficient, including by reducing the number of denials and appeals, or even by
eliminating requests for additional documentation, as noted elsewhere in this final rule.
ii. Requirement for Payers to Provide Specific Reason for Denial of Prior Authorizations
Based on the provisions of this final rule, states and Medicaid managed care plans must
provide specific information to providers about the status of prior authorization requests to
enable providers to plan care for their patients after submitting a prior authorization request. As
discussed in section II.D.3.of this final rule, when providers receive a response to a prior
authorization request, the payer will typically indicate whether the request is approved, or
denied, or if additional information is needed. If prior authorization has been denied, the payer
must give the provider the specific reason for the denial; that information may be used by the
provider to decide next steps, such as re-submitting the request with updated information,
identifying alternative treatments for the patient, or appealing the decision. These requirements
will improve the timeliness, clarity, and consistency of information for providers regarding prior
authorization requests; help providers determine the next steps for timely patient care; and
reduce payer, provider, and patient burden by eliminating the need for repeated inquiries. iii. Requirements for Prior Authorization Decision Timeframes, Notifications Related to Prior
Authorization Decision Timeframes, and Amendments to Existing Medicaid Fair Hearings and
Appeals Regulations
As discussed in section II.D.5. of this final rule, delayed prior authorization decisions
may directly affect patient care by delaying access to treatment, services, and supplies, as well as
transfers between hospitals and post-acute care facilities. The required timeframes for making
prior authorization decisions about items and services that require prior authorization in
Medicaid FFS and managed care programs will help providers better manage administrative
resources, make more time available for providers to render patient care, and facilitate faster
access to services. These requirements should make substantive improvements to the care
experience for Medicaid beneficiaries and lead to better health outcomes. In turn, better health
outcomes will contribute to more efficient use of Medicaid program resources.
The requirement to shorten the maximum amount of time for a Medicaid managed care
plan to make a prior authorization decision from 14 calendar days to 7 calendar days will
improve the efficient operation of the Medicaid program by facilitating faster receipt of services
or filing of appeals.
Our amendment to explicitly state in the regulation text that current notice and fair
hearing requirements apply to Medicaid FFS prior authorization decisions is authorized under
section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan
provide an opportunity for a fair hearing to any individual whose claim for medical assistance
under the plan is denied or is not acted upon with reasonable promptness. This is also supported
by the 14th Amendment to the United States Constitution and case law on due process,
specifically, Goldberg v. Kelly, 397 U.S. 254 (1970). States must establish timely notice and fair
hearing processes meeting due process standards under Goldberg v. Kelly, as incorporated into
existing Medicaid fair hearing regulations at 42 CFR part 431, subpart E, see 42 CFR
431.205(d). Additionally, section 1902(a)(17) of the Act requires state Medicaid plans to include
reasonable standards for determining the extent of medical assistance under the plan that are
consistent with the objectives of Title XIX of the Act. As setforth at 42 CFR 440.230, the
standards that states establish under section 1902(a)(17) of the Act could include appropriate
limits on a service based on such criteria as medical necessity or on utilization control
procedures, as long as each service is sufficient in amount, duration, and scope to reasonably
achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to
42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This
would include covered items and services described in sections 1905(a), 1915(c), 1915(i),
1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by
Congress. The standards that states establish under section 1902(a)(17) of the Act and 42 CFR
440.230 could include prior authorization requirements. The requirements to establish
timeframes for prior authorization decisions are authorized under section 1902(a)(17) of the Act
because they would be expected to help ensure that states make prior authorization decisions in a
manner that is consistent with the requirements in section 1902(a)(4), (a)(8), and (a)(19) of the
Act, thus helping to ensure that states standards for determining the extent of medical assistance
under the plan are consistent with the objectives of Title XIX.
Section 1932(b)(4) of the Act provides thateach Medicaid MCO must establish an
internal grievance procedure whereby a beneficiary who is eligible for medical assistance may
challenge the denial of coverage or payment for such assistance. CMS has implemented
requirements for those procedures at 42 CFR 438.210, which applies the same appeal and
grievance requirements for PIHPs and PAHPs as for Medicaid MCOs. We rely on our authority
in section 1902(a)(4) of the Act to adopt standards for PIHPs and PAHPs that mirror
requirements for MCOs. This is consistent with our prior practice for adopting standards for
Medicaid managed care plans (81 FR 27507). We rely on the same authority here to revise the
procedures under which Medicaid managed care plans may make prior authorization decisions about coverage and provide those decisions to providers and enrollees. Reducing plan response
time for prior authorization decisions may enable beneficiaries to file appeals if necessary and
receive a resolution to those appeals sooner. The earlier an appeal is filed, and the disposition
known, the sooner the provider and beneficiary can determine whether to request a state fair
hearing or to identify treatment alternatives, if necessary. The prior authorization requirements in
this rule are also consistent with how section 1932(c)(2)(A)(i) of the Act requires MCO contracts
to contain a provision for an annual external quality review of quality outcomes and access to
and timeliness of covered services. If the shorter prior authorization response requirements
successfully improve workflow and processes that facilitate timely access to services,
improvements to the care experience for patients, and better health outcomes, the results should
be visible in external reviews. This requirement reflects the importance and potential advantages
of timely access for beneficiaries to covered services through more efficient processing of prior
authorization requests as proposed in this rule.
iv. Public Reporting of Prior Authorization Metrics
We are also requiring Medicaid FFS programs and Medicaid managed care plans to
publicly report certain prior authorization metrics by posting them on the payers website. As
discussed in section II.D.7.of this final rule, publicly reporting these metrics may support more
timely access to services by identifying prior authorization process weaknesses or deficiencies
and enabling the implementation of corrective action, and for managed care programs, helping
beneficiaries select Medicaid managed care plans that best meet their needs and helping some
Medicaid providers make informed decisions on which Medicaid managed care plan networks to
join.
Section 1902(a)(4) of the Act authorizes this requirement because enabling more timely
access to services by identifying prior authorization deficiencies and facilitating the
implementation of corrective action to improve the prior authorization process will support the
proper and efficient operation of the state Medicaid plan. Requiring Medicaid managed care plans to publicly report their prior authorization metrics will hold them accountable and enable
them to monitor their performance and identify process improvement opportunities, which may
be an integral part of implementing a quality assessment and improvement strategy more easily.
This is consistent with the requirements for quality strategies for managed care programs at
section 1932(c)(1)(A)(i) of the Act.
Section 1902(a)(8) of the Act authorizes this requirement because identifying prior
authorization process weaknesses or deficiencies and enabling the implementation of corrective
action as well as helping beneficiaries select a Medicaid managed care plan that best meets their
needs may improve the promptness with which services are provided to beneficiaries. Section
1902(a)(19) of the Act authorizes this requirement because identifying prior authorization
process weaknesses or deficiencies and enabling the implementation of corrective action will
help ensure that care and services are provided in a manner consistent with the simplicity of
administration. Additionally, implementation of corrective action to improve prior authorization
processes, helping beneficiaries select a managed care plan that best meets their needs, and
helping providers make informed decisions on which Medicaid managed care plan networks to
join is in the best interest of beneficiaries.
c. CHIP
For CHIP, we finalized these requirements under the authority of section 2101(a) of the
Act, which sets forth that the purpose of Title XXI is to provide funds to states to provide child
health assistance to uninsured, low-income children effectively and efficiently that is coordinated
with other sources of health benefits coverage. This provision authorizes us to adopt these
requirements for CHIP to obtain access to program data for analysis. Such analysis supports
improvements in the efficacy of CHIP programs and more efficient administration of services.
As discussed previously, we are requiring the implementation of the Prior Authorization
API in section II.D.2.a. of this final rule to improve the prior authorization process for patients,
providers, and payers by addressing deficiencies and inefficiencies that exist currently. Today, a payers rules about when prior authorization is required and whatdocumentation requirements
must be fulfilled to submit the request are not necessarily easily accessible for providers. The
Prior Authorization API will enable a provider to determine if a prior authorization is required
electronically, in real-time and what the documentation requirements are regarding such
requests. While we expect providers to be the primary beneficiaries of this API, making this
information available in a standardized way and permitting access through an API will also serve
the requirements in section 2101(a) of the Act that CHIP ensures access to coverage and
coordinated care.
The Prior Authorization API is a mechanism for receiving and responding to requests for
coverage determinations before the services are furnished; this API will streamline the initial
authorization process for the payer by sharing this information in an easily accessible way. The
API will also allow the provider to know what to do if prior authorization is required for a certain
service, which will improve the providers ability to treat the patient timely. The Prior
Authorization API enables the payer to send a real-time response back to a provider, based on
the request for authorization. This, too, will improve the efficiency of providing services to the
patient because the request and response are automated and in real-time. We expect payers use
of this API to ensure that a provider can submit a request for prior authorization with the correct
and complete documentation to avoid an incorrect submission which might result in an
unnecessary denial. The Prior Authorization API will: (1) enable providers to submit a prior
authorization request faster and easier; (2) support more timely notice to the provider and
beneficiary of the disposition of the prior authorization request; and (3) permit faster scheduling
of services or filing appeals, depending on the decision. The Prior Authorization API has the
potential to improve the prior authorization process by making it more efficient, including
limiting the number of denials and appeals, or even eliminating requests for additional
documentation, as noted elsewhere. The safeguards for beneficiary information at 42 CFR part 431, subpart F, are also
applicable to CHIP through a cross reference at 42 CFR 457.1110(b). As discussed previously
for Medicaid, CHIP payers and providers data exchange through the Prior Authorization API is
related to providing services to beneficiaries, which is described at 42 CFR 431.302(c) as a
purpose directly related to state plan administration. We remind states that when they share
medical records or any other health or enrollment information aboutindividual beneficiaries,
they must comply with the privacy protections at 42 CFR 457.1110 and the release of
information provisions at 42 CFR 431.306.
The requirement in section II.D.5. of this final rule that CHIP FFS and CHIP managed
care entities meet certain timeframes to provide decisions for prior authorizations for expedited
and standard decisions is an improvement from the current state, where there is uncertainty about
expectations for when a prior authorization might be approved. This requirement is intended to
establish more certainty in the prior authorization process for providers and improve access to
appropriate care for all patients, particularly those with chronic conditions or complicated health
risks. Health parity may be increased as barriers due to process and timeframes will be removed.
Similarly, improved process improvements may reduce administrative costs for providers and
payers as redundancies will be removed from the system. We expect the requirement to improve
timeliness in responding to providers and patients to support process improvements for the state
and managed care programs and is consistent with our authorities under section 2101(a) of the
Act in that it improves the efficiency of the CHIP programs.
The policy to require CHIP FFS and CHIP managed care entities to publicly report prior
authorization metrics will also support the states oversight, evaluation, and administration
responsibilities. CMS may occasionally view some of the CHIPs FFS and managed care
websites to check for compliance, see how data are being reported, and determine if any trends in
prior authorization changes could be indicative of the benefits of the prior authorization policies as discussed in section II.D.7. of this final rule.The data may indicate the use of the APIs,
improvements in prior authorization numbers, or changes in total numbers, denials, and appeals.
d. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we finalized the requirements in this section under the
authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the
discretion to certify QHPs if the Exchange determines that making available such health plans
through the Exchange is in the interests of qualified individuals in the state in which the
Exchange operates.
The policies finalized here may improve the efficiency of the issuers that are certified to
offer QHPs on the FFEs and improve the quality of services they provide to providers and their
patients by increasing the efficiency in the prior authorization submission and review process. In
section II.D.2.a. of this final rule, we are requiring that QHP issuers on the FFEs implement an
API to support the prior authorization process. The Prior Authorization API will allow QHP
issuers on the FFEs to communicate requirements for prior authorization more efficiently and
enable providers to similarly operate more efficiently to determine when a prior authorization is
needed and locate the documentation requirements. The Prior Authorization API may enable
more accurate submission and subsequent processing of prior authorization requests, with the
potential of improving the delivery of services to patients. Qualified individuals enrolled in
QHPs on the FFEs may receive covered services more quickly using the API. Similar to the
other APIs, we believe that certifying only health plans that implement the Prior Authorization
API and adhere to the other requirements described in this section of the preamble is in the
interests of qualified individuals in the state or states in which a QHP issuer on the FFEs operates
because of the opportunities for improvements in patient care, in alignment with the goals of the
Affordable Care Act. We encourage SBEs to consider whether a similar requirement should
apply to QHP issuers participating in their Exchanges. We are also requiring that QHP issuers on the FFEs provide a specific reason fordenial
when sending a response to a prior authorization request, to facilitate better communication and
understanding between the provider and issuer. This may enable efficient and successful
resubmission of the previously denied prior authorization request, which may more promptly
facilitate the needed patient care.
Finally, the requirement for QHP issuers on the FFEs to publicly report prior
authorization metrics in section II.D.7. of this final rule will hold issuers accountable to their
providers and patients, which could help these organizations improve their program
administration. These data may help QHP issuers on the FFEs evaluate their processes and
determine if there are better ways to leverage the APIs, including the quality and sufficiency of
the coverage and documentation information included in the APIs. E. Extensions, Exemptions, and Exceptions and Federal Matching Funds for Medicaid and
CHIP
1. Background
The CMS Interoperability and Prior Authorization proposed rule discussed extensions,
exemptions, and exceptions forstate Medicaid and CHIP FFS Programs and QHP issuers on the
FFEs, Federal funding available to states, and applicability to state Medicaid expansion programs
for CHIP populations. As stated in the Provider Access, Payer-to-Payer, and Prior Authorization
API sections of this final rule we are consolidated in one section the requirements for applying
for an extension, exemption, or exception. Here we discuss those proposals,provide responses to
the comments received regarding the proposals,and include the final policies.
2. Extensions, Exemptions, and Exceptions
a. Extensions and Exemptions for State Medicaid and CHIP Fee-for Service
In the proposed rule we explained that state Medicaid and CHIP FFS agencies face
certain unique financing and operational circumstances that would not apply to other impacted
payers. For example, some states would need legislative approval to initiate a public
procurement process to secure contractors, particularly those with the necessary skills to support
a states implementation of the policies that require API development or enhancement. The
timeline for an openly competed procurement process, together with the time needed to onboard
contractors to develop the APIs can be lengthy for states (87 FR 76302). We described the issues
impacting the state Medicaid and CHIP FFS programs in the proposed rule for the Provider
Access (87 FR 76261), Payer-to-Payer (87 FR 76279), and Prior Authorization (87 FR 76302)
APIs. However, we also stated that if our proposals regarding these APIs were finalized, we
would strongly encourage state Medicaid and CHIP FFS programs to implement them as soon as
possible, because of the anticipated benefits for the impacted payers, patients, and providers.
Therefore, to address implementation concerns for state Medicaid and CHIP FFS programs, we
proposed a process through which states could seek an extension to, and, in specific circumstances, an exemption from, the requirements to implement and maintain Provider Access,
Payer-to-Payer, and Prior Authorization APIs.
We also proposed that states could request a one-time, 1-year extension through their
annual Advance Planning Document (APD) for Medicaid Management Information System
(MMIS) operations expenditures. We also proposed to permit state Medicaid FFS programs to
request an exemption from any or all of these three API requirements when at least 90 percent of
the states Medicaid beneficiaries are enrolled in Medicaid MCOs as defined at 42 CFR 438.2.
Similarly, we proposed that separate state CHIP FFS programs could request an exemption from
the API requirements if at least 90 percent of the states separate CHIP beneficiaries are enrolled
in CHIP MCOs as defined at 42 CFR 457.10. We proposed that states could apply for an
exemption by submitting a written request for the exemption as part of the annual APD for
MMIS operations expenditures. CMS approves project plans and enhanced FFP for Medicaid
Enterprise Systems (MES) using the APD process. CHIP waiver requests and expenditures for
systems are managed at CMS in the operations division responsible for management of APDs.
Guidance on the application process is available through each states Regional Office contact.
As discussed in section II.C.4.b. of this final rule, we proposed and are finalizing, that for
the payer to payer data exchange, state Medicaid and CHIP programs, rather than their managed
care plans or managed care entities, will be responsible for obtaining beneficiaries permission,
providing educational resources at the time of requesting permission, and identifying patients
previous/concurrent payers, including for beneficiaries covered under managed care (87 FR
76280). Therefore, we also proposed that an exemption would not apply to those requirements,
but only the API requirements,because it would prevent Medicaid managed care plans and CHIP
managed care entities from meeting their obligations.
For Medicaid managed care plans and CHIP managed care entities, we did not propose
an extension process because we believe that these managed care plans are actively working to
develop the necessary IT infrastructure to be able to comply with the requirements at 42 CFR 438.272(d)(5) and 42 CFR part 457. Many of these plans might benefit from efficiencies based
on allof the plan types that they offer. For example, many of these managed care plans with
Medicaid and CHIP beneficiaries are part of a larger organization serving MA and Marketplace
populations. These larger organizations often provide the technical and operational capacity that
would enable implementation of the APIs across all lines of business. We believe this would be a
practical and efficient use of resources to service all enrollees. Additionally, because the majority
of Medicaid beneficiaries receive all or some of their benefits in a managed care delivery system,
these plans should be held to the implementation times finalized in this rule to support the
intended policy goals. Please see 87 FR 76263 for the supporting narrative in the proposed rule.
Comment: Multiple commenters expressed support for the proposed Medicaid and CHIP
FFS extension policy and urged CMS to finalize this flexibility regarding compliance with the
Provider Access, Payer-to-Payer, and Prior Authorization APIs. Multiple commenters
highlighted extenuating circumstances that state Medicaid and CHIP agencies may face,
especially related to the conclusion of the COVID-19 public health emergency (PHE), and the
resulting impact on IT and personnel resources.
Multiple commenters submitted comments about which APIs should be included in the
extensions, exemptions, and exceptions proposals and some recommended that CMS extend
these flexibilities to all APIs included in the rule. A commenter recommended that CMS provide
clarity regarding the exemption and extension provisions for the Patient Access API
requirements.
Response: We acknowledge that states will be conducting long-term efforts to return to
normal Medicaid and CHIP operations after the end of the COVID-19 PHE and the continuous
enrollment condition under section 6008(b)(3) of the FFCRA. These efforts will continue
through 2024, and many of these states have ongoing system development initiatives that require
integration with MES and modules. Some states must work within their state legislative budget request cycle, as well as the Federal request cycle for requesting and obtaining funds for updates
to their systems or new contracts.
We reiterate that this final rule requires impacted payers to implement and maintain
Provider Access, Payer-to-Payer, and Prior Authorization APIs. Impacted payers should have
already implemented or begun implementation of the Patient Access and Provider Directory
APIs as required in the CMS Interoperability and Patient Access final rule, except for those
organizations that have approved exceptions, as applicable.148,149 We did notpropose a new
Patient Access API, but rather additional data requirements for that API, and reporting
requirements for use metrics. We did not propose any new extensions, exemptions, or exceptions
for the Patient Access API in the proposed rule and are not adding policies of that nature in the
final rule.
Comment: Multiple commenters expressed concern regarding the proposed state
Medicaid and CHIP FFS extension policies, specifically citing the importance of the impact of
these policies on Medicaid enrollees, and on the need for provider adoption to truly achieve the
burden reduction goals of the proposed rule for patients, payers, hospitals, and providers. A
commenter recommended that CMS not allow certain payers to have extensions because this
could affect provider adoption of the necessary technology. Another commenter expressed
appreciation of CMS for the proposal to allow extensions but stated that they believe provider
adoption is going to be the most important factor in achieving burden reduction. The commenter
emphasized the importance of having a certain percentage of their prior authorizations be
electronic so that there is a return on investment from the changes necessary (for example,
148IntheCMSInteroperabilityandPatientAccessfinalrule,wefinalizedthatPatientAccessAPIprovisionswould
beeffectivebeginningJanuary1,2021.Weannounceda6-monthenforcementdiscretionexercisedasaresultofthe
PHEuntilJuly1,2021.
149Forexample,45CFR156.221(h)permitstheFFEtograntanexceptiononanannualbasistotherequirementsin
paragraphs(a)through(g)ofthatsectionforanFFEQHPiftheExchangedeterminesthatmakingtheirhealth
plan(s)availablethroughtheExchangeisintheinterestsofqualifiedindividualsintheStateorStatesinwhichsuch
Exchangeoperates,andtheQHPissuersubmitsanarrativejustificationdescribingthereasonswhyitcannot
reasonablysatisfytherequirementsfortheapplicableplanyear,theimpactofnon-complianceuponenrollees,the
currentorproposedmeansofprovidinghealthinformationtoenrollees,andsolutionsandatimelinetoachieve
compliancewiththerequirementsofthissection. workflow changes, training, IT changes). The commenter stated that if payers are not held to the
requirements in the rule, it could be perceived as a disincentive to providers to invest in the
necessary technology.
Response: We thank commenters for confirmation that payers must be held accountable
for implementation of the APIs, and that provider adoption of certain APIs is going to be an
important factor in achieving burden reduction  particularly the Prior Authorization API.
Participation by both payers and providers in some of the API provisions of this final rule will be
important to ensure widespread adoption of the APIs. Because we also believe that provider
participation is important for the Prior Authorization API, we are finalizing a modification to our
proposal to adopt new Electronic Prior Authorization measures to incentivize providers
(specifically, MIPS eligible clinicians, eligible hospitals, and CAHs) to use the Prior
Authorization API under MIPS and the Medicare Promoting Interoperability Program as
discussed in section II.F. of this rule. We also reiterate that while these extensions and
exemptions apply to the new API provisions of this final rule, other policies must still meet the
compliance dates established in this final rule. These include the prior authorization information
to be included in the Patient Access API; information required under the finalized prior
authorization process, such as providing a specific reason for denial, and revised timeframes for
issuing prior authorization decisions. We encourage states to communicate their implementation
plans about the policies in this final rule (including those to which an extension or exemption
may apply) to network and enrolled providers. Such communication may help providers prepare
for changes in procedures or notify their vendors to make appropriate system changes on a
similar schedule.
Comment: A commenter said that the exemption for the APIs was a concern because it
creates an unfair, two-tiered system that may leave people with disabilities behind; these people
already face high barriers to care due to administrative burdens and uncertainties caused by prior
authorization. The commenter wrote that the proposed exemption process will leave some FFS Medicaid populations  groups that include a disproportionate share of people with disabilities 
without comparable access to any benefits derived from streamlining the prior authorization
process with the Patient Access, Provider Access, and Payer-to-Payer APIs. The commenter
noted the potential challenges of developing and maintaining the necessary data infrastructure for
a relatively small FFS population, but wrote that in many states, people receiving Home and
Community-Based Services (HCBS) through waivers that are carved out of managed care, may
be individuals who would fall under the proposed API exemption and would fail to benefit from
the streamlined prior authorization process in this regulation. Another commenter requested
clarification on whether and how CMS considered health equity when proposing exemptions for
some state Medicaid and CHIP programs. Other commenters expressed disagreement with the
proposed exemptions and stated that these exemption proposals should be withdrawn, to make
the APIs available to every Medicaid beneficiary. A commenter noted that states with managed
care populations close to the proposed threshold for exemption may be incentivized to pressure
beneficiaries into managed care to qualify for the exemption.
Response: We agree that it is important to consider access and equity issues, and the risk
of a two-tiered system that may impose barriers to care. CMS will only grant a state an
exemption from the Provider Access, Payer-to-Payer, and Prior Authorization APIs if the state
establishes an alternative plan to enable the electronic exchange and accessibility of the required
information that would otherwise be shared through the API. For example, CMS will only grant
a state an exemption from the Provider Access API requirement if the state has established an
alternative plan to ensure that enrolled providers have efficient electronic access to the same
required data content about their patients through other means while the approved exemption is
in effect. Similarly, states would be expected to use efficient means for electronic prior
authorization that would reduce burden for providers and improve access to information about
the requirements for when prior authorization is required for items and services or what
documentation is required in advance. In light of requirements for the accessibility of this information, states implementing an alternative plan will be required to provide this information
to all patients and providers in plain language and to offer auxiliary aids and services to ensure
effective communications with individuals with disabilities.
Comment: Multiple commenters recommended that CMS include managed care plans in
the proposed flexibilities (for extensions and exemptions) and some commenters said that each
state should be able to decide whether to allow an extension to managed care plans. A
commenter noted that managed care plans have greater resources than state Medicaid and CHIP
FFS programs and would be able to meet the rule requirements on time.On the other hand, a
commenter recommended that state Medicaid agencies offer managed care plans a 1-year
extension.
Response: We acknowledge commenters who recommended that CMS provide the
opportunity for an extension or exemption to Medicaid managed care plans and CHIP managed
care entities to align with our approach throughout the rule to apply most policies to both state
Medicaid and CHIP FFS programs and Medicaid managed care plans and CHIP managed care
entities. However, we reiterate that the purpose of the extension policy for state Medicaid and
CHIP FFS programs is to provide states that are making a good faith effort with additional time
to work through lengthy and complex state procurement processes, to secure the necessary
funding, personnel, and technical resources to successfully implement the requirements. The
purpose of the exemption policy for state Medicaid and CHIP FFS programs is to accommodate
the different enrollment models that are now in effect for each state and provide consideration
for states with relatively small FFS populations. In response to these and many other comments
requesting additional time for payers to implement the Provider Access, Payer-to-Payer, and
Prior Authorization APIs, we are extending the compliance dates for the policies in this final rule
that require API development or enhancement to 2027. This allows all impacted payers an
additional year to meet these requirements, compared to our initial proposal to implement the
requirements in 2026. We are finalizing the state Medicaid and CHIP FFS extension and exemption policies as proposed without extending this option to other payers in the Medicaid
program, such as Medicaid managed care plans. We do not agree with commenters who
suggested that each state be able to decide separately to allow an extension to managed care
plans because the purpose of this final rule is to encourage adoption of these policies as soon as
is practicable. As we have noted, Medicaid managed care plans are often owned and operated by
larger private organizations, also subject to this final rule, and likely have the resources and
capabilities to implement these policies and can efficiently leverage the work they do to build
APIs across their Medicaid, MA, and Marketplace lines of business. We do not want to
encourage a system where fewer Medicaid beneficiaries have access to the benefits of the
policies in this final rule versus those with other types of coverage.
Comment: Multiple commenters provided recommendations regarding additional payers
and plan types that should be eligible to benefit from the extensions, exemptions, and exceptions
proposals. Multiple commenters recommended that CMS extend these flexibilities to all
impacted payers. For example, a commenter recommended that HHS consider permitting state
Medicaid and CHIP agencies thathave a direct relationship with patients and providers to be
eligible for extensions, exemptions, or exceptions. Another commenter recommended that CMS
create an exception process for state Medicaid agencies in states or territories with HIEs that
would give participating providers the same data as the Provider Access API. Some Medicaid
agencies report concerns about duplication with these HIEs, as this would be an inefficient use of
resources, could confuse providers, and may inhibit efforts to expand HIEs. A commenter wrote
that CMS should create an exception process for Medicaid agencies in states or territories with
robust HIEs that provide access to the same data. Another commenter recommended that CMS
consider exception and extension criteria for plans where the proposed timelines and
requirements would jeopardize their ability to operate.
Response: We thank all commenters for their input regarding extensions, exemptions, and
exceptions for all payers. We are finalizing the extensions and exemptions policies as proposed for state Medicaid and CHIP FFS programs without extending them to additional payers because
state Medicaid and CHIP FFS programs face certain unique challenges. As noted previously,
unlike other impacted payers, state Medicaid and CHIP FFS programs do not have many discrete
health care plans, and therefore cannot balance implementation costs across plans with low
enrollment and those with higher enrollment. As stated at the beginning of this section, many
states have complex procurement and staffing/recruitment challenges which do not apply to non-
governmental organizations. We acknowledge HIEs could be helpful partners for payers when
implementing these APIs. Nothing in this rule would prohibit a state from partnering with an
HIE to meet its requirements. Further discussion regarding HIEs can be found in sections
II.B.3.b.iii. and II.C.3.a. of this final rule.
Comment: Some commenters recommended that CMS include extensions and/or
exemptions in the proposal for MA organizations, Special Needs Plans (SNPs), D-SNPs, or
Institutional Special Needs Plans (I-SNPs).150 A commenter wrote that CMS should also permit
extensions and exemptions for MA organizations offering integrated D-SNPs, especially if CMS
does not finalize a phased-in approach to implementation. The commenter wrote that some of
these payers are facing the challenge of unwinding current flexibilities implemented due to the
PHE and are also facing significant requirements in coming years as finalized in the CY 2024
MA and Part D final rule (88 FR 22120). Another commenter asked that CMS consider whether
there may be appropriate circumstances where it would be permissible for very small MA
organizations, such as SNPs or I-SNPs to seek a one-time extension to the compliance dates.
Response: We did not propose extensions or exemptions for MA organizations or
Medicaid managed care plans, including plans that integrate managed care Medicare and
Medicaid benefits (for example, D-SNPs or applicable integrated plans). We have provided
explanations for excluding Medicaid managed care plans in previous responses. We believe that
150WenoteforreadersthatMAorganizationsofferMAplans,whichincludeSNPs(includingthespecifictypesof
SNPsmentionedbycommenters-D-SNPsandI-SNPs),soweaddressthesecommentstogether. most MA organizations are supported by entities with an operational and technical infrastructure
that can support the API requirements because these organizations can leverage existing staff and
vendor resources from implementation of the Patient Access and Provider Directory APIs.
Further, MA organizations should have the operational infrastructure to analyze and implement
the requirements for the new APIs based on that expertise. Finally, because we did not propose
extensions or exemptions for MA organizations in the proposed rule, we cannot finalize such a
policy for these entities in this rule.
Comment: Some commenters recommended that CMS grant exemptions for states that
are already implementing electronic prior authorization solutions or state-level policies that
conflict with the proposed Prior Authorization API requirements.
Response: The option for states to apply for an exemption exists to alleviate burden for
states with small FFS populations and that have established an alternative plan to ensure that
enrolled providers have efficient electronic access to the same information through other means
while the exemption is in effect. We will not grant exemptions for situations where state law
conflicts with the final rule. The final rule pre-empts any conflicting state law.
Comment: Multiple commenters recommended that CMS consider allowing states to
obtain two 1-year extensions. A commenter stated that an additional, 1-year extension would
allow states to better meet the proposed requirements. Another commenter noted that states face
certain challenges that may be out of their control and prolong implementation.
Response: Afterconsideration of comments received and for the reasons outlined in our
response to these comments, we are extending the compliance dates for all of the polices that
require API development or enhancement finalized in this rule to begin January 1, 2027, which
will allow for additional time for the FHIR standard and IGs to continue to be refined and
advanced to support all of the policies in this final rule. This applies to the compliance dates for
the Provider Access, Payer-to-Payer, and Prior Authorization APIs. State Medicaid and CHIP
FFS programs will be eligible to apply for up to a 1-year extension as proposed. Comment: Multiple commenters expressed support for CMSs proposal regarding
exemptions for state Medicaid and CHIP FFS programs and recommended that CMS finalize
these proposed flexibilities regarding implementation of the Provider Access, Payer-to-Payer,
and Prior Authorization APIs. A commenter indicated that in reviewing exemption requests and
the compliance dates in the proposed rule, as well as other information system projects that are in
development, their plans to implement a comprehensive systems integration platform that would
integrate the MES would necessitate the option for an exemption. This commenter indicated that
the project was particularly urgent due to the end of system support for another legacy system.
Another commenter recommended thatCMS use a flexible interpretation for the exemption
process and noted that it would not be reasonable to require a state to build out APIs for a
Federal Emergency Services Program (FESP), explaining that some agencies report having a
high number of FFS enrollees in an FESP, such that less than 90 percent of their members are
technically enrolled in managed care.
Response: We appreciate the support for the proposed exemption process, as well as for
the simultaneous encouragement for payers to secure the necessary resources to implement the
technology for the prior authorization and other APIs being finalized in this rule. We also
confirm that the policy in this final rule does not apply to FESPs, and that other payers are not
being considered eligible for exemptions, extensions, or exceptions at this time.
Comment: A commenter noted that states with managed care populations close to the
proposed threshold for exemption may be incentivized to pressure beneficiaries into managed
care to qualify for the exemption. A commenter stated that larger states qualifying for an
exemption will have a total number of FFS beneficiaries that is greater than the total Medicaid
population of smaller states that would not qualify for the exemption.
Response: CMS needs to balance the benefits to small populations of beneficiaries with
the burden of new operations and costs being placed on states.CMS will not approve exemptions
unless a state has established an alternative plan to ensure that enrolled providers have efficient electronic access to the same information, including prior authorization information, through
other means while the exemption is in effect, or that states are providing efficient electronic
access to other payers. Additionally, state agencies with an approved exemption will be required
to meet the policies that do not require API development or enhancement for their FFS
populations (that is, the reduced prior authorization decision timeframes, providing a specific
reason for a denial, and reporting prior authorization metrics). These policies, to the extent they
will mitigate barriers to care or support improvements in the transparency of information
between the states and providers, are part of the overall scope for this final rule to address
challenges with prior authorization. Concerning the methodology states use to apply and be
approved for an exemption, we believe we have provided a threshold where a state could
appropriately claim an exemption without taking actions that would inappropriately influence the
enrollment process or individual enrollees enrollment decisions. States use of enrollment
brokers for choice counseling and enrollment processing also protects enrollees from undue
pressure during the enrollment process. We remind states of the enrollee protections specified at
42 CFR 438.54 and 457.1210 for Medicaid and CHIP managed care enrollment respectively, as
well as disenrollment rights specified at 42 CFR 438.56(c) and 457.1212, respectively.
Comment: A commenter urged CMS to use a flexible interpretation for the exemption
process for the API requirements for Medicaid agencies with at least 90 percent of their members
enrolled in managed care, noting that some states have a high number of FFS beneficiaries in an
FESP that are only covered for emergency care. The commenter stated that it would not be
reasonable to require a state to build out APIs for beneficiaries and programs that cover such a
narrow scope of services.
Response: We appreciate the commenter highlighting that some states may have larger
populations in FFS where beneficiaries are not receiving comprehensive benefits and thus may
experience only limited value from the APIs. Our intent with establishing this condition for
exemption approval is that no FFS population will experience diminished health care delivery or information exchange capabilities as a result of an approved exemption.The exemption intends
to alleviate the cost burden of implementing the API provisions on state Medicaid and/or CHIP
agencies with small FFS populations, regardless of the scope of their benefit package. We
remind states that CMS will grant an exemption if the state establishes to CMSs satisfaction that
the state meets the criteria for the exemption and has established an alternative plan to ensure
that enrolled providers have efficient electronic access to the same information through other
means while the exemption is in effect, including patient information and prior authorization
information.
b. Exception for Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
For QHP issuers on the FFEs, we proposed an exception process to the Provider Access,
Payer-to-Payer, and Prior Authorization APIs for issuers applying for QHP certification that
cannot satisfy the proposed requirements. To apply for an exception, we proposed that an issuer
must include as part of its QHP application a narrative justification describing the reasons why it
cannot reasonably satisfy the requirements for the applicable plan year, the effect of non-
compliance upon providers and enrollees, the current or proposed means of providing the
required information to providers or other payers, and solutions and a timeline to achieve
compliance with the requirements (87 FR 76304). We reiterate in this final rule that QHP issuers
on the FFEs submit a new application each year and that this information will be part of the
annual QHP Certification application submission. Thus, should the size, financial condition, or
capabilities of the QHP issuer change such that it believes it can implement one or more of the
APIs, that information would be included in the application. We received a few comments on the
proposals for exceptions for QHPs.
Comment: Multiple commenters expressed support for the proposed exception process for
QHP issuers on the FFEs, highlighting the need for this policy and recommending that CMS
finalize the proposal to allow exceptions for QHP issuers on the FFEs regarding compliance with
allproposed APIs. Response: We appreciate the support for the policy that QHPs be permitted an exception
for the policies that require API development or enhancement in cases where the FFE determines
that making such QHPs available is in the interests of qualified individuals in the state or states
in which the FFE operates, and an exception would be warranted to permit the QHP issuer to
offer QHPs through the FFE. This policy and the exceptions per 45 CFR 156.222(c) are
consistent with the exception for QHP issuers on the FFEs that we finalized for the Patient
Access API in the CMS Interoperability and Patient Access final rule (85 FR 25552). We believe
that having a QHP issuer offer QHPs through an FFE generally is in the best interest of patients;
we would not want patients to have to go without access to QHP coverage because an issuer is
unable to implement these APIs.
Comment: Multiple commenters expressed concern regarding the proposed exception
process for QHP issuers on the FFEs. Commenters specifically highlighted the ability for a QHP
issuer to be certified, even with an exception to these requirements. A commenter recommended
that CMS limit using exceptions for QHP issuers on the FFEs for the Provider Access API, and
another commenter recommended that CMS explain that QHP issuers on the FFEs must
eventually comply with the proposed requirements. A commenter expressed concern that if QHP
issuers on the FFEs can be certified without complying with the regulation, then there would not
be an incentive for compliance. A commenter stated that the proposal does not make sense given
the financial position of QHP issuers on the FFEs and their ability to afford cost-saving
technology. The commenter recommended that any exception be conditioned on no profit
taking by a health plan and limited executive compensation plans until the plan can comply.
Additionally, the commenter stated that CMS had not offered a reasonable proposal for criteria
to qualify a QHP issuer to be exempt from the proposed API requirements.
Response: We understand concerns from commenters about permitting delayed
implementation of requirements to promote access to information and expedited decision-
making.However, given the comments in support of the proposed exceptions process and our interest in ensuring a variety of coverage options for FFE enrollees, we are finalizing this
exception as proposed. While some issuers are in a position to implement the updates that this
rule requires, a wide range of issuers participate in the FFEs and vary in terms of when they will
have available resources to adopt these new requirements. Per applicable rules at 45 CFR
156.221(h), 156.222(c), and 156.223(d), we have been and will continue granting exceptions to
QHP issuers on the FFEs on an annual basis, and use information that issuers submit as part of
the QHP certification process to track their progress.
We will implement the exceptions processes per 45 CFR 156.222(c), and 45 CFR
156.223(d), based on our experience to date with implementing the existing exception per 45
CFR 156.221(h) that is available to QHP issuers on the FFEs that cannot satisfy the requirements
per 45 CFR 156.221(a) through (g) to implement and maintain the Patient Access API for the
applicable plan year. When determining whether a QHP issuer on an FFE may qualify for an
exception to the current requirement to provide a Patient Access API, we take into consideration
the content that the issuer submits per the requirement at 45 CFR 156.221(h), including the
impact of non-compliance upon enrollees, the current or proposed means of providing health
information to enrollees, and solutions and a timeline to achieve compliance with the
requirements of this section. This information allows us to assess whether a QHP issuer has a
plan in place to mitigate harm or inconvenience to enrollees by ensuring they can access
necessary information, as well as a plan to fully implement the requirements as soon as possible.
Information that issuers submit during the QHP certification process also allows us to develop a
knowledge base of API development capacity for issuers based on size and other circumstances,
which can inform future decisions about whether to allow exceptions. We expect to build on this
knowledge base as we implementthe exceptions processes per 45 CFR 156.222(c) and
156.223(d), and as part of our updates to the QHP certification process in the coming years to
reflect this rules new requirements, we will continue to work closely with issuers and other stakeholders to ensure that our implementation balances the importance of access to information
with robust QHP issuer participation on the FFEs.
Finally, QHP issuer applications for plan years 2023 and 2024 indicated that most issuers
were compliant with the requirement to provide a Patient Access API. Further, issuers that
sought an exception under 45 CFR 156.221(h) generally explained in their justifications that they
planned to become compliant with the API requirements mid-way through the upcoming plan
year, or shortly after the start of the plan year. This high level of compliance suggests that the
availability of an exception does not discourage or de-incentivize issuers implementation of
these standards.
We agree that the intent of our final policies is for all impacted payers to provide patients
with the benefits of the Provider Access,Payer-to-Payer, and Prior Authorization APIs as soon
as they are financially and operationally able. For example, for each of the API provisions for
which an exemption is available, we have indicated that if the payer cannot implement the API
and is seeking an exemption, it must offer alternative options to the providers to support the
intent of the policies; such programs would generally improve the exchange of patient data
between payers for care management or access to information for patients, and to improve the
prior authorization process for providers and payers. We believe that by requiring alternatives to
the APIs during the exemption, payers will investigate options to implement the APIs because, in
the long term, these will be more efficient and financially viable than maintaining current manual
processes.
Table F1 shows the impacted payers that are eligible to apply for an extension,
exemption, or exception for the Provider Access, Payer-to-Payer, and/or Prior Authorization
APIs required in this final rule. Tables C1, D1, and E4 found in sections II.B., II.C., and II.D. of
this finalrule include the regulatory citations for the extensions, exemptions, and exceptions for
each impacted payer. TABLE F1: IMPACTED PAYERS ELIGIBLE TO APPLY FOR EXTENSIONS,
EXEMPTIONS, OR EXCEPTIONS BY APPLICATION PROGRAMMING INTERFACE
IN THE CMS INTEROPERABILITY AND PRIOR AUTHORIZATION FINAL RULE
API EligibleforExtension EligibleforExemption EligibleforException
ProviderAccess  MedicaidFFS  MedicaidFFSprogramwith>  QHPissuersonthe
API program 90%inMCOs FFEs
 CHIPFFSprogram  CHIPFFSprogramywith>
90%inMCOs
 NEMTPAHP*
Payer-to-PayerAPI  MedicaidFFS  MedicaidFFSprogramwith>  QHPissuersonthe
program 90%inMCOs FFEs
 CHIPFFSprogram  CHIPFFSprogramwith>90%
inMCOs
PriorAuthorization  MedicaidFFSstate  MedicaidFFSprogramwith>  QHPissuersonthe
API program 90%inMCOs FFEs
 CHIPFFSprogram  CHIPFFSstateagencywith>
90%inMCOs
*NEMTPAHPsarenotsubjecttotheProviderAccessandPayer-to-PayerAPIrequirementsanddonot
needtoapplytoCMSforthisexemption.
3. Federal Matching Funds for State Medicaid and CHIP Expenditures on Implementation of the
Provider Access, Payer-to-Payer, and Prior Authorization APIs
We explained in the proposed rule for each of the APIs, we would anticipate that states
operating Medicaid and CHIP programs would be able to access Federal matching funds to
support their implementation of the APIs  specifically, the Provider Access, Payer-to-Payer, and
Prior Authorization APIs. We expect these APIs to lead to more efficient administration of
Medicaid and CHIP state plans by supporting more efficient data exchange and prior
authorization processes, consistent with sections 1902(a)(4) and 2101(a) of the Act, respectively.
We do not consider state expenditures for implementing the Provider Access,
Payer-to-Payer, or Prior Authorization APIs to be attributable to any covered Medicaid item or
service within the definition of medical assistance. Thus, in Medicaid, CMS will not match
these expenditures at the states regular Federal Medical Assistance Percentage (FMAP).
However, FFP at a rate of 50 percent could be available for state expenditures related to
implementing these APIs for Medicaid programs under section 1903(a)(7) of the Act (for the
proper and efficient administration of the Medicaid state plan). The three APIs should, over time,
help the state more efficiently administer its Medicaid program by supporting data exchange with providers and other payers and improving efficiencies in the prior authorization process.As
we stated in the proposed rule, sharing certain data through the Provider Access API with
participating providers could improve the quality of care for patients, using the Payer-to-Payer
API may help patients manage their information across payers to support patient care, and using
the Prior Authorization API will enable administrative efficiencies by reducing delays in the
prior authorization process overall, and by helping reduce the number of denied and appealed
prior authorization decisions.
States expenditures to implement the proposed requirements could be eligible for 90
percent enhanced FFP under section 1903(a)(3)(A)(i) of the Act if the expenditures can be
attributed to the design, development, and installation (DDI) of mechanized claims processing
and information retrieval systems. Additionally, 75 percent enhanced FFP, under section
1903(a)(3)(B) of the Act, could be available for state expenditures to operate Medicaid
mechanized claims processing and information retrieval systems to comply with the finalized
API requirements.
States can request Medicaid enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the
Act through the APD process described at 45 CFR part 95, subpart F. Additionally, 42 CFR
433.112(b)(12) and 433.116(c) require that any system for which states are receiving enhanced
FFP under section 1903(a)(3)(A)(i) or (B) of the Act align with and incorporate the ONC Health
IT standards adopted at 45 CFR part 170, subpart B. The APIs complement this requirement
because they further interoperability by using standards adopted by ONC at 45 CFR 170.215.151
States must comply with 42 CFR 433.112(b)(10) and 433.116(c) to explicitly support exposed
APIs, meaning the APIs functions are visible to others to enable the creation of a software
program or application, as a condition of receiving enhanced FFP under section 1903(a)(3)(A)(i)
or (B) of the Act. We note that FHIR is an open-source standard that can meet the requirements
151CentersforMedicareandMedicaidServices(2020).SHO#20-003RE:ImplementationoftheCMS
InteroperabilityandPatientAccessFinalRuleandCompliancewiththeONC21stCenturyCuresActFinalRule.
Retrievedfromhttps://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf. at 42 CFR 433.112(b)(10) and 433.116(c) if implemented by following our regulations,
particularly the technical, documentation and denial or discontinuation requirements at 42 CFR
431.60.
Finally, 42 CFR 433.112(b)(13) and 433.116(c) require states to promote sharing,
leverage, and re-use of Medicaid technologies and systems within and among states as a
condition of receiving enhanced FFP under section 1903(a)(3)(A)(i) or (B) of the Act. CMS
interprets that requirement to apply to technical documentation associated with a technology or
system, such as technical documentation for connecting to a states APIs. Making the needed
technical documentation publicly available so that systems that need to do so can connect to the
APIs finalized in this rule is required as part of the technical requirements at 42 CFR 431.60(d)
for all APIs, including the Provider Access, Payer-to-Payer, and Prior Authorization APIs.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act and 42 CFR 457.618,
limiting administrative costs to no more than 10 percent of a states total computable
expenditures for a fiscal year (FY), will apply to administrative claims for developing the APIs
finalized in this rule.
Comment: Multiple commenters expressed appreciation for the inclusion of language that
states may be eligible for enhanced FFP to support implementation of the Provider Access,
Payer-to-Payer, and Prior Authorization APIs in this final rule. While these commenters
expressed support for this option, others asked CMS to explain whether enhanced FFP is also
available to implement the Patient Access API requirements.
Response: Many states have already requested enhanced Federal matching funds for their
expenditures on implementation of the Patient Access API required in the CMS Interoperability
and Patient Access final rule. Additionally,enhanced funding under section 1903(a)(3)(A)(i) of
the Act may be available for certain expenditures to design, develop, and install the
enhancements to the Patient Access API finalized in this rule, in addition to expenditures related
to the Provider Access, Payer-to-Payer, and Prior Authorization APIs. CMS encourages states to seek enhanced FFP where it might be applicable for states expenditures on work needed to meet
state Medicaid and CHIP agencies requirements under this rule and looks forward to reviewing
any APDs submitted by states. Instructions for submitting the APDs are available on the
Medicaid website152 under the topic of Medicaid State Plan Amendments with information
about what categories of costs may be included in the requests, such as HIE connection/interface
costs. The information on the categories that are included in these requests can be found in the
State Medicaid Manual (SMM), Chapter 11, sections 265 & 276,153 the State Medicaid Director
Letter (SMDL) 16-004, Mechanized Claims Processing and Information Retrieval Systems-
Enhanced Funding,154 and the State Health Official (SHO) #20-003, Implementation of the
CMS Interoperability and Patient Access final rule.155
Comment: A commenter recommended that states receive a 90 percent Federal match to
support implementation of these requirements. Another commenter urged CMS to explain in the
final rule, or additional guidance, whether all, or likely all, of the required state investment to
develop these APIs, would qualify for enhanced Federal matching to establish and operate API
systems.
Response: States expenditures to implement the proposed requirements for each of the
APIs may be eligible for 90 percent enhanced FFP if the expenditures can be attributed to the
DDI for those APIs that benefit the Medicaid program. CMS determines on a case-by-case basis
when states APDs requesting this 90 percent FFP are approvable, consistent with the
requirements at 42 CFR part 433, subpart C, and 45 CFR part 95, subpart F. States should work
with their MES State Officers for further guidance specific to their programs.
152CodeofFederalRegulations(amended2016,June2).Retrievedfrom45CFR95.610,Submissionsofadvance
planningdocuments.
153CentersforMedicareandMedicaidServices.TheStateMedicaidManual(SMM),Chapter11,sections265&
276.Retrievedfromhttps://www.cms.gov/regulations-and-guidance/guidance/manuals/paper-based-manuals-
items/cms021927.
154CentersforMedicareandMedicaidServices(2016,March31).StateMedicaidDirectorletter#16-004.Retrieved
fromhttps://www.medicaid.gov/sites/default/files/federal-policy-guidance/downloads/SMD16004.pdf.
155CentersforMedicareandMedicaidServices(2020,August14).StateHealthOfficialletter#20-003.Retrieved
fromhttps://www.medicaid.gov/sites/default/files/2020-08/sho20003_0.pdf. Comment: A commenter recommended that CMS clarify that the Federal funding
resources available for states meeting the Prior Authorization API requirement can also include
pass-through payments to providers to obtain and utilize interoperable EHR technology for these
purposes. This commenter also expressed concern that the proposed rule did not offer any
indication of available resources for providers, but they appreciate CMSs clarification of
available Federal resources available to states for implementing the Prior Authorization API
requirement. Another commenter said that states should be granted flexibility for Federal
funding sources to expand the number of SNF providers able to utilize the new Provider Access
API.
Response: We encourage states to apply for Federal funding to support their planning,
development, and implementation of state systems including the Provider Access, Payer-to-
Payer, and Prior Authorization APIs, because these APIs will enable more providers to engage in
data exchange with state systems to improve patient care. As previously noted, enhanced Federal
Medicaid funding at the 90 percent rate may be available for the DDI and at the 75 percent rate
for the operation of these API initiatives that benefit the Medicaid program. These enhanced
Federal matching funds, as outlined at 42 CFR 433.112 (DDI) and 433.116 (operation), are
available for state expenditures on Medicaid state systems only, and not available for other state
or provider expenditures on provider-only systems to support providers or other entities efforts
to implement APIs. Similarly, Federal matching funds at 50 percent under section 1903(a)(7) of
the Act might be available to support Medicaid state specific activities for the required
provisions. However, none of these funds are available for funding to providers, as these are
designated to support state-specific initiatives.
4. Medicaid Expansion CHIP
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. We proposed and are now finalizing our policy at 42 CFR 457.700(c), that for states with Medicaid Expansion CHIP programs, the final
requirements as proposed for Medicaid will apply to those programs rather than separate
provisions for the CHIP program. In this final rule, we make explicit that the Medicaid
requirements at  431.60, 431.61, and 431.80 apply to the Medicaid expansion CHIP programs
rather than the separate CHIP requirements at  457.730, 457.731, and 457.732.
Comment: A commenter stated that most states have operating Medicaid expansion CHIP
programs and that the provisions outlined in the proposed rule would apply to most states.
Response: We agree with this commenter and as stated, are confirming that Medicaid
requirements apply equally to Medicaid expansion CHIP programs.
5. Final Action
After consideration of the comments received, and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule and our responses to those comments (as
summarized), we are finalizing our proposal to allow for state Medicaid and CHIP FFS programs
and QHP issuers on the FFEs to apply for certain extensions, exemptions, or exceptions for the
Provider Access, Payer-to-Payer and/or Prior Authorization APIs. We are also finalizing our
proposal regarding Medicaid Expansion CHIP programs.
We are finalizing the policy to allow state Medicaid and CHIP FFS programs to apply for
an extension to the deadline from the requirements to implement the Provider Access, Payer-to-
Payer, and/or Prior Authorization APIs. Specifically, we are finalizing that states may request a
one-time, 1-year extension as part of their annual APD for MMIS operations expenditures before
the compliance dates. The written extension request must include the following: (1) a narrative
justification describing the specific reasons why the state cannot satisfy the requirement(s) by the
compliance dates, and why those reasons result from circumstances that are unique to the agency
operating the Medicaid and/or CHIP FFS program; (2) a report on completed and ongoing state
activities that evidence a good faith effort toward compliance; and (3) a comprehensive plan to
meet the requirements no later than 1 year after the compliance date. CMS will grant an extension if the state establishes, to CMSs satisfaction, that the request adequately establishes a
need to delay implementation; and that the state has a comprehensive plan to meet the
requirements no later than 1 year after the compliance date.
We are finalizing a policy to allow state Medicaid and CHIP FFS programs to apply for
an exemption from the requirements of the Provider Access, Payer-to-Payer, and/or Prior
Authorization APIs when at least 90 percent of the states Medicaid beneficiaries are enrolled in
Medicaid MCOs or when at least 90 percent of the states separate CHIP beneficiaries are
enrolled in CHIP MCOs. We are finalizing that the requirements for the Payer-to-Payer API to
obtain beneficiaries permission, provide educational resources at the time of requesting
permission, and identify patients previous/concurrent payers, including for beneficiaries covered
under managed care are not eligible for the exemption. Specifically, we are finalizing the policy
that a state may request an exemption, as part of their annual APD for MMIS operations
expenditures before the compliance date (which may be extended by 1 year if the state receives
an extension). The exemption request must include documentation showing that the state meets
the threshold criterion based on enrollment data from the most recent CMS Medicaid Managed
Care Enrollment and Program Characteristics (for a Medicaid FFS exemption) or enrollment
data from section 5 of the most recently accepted state submission to CHIP Annual Report
Template System (CARTS). The state must also include an alternative plan to ensure that
providers have efficient electronic access to the same information through other means while the
exemption is in effect. CMS will grant the exemption if the state establishes, to CMSs
satisfaction, that the state meets the criteria for the exemption, including an alternative plan to
ensure efficient electronic access to the same information through other means while the
exemption is in effect.
We are finalizing that an exemption will expire under two scenarios. First, an exemption
will expire if, based on the 3 previous years of available, finalized Medicaid Transformed
Medicaid Statistical Information System (T-MSIS) and/or CHIP CARTS enrollment data, the States MCO enrollment for 2 of the previous 3 years is below 90 percent. Second, an exemption
will expire if CMS approves a state plan amendment, waiver, or waiver amendment that would
significantly reduce the percentage of beneficiaries enrolled in managed care and the anticipated
shift in enrollment is confirmed by the first available, finalized Medicaid T-MSIS and/or CHIP
CARTS enrollment data.
We are finalizing that states must provide written notification to CMS if they no longer
qualify for an approved exemption. Written notification must be submitted to CMS within 90
days of the finalization of the first annual Medicaid T-MSIS managed care enrollment data
and/or the CARTS report for CHIP demonstrating the enrollment shift to below 90 percent in
managed care. States must obtain CMS approval of a timeline for compliance with the API
requirements for Medicaid FFS and/or CHIP FFS within 2 years of the expiration of the
exemption. For additional context, please refer to the proposed rule (87 FR 76263).
In addition, we are finalizing that for states with Medicaid expansion CHIPs, the
requirements for Medicaid will apply to those programs rather than the provisions for separate
CHIPs.
We are finalizing that an issuer applying for QHP certification may apply for an
exception from requirements of the Provider Access, Payer-to-Payer, and/or Prior Authorization
APIs. The issuer must include, as part of its QHP application, a narrative justification describing
the reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan
year, the impact of non-compliance upon providers and enrollees, the current or proposed means
of providing health information to providers or other payers, and solutions and a timeline to
achieve compliance with the requirements. An FFE may grant an exception to the requirements
if it determines that making that issuers QHPs available through the FFE is in the interests of
qualified individuals in the state or states in which the FFE operates, and an exception is
warranted to permit the issuer to offer QHPs through the FFE. These final policies apply to state Medicaid and CHIP FFS programs and QHP issuers on
the FFEs at the CFR sections listed in Tables C1, D1, and E4. F. Electronic Prior Authorization Measures for the Merit-based Incentive Payment System
Promoting Interoperability Performance Category and the Medicare Promoting Interoperability
Program
1. Background
As discussed in detail in section II.D. of this final rule, the current prior authorization
process needs improvement to reduce the burden associated with the process itself. To facilitate
those needed improvements in the prior authorization process, we are requiring impacted payers
to implement and maintain a Prior Authorization API. The Prior Authorization API aims to
improve care coordination and shared decision-making by enabling enhanced electronic
documentation discovery and facilitating electronic prior authorization. We believe the Prior
Authorization API will reduce administrative burden, improve efficiency, and ensure patients
promptly receive necessary medical items and services. We also recognize that efficiencies from
payer implementation of these APIs will only be realized if they are utilized by requesting
providers to complete prior authorization requests.
Therefore, we proposed a new measure for MIPS eligible clinicians (as defined at 42
CFR 414.1305) under the MIPS Promoting Interoperability performance category, as well as for
eligible hospitals and CAHs under the Medicare Promoting Interoperability Program, related to
electronic prior authorization and the Prior Authorization API (87 FR 76312 - 76314). We
proposed the new measures, titled Electronic Prior Authorization, to be included in the HIE
objective for the MIPS Promoting Interoperability performance category and in the HIE
objective for the Medicare Promoting Interoperability Program. The Electronic Prior
Authorization measure aims to address concerns, specifically from commenters in response to
the December 2020 Interoperability proposed rule (85 FR 82586), that few providers would use
the Prior Authorization API established by impacted payers.
MIPS is authorized under section 1848(q) of the Act. As described in sections 1848(q)(2)
and (5) of the Act, we evaluate the performance of MIPS eligible clinicians in four performance categories, which we refer to as the quality, cost, improvement activities, and Promoting
Interoperability performance categories. Under 42 CFR 414.1375(b)(2), MIPS eligible clinicians
must report on objectives and measures as specified by CMS for the Promoting Interoperability
performance category. We refer readers to the CY 2024 Physician Fee Schedule (PFS) final rule
(88 FR 79357-79362) for a list of the current objectives and measures required for the MIPS
Promoting Interoperability performance category.156 We determine a final score for each MIPS
eligible clinician based on their performance in the MIPS performance categories during a MIPS
performance period for a year. Based on the MIPS eligible clinicians final score, we calculate a
MIPS payment adjustment (which can be positive, neutral, or negative) that applies for the
covered professional services they furnish in the MIPS payment year which occurs 2 years later.
The Medicare Promoting Interoperability Program for eligible hospitals and CAHs is
authorized in part under sections 1886(b)(3)(B)(ix) and 1814(l)(4) of the Act. Under these
statutory provisions, eligible hospitals and CAHs that are not meaningful EHR users are subject
to Medicare payment reductions. To be considered a meaningful EHR user (as defined under 42
CFR 495.4), the eligible hospital or CAH must demonstrate meaningful use of CEHRT by
satisfying objectives and measures as required under 42 CFR 495.24. We refer readers to the FY
2024 Hospital Inpatient Prospective Payment System (IPPS) and Long-Term Care Hospital
(LTCH) final rule (88 FR 59269-59277) for a summary of the currently adopted objectives and
measures for the Medicare Promoting Interoperability Program.
2. Electronic Prior Authorization
To support the policies in this final rule and maximize the potential to improve the prior
authorization process for providers and patients, we proposed to add new measures, titled
Electronic Prior Authorization, under the HIE objective of the MIPS Promoting
156Intheproposedrule(87FR76312),wereferredreaderstotheCY2023PFSfinalrule(87FR70075-70080)for
thethen-currentlistofobjectivesandmeasures.WehaveupdatedthisfinalruletorefertotheCY2024PFSfinal
rulewhichincludesthemostrecentobjectivesandmeasures,includingchangeseffectivefortheCY2024MIPS
performanceperiod. Interoperability performance category and under the HIE objective of the Medicare Promoting
Interoperability Program. These measures support the electronic exchange of health information
to improve the quality of health care, such as promoting care coordination, as described in
section 1848(o)(2)(A)(ii) of the Act with respect to MIPS eligible clinicians, and section
1886(n)(3)(A)(ii) of the Actwith respect to eligible hospitals and CAHs.
We proposed that for purposes of the Electronic Prior Authorization measures, a prior
authorization request must be made using the Prior Authorization API to satisfy the measure,
unless the MIPS eligible clinician, eligible hospital, or CAH could claim an applicable exclusion.
As discussed in more detail in the proposed rule (87 FR 76313) and further in this section II.F.,
we proposed that MIPS eligible clinicians, eligible hospitals, and CAHs would report the number
of prior authorizations requested electronically via the Prior Authorization API using data from
their CEHRT as a numerator and denominator, unless they could claim an applicable exclusion.
We proposed that beginning with the CY 2026 performance period/CY 2028 MIPS payment year
for MIPS eligible clinicians and the CY 2026 EHR reporting period for eligible hospitals and
CAHs, a MIPS eligible clinician, eligible hospital, or CAH that fails to report the measure or
claim an exclusion would not satisfy the MIPS Promoting Interoperability performance category
or Medicare Promoting Interoperability Program reporting requirements. For the CY 2026
performance period/CY 2028 MIPS payment year for MIPS eligible clinicians and the CY 2026
EHR reporting period for eligible hospitals and CAHs, we proposed that the Electronic Prior
Authorization measure would not be scored and would not affect the total score for the MIPS
Promoting Interoperability performance category or the Medicare Promoting Interoperability
Program. In other words, for CY 2026, a MIPS eligible clinician, eligible hospital, or CAH
would be required to report a numerator of at least one for the measure or claim an exclusion, but
the measure would not be scored. We proposed that, if the MIPS eligible clinician or eligible
hospital or CAH does not report a numeratorof at least one for the measure or claim an
exclusion, they would receive a zero score for the MIPS Promoting Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We noted that we
intend to propose a scoring methodology for the measure in future rulemaking.
First, we are finalizing that MIPS eligible clinicians report the Electronic Prior
Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment
year (rather than the CY 2026 performance period/2028 MIPS payment year), and that eligible
hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY
2027 EHR reporting period (rather than the CY 2026 EHR reporting period). We believe that this
modification to our proposed policy for the Electronic Prior Authorization measures will allow
more time for MIPS eligible clinicians, eligible hospitals, and CAHs to adjust to the new
electronic prior authorization workflow using the Prior Authorization API.
Second, we are finalizing the Electronic Prior Authorization measure with a modification
such that it is structured as an attestation (yes/no) measure, instead of a numerator and
denominator measure as originally proposed, for both MIPS eligible clinicians and eligible
hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible hospitals, and
CAHs will report a yes or no response or report an applicable exclusion for the Electronic
Prior Authorization measure. Instead of reporting how many times the MIPS eligible clinician,
eligible hospital, or CAH requested prior authorization electronically via the Prior Authorization
API in a numerator and all priorauthorizations in a denominator as proposed (87 FR 76313), the
MIPS eligible clinician, eligible hospital, or CAH will either submit an attestation (yes/no)
regarding whether they used the Prior Authorization API to submit at least one prior
authorization request electronically or claim an applicable exclusion to report the modified
Electronic Prior Authorization measures. We are modifying the proposed reporting methodology
to align with the modification to the measure specifications we are finalizing,specifically
reporting this measure as an attestation yes/no response instead of a numerator and denominator.
We believe that this modification to our proposed policy for the Electronic Prior Authorization
measures will reduce burden by not requiring MIPS eligible clinicians, eligible hospitals, and CAHs to calculate and report a numerator and denominator for the Electronic Prior
Authorization measure.
Additionally, we are finalizing that the measures will not be scored (that is, not assigned
points for completion or failure). Instead, if a MIPS eligible clinician, eligible hospital, or CAH
fails to report the measure as specified, they would not meet the minimum reporting
requirements, not be considered a meaningful EHR user,and fail the Medicare Promoting
Interoperability Program or the MIPS Promoting Interoperability performance category. A
failure in the Medicare Promoting Interoperability Program would result in a downward payment
adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a
hardship exception). A failure in the Promoting Interoperability performance category would
result in the MIPS eligible clinician receiving a score of zero for the performance category,
which is currently worth 25 percent of their final score for MIPS. This is consistent with our
original proposal that failure to report a numerator of at least one for the measure, or claim an
exclusion, warrants a zero score for the MIPS Promoting Interoperability performance category
and failure to meet Medicare Promoting Interoperability Program reporting requirements (87 FR
76313).
For the MIPS Promoting Interoperability performance category, satisfactory performance
on this measure can be demonstrated only by reporting a yes response on the attestation or
claiming an applicable exclusion. A no response on the attestation will result in the MIPS
eligible clinician failing to meet the minimum reporting requirements, therefore not being
considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and
defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR414.1305). MIPS eligible
clinicians that do not report a yes response or claim an applicable exclusion for the Electronic
Prior Authorization measure as specified (that is, they do not submit the measure or claim an
exclusion or report a no response) will not earn a score for the MIPS Promoting
Interoperability performance category (a score of zero for the category). A MIPS eligible clinicians score in the Promoting Interoperability performance category is generally worth 25
percent of their total final score for MIPS.157 We note that to report a yes, the action of the
measure must occur during the selected performance period158 or EHR reporting period,159 as per
the measure specifications defined below.
For the Medicare Promoting Interoperability Program, only a yes response on the
attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this
measure. A no response will result in the eligible hospital or CAH failing to meet the measure,
and therefore failing to meet minimum program reporting requirements, thus not being
considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3)
of the Act.160 Eligible hospitals and CAHs that do notmeet the minimum program reporting
requirements are subject to a downward payment adjustment (unless the eligible hospital or CAH
receives a hardship exception).
The following is a summary of the comments we received on our proposals and our
responses.
Comment: Multiple commenters expressed support for our proposal to add the Electronic
Prior Authorization measure under the MIPS Promoting Interoperability performance category
for MIPS eligible clinicians and the Medicare Promoting Interoperability Program for eligible
hospitals and CAHs to incentivize use of the Prior Authorization API among providers. Multiple
commenters agreed that it is appropriate to place the proposed Electronic Prior Authorization
measure under the HIE objective for both the MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program. Multiple commenters noted that
the Electronic Prior Authorization measure would incentivize MIPS eligible clinicians, eligible
hospitals, and CAHs to use the Prior Authorization API capabilities to automate the prior
157See42CFR414.1375(a);414.1380(c)(1).
158See42CFR414.1320.
159See42CFR495.40(b)(2)(i).
160See42CFR495.4;495.24(f)(1)(i)(A). authorization process, which could lead to more timely delivery of care. A commenter stated that
this proposal would help ensure that providers utilize the Prior Authorization and Provider
Access APIs technology, in addition to promoting interoperability and the electronic exchange
of health information.
Response: We thank commenters for their feedback and support of the proposed
Electronic Prior Authorization measure under the MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program. We agree that the Electronic
Prior Authorization measure will help incentivize MIPS eligible clinicians, eligible hospitals, and
CAHs to use the Prior Authorization API to automate the prior authorization process, which
could lead to more timely delivery of care.
Comment: Multiple commenters encouraged CMS to continue to explore additional and
alternative opportunities to foster API adoption and utilization of electronic prior authorization
tools, as well as incentivize the adoption of the Prior Authorization API across the industry and
include a broader set of providers outside of these incentive programs. Commenters suggested
expanding the Electronic Prior Authorization measure to other programs to reach additional
provider populations, such as the Medicare Shared Savings Program (MSSP) and Alternative
Payment Models (APMs). A commenter also recommended implementing a pilot program as
part of CMSs Primary Care First (PCF) model. A commenter recommended that CMS should
work in partnership with ONC to implement incentives that encourage further adoption of
electronic prior authorization. Another commenter supported further development of
performance measures to encourage interoperability enhancements and API uptake. A
commenter recommended that CMS engage with various associations to encourage further
adoption. A commenter supported industry-wide adoption of electronic priorauthorization
processes but suggested that only requiring impacted payers to build APIs would not lead to
broad adoption. A commenter stated that CMS should use every available option to influence
and incentivize adoption of these standards within the health care industry if it intends to mandate that impacted payers participate. Commenters also acknowledged thatthe provider
community is an important, interested group in the drive to enable widespread interoperability.
Response: We thank the commenters for their support and additional recommendations
on how we can incentivize using the Prior Authorization API. We will continue to monitor and
assess opportunities we can leverage to encourage API implementation uptake. Additionally, we
will continue to collaboratively work with ONC to identify ways to incentivize the adoption of
electronic prior authorization. We believe that establishing the Electronic Prior Authorization
measure is a viable method to begin fostering the adoption and utilization of the Prior
Authorization API by MIPS eligible clinicians, eligible hospitals, and CAHs in these initiatives.
We note that nothing in the Prior Authorization API proposal we are finalizing would prohibit
providers that are not subject to MIPS or the Medicare Promoting Interoperability Program from
using the API for electronic prior authorization as well. Where permitted under applicable law
and relevant program requirements, we encourage providers who are not included in these
programs to leverage the Prior Authorization APIs to gain the intended benefits, such as
improving efficiency and reducing the administrative burden of prior authorization processes.
We agree that requiring impacted payers to build the APIs would not lead to broad adoption.
However, we believe that establishing the Electronic Prior Authorization measure under both
MIPS and the Medicare Promoting Interoperability Program will help promote the
implementation and use of the Prior Authorization API by MIPS eligible clinicians, eligible
hospitals, and CAHs. In order for the industry to realize the efficiencies of the Prior
Authorization API and achieve the goals set forth in this final rule, it is essential that both
impacted payers and providers adopt and use a Prior Authorization API.
Comment: Multiple commenters opposed adoption of the proposed Electronic Prior
Authorization measure stating that the measure would be inefficient and burdensome, citing
challenges with additional workflow requirements, increased provider burden, and financial
burden. A commenter stated that it would potentially leave providers unfairly penalized. Several commenters noted that the burden of reporting outweighs the benefits of use and that hospital IT
resources are already overloaded and limited. Other commenters noted that mandating the
Electronic Prior Authorization measure could further increase provider burden and detract from
patient care, directing MIPS eligible clinicians, eligible hospitals, and CAHs attention away
from patients. A commenter stated that the Electronic Prior Authorization measure proposal is
unlikely to provide significant relief to providers (that is, MIPS eligible clinicians, eligible
hospitals, and CAHs). Another commenter stated that payers should compensate providers fairly
for the cost of each prior authorization for the implementation of costly and burdensome
electronic prior authorization requirements. This commenter stated that each prior authorization
is a net financial loss for practices. Another commenter recommended that the Electronic Prior
Authorization measure should remain optional until a time when the benefit, both monetarily and
in reduced administrative burden, can be quantified for a calculated return on investment.
Response: We appreciate the feedback provided by commenters and note that we believe
the benefit of the Prior Authorization API will outweigh the burden of implementation. We refer
readers to the Collection of Information (COI) requirements in section III. of this final rule
regarding burden and the regulatory impact analysis (RIA) we conducted in section IV. of this
final rule for the additional information on the cost calculations of this Electronic Prior
Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting
Interoperability performance category and for eligible hospitals and CAHs reporting for the
Medicare Promoting Interoperability Program. We acknowledge that there is an initial
implementation and data collection burden associated with the Electronic Prior Authorization
measure. However, we believe that the benefits of using an electronic prior authorization process
outweigh the burdensome manual process used today. We believe that making the prior
authorization process electronic will improve the time and burden associated with the current
process, allowing providers to put time back into direct patient care, and ultimately will reduce
provider burnout. We emphasize that we are implementing requirements for both impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) to help
streamline the prior authorization process because both payers and providers have a role to play
in this process and the solution cannot be one-sided. As discussed further in this section, in order
to address concerns regarding the burden of the Electronic Prior Authorization measure on MIPS
eligible clinicians, eligible hospitals, and CAHs, we are modifying the measure to be an
attestation (yes/no) measure rather than a numerator and denominator measure. Therefore, data
collection to report a numerator and denominator for the Electronic Prior Authorization measure
is no longer required.
Comment: A commenter cautioned that the Electronic Prior Authorization measure for
the MIPS Promoting Interoperability performance category would reflect data regarding a
different population than other MIPS measures, stating that other measures in MIPS are designed
to capture information about the Medicare beneficiary population specifically. The commenter
stated that this would make these measures difficult to compare. Another commenter stated that
the Electronic Prior Authorization measure proposed for the MIPS Promoting Interoperability
performance category does not apply to Medicare FFS, which results in misalignment.
Response: We thank the commenters for their feedback. First, we disagree that the
Electronic Prior Authorization measure will reflect data regarding a different population than
other MIPS measures. We note that all of the MIPS Promoting Interoperability performance
category measures are based on using CEHRT, utilizing data that are captured in the CEHRT,
and require submission of applicable data, regardless of payer. The Electronic Prior
Authorization measure is consistent with other measures reported under the MIPS Promoting
Interoperability performance category.
Second, although Medicare FFS is not an impacted payer, we refer readers to section
I.D.1. of this final rule where we discuss CMSs intent to align Medicare FFS to the
requirements of this final rule, as applicable. Although, generally, the policies in this final rule
do not directly pertain to Medicare FFS, we want to ensure that Medicare beneficiaries, as well as other individuals, can benefit from these policies, regardless of their coverage, delivery
system, or payer.
Comment: A commenter stated that, if CMS does move forward with the proposed
Electronic Prior Authorization measure for the MIPS Promoting Interoperability performance
category, CMS should consider exempting small, rural, and underserved practices from reporting
the Electronic Prior Authorization measure, which would redistribute the Promoting
Interoperability performance categorys weight to other performance categories. A few
commenters suggested that the inclusion of the Electronic Prior Authorization measure would
have a disproportionately adverse effect on small business entities, federally recognized
American Indian and Alaska Native-Tribal communities, psychiatric practices, and other
specialties and could contribute to the electronic divide.
Response: We thank commenters for their feedback and would like to note that there are
a number of situations in which MIPS eligible clinicians may qualify for reweighting of the
MIPS Promoting Interoperability performance category. This includes policies implemented in
our regulations at 42 CFR part 414, subpart O, including 42 CFR 414.1380(c)(2), if they have a
special status (defined at 42 CFR 414.1305), are a qualifying clinician type, or have a CMS-
approved significant hardship or other exception application. For example, MIPS eligible
clinicians in small practices (fifteen or fewer MIPS eligible clinicians) may have the MIPS
Promoting Interoperability performance category reassigned a weight of zero percent
automatically in the event the MIPS eligible clinician in a small practice (as verified by CMS on
an annual basis) does not submit any data for any of the measures in that category as provided at
42 CFR 414.1380(c)(2)(i)(C)(9), and therefore would not be required to meet the MIPS
Promoting Interoperability performance categorys requirements including reporting on this
Electronic Prior Authorization measure (86 FR 65485 - 65487). If the MIPS Promoting
Interoperability performance category is reweighted to zero percent as provided at 42 CFR 414.1380(c)(2)(i), the categorys 25 percentweight will be redistributed to the remaining MIPS
performance categories in accordance with 42 CFR 414.1380(c)(2)(ii).
Comment: Multiple commenters opposed the proposed addition of the Electronic Prior
Authorization measure. Commenters believed that the finalization of the Electronic Prior
Authorization measure would not be necessary because MIPS eligible clinicians, eligible
hospitals, and CAHs would be prompted to voluntarily adopt and use the Prior Authorization
API if the API achieves the goal of streamlining the prior authorization process, which likely
would reduce provider burden, improve prior authorization processing time, and enable more
timely access to care. Multiple commenters expressed that they do not believe that the proposed
Electronic Prior Authorization measure would address concerns about low provider utilization of
APIs, especially for small, rural providers, due to cost, limited bandwidth, and lack of dedicated
health IT staff. A commenter expressed that they do not believe that the inclusion of the
Electronic Prior Authorization measure would be a sufficient incentive for MIPS eligible
clinicians, eligible hospitals, and CAHs to overcome the costs associated with the transaction.
Some commenters stated that, as electronic prior authorization becomes more common and
affordable, providers would be incentivized to adopt this process, which promises to free up
resources and allow providers to spend more time on patient care. A commenter stated that
providers will be naturally incentivized to engage in electronic prior authorization processes if
the processes lower costs, carry a minimal burden, do not cause unreasonable delays in care, and
lead to care that is in their patients best interests. Another commenter stated that the proposal to
add a measure on conducting electronic prior authorization for items or services using the Prior
Authorization API is notsufficient to encourage robust use of the Prior Authorization API by
providers and stated that the proposals will be a one-sided mandate on impacted payers.
Response: We appreciate the commenters feedback and are glad to hear that providers
likely would be naturally incentivized and prompted to voluntarily adopt and use the Prior
Authorization API if the API achieves the goal of streamlining the prior authorization process, which we believe it will. However, based on experience with adoption of other similar new EHR
technology, we believe there needs to be an initial drive to encourage all parties involved (payers
and providers) to develop, implement, and use the new Prior Authorization API to support
widespread adoption, thus reaping the benefits of burden reduction through the electronic prior
authorization processes. We understand and agree that the Electronic Prior Authorization
measure itself may not be enough to address concerns about low provider utilization of APIs,
particularly for small and rural providers. However, we believe the improvement and benefits in
the prior authorization processes resulting from using the Prior Authorization API, specifically,
may encourage such providers to adopt the API to help streamline existing paper-based or portal-
based processes.
We acknowledge that small, rural providers may have limited bandwidth and fewer
dedicated IT staff. We note that implementing an electronic prior authorization process could
free up resources and allow providers to spend more time on patient care, which can be a
challenge for small, rural providers. We also note that MIPS eligible clinicians in small practices
(fifteen or fewer MIPS eligible clinicians) may have the MIPS Promoting Interoperability
performance category reassigned a weight of zero percent automatically in the event the MIPS
eligible clinician in a small practice (as verified by CMS on an annual basis) does not submit any
data for any of the measures in that category as provided at 42 CFR 414.1380(c)(2)(i)(C)(9), and
therefore would not be required to meet the categorys requirements including reporting on this
Electronic Prior Authorization measure (86 FR 65485 - 65487). We believe that using electronic
prior authorization processes will benefit small, rural providers, and small practices in
underserved communities who are able to implement and maintain the Prior Authorization API
in their processes with by saving time, faster turnaround on priorauthorization requests, and, in
turn, improved patient satisfaction. Comment: A commenter requested that CMS calculate the additional cost of compliance
with the MIPS requirements generally and consider what benefit MIPS reporting offers when
practices already have a great interest in lowering their expenses related to prior authorization.
Response: We appreciate the commenters feedback regarding cost of the Electronic
Prior Authorization measure and refer readers to the RIA we conducted in section IV. of this
final rule for the additional information on the cost calculations of this Electronic Prior
Authorization measure for MIPS eligible clinicians reporting for the MIPS Promoting
Interoperability performance category and for hospitals and CAHs reporting for the Medicare
Promoting Interoperability Program. We note that the cost of compliance and benefits of
reporting for MIPS as a whole are outside the scope of this rule. We will continue to evaluate use
of the Prior Authorization API and assess whether the Electronic Prior Authorization measure
has achieved its goal of promoting widespread Prior Authorization API adoption.
Comment: Multiple commenters acknowledged that the proposed Electronic Prior
Authorization measure is not directed toward the impacted payers. A commenter stated that CMS
should collect prior authorization data from payers to measure their performance rather than
from providers. Another commenter noted that the electronic prior authorization proposal does
not assess any financial costs against payers to discourage their overuse of prior authorizations.
Response: We thank the commenters for their feedback and acknowledge that this
Electronic Prior Authorization measure is not intended to incentivize payers to use the Prior
Authorization API. For more information about the Prior Authorization API requirements for
payers, we refer readers to section II.D. of this final rule.
To reiterate, the success of the Prior Authorization API is dependent upon both payers
and providers using the Prior Authorization API. We want to stress the importance of both
payers and providers using the Prior Authorization API to ensure that all parties can experience
the maximum benefits of engaging in the electronic prior authorization process. Thus, we
recognize the importance of not only requiring impacted payers to build, implement, and maintain the API, but also to drive MIPS eligible clinicians, eligible hospitals, and CAHs to use
it.
We agree that collecting prior authorization data from payers is important and provides
accountability for using prior authorization processes. As such, we are finalizing our proposal to
require payers to publicly report certain prior authorization metrics. We refer readers to section
II.D. of this final rule for further information on these requirements for impacted payers.
We note that prior authorization is an established administrative process used 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. The policies we are finalizing are not intended to discourage the use
of prior authorization, nor do they impose direct financial repercussions for using prior
authorization by payers. The policies we are finalizing in this final rule are intended to streamline
the existing prior authorization process.
Comment: Multiple commenters noted that the adoption of the Electronic Prior
Authorization measure contradicts CMSs goal of reducing provider burden and urged CMS not
to replace one type of administrative burden with another. Another commenter cautioned that the
proposed Electronic Prior Authorization measure is not suitable for a quality improvement
program given that the focus is on technological capability. A commenter stated that measures
related to prior authorization conflict with the goal of MIPS to improve quality of health care,
stating there is no evidence to indicate that prior authorization improves outcomes.
Response: We disagree that the Electronic Prior Authorization measure conflicts with our
goals and believe the policies we are finalizing in this rule are necessary to support a more
efficient prior authorization process in the future. We believe this measure is entirely suitable for
MIPS since the goal of MIPS is to provide financial incentives to clinicians that provide high-
value and high-quality care to Medicare patients. MIPS supports care improvements by focusing
on better patient outcomes and decreasing clinician burden. We believe that electronic prior authorization aligns with these goals, as it streamlines a historically burdensome process to allow
providers to spend more time focused on improving patient outcomes instead of administratively
burdensome processes.
We also believe that the Electronic Prior Authorization measure fits within the goals of
the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability
performance category by enhancing the meaningful use of CEHRT. For the MIPS Promoting
Interoperability performance category, section 1848(q)(2)(B)(iv) of the Act requires MIPS
eligible clinicians to report on specified measures and activities demonstrating that they meet the
requirements established under section 1848(o)(2) of the Act for determining whether the MIPS
eligible clinician is a meaningful EHR user. For the Medicare Promoting Interoperability
Program, section 1886(n) of the Act similarly requires eligible hospitals and CAHs to
demonstrate that they meet requirements established under section 1886(n)(3)(A) (which align
with section 1848(o)(2)(A) of the Act) for determining whether the eligible hospital or CAH is a
meaningful EHR user. Electronic exchange of information to improve health care and care
coordination is a central statutory requirement for both the Medicare Promoting Interoperability
Program and the MIPS Promoting Interoperability performance category.
We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the
Act for MIPS and the Medicare Promoting Interoperability Program, respectively, because we
believed, and continue to believe, this measure will further enable the electronic exchange of
health information to improve the quality of health care (87 FR 76312). More specifically, we
believe the proposed Electronic Prior Authorization measure, which we are finalizing with
modifications, is fundamental to determining whether a MIPS eligible clinician, eligible hospital,
or CAH meets criterion two of being a meaningful EHR user:demonstrating that their CEHRT is
connected in a manner that provides for the electronic exchange of health information to improve
the quality of health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and
1886(n)(3)(A)(ii) of the Act). We believe the Electronic Prior Authorization measure is another means by which MIPS eligible clinicians, eligible hospitals, and CAHs, can use their health IT to
timely and efficiently share key health information with payers to obtain prior authorizations
promptly and thereby provide necessary health care to their patients expeditiously. Therefore, we
believe the Electronic Prior Authorization measure does meet the intended goal of these
programs to promote interoperability and electronically exchange health information.
Comment: Multiple commenters opposed the Electronic Prior Authorization measure
stating that prior authorizations are a harmful practice that result in delays and denials of
necessary care which can worsen a patients condition. Several commenters shared concerns
about payer prior authorization policies themselves. A commenter stated that prior authorizations
lower the costs for payers but raise the overall cost of care by delaying care and shifting costs to
providers and patients, thus worsening clinical outcomes which necessitates the escalation of
more expensive care.
Response: We would like to thank commenters for their feedback regarding payers prior
authorization processes and the burden placed on patients and providers. We understand that
some commenters expressed concerns about prior authorization itself, regardless of whether it
could be completed electronically, and whether or not these existing prior authorization
requirements support improved outcomes. We note that the existence and use of prior
authorization processes is outside the scope of this rule. Our policies are limited to streamlining
this already existing process.
The policies we are finalizing in this rule are not intended to encourage or discourage the
prior authorization requirements that payers already have; these policies are intended to increase
the efficiency of these existing requirements and processes by encouraging use of electronic
methods. We understand that the existing prior authorization process can be burdensome, and
thus believe the policies we are finalizing in this rule are necessary to supporta more efficient
prior authorization process in the future. We received many comments on the December 2020 CMS Interoperability proposed rule,
which has since been withdrawn, and in response to the CMS Interoperability and Prior
Authorization proposed rule that indicated that prior authorization processes could be improved
by electronic, interoperable data exchange. Those comments have informed the policies we are
finalizing in this rule.
Comment: Multiple commenters stated that the Electronic Prior Authorization measure
should not penalize LTCHs and Inpatient Rehabilitation Facilities (IRFs) for failing to use EHRs.
Another commenter expressed that practices have many different technical and infrastructure
capabilities; therefore, they recommended that CMS consider ways to further engage and support
allprovider types  especially safety-net, small/independent, and/or rural health providers  to
adopt and use the Prior Authorization API. The commenter continued by stating that they are
concerned that these providers are at risk of being left behind. Likewise, the commenter stated
that CMS should also explore ways to expand provider incentives to reach broadly across the
health care system to encourage widespread adoption of the Prior Authorization API. Another
commenter recommended that CMS include all health care providers as recipients of the benefits
of the final rule, whether they are recipients of Meaningful Use dollars or are participants in
MIPS. The commenter continued by providing a possible scenario in which payers further delay
decisions of excluded providers in favor of meeting the requirements for providers included
under the provisions of the rule.
Response: We note that LTCHs and IRFs are not included in the definition of an eligible
hospital or CAH (42 CFR 495.4 definitions, 75 FR 44327) and therefore would not be required
to report the Electronic Prior Authorization measure under the Medicare Promoting
Interoperability Program.161 We also understand that different practices have different technical
and infrastructure capabilities. To the extent that these facilities or any provider type ordering
161CentersforMedicareandMedicaidServices(2023,September6).MedicarePromotingInteroperability
Program:EligibilityHospitalInformation.Retrievedfromhttps://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Eligibility-#BOOKMARK2. items or services requiring priorauthorizations have access to appropriate health IT and the Prior
Authorization API and are otherwise permitted to use the Prior Authorization API, we encourage
them to use this technology for their own benefit.Our proposals for the Prior Authorization API
technology and functionality do not limit its use to participants under the MIPS Promoting
Interoperability performance category and the Medicare Promoting Interoperability Program. We
will continue to look for ways to encourage API implementation uptake and ways to incentivize
the adoption of electronic prior authorization across additional programs and provider types,
especially safety-net, small/independent, and rural health providers.
Additionally, we appreciate the comment regarding possible scenarios in which impacted
payers further delay decisions on prior authorizations from providers not participating in MIPS
or the Medicare Promoting Interoperability Program or not using the Prior Authorization API.
However, to mitigate this, we are finalizing certain prior authorization decision timeframes for
allimpacted payers. We refer readers to section II.D. of this final rule for more information on
the prior authorization decision timeframe provisions.
Comment: A commenter suggested that instead of developing the Electronic Prior
Authorization measure, CMS should engage in stringent oversight to ensure that impacted payers
are not only developing and implementing a Prior Authorization API but are also implementing
allof the provisions of this final rule. The commenter also suggested that CMS should release
additional information on how it will enforce the proposed requirements contained in the CMS
Interoperability and Prior Authorization proposed rule to ensure compliance.
Response: As explained in the proposed rule, and in the CMS Interoperability and Patient
Access final rule, each program oversees compliance under existing program authorities and
responsibilities. These compliance processes vary among programs and may have different
implications based on a payers status in the program, previous compliance actions, and
corrective action. Patients and providers should submit an inquiry or complaint to the appropriate
program, depending on their coverage as described in section I.D.2. of this final rule. Compliance questions or complaints about compliance may be sent to the respective program
contact at the website or email address provided there.Compliance will be tracked through
specific methods managed by the programs. While these compliance efforts will help payer
compliance, as we have stated repeatedly throughout this section, it is imperative that both
payers and providers come together to use the Prior Authorization API to ensure that all parties
can experience the maximum benefits of engaging in the electronic prior authorization process.
Thus, we recognize the importance of not only requiring impacted payers to build the Prior
Authorization API, but also to incentivize MIPS eligible clinicians, eligible hospitals, and CAHs
to use it through the finalization of this Electronic Prior Authorization measure.
Comment: A commenter stated that CMS lacks a legitimate justification for imposing the
new Electronic Prior Authorization measure, as it does not align with the legal requirements
under section 1848(q) of the Act. The commenter sought clarification on how the proposed
measure complies with the governing regulations.
Response: We have authority under section 1848(q)(2)(A)(iv) and (B)(iv) of the Act,
which requires that we assess MIPS eligible clinicians performance with respect to their
meaningful use of CEHRT in accordance with the requirements established in section 1848(o)(2)
of the Act. We also have authority under section 1848(q)(2)(B)(iv) of the Act to create new
measures under the MIPS Promoting Interoperability performance category as well as for
determining whether an eligible professional is a meaningful EHR user in accordance with the
requirements established in section 1848(o)(2) of the Act. Connecting to the API technology
identified in the Electronic Prior Authorization measure helps to facilitate bi-directional data
exchange electronically and can significantly reduce the burden associated with the prior
authorization processes for providers using data from CEHRT when accessing the Prior
Authorization API. This type of function demonstrates meaningful use of CEHRT and is
therefore appropriate in assessing whether a MIPS eligible clinician is a meaningful EHR user
under section 1848(o)(2)(A) of the Act. Comment: A commenter requested that CMS use its authority to permit payers to include
quality measures tied to use of the APIs in the provider contracts.
Response: We appreciate the commenters recommendation. However, we leave this
decision  whether payers require measures like this for their providers and how they work with
their providers on using the Prior Authorization API  up to the discretion of the payers.
a. Measure Specifications
In the proposed rule (87 FR 76313), we proposed the following specifications for the
Electronic Prior Authorization measure:162
1. For MIPS Eligible Clinicians under the MIPS Promoting Interoperability Performance
Category--Electronic Prior Authorization
 Measure Description: For at least one medical item or service (excluding drugs)
ordered by the MIPS eligible clinician during the performance period, the prior authorization is
requested electronically from a Prior Authorization API using data from CEHRT.
The MIPS eligible clinician would be required to report a numerator and denominator for
the measure or (if applicable) report an exclusion:
 Denominator: The number of unique prior authorizations requested for medical items
and services (excluding drugs) ordered by the MIPS eligible clinician during the performance
period, excluding prior authorizations that cannot be requested using the Prior Authorization API
because the payer does not offer an API that meets the Prior Authorization API requirements
outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule.
 Numerator: The number of unique prior authorizations in the denominator that are
requested electronically from a Prior Authorization API using data from CEHRT.
 Exclusion: Any MIPS eligible clinician who:
162Intheproposedrule,weusedthetermPriorAuthorizationRequirements,Documentation,andDecisionAPI
(PARDDAPI).Forsimplicity,wearefinalizingthenameofthatAPIassimplythePriorAuthorizationAPI. (1) Does not order any medical items or services (excluding drugs) requiring prior
authorization during the applicable performance period; or
(2) Only orders medical items or services (excluding drugs) requiring prior authorization
from a payer that does not offer an API that meets the Prior Authorization API requirements
outlined in section II.D.3.a. of the CMS Interoperability and Prior Authorization proposed rule
during the applicable performance period.
2. For Eligible Hospitals and Critical Access Hospitals under the Medicare Promoting
Interoperability Program--Electronic Prior Authorization
 Measure Description: For at least one hospital discharge and medical item or service
(excluding drugs) ordered during the EHR reporting period, the prior authorization is requested
electronically via a Prior Authorization API using data from CEHRT.
The eligible hospital or CAH would be required to report a numerator and denominator
for the measure or (if applicable) report an exclusion:
 Denominator: The number of unique prior authorizations requested for medical items
and services (excluding drugs) ordered for patients discharged from the eligible hospital or CAH
inpatient or emergency department (POS code 21 or 23) during the EHR reporting period,
excluding prior authorizations that cannot be requested using the Prior Authorization API
because the payer does not offer an API that meets the Prior Authorization API requirements
outlined in section II.D.3.a. of the proposed rule.
 Numerator: The number of unique prior authorizations in the denominator that are
requested electronically from a Prior Authorization API using data from CEHRT.
 Exclusions: Any eligible hospital or CAH that--
++ Does not order any medical items or services (excluding drugs) requiring prior
authorization during the applicable EHR reporting; or ++ Only orders medical items or services (excluding drugs) requiring prior authorization
from a payer that does not offer an API that meets the Prior Authorization API requirements
outlined in section II.D.3.a. of the proposed rule during the applicable EHR reporting period.
Comment: Multiple commenters expressed support for CMSs proposal regarding the
proposed Electronic Prior Authorization measures numerator and denominator criteria.
Specifically, a commenter agreed with the numerator being the number of unique prior
authorizations that are requested electronically via a Prior Authorization API using data from
CEHRT if the Electronic Prior Authorization measure includes electronic prior authorizations
from commercial payers. A commenter recommended that CMS ask for the percentage of prior
authorization requests that are not being completed through the Prior Authorization API. Another
commenter supported CMSs proposal to include prior authorization requests that are made using
fax, mail, or portal in the denominator of the Electronic Prior Authorization measure unless the
prior authorization cannot be requested using the Prior Authorization API because the payer does
not offer an API that meets the Prior Authorization API requirements, in which case it would be
excluded from the denominator. A commenter expressed support for CMS progressing the
proposed Electronic Prior Authorization measure to a performance-based measure in future
years.
Response: We thank the commenters for their feedback and appreciate their support for
the numerator and denominator criteria for the Electronic Prior Authorization measure for the
MIPS Promoting Interoperability performance category and the Medicare Promoting
Interoperability Program. We agree thatrequiring participants to report a numerator and
denominator for the measure would ultimately give us the most insight into the degree of
adoption and use of the Prior Authorization API. However,after consideration of comments
received, and as discussed in more detail later in this section, we are modifying the specifications
of the Electronic Prior Authorization measure to require an attestation (yes/no), in lieu of
reporting data for a numerator and denominator as proposed, for this measure beginning with the CY 2027 performance period/2029 MIPS payment year for MIPS and the CY 2027 EHR
reporting period for the Medicare Promoting Interoperability Program.
Comment: A commenter suggested that CMS explore different mechanisms for tracking
electronic prior authorization requests. A few commenters also noted that tracking these data
elements should be the responsibility of payers, as they would have this information more easily
accessible. Another commenter stated that CMS needs to determine an approach to measure the
usage of electronic prior authorization tools that does not require collecting information about
the availability of corresponding APIs or functionality. Another commenter stated that measuring
the success of these policies should not be punitive for providers and that the metrics of success
should exist for all stakeholders. Multiple commenters urged CMS to work with the provider
community, as well as other stakeholders, on various aspects of the Electronic Prior
Authorization measure as well as other prior authorization reforms to identify ways to
incentivize provider uptake without creating unnecessary provider burden and determine how to
engage providers in the testing and development of the proposed Electronic Prior Authorization
measure. Another commenter noted that the technology supporting electronic prior authorization
must be widely available and demonstrated to be effectively integrated into EHR workflows
through real-world testing prior to requiring MIPS eligible clinicians, eligible hospitals, and
CAHs to report on use of the Prior Authorization API for the Electronic Prior Authorization
measure. A commenter suggested that CMS should require payers to provide these data on
electronic prior authorization, rather than place increasing demands on providers.
Response: We thank the commenters for their recommendations. We will consider
exploring additional mechanisms for tracking electronic prior authorization requests in future
rulemaking. We believe that tracking the use of electronic prior authorization processes by
impacted payers and providers (that is, MIPS eligible clinicians, eligible hospitals, and CAHs) is
important to ensure widespread implementation and use of the Prior Authorization API by both
user groups. In this context, we view the Electronic Prior Authorization measure not merely as a way to track performance or success. Instead, we view this measure as a way for MIPS eligible
clinicians, eligible hospitals, and CAHs to adopt and use the electronic Prior Authorization APIs
implemented by payers.As we have noted previously, payers impacted by this rule are required
to implement and maintain the Prior Authorization API. To fully recognize the benefits and
efficiencies of payer implementation of this API, we need to encourage providers to use said API
to complete prior authorization requests. While we are encouraged by commenters statements
that the benefits of the Prior Authorization API are enough to encourage providers to use it, we
also believe that accessing this API using data from CEHRT demonstrates meaningful use of
CEHRT that can improve patient care under sections 1848(o)(2)(A) and 1886(n)(3)(A) of the
Act, and thus believe this measure is appropriate to incentivize providers to adopt and use this
technology. We refer readers to section II.D. of this rule where we discuss in further detail the
metrics impacted payers will be required to report on electronic prior authorizations.
We note that we do not currently use established workgroups to test and develop
measures for the Medicare Promoting Interoperability Program or the MIPS Promoting
Interoperability performance category outside of our annual call for measures.163 We do work
with members of the provider community in HL7 workgroups to obtain their feedback during the
development and testing phases of the IGs that support the Prior Authorization API, as well as
during discussions around technical workflow. We encourage providers to engage in the HL7
FHIR workgroup meetings to get involved in the standards development and implementation
discussions for specific use cases. The IGs are also tested during Connectathons and throughout
the IG development lifecycle and refined based on testing and implementation feedback. We
have also previously reviewed public comments received on the Reducing Burden and
Improving Electronic Information Exchange of Prior Authorizations RFI (85 FR 82639) and
December 2020 CMS Interoperability proposed rule (85 FR 82586) regarding ways in which we
163CentersforMedicareandMedicaidServices.(2023,September6).AnnualCallForMeasures.Retrievedfrom
https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/CallForMeasures. could incentivize and encourage provider use of the electronic Prior Authorization API and used
that feedback to develop our policies outlined in this final rule.
Comment: Multiple commenters expressed their disapproval of the proposed Electronic
Prior Authorization measures numerator and denominator criteria. Numerous commenters stated
that the Electronic Prior Authorization measure as proposed would create significant data
collection and reporting burden on MIPS eligible clinicians, eligible hospitals, CAHs, and
support staff. Many commenters specifically identified the excessive burden with calculating the
denominator. Multiple commenters expressed concern regarding identifying which prior
authorization requests meet the denominator requirements of the proposed Electronic Prior
Authorization measure (for example, which payers offer a Prior Authorization API or how a
provider will be able to determine the number of prior authorization requests that should be
counted in the denominator) making this measure particularly burdensome, contributing to
provider burnout, and causing further delays in care. A commenter sought clarification on
whether CMS is considering alternatives to the proposed numerator and denominator measure
criteria and requested changes to these specifications that would reduce the implementation
burden for both providers and health IT developers.
Some commenters expressed concern regarding compliance and documentation for the
proposed Electronic Prior Authorization measure. Commenters stated that providers submit prior
authorizations in a variety of modalities and noted it will be hard to track all prior authorizations
submitted. Other commenters expressed similar concerns given that data surrounding prior
authorizations are captured outside of an EHR, which would make the data collection process
extremely burdensome.
Several commenters urged CMS not to implement the Electronic Prior Authorization
measure as proposed due to these concerns or consider ways the measure could be implemented
without increasing provider burden. A commenter recommended that CMS continue to evaluate
the numerator and denominator proposals and adjust the requirements based on real-world testing. Another commenter questioned why CMS would create a numerator/denominator
measure that is not automatically calculated by EHRs. The commenter continued by stating that
several EHR vendors will likely nothave the capability to assist in tracking prior authorization
requests for reporting purposes. Another commenter disagreed with the proposed measure
criteria to collect information on the total number of prior authorization requests submitted by
the Prior Authorization API versus other request methods given that collecting these data does
nothing to improve patient clinical outcomes.Therefore, multiple commenters recommended that
CMS should use an attestation (yes/no) measure and remove the proposed
numerator/denominator criteria.
Response: We appreciate the commenters sharing their concerns regarding the burden
associated with calculating a numerator and denominator as proposed for the Electronic Prior
Authorization measure. Generally, we proposed that to report these measures, MIPS eligible
clinicians, eligible hospitals, and CAHs must use data from their CEHRT to request prior
authorization from a payer for at least one medical item or service (excluding drugs), and, for
eligible hospitals and CAHs, one hospitaldischarge and medical item or service that they
ordered via the Prior Authorization API (87 FR 76313). However, we recognize that the
challenge of consistently calculating a numerator and denominator for these proposed measures
across providers increases if providers are accessing the Prior Authorization API in different
ways. We further recognize that it would be challenging for MIPS eligible clinicians, eligible
hospitals, and CAHs to report a numerator and denominator for these measures as we proposed
until such time as the ONC Health IT Certification Program establishes health IT certification
criteria to support standardized exchange via the Prior Authorization API and adopts updated
certification criteria supporting numerator and denominator calculation.
We acknowledge that modifying the Electronic Prior Authorization measure to be
attestation-based would substantially reduce the reporting burden placed on MIPS eligible
clinicians, eligible hospitals, and CAHs. With an attestation-based yes/no measure, those providers would be required to report a yes/no response, rather than a numerator and
denominator, to indicate whether they used a Prior Authorization API to submit at least one
electronic prior authorization during the applicable performance period/MIPS payment year or
EHR reporting period. After consideration of this feedback, and as discussed in more detail later
in this section, we are modifying the Electronic Prior Authorization measure to be an attestation
measure, meaning that MIPS eligible clinicians, eligible hospitals, and CAHs will report a yes/no
response for the measure. We will continue to explore ways to move toward numerator and
denominator reporting for future years of the measure, particularly should ONC Health IT
Certification Program criteria be made available to support certification of EHRs to the
capability associated with tracking prior authorizations requested electronically via the Prior
Authorization API using data from CEHRT.
Comment: A commenter stated that the Electronic Prior Authorization measure should
not be restricted only to items and services but should also include drugs to provide consistency
across prior authorization needs.
Response: As discussed earlier in this final rule, the Prior Authorization API
requirements we have finalized for impacted payers are limited to medicalitems and services
(excluding drugs). Therefore, for consistency, we are aligning using the API for the Electronic
Prior Authorization measure to limit it to evaluating using a Prior Authorization API for medical
items and services authorization requests only. We refer readers to section II.D. for additional
information on the Prior Authorization API requirements for impacted payers and the exclusion
of drugs.
Comment: A commenter stated that industry would need to review and endorse the
specification criteria prior to requiring the Electronic Prior Authorization measure.
Response: We thank commenters for this suggestion; however, we must note that there is
no requirement for industry to review or endorse measures in either the MIPS Promoting
Interoperability performance category or the Medicare Promoting Interoperability Program. We welcome comments from any interested parties through public comment during rulemaking, and
also during the annual call for measures for the MIPS Promoting Interoperability performance
category and the Medicare Promoting Interoperability Program, every summer.
Comment: Multiple commenters expressed concern that MIPS eligible clinicians, eligible
hospitals, and CAHs will not have the necessary health IT to support the Prior Authorization API
and therefore will not be able to report the proposed Electronic Prior Authorization measure by
the proposed implementation year of CY 2026. Multiple commenters urged CMS to delay
mandating the proposed Electronic Prior Authorization measure until adequate standards and
specifications are available to support electronic prior authorization, the Prior Authorization API
is implemented, and workflow is established. A commenter stated that providers should have the
flexibility to stage their adoption, as recognized in the Electronic Prior Authorization measure
proposal, to support a smooth transition from the current, manual process to a fully electronic
workflow. Another commenter suggested that CMS needs to provide eligible hospitals with
adequate time to convert their current processes into an electronic prior authorization process
prior to implementing the Electronic Prior Authorization measure underthe Medicare Promoting
Interoperability Program. The commenter expressed their concern that this transition to a new
electronic process will allow cases to fall through the cracks.
Response: We thank the commenters for their feedback. After reviewing comments for
both the Prior Authorization API and for using that API in this Electronic Prior Authorization
measure, we reconsidered our proposal and agree that provision of additional time for
implementation would be beneficial. As previously discussed, we understand that there may be
challenges with the availability of health IT to calculate a measure numerator and denominator
consistently for the Electronic Prior Authorization measures as we originally proposed. We also
believe the functionality of the Prior Authorization API should be in place and used by hospitals
and providers prior to requiring a numerator and denominator be reported. We will continue to
work with ONC to explore the adoption of standards and health IT certification criteria where appropriate to streamline data exchange, support interoperability, and increase efficiencies
associated with the policies in this final rule. As noted previously, the Unified Agenda, current at
the time of this final rules publication, includes an entry for a proposed rule from ONC (RIN
0955-AA06). The description indicates that that proposed rule aims to advance interoperability,
including proposals to expand the use of certified APIs for electronic prior authorization.164
As previously discussed, we are finalizing the Electronic Prior Authorization measure
with modification, to delay implementation for a year later than originally proposed, beginning
with CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians in the
MIPS Promoting Interoperability performance category, and beginning with the CY 2027 EHR
reporting period for eligible hospitals and CAHs under the Medicare Promoting Interoperability.
This modification also aligns with the finalized compliance dates in 2027 for the Prior
Authorization API. Also, as previously discussed, we are finalizing the Electronic Prior
Authorization measure with modification as an attestation (yes/no) measure, instead of requiring
reporting of data for a numerator and denominator. We believe this modification will minimize
data collection and reporting burden for this measure.
Comment: Many commenters recommended that the Electronic Prior Authorization
measure be an attestation (yes/no) measure to mitigate provider burden if CMS moves forward
with the proposed measure. Some commenters stated that they are not opposed to the Electronic
Prior Authorization measure and appreciated CMS not scoring it initially. However, a
commenter noted there may be implementation challenges due to eligible hospitals and CAHs
still recovering from the PHE and not having enough resources to implement. Another
commenter suggested that the Electronic Prior Authorization measure remain unscored
indefinitely. The commenter noted that the Prior Authorization API still being in the pilot testing
phase is an additional challenge. Another commenter expressed their appreciation for the
164OfficeofInformationandRegulatoryAffairs(2023,November).HealthData,Technology,andInteroperability:
PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. implementation timeline of the Electronic Prior Authorization measures stating that it would
allow for technical implementation, provider implementation, and education. Multiple
commenters were displeased with the proposed scoring methodology for the Electronic Prior
Authorization measure. Multiple commenters recommended that CMS consider making the
Electronic Prior Authorization measure voluntary or award bonus points for the proposed
Electronic Prior Authorization measure rather than including the measure in the composite score.
A commenter stated that an attestation (yes/no) measure would align the proposed Electronic
Prior Authorization measure with the other measures within the HIE objective.
Response: We appreciate the commenters concerns and recommendations on ways to
ease burden by making the Electronic Prior Authorization measure an attestation (yes/no)
measure. We agree and acknowledge that it would significantly reduce the reporting burden for
MIPS eligible clinicians, eligible hospitals, and CAHsif we did not require a numerator and
denominator to be calculated, and instead require only a yes or no response be reported to
indicate whether the Prior Authorization API was used for at least one prior authorization during
the applicable performance period/MIPS payment year or EHR reporting period. After
consideration of this feedback, and as discussed in more detail elsewhere in this section, we are
modifying the proposed Electronic Prior Authorization measure to be reported as an attestation
(yes/no) measure.
We appreciate the commenters recommendations for scoring this measure, such as not
scoring the measure or only assigning bonus points. However, we respectfully disagree with
these approaches. First, we did not propose to score this measure by assigning points (for
example, between 10 and 30 points for successful completion as provided at 42 CFR
414.1380(b)(4)(ii) for MIPS). However, we did propose that a MIPS eligible clinician, eligible
hospital, or CAH would receive a zero score for the MIPS Promoting Interoperability
performance category or the Medicare Promoting Interoperability Program if they did not
report a numerator of a least one for the measure or claim an exclusion (87 FR 76313). In other words, we proposed that if a MIPS eligible clinician, eligible hospital, or CAH failed to request
at least one prior authorization electronically via the Prior Authorization API using data from
their CEHRT, as would be required to report a numerator under the originally proposed measure
specifications (attesting no to the measure), or claim an applicable exclusion, then they would
not meet the minimum reporting requirements, not be considered a meaningful EHR user, and
fail the Medicare Promoting Interoperability Program or the Promoting Interoperability
performance category. A failure in the Medicare Promoting Interoperability Program would
result in a downward payment adjustment for eligible hospitals or CAHs (unless the eligible
hospital or CAH receives a hardship exception). A failure in the MIPS Promoting
Interoperability performance category would result in the MIPS eligible clinician receiving a
score of zero for the performance category, which is currently worth 25 percent of their final
score for MIPS.
Second, we clarify our rationale for proposing this scoring policy of zero for this
measure, which we are finalizing with modification to align with the attestation-based measure
specifications we are finalizing in this section. Fundamentally, a MIPS eligible clinician, eligible
hospital, or CAH must demonstrate it is a meaningfulEHR user by meeting three statutory
criteria set forth in sections 1848(o)(2)(A) and 1886(n)(3)(A) of the Act, to earn a score for the
MIPS Promoting Interoperability performance category (section 1848(q)(2)(B)(iv) of the Act) or
avoid a downward payment adjustment for the Medicare Promoting Interoperability Program.
We proposed this measure under sections 1848(o)(2)(A)(ii) and 1886(n)(3)(A)(ii) of the Act for
MIPS and Medicare Promoting Interoperability Program, respectively, because we believed, and
continue to believe, this measure would further enable the electronic exchange of health
information to improve the quality of health care (87 FR 76312). More specifically, we believe
the proposed Electronic Prior Authorization measure, which we are finalizing with modification,
is fundamental to determining whether a MIPS eligible clinician, eligible hospital, or CAH meets
criterion two of being a meaningful EHR user: demonstrating that their CEHRT is connected in a manner that provides for the electronic exchange of health information to improve the quality of
health care, such as promoting care coordination (sections 1848(o)(2)(A)(ii) and
1886(n)(3)(A)(ii) of the Act). A MIPS eligible clinician, eligible hospital, or CAH using the
Prior Authorization API to request at least one prior authorization electronically for, or claiming
an applicable exclusion from, reporting this measure, fundamentally demonstrates that they are a
meaningful EHR user. Therefore, we believe that failure to report the Electronic Prior
Authorization measure as specified, or to claim an applicable exclusion, demonstrates they are
not a meaningful EHR user and warrants the MIPS eligible clinician, eligible hospital, or CAH
receiving a score of zero for the MIPS Promoting Interoperability performance category or
Medicare Promoting Interoperability Program.
After consideration of public comments we received, we are finalizing a modification to
our proposal that the Electronic Prior Authorization measure will require MIPS eligible
clinicians, eligible hospitals, and CAHs to report a numerator and denominator, and instead,
require that MIPS eligible clinicians, eligible hospitals, and CAHs attest yes or no to having
performed at least one electronic prior authorization using the Prior Authorization API, or claim
an applicable exclusion. We are also finalizing that, if a MIPS eligible clinician, eligible hospital,
or CAH attests no or fails to claim an applicable exclusion for this measure, then they will
receive a zero score for the MIPS Promoting Interoperability performance category (currently
worth 25 percent of their final score for MIPS) or fail to meet Medicare Promoting
Interoperability Program reporting requirements. To allow for additional implementation time,
we are finalizing inclusion of the Electronic Prior Authorization measure in the MIPS Promoting
Interoperability performance category beginning with the CY 2027 performance period/2029
MIPS payment year and in the Medicare Promoting Interoperability program beginning with the
CY 2027 EHR reporting period.
Comment: Some commenters expressed concerns that providers may be unfavorably
evaluated or unfairly penalized for infrastructure and system issues or lack of capabilities and not the providers willingness or desire to conduct electronic prior authorizations. A commenter
requested clarification on the proposed measure exclusion criteria applying only to medical items
and services (excluding drugs) requiring prior authorization from a payer that does not offer a
Prior Authorization API, questioning whether this exclusion would lead to unintended
consequences.
Response: We recognize that these capabilities may not yet be widely adopted in some
settings, and that successful implementation of these capabilities may vary across providers and
systems. We note that we are finalizing that the Electronic Prior Authorization measure would be
reported as an attestation (yes/no) measure, as opposed to the proposed numerator and
denominator, which should reduce some of the initial implementation challenges. We are also
finalizing that the measure would first be reportable beginning with the CY 2027 performance
period/2029 MIPS payment year and CY 2027 EHR reporting period. This delayed
implementation will give both providers (that is, MIPS eligible clinicians, eligible hospitals, and
CAHs) and payers time to implement these changes to workflows and establish integrations prior
to the measure reporting being required.
We believe electronic prior authorization capabilities represent an important investment
that will benefit providers, patients, and other health care system entities. We note that some
payers do not fall under the definition of impacted payers in this final rule. Therefore, we are
finalizing the measures exclusion criterion (excluding MIPS eligible clinicians, eligible
hospitals, and CAHs that only order medical items or services [excluding drugs] requiring prior
authorization from a payer that does not offer an API that meets the Prior Authorization API
requirements finalized in this final rule) because we do not want to penalize MIPS eligible
clinicians, eligible hospitals, or CAHs for ordering medical items or services (excluding drugs)
from payers that do not have the API functionality for reasons such as not being an impacted
payer. Comment: A commenter stated that they oppose measures that could negatively impact a
MIPS eligible clinicians score, such as the current all-or-nothing scoring methodology used to
score the MIPS Promoting Interoperability performance category. Another commenter stated
their belief that the proposed rule lacks detail on how the Electronic Prior Authorization measure
will be scored and tied into the broader scoring of the Medicare Promoting Interoperability
Program for eligible hospitals and CAHs.
Response: We note that the overall scoring methodology for MIPS Promoting
Interoperability performance category is not being changed with the addition of the Electronic
Prior Authorization measure, nor the scoring methodology for the HIE measure itself. As
discussed previously in this section, we believe that failure to report the Electronic Prior
Authorization measure as specified, or to claim an applicable exclusion, demonstrates that the
MIPS eligible clinicians is nota meaningful EHR user and warrants the MIPS eligible clinician
receive a score of zero for the MIPS Promoting Interoperability performance category. While we
understand that the all-or-nothing approach requires MIPS eligible clinicians to report and attest
to all requirements, we note that requiring the Electronic Prior Authorization measure is in
alignment with our scoring policies and methodologies. Our regulation at 42 CFR 414.1375(b)
provides that, to earn a score for the MIPS Promoting Interoperability performance category, the
MIPS eligible clinician must report on objectives and associated measures as specified by CMS.
For additional information on overall MIPS scoring policies and MIPS Promoting
Interoperability performance category scoring policies, we refer readers to our regulations at 42
CFR 414.1375 (governing the requirements for the MIPS Promoting Interoperability
performance category), 42 CFR 414.1380 (governing scoring for MIPS), as well as Table 46:
Scoring Methodology for the Performance Period in CY 2024 for the Promoting Interoperability
performance category in the CY 2024 PFS final rule (88 FR 52587). For information on the
overall scoring methodology currently used to calculate MIPS final scores, we refer readers to
the MIPS Final Score Methodology section in the CY 2024 PFS final rule (88 FR 52591). To be considered a meaningful EHR user, fulfill the minimum reporting requirements,
and avoid a downward payment adjustment, the Medicare Promoting Interoperability Program
requires that eligible hospitals and CAHs meet, by reporting on or attesting to, all objectives and
measures selected by CMS. Failure to meet the minimum reporting requirements results in
failure of the Medicare Promoting Interoperability Program, subjecting the eligible hospital or
CAH to a downward payment adjustment (unless the eligible hospital or CAH receives a
hardship exception).
b. Prior Authorization API Functionality
In the proposed rule (87 FR 76313), we proposed that a prior authorization request must
be made using the Prior Authorization API to satisfy the Electronic Prior Authorization measure.
The Prior Authorization API functionality is outlined in further detail in section II.D.2. of this
final rule. We proposed that prior authorization requests that are made using fax, mail, or portal
would be included in the denominator of the measure unless the prior authorization cannot be
requested using the Prior Authorization API because the payer does not offer an API that meets
the Prior Authorization API requirements, in which case any such prior authorization request
would be excluded from the denominator. Instances where a payer offering the Prior
Authorization API specifically requests a mailed or faxed prior authorization would be included
in the denominator. Prior authorization requests that are made using fax, mail, or portal would
not be included in the numerator of the measure because these methods would not incentivize
using the standards-based API functionality as intended by the measure. Prior authorizations for
any and all drugs would be excluded from both the numerator and denominator of the measure.
(For a more detailed discussion of the exclusion of drugs, see section I.C. of this final rule.)
We proposed that only prior authorizations that are requested electronically via a Prior
Authorization API using data from CEHRT would be included in the numerator. Using the API
to query documentation requirements alone, and not to request the prior authorization, would not
count in the numerator or denominator. To satisfy the Electronic Prior Authorization measure, the health care provider uses data
from their CEHRT (such as patient demographics and medicalinformation) to justify the prior
authorization request. The Prior Authorization API then automates the HIPAA-compliant prior
authorization request. Additional information not contained in CEHRT may also be required for
submission.
Comment: Multiple commenters urged CMS to delay mandating the proposed Electronic
Prior Authorization measure until adequate standards and specifications are available to support
electronic prior authorization and until the Prior Authorization API workflow is established. A
commenter urged CMS to evaluate whether sufficient implementation guidance exists to support
automating data retrieval before moving to require the Electronic Prior Authorization measure in
future years. Some commenters noted that CMS must ensure that the desired standards outlined
in the Electronic Prior Authorization measure specification are achievable. Another commenter
recommended that CMS make all IGs required for payers so the burden is not placed on
providers to figure out something that will be incredibly difficult and resource-intensive to do.
Another commenter recommended thatCMS or ONC should issue an IG to ensure there is
standardization of implementation across payers. The commenter stated that IGs could reduce
payer variability in the creation of the Prior Authorization API. Another commenter sought
clarification on how it will be feasible for CEHRT to implement an API-based prior
authorization functionality to support performance measurement if payers are not required to
adhere to standardized IGs. The commenter stated that for this to occur seamlessly CEHRT
standards would need to be updated appropriately.
Response: We thank the commenters for sharing their recommendations. We are working
with HL7, the HL7 FHIR accelerator workgroups, and interested parties within the standards
development industry to move the IGs towards greater maturity by defining technical
specifications, participating in and convening testing events for them, and developing and
maintaining the technical specifications. Electronic prior authorization using a FHIR API has been implemented and is in production, proving sufficient implementation guidance exists. We
agree that IGs help to ensure standardization of implementation across the industry. In section
II.G. of this final rule, we outline the required standards and technical specifications necessary to
build the Prior Authorization API and to ensure that implementation is consistent across all
impacted payers and providers to avoid unnecessary duplication of efforts. We have also
recommended certain IGs to help providers and payers meet that requirement. These IGs are
developed using a consensus process involving many members of the payer and provider
communities. They aid in the implementation process of the APIs. We anticipate that payers will
use the recommended IGs so that most, if not all, providers benefit from a standardized approach
to accessing patient data with all payers with whom they contract. Our approach in the proposed
rule of recommending, but not requiring, the specific IGs for each API implementation was to
provide directional guidance with flexibility to the industry without locking implementers into
the versions available at the time of the proposed rule. As industry moves forward with
implementation of these policies and use of these standards, industry can continue to harmonize
on common approaches that work, eventually culminating in a required set of specifications
when ready.
Comment: A commenter recommended that CMS explain that the electronic prior
authorization workflow does not necessarily need to be completed by the provider and that such
workflows do not necessarily need to be included in CEHRT. The commenter recommended that
CMS emphasize that only using data from CEHRT as part of the process for requesting prior
authorization via a payers Prior Authorization API is sufficient to meet the Electronic Prior
Authorization measure. Another commenter suggested that CMS should consider not limiting the
Electronic Prior Authorization measure to only data relevant to a prior authorization that is
obtained from an EHR as relevant prior authorization data may not be limited to the providers
EHR alone. A commenter stated that certain health insurance data, clinical data, and other
administrative data subject to follow-up requests or initial submissions may exist in non-EHR systems in use. The commenter stated that this further underscores the premise that any health IT
developer wishing its health IT to be certified must support allUSCDI in its health IT. The
commenter stated that USCDI as a driver to enable standards-based exchange is increasingly less
relevant and, instead, the various IGs would indicate what participating systems should support.
A commenter requested clarification on the expectations for incorporating such workflows into
the Medicare Promoting Interoperability Program. The commenter sought clarification on
whether eligible hospitals are expected to begin to share prior authorization information via the
integrations with HINs to meet the bi-directional HIE measure. Multiple commenters encouraged
the use of HIEs to connect impacted payers and providers to facilitate electronic prior
authorization. A commenter stated that HIEs could provide support for continuing to connect
providers and payers, including for the purposes of prior authorization. Another commenter
recommended that CMS should include an optional, alternative measure that allows MIPS
eligible clinicians, eligible hospitals, and CAHs to claim a Promoting Interoperability credit by
attesting to using a HIE/HIN to request a prior authorization. Another commenter recommended
that CMS create a health IT activity as part of the HIE Objective for mapping to a Prior
Authorization API that is measured by the transmission of at least one prior authorization
through the Prior Authorization API.
Response: We did not propose, and are not finalizing, details of a specific workflow, or
by whom, that must be completed to report the Electronic Prior Authorization measure beyond
specifying that data from CEHRT must be used for the transaction with a Prior Authorization
API. CMS recognizes that, under the Electronic Prior Authorization measure that we are
finalizing in this rule, MIPS eligible clinicians, eligible hospitals, and CAHs may utilize different
workflows to submit an electronic prior authorization request. As noted, the Unified Agenda,
current at the time of publication of this final rule, includes an entry for a proposed rule from
ONC entitled Health Data, Technology, and Interoperability: Patient Engagement, Information
Sharing, and Public Health Interoperability (RIN 0955-AA06). The description for this proposed rulemaking notes that this rule aims to advance interoperability through proposals for
the expanded use of certified APIs for electronic prior authorization, among other proposals.165
We plan to continue to explore how potential future updates to the ONC Health IT Certification
Program can supportour policies and will address any updates to our requirements related to
these future updates to the ONC Health IT Certification Program criteria if finalized, in future
rulemaking. In reference to the USCDI, we note that health IT modules may be certified to only
one or a few certification criteria that do not reference the USCDI standard, and therefore are not
all required to support USCDI.
With regard to workflows, there is no requirement under the MIPS Promoting
Interoperability performance category or the Medicare Promoting Interoperability Program that a
specific individual person must request prior authorization electronically via the Prior
Authorization API to meet requirements of the Electronic Prior Authorization measure. Instead,
it can be someone who legally can enter information into the medical record in accordance with
applicable laws and professional guidelines. Regarding the measures specifications, we
emphasize that data must come from the CEHRT, as use of CEHRT is a required element of both
the MIPS Promoting Interoperability performance category and the Medicare Promoting
Interoperability Program. However, additional data outside of CEHRT may also be used in
addition to support the interaction with a Prior Authorization API.
Regarding the USCDI, we note that this standard is referenced in many of the IGs
recommended for these use cases, however, the relative utility, in the abstract, of USCDI as a
standard adopted for use in certified health IT and cross referenced in certain ONC Health IT
Certification Program criteria is outside the scope of this final rule. We also note that we did not
propose and are not finalizing a requirement under the MIPS Promoting Interoperability
performance category or the Medicare Promoting Interoperability Program to share prior
165OfficeofInformationandRegulatoryAffairs(2023,November).HealthData,Technology,andInteroperability:
PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. authorization information via the integrations with HINs to meet the Bi-Directional HIE
measure. Additionally, we thank commenters for their recommendations on additional measures
to promote electronic prior authorization. CMS reiterates that to meet the requirements of the
Electronic Prior Authorization measure, the electronic prior authorization must use a Prior
Authorization API as finalized in this rule. CMS agrees that using HIEs and other HINs could
help to facilitate sharing of prior authorization information. Nothing in the Electronic Prior
Authorization measures we are finalizing would restrict using such networks as long as the
payers Prior Authorization API is used for the electronic prior authorization.
Comment: A commenter sought clarification on whether a provider must implement
capabilities to connect to all parts of the Prior Authorization API for full automation of the
electronic prior authorization processing in order to claim numerator credit. Another commenter
questioned whether a provider meets the numerator criteria if they use the Prior Authorization
API that does not meet all the capabilities outlined in the recommended HL7 Da Vinci CRD,
DTR, and PAS IGs. Another commenter requested clarification regarding whether a MIPS
eligible clinician using the Prior Authorization API to submit a prior authorization request is not
required to use all capabilities (that is, CRD, DTR, and PAS) in order to meet the numerator
qualification, but rather that, at a minimum, the PAS IG request is used.
Response: We thank the commenters for their feedback and note that we are finalizing
this measure with modification to no longer require MIPS eligible clinicians, eligible hospitals,
and CAHs to report a numerator and denominator for the measure. Instead, we are finalizing this
measure to require MIPS eligible clinicians, eligible hospitals, and CAHs to attest a yes or
no response for the measure or claim an applicable exclusion. In order to attest yes, for at
least one medical item or service (excluding drugs) and, for eligible hospitals and CAHs, for one
hospital discharge ordered during the performance period or EHR reporting period, a prior
authorization request must be submitted to a payer using a Prior Authorization API. We note that to report a yes, the action of the measure must occur during the selected performance period166
or EHR reporting period,167 as per the measure specification. The Prior Authorization API is
discussed in more detail in section II.D. of this final rule, and we note that the submission of the
prior authorization request itself is described through the recommended PAS IG.
Comment: Some commenters stated that certain EHR systems are more sophisticated than
others and could track Prior Authorization API activity, while other hospitals and providers lack
this technology. A commenter sought clarification on how a provider can use their EHR to
identify situations where the prior authorization cannot be requested via a payers Prior
Authorization API for the purposes of performance measurement. A commenter stated that some
provider systems do not support one or more payer APIs due to slightdifferences in structure,
interpretation, or both, which could result in the provider being penalized due to an EHR
systems lack of capability and not the providers lack of desire to use the Prior Authorization
API. A commenter noted that the Electronic Prior Authorization measure would be
counterproductive to ONCs strategy of reducing burden related to using health IT and EHRs and
that there should be near-zero reporting burden. Multiple commenters noted that there will be
technical and financial challenges with adopting an electronic prior authorization process. Some
commenters recommended that CMS should provide financial and technical assistance/training
to providers to adopt and implement the technology requirements. The commenter noted that
some provider types, such as physical therapists, are ineligible to participate in the Medicare and
Medicaid EHR Incentive Programs and have received little guidance on using EHR systems. A
commenter stated that CMS should acknowledge the significant financial and administrative risk
providers face when purchasing EHR systems in the context of MIPS. A commenter noted that
many health IT vendors currently charge separately for electronic prior authorization
functionality and the cost associated with purchasing these functionalities has been a substantial
166See42CFR414.1320.
167See42CFR495.40(b)(2)(i). barrier to adoption for many small and independent practices, as well as rural hospitals. Some
commenters noted the financial burden associated with using APIs and that practices must first
be able to affordably adopt this technology before a new requirement is established for its use.
Response: We acknowledge there will be variability in EHR technology capabilities to
track Prior Authorization API activity. As noted previously, for this reason and to reduce
reporting burden, we are finalizing the Electronic Prior Authorization measure as an attestation
(yes/no) measure. As noted, ONC has sought comment on how updates to the ONC Health IT
Certification Program could support electronic prior authorization (87 FR 3475). We also note
that the Unified Agenda, current at the time of publication of this final rule, has been updated to
include an entry for a proposed rule from ONC (RIN 0955-AA06) that includes proposals for the
expanded use of certified APIs for electronic prior authorization.168 We will monitor these
developments in order to inform updates to the Electronic Prior Authorization measure in the
future, for instance, requiring reporting of a numerator and denominator.
While we acknowledge there may be costs associated with implementing functionality
needed to interact with a payers Prior Authorization API, as well as add-on costs charged by
health IT vendors for adding these features, we believe that the benefits of the technology
outweigh the costs. We also remind readers that this attestation (yes/no) measure would not be
included under the Medicare Promoting Interoperability Program and the MIPS Promoting
Interoperability performance category until the CY 2027 performance period/2029 MIPS
payment year and CY 2027 EHR reporting period. We believe extending the inclusion of the
Electronic Prior Authorization measure to the CY 2027 performance period/2029 MIPS payment
year for MIPS eligible clinicians and the CY 2027 EHR reporting period for eligible hospitals
and CAHs will allow participants in these programs to work with health IT vendors to adopt and
168OfficeofInformationandRegulatoryAffairs(2023,November).HealthData,Technology,andInteroperability:
PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. implement functionality that can facilitate the actions needed to satisfy the Electronic Prior
Authorization measure.
As far as technical assistance, CMS does host CMS and HL7 FHIR Connectathons,
which are free for interested parties to attend, as well as provides educational webinars with
overviews of the technical requirements in the CMS Interoperability and Patient Access final
rule and proposed requirements in the CMS Interoperability and Prior Authorization proposed
rule. Additional public resources also exist through HL7, such as HL7 FHIR Connectathons,
HL7 website resources, and HL7 FHIR workgroup meetings. CMS believes that using the EHR
systems, and training for staff using them, is up to each practice or hospitalsystem to ensure
occurs.
CMS also is aware thatthe initial incentive programs (that is, the Medicare and Medicaid
EHR Incentive Programs) supported EHR adoption for only certain provider types and the
challenges that brings for certain provider types that were not originally eligible for this funding.
CMS continues to evaluate ways to support providers that may lag in health IT adoption.
Comment: A commenter requested that CMS establish requirements for impacted payers
to publish their API endpoints for the Prior Authorization API or provide information on where
to find the APIs and make information concerning how to connect to them conspicuously
available for third-party app developers and for providers through their public websites similar to
what is asked of certified health IT developers of API functions as a part of their basis of
CEHRT under 45 CFR 170.315(g)(10).
Response: We understand that a directory of impacted payers digital endpoints would be
highly beneficial to facilitate the Prior Authorization API. Without such a directory, payers
would need to discover other payers endpoints one by one, and each payer would have to
maintain a list of payers with whom they have previously connected. Therefore, we are
committing to exploring an NDH that contains payers digitalendpoints before the 2027
compliance dates for the Prior Authorization API, which could allow providers to easily access those APIs and thereby facilitate electronic prior authorization, as discussed in this final rule.
Further details about the NDH structure, requirements, and timing will be released if and when
they become available.
Comment: A commenter discussed the X12 standards and expressed that they do not
believe that the inclusion of the Electronic Prior Authorization measure would be a sufficient
incentive for MIPS eligible clinicians, eligible hospitals, and CAHs to overcome the costs
associated with the transaction. Multiple commenters recommended that CMS should include the
usage of the X12 278 standard in the numerator of the proposed measures. A commenter noted
organizations that have standardized usage of the X12 standard may find this effective and
efficient. The commenter stated that requiring these groups to transition to the Prior
Authorization API to meet the measure requirements would be disruptive and burdensome.
Another commenter recommended CMS use a single standard if CMS would like to incorporate
the Electronic Prior Authorization measure. A commenter also recommended that CMS provide
guidance on the role of HIPAA administrative transaction standards.
Response: We thank the commenters for their feedback; however, we do not agree that
the X12 278 standard is appropriate for the numerator of the proposed Electronic Prior
Authorization measure because of its persistent and historically low utilization. While the CAQH
efficiency index report is more reflective of payer and vendor uptake of the HIPAA standards, it
does include some provider information.169 In the last four reporting years, the utilization of the
X12 278 transaction has not exceeded 21 percent. Comments from reporting submitters (for the
CAQH Index) indicate that providers do not use the X12 278 because it does notinclude the data
elements they need for complete processing, and many payers are still not supporting it. Thus, to
consider using that standard as the numerator, knowing the utilization rates are low, would not
seem appropriate. We believe the benefit of moving towards a standardized electronic prior
169CoalitionforAffordableQualityHealthcare(2022).TheCAQHIndexReport.Retrievedfromhttps://
https://www.caqh.org/insights/caqh-index-report. authorization process that leverages FHIR outweighs the initial implementation cost and burden
of the transition. We will continue coordinating with colleagues across CMS and other Federal
agencies on all ways that that HIPAA administrative transaction standards could impact our
policies. We also note that we are finalizing a modification to our proposal to no longer require
reporting of a numerator and denominator for this measure, as discussed in more detail
throughout this section.
c. Measure Exclusions
In the proposed rule (87 FR 76314), we proposed that MIPS eligible clinicians,eligible
hospitals, or CAHs that do not order any medical items or services (excluding drugs) requiring
prior authorization during the applicable performance period or EHR reporting period could
claim an exclusion for the Electronic Prior Authorization measure. We also proposed that MIPS
eligible clinicians, eligible hospitals, or CAHs that only order medical items or services
(excluding drugs) requiring prior authorization from a payer that does not offer an API that
meets the Prior Authorization API requirements outlined in section II.D.2. of this final rule (that
is, payers not subject to this regulation or impacted payers that are non-compliant with the Prior
Authorization API requirements outlined in section II.D.2. of this final rule), during the
applicable performance period/MIPS paymentyear or EHR reporting period, could claim an
exclusion for the Electronic Prior Authorization measure. As an alternative to this proposal, we
considered whether MIPS eligible clinicians, eligible hospitals, and CAHs that request a small
number of prior authorizations, such as five prior authorizations during the performance
period/EHR reporting period, should also be able to claim the exclusion. We sought public
comment on the alternative we considered and whether another minimum number of prior
authorization requests would be appropriate for the exclusion. Given the previously discussed
limitations of the current prior authorization process, we believe that all MIPS eligible clinicians,
eligible hospitals, and CAHs (as well as their patients and the payers they request prior
authorization from) would benefit from using the electronic process described here, regardless of how often they request prior authorization. Therefore, we believe that no minimum number of
prior authorization requests, other than zero, would be a reasonable threshold for claiming an
exclusion for the Electronic Prior Authorization measure.
Comment: A few commenters stated that if a payer insists on faxing or other means of
communication, CMS should consider treating this scenario as the basis for exclusion from the
Electronic Prior Authorization measure versus still having authorizations impacted by such a
requirement of a payer included in the denominator. A commenter stated that some practitioners
do not have enough prior authorization requests or the necessary technology to support electronic
prior authorization, and suggested the exclusion should be based on not only quantity but also on
technical capability of those who do not submit a high volume of prior authorization requests.
The commenter encouraged CMS to consider alternative exclusion criteria, such as the technical
capability of those who do not submit a high volume of prior authorization requests. The
commenter continued by stating that CMS should not penalize providers for failing to use EHRs
for this purpose of electronic prior authorization if they either do not have enough requests or if
the technology they use does not support this capability.
Response: We appreciate commenters recommendations and feedback that some
providers may not have enough prior authorization requests or the necessary technology to
support electronic prior authorization. We believe that all MIPS eligible clinicians, eligible
hospitals, and CAHs (as well as their patients and the impacted payers they request prior
authorization from) would benefit from using the electronic prior authorization process described
in this final rule. We also note that the modified version of the Electronic Prior Authorization
measure being finalized in this rule only requires reporting of at least one medical item or
service (excluding drugs) ordered during the performance period/MIPS payment year or EHR
reporting period. We believe this is achievable for all MIPS eligible clinicians, eligible hospitals,
and CAHs who make any prior authorization requests in a given year. For those who do not have
any prior authorization requests, we are finalizing our exclusion as proposed. MIPS eligible clinicians, eligible hospitals, and CAHs who do not order any medical items or services
(excluding drugs)requiring prior authorization during the applicable performance period/MIPS
payment year or EHR reporting period would be able to report that they qualify for the exclusion
for the Electronic Prior Authorization measure.
We acknowledge that EHR technology may not consistently support interactions with the
Prior Authorization APIs at this time, and as discussed in further detail elsewhere in this section,
we will continue to work with ONC on potential ONC Health IT Certification Program criteria
that would support the Electronic Prior Authorization measure. For this reason, we are finalizing
this measure for the MIPS Promoting Interoperability performance category beginning with the
CY 2027 performance period/2029 MIPS payment year and for the Medicare Promoting
Interoperability Program beginning with the CY 2027 EHR reporting period.
d. Office of the National Coordinator for Health Information Technology Health IT Certification
Program
As described previously, ONC previously sought comment through an RFI titled
Electronic Prior Authorization Standards, Implementation Specifications, and Certification
Criteria (87 FR 3475), which appeared in the January 24, 2022, issue of the Federal Register,
on how updates to the ONC Health IT Certification Program could support electronic prior
authorization. Since then, the Unified Agenda has been updated to include a proposed rule from
ONC (RIN 0955-AA06) that aims to advance interoperability through proposals for the
expanded use of certified APIs for electronic prior authorization, among other proposals.170 We
plan to continue to explore how potential updates to the ONC Health IT Certification Program
could support our policies and will address any updates to our requirements related to future
updates to the ONC Health IT Certification Program, if finalized, in future rulemaking.
e. Other Considerations
170OfficeofInformationandRegulatoryAffairs(2023,November).HealthData,Technology,andInteroperability:
PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. We invited public comment on considerations and alternatives related to the Electronic
Prior Authorization measure. For example, we sought comment on the proposed numerator and
denominator of the Electronic Prior Authorization measure or any changes to the specifications
that would reduce the implementation burden for both impacted providers (MIPS eligible
clinicians, eligible hospitals, and CAHs) and health IT developers. We also sought comment on
challenges that MIPS eligible clinicians, eligible hospitals, and CAHs might face in identifying
those payers that have the Prior Authorization API technology to accurately include eligible prior
authorization requests in the denominator. Additionally, we sought comment on challenges
MIPS eligible clinicians, eligible hospitals, and CAHs could face in performing the actions
included in the Electronic Prior Authorization measure specifications if certification criteria are
not available in the ONC Health IT Certification Program at the time MIPS eligible clinicians,
eligible hospitals, and CAHs are required to report the Electronic Prior Authorization measure
under the Medicare Promoting Interoperability Program or MIPS Promoting Interoperability
performance category.
We received many comments in response to our request for comment. We thank
commenters for their feedback as we consider any future rulemaking, including collaboration
with ONC as appropriate.
Comment: Multiple commenters opposed the proposed Electronic Prior Authorization
measure because of the lack of health IT certification criteria to ensure EHRs communicate with
payers through Prior Authorization API. Multiple commenters expressed concern about the
inclusion of the Electronic Prior Authorization measure due to possible technical challenges and
the lack of health IT that has the capacity to supportelectronic prior authorization. Multiple
commenters encouraged CMS to focus on ensuring that the proposed APIs are implemented and
supported by CEHRT to make sure they are successfully implemented within the providers
workflow rather than developing a measure related to electronic prior authorization. Several commenters noted that ONC has not established health IT certification criteria to
support electronic prior authorization in such technologies. Multiple commenters suggested
various alternative timeframes for CMS to consider. A commenter recommended that CMS
require payers to make the Prior Authorization API available to providers no later than 12
months following the publication of this final rule. Another commenter suggested a compliance
date 12 months after the implementation of the Prior Authorization API or 36 months following
publication of this final rule, whichever is later. Another commenter requested that CMS
consider reopening the comment period for this rule following the publication of the HTI-1
proposed rule (88 FR 23746). The commenter stated that CMS should give industry 24 months
from the reopening of the comment period to create specifications, perform development,
complete certification testing, and execute client deployments. Another commenter
recommended that CMS suspend the proposed Electronic Prior Authorization measure until
payers implement and maintain the Prior Authorization API as specified in this rule and the Prior
Authorization API is in effect for at least 3 years. Multiple commenters were concerned that
providers will not be guaranteed access to the Prior Authorization API if health IT developers are
not required to incorporate the functionality into CEHRT and therefore should not be held
accountable for using the Prior Authorization API nor reporting on the proposed Electronic Prior
Authorization measure. A commenter recommended that CMS and ONC work in collaboration
to leverage technologies, such as electronic prior authorization tools. Another commenter urged
CMS to work with ONC to establish ONC Health IT Certification Program criteria to require
providers and EHR vendors to adopt the IGs associated with electronic prior authorization.
Commenters stated that it is unreasonable to measure utilization by MIPS eligible clinicians,
eligible hospitals, and CAHs of electronic prior authorization processes for incentive payments
until the ONC Health IT Certification Program requires CEHRT to include the functionality
necessary for health IT systems to communicate through a Prior Authorization API. Another
commenter stated that CMS should postpone implementation of the Electronic Prior Authorization measure until both the ONC Health IT Certification Program and HIPAA
attachment standards are updated. Another commenter stated that the proposed Electronic Prior
Authorization measure would subject MIPS eligible clinicians, eligible hospitals, and CAHs to
be reliant upon untested technology and tie their performance to such technology. A commenter
emphasized the importance of industry adoption and noted thatthe API will have minimal value
if EHR vendors do not build the necessary connections to allow clinicians to access it and if
clinicians are not incentivized to adopt. To mitigate this, the commenter recommended that CMS
require EHR vendors to provide bi-directional patient data access via an API so payers can better
leverage digital patient information and automate prior authorization requests. Another
commenter recommended that CMS ensure that the proposed Electronic Prior Authorization
measure is supported by technology used by all of the impacted users. Several commenters stated
that providers should not be subject to punitive action if they do not implement the Prior
Authorization API requirements and should not be evaluated on electronic prior authorization
utilization for payment purposes until EHRs are required to provide this functionality by the
ONC Health IT Certification Program.
Response: We appreciate the comments received on this request for comments. As noted,
the Unified Agenda, current at the time of publication of this final rule, includes an entry for a
proposed rule from ONC (RIN 0955-AA06) that aims to advance interoperability through
proposals for the expanded use of certified APIs for electronic prior authorization.171 We will
work with ONC to ensure that any future updates to the ONC Health IT Certification Program
around electronic prior authorization will improve health care providers capabilities to interact
with the Prior Authorization APIs established by impacted payers, as well as further support
health care providers ability to complete the action specified in the Electronic Prior
Authorization measure we are finalizing. We will provide further guidance in future rulemaking
171OfficeofInformationandRegulatoryAffairs(2023,November).HealthData,Technology,andInteroperability:
PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. about how any updates made by ONC to the ONC Health IT Certification program related to
electronic prior authorization relate to the requirements of the Medicare Promoting
Interoperability Program and Promoting Interoperability performance category of MIPS. We
note that CMS does not have authority to regulate EHR vendors directly; however, we
collaborate with ONC regarding certification criteria for health IT that are included in the
voluntary ONC Health IT Certification Program and referenced in CMS program requirements.
In the interim, we note that MIPS eligible clinicians, eligible hospitals, and CAHs are
required to use CEHRT for the measure as a means to capture clinical information as structured
data and to use such structured data for the prior authorization. This function of gathering
structured data from CEHRTs is achievable today without additional CEHRT criteria. The
request for prior authorization through the Prior Authorization API could be accomplished
through the use of additional technology to complement CEHRT depending on implementation
preference. We note that MIPS eligible clinicians, eligible hospitals, and CAHs can report on the
measure, saying yes they submitted a prior authorization request electronically using the Prior
Authorization API with data from CEHRT, without needing additional certification criterion in
the ONC Health IT Certification Program.
We also note that in December 2022, HHS proposed to adopt a standard for attachments
in the HIPAA Standards for Health Care Attachments proposed rule (87 FR 78438). That
proposed rule has not yet been finalized. At this time there are no operating rule requirements
applicable to the APIs required for use in this final rule, or to the HIPAA X12 278 transaction
standard.
We appreciate commenters recommendations regarding implementation timelines, such
as making the Prior Authorization API available to providers no later than 12 months or 36
months following the publication of this final rule. We note that, after consideration of comments
received and discussed in more detail elsewhere in the rule, we are finalizing our proposal with
the modification to have MIPS eligible clinicians report the Electronic Prior Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment year and eligible
hospitals and CAHs report the Electronic Prior Authorization measure beginning with the CY
2027 EHR reporting period. We also acknowledge that a commenter recommended suspending
the Electronic Prior Authorization measure until payers implement the Prior Authorization API
as specified in this rule and use it for some time period. However, we believe finalization of this
Electronic Prior Authorization measure encourages all parties involved (payers and providers) to
develop, implement, and use the new Prior Authorization API to drive widespread adoption, thus
reaping the benefits of burden reduction through electronic prior authorization processes. The
Prior Authorization API needs parties on both ends of a request to be using the API in order for
the API to be beneficial to everyone involved.
Comment: Multiple commenters recommended that ONC conduct oversight of CEHRT
products to determine if the products do or do not successfully support electronic prior
authorization, and then publicize CEHRT products that fail ONC review on the Certified Health
IT Product List (CHPL) so providers can avoid products that will not support the new electronic
prior authorization requirements. The commenter recommended that ONC work with
professional associations to educate providers about their oversight and reporting process.
Response: There is not a dedicated certification criterion related to electronic prior
authorization in the ONC Health IT Certification Program at this time. However, as noted
previously, ONC previously sought comment on how updates to the ONC Health IT Certification
Program could support electronic prior authorization (87 FR 3475). We also note that the Unified
Agenda, current at the time of publication of this final rule, includes an entry for a proposed rule
from ONC (RIN 0955-AA06), which describes planned proposals for the expanded use of
certified APIs for electronic prior authorization.172 We note that the Electronic Prior
Authorization measure requires using data from CEHRT, and the Prior Authorization API can be
172OfficeofInformationandRegulatoryAffairs(2023,November).HealthData,Technology,andInteroperability:
PatientEngagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. implemented without regard to any changes ONC may propose for the ONC Health IT
Certification Program.
While ONC oversight and enforcement authority is beyond the scope of this final rule,
we note that health IT products certified to all certification criteria are subject to oversight
mechanisms within the ONC Health IT Certification Program. For more information about the
oversight elements within the ONC Health IT Certification Program, readers should visit the
ONC website at https://www.healthit.gov/topic/certification-ehrs/oversight-and-surveillance.
Regarding the CHPL (https://chpl.healthit.gov/), we note this resource includes listings of those
health IT products that have successfully certified to health IT certification criteria under the
Certification Program.
Comment: Multiple commenters recommended that CMS and ONC outline a roadmap for
electronic prior authorization adoption that leverages the ONC Health IT Certification Program.
A commenter recommended that the roadmap should include details from the ONC Cures Act
final rule (85 FR 25642) and these requirements. Another commenter stated that an established
path to electronic prior authorization will avoid delays and confusion.
Response: We appreciate commenters feedback. CMS will consider developing a
roadmap for electronic prior authorization adoption in collaboration with ONC. We will
collaborate with ONC to incorporate any future policies for the ONC Health IT Certification
Program as part of a comprehensive approach to ensuring electronic prior authorization is
conducted in a standardized fashion across parties.
3. Final Action
After consideration of the comments received and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule and our response to those comments (as
summarized previously), we are finalizing our proposal with the following modifications:
 The Electronic Prior Authorization measure will be reported as an attestation
(yes/no) measure, instead of reporting a numerator and denominator, regarding whether the MIPS eligible clinician, eligible hospital, or CAH submitted at least one prior authorization
request electronically via a Prior Authorization API using data from CEHRT during the
performance period/EHR reporting period, as further specified below.
 MIPS eligible clinicians will report the Electronic Prior Authorization measure for
the MIPS Promoting Interoperability performance category beginning with the CY 2027
performance period/2029 MIPS payment year and eligible hospitals and CAHs participating
under the Medicare Promoting Interoperability Program will report the measure beginning with
the CY 2027 EHR reporting period.
See further discussion below for exact details of the final requirements for MIPS eligible
clinicians, eligible hospitals, and CAHs.
We are finalizing the following specifications for the Electronic Prior Authorization
measures:
1. For MIPS eligible clinicians under the MIPS Promoting Interoperability Performance
CategoryElectronic Prior Authorization
 Measure Description: For at leastone medical item or service (excluding drugs)
ordered by the MIPS eligible clinician during the performance period, the prior authorization is
requested electronically via a Prior Authorization API using data from CEHRT.
 Reporting Requirements: Yes/No response.
To successfully report this measure, MIPS eligible clinicians must attest yes to
requesting prior authorization electronically via a Prior Authorization API using data from
CEHRT for at least one medical item or service (excluding drugs) ordered by the MIPS eligible
clinician during the performance period or (if applicable) report an exclusion.
 Exclusion: Any MIPS eligible clinician who--
++ Does not order any medical items or services (excluding drugs) requiring prior
authorization during the applicable performance period; or ++ Only orders medical items or services (excluding drugs) requiring prior authorization
from a payer that does not offer an API that meets the Prior Authorization API requirements
outlined in section II.D.2. of this final rule during the applicable performance period.
2. For Eligible Hospitals and Critical Access Hospitals under the Medicare Promoting
Interoperability Program--Electronic Prior Authorization
 Measure Description: For at leastone hospital discharge and medical item or service
(excluding drugs) ordered during the EHR reporting period, the prior authorization is requested
electronically via a Prior Authorization API using data from CEHRT.
 Reporting Requirements: Yes/No response.
To meet this measure, the eligible hospital or CAH must attest yes to requesting a prior
authorization electronically via a Prior Authorization API using data from CEHRT forat least
one hospital discharge and medical item or service (excluding drugs) ordered during the EHR
reporting period or (if applicable) report an applicable exclusion.
 Exclusions: Any eligible hospital or CAH that--
++ Does not order any medical items or services (excluding drugs) requiring prior
authorization during the EHR reporting period.
++ Only orders medical items or services (excluding drugs) requiring prior authorization
from a payer that does not offer an API that meets the Prior Authorization API requirements
outlined in section II.D.2. of this final rule during the applicable EHR reporting period.
We intend to reevaluate the Electronic Prior Authorization measure criteria and reporting
structure of this measure in future years as the Prior Authorization API becomes more widely
adopted and if additional certification criteria become available for CEHRT to determine
whether a numerator/denominator reporting structure would be more appropriate at that time. We
would address those issues in future rulemaking.
We are finalizing our proposal that the Electronic Prior Authorization measure will not be
assigned points for the CY 2027 performance period/2029 MIPS payment year for MIPS eligible clinicians, and the CY 2027 EHR reporting period for eligible hospitals and CAHs. Instead, if a
MIPS eligible clinician, eligible hospital, or CAH fails to reportthe measure as specified, they
would not meet the minimum reporting requirements, not be considered a meaningful EHR user,
and fail the Medicare Promoting Interoperability Program or the MIPS Promoting
Interoperability performance category. A failure to meet the minimum reporting requirements of
the Medicare Promoting Interoperability Program would result in a downward payment
adjustment for eligible hospitals or CAHs (unless the eligible hospital or CAH receives a
hardship exception). A failure in the Promoting Interoperability performance category would
result in the MIPS eligible clinician receiving a score of zero for the performance category,
which is currently worth 25 percent of their final score for MIPS.
For the MIPS Promoting Interoperability performance category, satisfactory performance
on this measure can be demonstrated only by reporting a yes response on the attestation or
claiming an applicable exclusion. A no response on the attestation will result in the MIPS
eligible clinician failing to meet the minimum reporting requirements, therefore not being
considered a meaningful EHR user for MIPS, as set forth in section 1848(o)(2)(A) of the Act and
defined at 42 CFR 414.1305, for the MIPS payment year (42 CFR 414.1305). MIPS eligible
clinicians that do not report a yes response or claim an applicable exclusion for the Electronic
Prior Authorization measure as specified (that is, they do not submit the measure or claim an
exclusion or report a no response) will not earn a score for the MIPS Promoting
Interoperability performance category (a score of zero for the category). A MIPS eligible
clinicians score in the Promoting Interoperability performance category is generally worth 25
percent of their total final score for MIPS (42 CFR 414.1375(a); 414.1380(c)(1)). We note that to
report a yes, the action of the measure must occur during the selected performance period173 or
EHR reporting period,174 as per the measure specification defined below.
173See42CFR414.1320.
174See42CFR495.40(b)(2)(i). For the Medicare Promoting Interoperability Program, only a yes response on the
attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this
measure. A no response will result in the eligible hospital or CAH failing to meet the measure,
and therefore failing to meet minimum program reporting requirements, thus not being
considered a meaningful EHR user for an EHR reporting period, as defined in section 1886(n)(3)
of the Act.175 Eligible hospitals and CAHs that do notmeet the minimum program requirements
are subject to a downward payment adjustment (unless the eligible hospital or CAH receives a
hardship exception).
175See42CFR495.4and495.24(f)(1)(i)(A). G. Interoperability Standards for APIs
1. Background
In the CMS Interoperability and Patient Access final rule(85 FR 25510), we finalized a
requirement to implement, maintain, and use API technology conformant with the API technical
standards at 45 CFR 170.215, which at the time included (85 FR 25521):
 Health Level Seven (HL7) FastHealthcare Interoperability Resources (FHIR) Release
4.0.1
 HL7 FHIR US Core Implementation Guide (IG) Standard for Trial Use (STU) 3.1.1
 HL7 SMART Application Launch Framework IG Release 1.0.0, including mandatory
support for the SMART Core Capabilities
 FHIR Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1), including mandatory support
for the group-export OperationDefinition
 OpenID Connect Core 1.0, incorporating errata set 1
When we finalized the requirement for conformance with the specifications at 45 CFR
170.215 in the CMS Interoperability and Patient Access final rule, we required impacted payers
to comply with all standards at 45 CFR 170.215 for each of the APIs finalized in that rule.
However, we understand that the existing requirements for payers to use API technology
conformant with 45 CFR 170.215 (85 CFR 25632) for each API may introduce confusion to the
compliance requirements, because not all the standards at 45 CFR 170.215 may be applicable for
each specific API.176
Accordingly, to provide clarity, in the CMS Interoperability and Prior Authorization
proposed rule, we outlined modifications to be more specific regarding which standards at 45
CFR 170.215 are applicable to each API (87 FR 76314-21). Specifically, instead of the existing
requirements to use API technology conformant with 45 CFR 170.215, we proposed that each
176See42CFR422.119(Accesstoandexchangeofhealthdataandplaninformation),431.60(Beneficiaryaccessto
andexchangeofdata),and457.730(Beneficiaryaccesstoexchangeofdata)and45CFR156.221(Accesstoand
exchangeofhealthdataandplaninformation). standard at 45 CFR 170.215 would apply to a given setof APIs. The specific CFR citations were
listed in Table 8 of the proposed rule (87 FR 76318). We are now finalizing those requirements,
with modifications to some of the specific API requirements. We are finalizing that impacted
payers will only be required to use those specifications at 45 CFR 170.215 that are listed in Table
H3 as necessary for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and
Prior Authorization APIs. We are also finalizing our proposal to allow impacted payers to use
updated standards, specifications, or IGs for each of these APIs. Finally, we are reiterating our
recommendations to use the IGs listed in Table H3. We discuss these policies in detail elsewhere
in the final rule.
2. Modifications to Required Standards for APIs
We proposed specific standards at 45 CFR 170.215 that would apply to each API. In the
proposed rule, we listed the standards applicable to each API in Table 10 (87 FR 76320). Since
the publication of the CMS Interoperability and Prior Authorization proposed rule, ONC has
published the HTI-1 final rule which reorganized the structure of 45 CFR 170.215 to delineate
the purpose and scope more clearly for each type of standard or implementation specification (89
FR 1283). We note that the HTI-1 final rule adopted updated versions of several standards at 45
CFR 170.215, which now includes:
 Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) Release
4.0.1 at 45 CFR 170.215(a)(1) (HL7 FHIR);
 HL7 FHIR US Core IG Standard for Trial Use (STU) 3.1.1, which expires on
January 1, 2026, at 45 CFR 170.215(b)(1)(i);
 HL7 FHIR US Core IG STU 6.1.0 at 45 CFR 170.215(b)(1)(ii) (US Core IG),
 HL7 SMART Application Launch Framework IG Release 1.0.0, which expires on
January 1, 2026, at 45 CFR 170.215(c)(1);
 HL7 SMART App Launch IG Release 2.0.0 at 45 CFR 170.215(c)(2) (SMART App
Launch IG);  FHIR Bulk Data Access (Flat FHIR) IG (v1.0.0: STU 1) at 45 CFR 170.215(d)(1)
(Bulk Data Access IG); and
 OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(e)(1)
(OpenID Connect Core).
We refer readers to the HTI-1 proposed and final rule for additional information (FR
1284 through 1295). The specific standards at 45 CFR 170.215 that we identified in our
proposed rule were restructured by HTI-1 and moved to new locations at 45 CFR 170.215. In
addition, in several cases ONC adopted new versions of the same standards proposed in the CMS
Interoperability and Prior Authorization proposed rule. Specifically, ONC finalized US Core IG
STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IGRelease 2.0.0 (at 45
CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU
3.1.1 (at 45 CFR 170.215(b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0 (at
45 CFR 170.215(c)(1)) to indicate when a version of a standard may no longer be used for the
ONC Health IT Certification Program. While we did not propose to require those updated
versions, we emphasize that impacted payers are permitted to use them based on our policy to
allow updated versions of required standards, as discussed. We intend to align with the updated
versions finalized at 45 CFR 170.215 through future rulemaking prior to our API compliance
dates.
We are finalizing our proposals to identify specific required standards at 45 CFR 170.215
that are applicable to each of the APIs, with modifications. The finalized requirements include
any additional mandatory support requirements listed, such as for both the SMART App Launch
IG at 45 CFR 170.215(c) and Bulk Data Access IG at 45 CFR 170.215(d). We are cross-
referencing the new locations for these standards at 45 CFR 170.215 finalized by ONC in the
HTI-1 final rule. Table H3 lists the required versions of each standard and their citation.
Throughout this preamble we refer to the current structure of 45 CFR 170.215 as updated by the
HTI-1 final rule. For the Patient Access API, we are finalizing the required standards as proposed with
modifications to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and
(c)(1). For the Provider Directory API, we are finalizing our proposal with modifications to
incorporate the expiration date ONC adopted at 45 CFR 170.215(b)(1)(i), and to remove the
SMART App Launch IG at 45 CFR 170.215(c)(1) and OpenID Connect Core at 45 CFR
170.215(e), which were erroneously included in the proposed rule. We refer readers to the
footnote in Table H3 for additional information. For the Provider Access API, we are finalizing
our proposal with the modification to not require OpenID Connect Core at 45 CFR 170.215(e)
and with modifications to incorporate the expiration dates ONC adopted at 45 CFR
170.215(b)(1)(i) and (c)(1). For the Payer-to-Payer API, we are finalizing our proposal with
modifications to not require the SMART App Launch IG at 45 CFR 170.215(c) and OpenID
Connect Core at 45 CFR 170.215(e), and to incorporate the expiration date ONC adopted at 45
CFR 170.215(b)(1)(i). For the Prior Authorization API, we are finalizing our proposal with
modifications to not require OpenID Connect Core at 45 CFR 170.215(e) and to incorporate
expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and (c)(1). Payers will be required to
comply with the applicable specifications that we have identified for the Patient Access, Provider
Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs as listed in Table H3.
The exact regulation text for each API will vary depending on which standards apply to that API.
These updates particularize the specifications at 45 CFR 170.215 that are required for each API.
We received comments on these proposals and discuss details of the modifications.
a. HL7 FHIR and Technical Readiness
Comment: Multiple commenters expressed support for CMSs proposal to specify
technical standards for each API and recommended that CMS finalize the proposal. A
commenter expressed appreciation for CMSs efforts to explain the technical requirements for
each API and agreed with the proposal to add more specific language regarding which standards
apply to which API. Multiple commenters also supported CMSs proposalto require payers to use the FHIR
standard to facilitate information exchange and promote interoperability. Multiple commenters
stated that FHIR APIs help connect patients, providers, and payers to the correct information. A
commenter stated that FHIR-based standards maximize the chance for innovation and the
proposed revision provides technical clarity to payers. Another commenter stated that utilizing
the FHIR standard continues to advance the use of transparent, widely available standards and
helps to facilitate electronic information exchange, while another stated that the FHIR-based IGs
support the provider team's workflow and enable them to better understand patient-specific
benefits.
Response: We appreciate commenters support for using the FHIR standard and FHIR
APIs to improve information exchange and agree with the commenters assessments that these
will advance interoperability.
Comment: Multiple commenters expressed concern about mandating the FHIR standard.
Multiple commenters expressed concern regarding the maturity of the proposed standards,
specifications, and recommended IGs. Multiple commenters stated that it would be inadvisable
to specify technical requirements at this time given that the technical standards and IGs have not
fully matured. Multiple commenters recommended that CMS, along with ONC, take steps to
adequately and inclusively develop technical standards and relevantIGs to full maturity as a
baseline of industry consistency, ensuring standards are tested and transparently evaluated prior
to mandated adoption. Another commenter encouraged CMS to maintain flexibility in the
agencys ongoing data exchange activities to ensure the success of interoperability programs.
Another commenter urged CMS to ensure careful consideration of what technical standards to
require in the future. Another commenter suggested that requiring all entities to use the FHIR
standard may be burdensome. The commenter stated that CMS has not proposed any alternatives
and that adoption of the FHIR standard may not be feasible for small entities and asked questions
such as what will happen if small businesses are not able to convert to FHIR. A commenter cautioned CMS not to view the FHIR standard as the sole solution to
interoperability and patient data exchange challenges. The commenter noted that as currently
proposed, the Patient Access API would experience challenges if the FHIR standard failed to
reach widespread adoption and maturity. A commenter stated that the HL7 Da Vinci IGs that
support the Patient Access API have not yet reached sufficient maturity for widespread adoption.
The commenter stated that using the FHIR standard, agnostic of a particular IG, will give
industry stakeholders greater flexibility to pilot different approaches and build consensus without
the risk of distortions that could result from mandatory adoption of immature specifications.
Response: We thank commenters for providing their thoughts regarding the FHIR
standard. However, we disagree that FHIR is not mature. The primary components of the FHIR
standard are mature, as are the standards we are requiring in this rule, such as the US Core IG.
We acknowledge that the FHIR resource profiles included in the IGs we recommend are of
varying levels of maturity, but we believe they are sufficiently mature for industry to start
implementing them. We refer readers to our discussion on IG maturity in section II.G.3.b. of this
final rule.The FHIR standard will help move the health care industry toward a more
interoperable state, and we believe that it supports transmission of health data in a standard,
structured, but flexible format as FHIR specifications continue to advance and mature. HHS has
already adopted standards for FHIR APIs at 45 CFR 170.215, as finalized in the ONC Cures Act
final rule, and therefore we did not propose any alternatives (85 FR 25521). We disagree that the
HL7 Da Vinci IGs that support the Patient Access API have not yet reached sufficient maturity
for widespread adoption as they have already been successfully implemented and are being used
today. Since 2021 impacted payers have been required to implement and maintain a standards-
based Patient Access API that uses FHIR and other technical standards at 45 CFR 170.215, as
finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558). We are
delaying the compliance date for policies that require API enhancement or development to 2027,
which will allow additional time for the recommended FHIR IGs to be refined to support the policies in this final rule. We believe the adoption of the FHIR standard is feasible for all the
APIs finalized in this rule, especially with the additional implementation time.
Comment: Multiple commenters appreciated CMSs efforts to move industry towards
interoperability and expressed support for CMSs proposals to promote electronic data exchange
among patients, providers, and payers via APIs leveraging technical standards and IGs. Multiple
commenters supported using FHIR-based standards to facilitate data transport across the industry
and that FHIR-based exchange is technically feasible for both payers and providers to adopt and
implement. A commenter stated that the FHIR standard and IGs promote a level of consistency
in terms of format, structure,and vocabulary, as well as allow for a variety of interoperability
paradigms that best suit the interaction requirements between providers, payers, and patients. A
commenter supported using USCDI data classes and data elements in addition to claims and
encounter data when exchanging patient information.
Multiple commenters expressed support for CMSs proposals to use standards-based
APIs and stated that the industry-wide adoption of uniform standards will help enhance
interoperability and minimize complexity. Multiple commenters stated that having an established
technical infrastructure to support the development and adoption of the new APIs outlined in this
rule is crucial to prevent added administration burden, complexity, and variability in
implementation.
Response: We agree with the commenters assessments and thank them for their support
of our policies.
Comment: A commenter requested that CMS define a more prescriptive designated data
set for claims and encounter data akin to USCDI. The commenter continued by stating that CMS
should explicitly call out the Common Payer Consumer Data Set (CPCDS), which would ensure
a more uniform implementation and ensure that patients, providers, and payers can use those
capabilities in a way that the rule intended. Another commenter suggested a realignment of the purpose and use of USCDI as a library of data types, classes, and specifications from which
interoperability requirements can be drawn.
Response: While altering the design and structure of the USCDI are out of scope for this
rule, we will continue to work with ONC to expand and build upon the USCDI. For instance, we
have worked with ONC on the USCDI+ initiative, which aims to harmonize data sets that extend
beyond the USCDI for additional use cases. While USCDI is one category of data required to be
exchanged via the APIs, we understand that the USCDI is limited in scope and that additional
data and standards will be necessary to implement these APIs. For instance, the recommended
HL7 FHIR CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue
Button) (87 FR 76316), which was itself informed by and includes mappings to CPCDS.
Comment: A commenter noted that the implementation of the APIs is contingent on
compliant technical solutions being available in the marketplace. Another commenter stated that
the lack of specificity in API requirements gives payers significant latitude to determine what
data elements they want to include in their APIs and under what circumstances, which will not
promote widespread interoperability. Another commenter stated that technical standardization
and payer participation are the only ways that these proposals could be effective. The commenter
stated if the responsibility is not shared across stakeholders,CMS will simply shift more burden
onto providers. Another commenter stated that variance in API implementation could require
providers to need significant assistance from health IT vendors to navigate these systems, which
would eliminate any efficiencies CMS expected to derive from the new interoperability
requirements. Another commenter noted a frequent problem with the implementation of
technical processes is variation from system-to-system and interpretation differences since
guidance is not universally communicated to developers who need the information. Similarly, a
commenter noted that these technical API standards may require providers to hire additional staff
to implement them. Response: The industry already has significant adoption of the FHIR standard for several
use cases and there are solutions available today to FHIR-enable existing systems. Additionally,
many of the IGs recommended in this rule have already been implemented by multiple
implementers at some level. We anticipate more solutions will be available in the marketplace
ahead of the API compliance dates in 2027. We acknowledge that using marketplace technical
solutions may ease implementation. We understand that there is still a learning curve with
respect to the FHIR-based standards and IGs and that entities may need to hire and train staff.
We appreciate these perspectives and acknowledge that standards are what promote
interoperability. The adoption of the FHIR standard and the IGs promote interoperability by
enabling the secure exchange of health information across disparate systems. The FHIR APIs
provide the framework for this exchange. Regarding concerns for the lack of specificity in the
API requirements, we acknowledge that we are only recommending rather than requiring several
IGs because they continue to evolve and are not adopted by HHS at 45 CFR 170.215. As these
IGs continue to mature, we will consider proposing to require them through future rulemaking.
The IGs provide the exchange of the essential data elements, such as patient demographics,
clinical information, prior authorization requests, and other data to ensure the necessary
information is shared between payers and providers. We acknowledge that implementation and
testing will take time and welcome ongoing feedback through the programs and standards
workgroups.
Comment: Multiple commenters expressed concern regarding the proposed technical
standards and IG provisions outlined in the proposed rule. Multiple commenters noted that
technical challenges around health information exchange could persist despite these proposals
and that the technical standards lack the specificity and flexibility to properly support the
interoperable exchange of data.
Response: We received many comments regarding our approach in the proposed rule of
recommending, rather than requiring, specific IGs. We believe that this approach optimally balances the need for us to provide directional guidance without locking implementers into the
versions of the recommended IGs that were available at the time of the proposed rule. As these
IGs mature, industry can continue to harmonize on common approaches that work, eventually
culminating in a required set of specifications, which, when ready, could be proposed through
future CMS rulemaking. If we chose not to recommend specific IGs, this lack of direction would
mean a more diverse setof proprietary solutions, resulting in little to no interoperability.
Comment: A commenter stated that there is transformative effort and overall risk in
requiring the Patient Access,Provider Access, and Payer-to-Payer APIs to be implemented
around the same time. A commenter noted that the attachments standard is not mature and that
could hinder non-structured data exchange such as in CMSs proposals to require prior
authorization documentation in the Patient Access, Provider Access, and Payer-to-Payer APIs.
The commenter noted there is a risk in needing necessary endpoint connections and the
functionality to convert documents between FHIR exchanges to be established by payers,
providers, and health IT vendors for the purpose of data exchange. The commenter
recommended that CMS first require the APIs and then add the exchange of attachments a few
years later.
Response: For the Patient Access, Provider Access, and Payer-to-Payer APIs, we are
requiring impacted payers to share claims and encounter data, all data classes and data elements
included in a content standard at 45 CFR 170.213 (USCDI), and certain information about prior
authorizations. Many of the data classes and data elements are already required for the Patient
Access API, which means that payers have already formatted these data and prepared their
systems to share via a FHIR API. We thus believe that payers can concurrently implement the
APIs in this final rule.
We agree that standards for transmitting documentation and attachments via the FHIR
APIs are still under development and in testing, and thus not yet in widespread use across the
industry. Further, as elaborated in sections II.A. and II.B. of this final rule, we agree that the burden of requiring impacted payers to make unstructured documentation available via the
Patient Access and Provider Access APIs outweighs the benefits such documentation would
provide. However, as discussed in section II.C., for the Payer-to-Payer API we are finalizing a
requirement to exchange structured and unstructured administrative and clinical documentation
submitted by providers related to prior authorization requests and decisions.
Comment: Multiple commenters encouraged CMS to work with ONC to ensure relevant
technical standards and related IGs are sufficiently mature and reflect the proper content and
policies to allow seamless data transfers between payers and providers. Another commenter
urged CMS to work in partnership with ONC to establish a clear pathway for the required IGs
including: (1) the ability to advance IG versions outside the regulatory cycle; (2) adequate time
for industry to understand and adopt new IG versions; and (3) limiting options, so as not to
disrupt interoperability.
Response: As previously mentioned in this section, the primary components of the FHIR
standard are mature, as are the standards we are requiring in this rule. We acknowledge that the
FHIR resource profiles included in the IGs we recommend are of varying levels of maturity, we
believe they are sufficiently mature for industry to start implementing them. We refer readers to
our discussion on IG maturity in section II.G.3.b. of this final rule. We will continue to closely
coordinate our policies with ONC to ensure that they are mutually reinforcing. We are also
finalizing our proposal to allow payers to use updated standards, specifications, or IGs for each
API, as long as certain conditions are met, including that the updated version does not disrupt an
end users ability access the data required for that API.
Comment: A few commenters shared concerns with the lack of a mandatory testing
system, as well as lack of available test data, staging environments, sandboxes, and other
mechanisms to help developers test their APIs. A commenter suggested CMS conduct usage
validity testing of the payers APIs throughout the development and deployment process of the
APIs to track and mitigate any risks associated with missing or incorrect data. The commenter requested that CMS delay the enforcement timeline to accommodate these critical prerequisites.
Likewise, another commenter recommended that CMS postpone publication of the final rule
until it can require both the technical standards and IGs to prevent non-standard implementation
across the industry. The commenter recommended that CMS work with the HL7 Da Vinci
workgroup and ONC to ensure the APIs and associated standards are tested for complex use
cases and to scale. Another commenter recommended CMS define or promote conformity to the
ONC Inferno Framework. Another commenter recommended that CMS should establish a
mandatory testing system like the ONC Cypress testing tool for the proposed APIs and data
standards requirements.
Multiple commenters noted that testing should be conducted in a variety of clinical
settings, including small, independent, and rural practices, and with all end users to ensure that
the technical standards and IGs are effective, adaptable, and efficient. A commenter highlighted
that it is critical that any solution be fully developed and tested prior to wide-scale industry
rollout and required usage to ensure the best return on the investment of industry resources. The
commenter stated that this process should include careful consideration of the transactions
scalability, privacy guardrails, and ability to complete administrative tasks in a real-world
setting. Other commenters recommended that CMS establish additional pilot testing programs to
ensure industry readiness before the compliance dates.
Response: We agree that testing is an important part of the implementation process and
will continue to support industry efforts to do so, including coordinating with ONC and HL7,
including the DaVinci Accelerator, on such efforts. We will also continue to engage with ONC
to determine whether the Inferno Framework177 could be utilized in the future. HL7s IG testing
process includes privacy and security testing. Also, FAST,178 which is an initiative started by
177OfficeoftheNationalCoordinatorforHealthInformationTechnology(n.d.).Inferno.Retrievedfrom
https://inferno.healthit.gov/.
178HealthLevelSevenInternational(2023,October13).FHIRatScaleTaskforce(FAST).Retrievedfrom
https://confluence.hl7.org/display/FAST. ONC, identifies FHIR scalability gaps, defines solutions to address current barriers, and
identifies needed infrastructure for scalable FHIR solutions. Real-world testing can only be
accomplished if payers choose to pilot an implementation during the testing phase, which CMS
cannot require participation in. However, we are not delaying publication of this final rule, as we
understand that industry requires a firm commitment from the Federal Government to the
adoption and recommendation of standards. Based on comments received, and as discussed
throughout this final rule, we are delaying the compliance dates for all the policies that require
API developmentand enhancement to 2027, which will allow additional time for FHIR
specifications to continue to be refined and advanced to support the policies in this final rule.
We also appreciate the multiple comments received on the importance of testing and the
provision of examples, such as the ONC Cypress testing tool, which is an open-source tool used
in the ONC Health IT Certification Program to ensure certified health IT accurately calculates
electronic clinical quality measures (eCQMs). We will continue to collaborate with ONC and
DaVinci on testing the APIs and with HL7 on communication and outreach to payers,
developers, and providers.
Comment: Multiple commenters urged CMS to closely track and participate in the
standards development process to ensure that all perspectives are considered, such as providers,
payers, and other applicable end users. Multiple other commenters urged CMS and ONC to
provide funding to HL7 FHIR Accelerators and task forces. A commenter expressed their desire
for CMS to increase opportunities for greater stakeholder participation in the standards
development process. Another commenter recommended that CMS release a formal assessment
of the status of technology development in support of the new requirements to demonstrate that
the technology is fully developed and implementable.
Response: We are an active participant in the standards developmentprocess through
various workgroups and FHIR Accelerators. A few of the recommended IGs have been
developed by HL7 FHIR Accelerator programs, which bring together individuals across the industry to create and adopt IGs in alignment with HL7, which allows new and revised
requirements to become open industry standards. Under HL7 FHIR Accelerators, interested
parties within the industry have defined, designed,and created use-case-specific implementations
of FHIR to address value-based care initiatives. Some HL7 FHIR Accelerators, such as Da Vinci
and CARIN, have created IGs that we recommend be used for the Patient Access, Provider
Directory, Provider Access, Payer-to-Payer, and Prior Authorization APIs. We also provide
contract support to supplement existing work led by the SDOs and FHIR Accelerators. Further,
we cohost an annual FHIR Connectathon testing event with HL7 and encourage diverse
stakeholder participation from payers, providers and patient advocates. HL7 has developed a
FHIR Maturity Model (FMM)179 that defines thresholds of standards maturity as part of their
standards development and publication process. HL7 requires a specific maturity level for parts
of the standards development and publication process. We also note that ONC publishes an
Interoperability Standards Assessment (ISA).180 The latest published 2023 version provides
information on the HL7 standards that are required or recommended in this rule.
Comment: A commenter urged CMS to pay close attention to principles that focus on
assessing provider impact, measuring success in achieving stated goals, and monitoring
standards development and use. The commenter stated that these principles can help guide CMS
and developers to better respond to provider needs. Another commenter urged CMS to ensure
that the technical standards meet provider and patient needs and accurately embody CMSs goals
to improve care and reduce provider burden.
Response: We will continue to assess standards development and use as an active
participant in the HL7 community and FHIR workgroups. We also encourage stakeholders to
179HealthLevelSevenInternational(n.d.).VersionManagementPolicy.Retrievedfrom
http://hl7.org/fhir/R4/versions.html#maturity.
180OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023).2023InteroperabilityStandards
AdvisoryRetrievedfromhttps://www.healthit.gov/sites/isa/files/inline-
files/2023%20ReferenceM.A20Edition_ISA_508.pdf. participate and contribute to the work of the SDOs in the standards development and evolution,
because broad engagement would support the improvement of interoperable standards.
Comment: A commenter recommended continued Federal support of ongoing standards
development and data interoperability work, including financial and technical support, for SDOs
such as the HL7 Da Vinci Workgroup, FAST, and other applicable workgroups. Some
commenters encouraged CMS to advance the FAST initiatives to address the ongoing challenges
of patient matching, identity management, security and authentication, and access to the
necessary digital endpoints. Another commenter expressed support for incentives and investment
in FHIR-based pilots and technology, stating that this would move the industry towards FHIR
APIs for real-time information exchange.
Response: We agree and intend to continue our support for and participation in various
standards development activities. As noted previously, we provide contract support to
supplement existing work led by the SDOs and FHIR Accelerators. We believe that the policies
that we are finalizing are a crucial step in moving the industry towards real-time information
exchange.
Comment: A commenter stated that to assist providers in making informed decisions,
CMS should apply the same discrete data element standards the agency applied to the original
Patient Access API to the new prior authorization data added to the Patient Access, Provider
Access, and Payer-to-Payer APIs. Another commenter requested that CMS consider
synchronizing the required technical standards for those three APIs given that the APIs are
functionally identical. The commenter stated that having a single standardized API for the three
different access types (patient, provider, and payer) would provide three key benefits: (1)
simplifies the technical approach for initial rollout and any future changes; (2) allows Medicaid
programs to focus on challenges that these APIs pose; and (3) reduces end user confusion since
end users will see the same data shared through the APIs. A commenter requested that CMS
continue to standardize and harmonize API requirements to reduce potential burden for providers and confusion for consumers. Another commenter stated that these requirements should be
consistent across all stakeholders.
Response: Each of the APIs in this rule will require sharing only structured
documentation, except for the Payer-to-Payer API, which includes unstructured administrative
and clinical documentation submitted by a provider to support a prior authorization request. We
intentionally based the requirements for the Provider Access and Payer-to-Payer APIs on the
content requirements for the Patient Access API, to facilitate reuse, since payers have already
formatted these data elements and prepared their systems to share these standardized data via a
FHIR API. Payers already devoted the development resources to build a FHIR API infrastructure
when they implemented the Patient Access API, which can be adapted for additional
interoperability use cases. While the data we are requiring to be shared via these APIs would be
nearly identical, they have different use cases, thus necessitating separate API regulatory
requirements. We also encourage payers to reuse infrastructure for all the APIs. Payers may
implement the API functionality by using one or multiple APIs, depending on their approach, as
long as all requirements are met for each of the APIs.
Comment: Multiple commenters recommended that CMS align the technical standards
provisions outlined in this rule with the HIPAA Standards for Health Care Attachments proposed
rule (87 FR 78438). A commenter recommended that CMS work with ONC to do so. Another
commenter stated that they support both rules and urged CMS to ensure that there are no
duplicative efforts. Another commenter recommended removing the prior authorization
provisions outlined in the HIPAA Standards for Health Care Attachments proposed rule and
moving forward with finalizing FHIR-based standards and transactions. Another commenter
encouraged CMS to work with ONC to align any prior authorization proposals with HHSs
proposal to establish a national standard for electronic attachments.
Response: Requirements to use certain HIPAA transaction standards for prior
authorization were proposed in the HIPAA Standards for Health Care Attachments proposed rule. These are related policies, and we will ensure a path toward implementation that will allow
payers and providers to comply with both. However,because that rule has not been finalized, we
cannot comment on how the standards would align with the policies in this rule. If finalized, in
that final rule we would discuss the impact of those policies and any opportunities to align with
our policies in this final rule. We will also continue to work with ONC on alignment between
standards in this rule, and other standards adopted across CMS.
Comment: Multiple commenters recommended that CMS institute financial incentives for
market suppliers, providers, and payers to participate in the testing and development of technical
standards, IGs, and applicable processes. The commenter stated that one of the primary
challenges of standards development and testing is a lack of financial and regulatory incentives
for stakeholders to participate, which then slows down testing. Multiple commenters cautioned
CMS to consider the cost of establishing the proposed API infrastructure. Another commenter
noted that implementation will require integration between the newly acquired API functionality
and the existing data sources, which includes exporting data from current systems to be imported
and stored within a FHIR-compliant repository so that it can be presented via the API to the user.
Multiple commenters requested that CMS provide technical assistance and resources to help the
industry implement the APIs and meet allthe technical standards and requirements outlined in
this rule.Another commenter requested that CMS engage with stakeholders to develop resources
and technical assistance to help industry operationalize and meet the proposed technical
standards and API requirements outlined in the rule and any other parallel agency efforts.
Response: At this time, we lack statutory authority to provide financial incentives to
participate in the testing and development of technical standards, IGs, and applicable processes.
While we do not currently provide funding for IT infrastructure development costs (except for
Medicaid agencies, as discussed in section II.E. of this final rule), we do provide educational
webinars providing overviews of the technical requirements in the interoperability rules.
Additional public resources also exist through HL7, such as their Connectathons, HL7 website resources, and HL7 FHIR workgroup meetings that are generally available. We also cohost an
annual Connectathon with HL7, which is free for stakeholders to attend. Ultimately, each payer
is responsible for ensuring that their users are trained on their systems.
Comment: A commenter stated that a frequent problem is that there is not a well-
established or monitored mechanism for an implementer to contact a payer about implementation
issues or implementation questions. The commenter stated that this is an important missing piece
to making widespread implementation viable. The commenter reflected on the experience of
third-party apps engaging with payers to implement the existing Patient Access API. They stated
that third-party apps struggle with finding someone to fix issues, answer questions, approve their
registrations, and address other barriers to implementation they experienced.
Multiple commenters stated that to support the proposed APIs, provider and payer
endpoints must be included in a national directory, available to support endpoint discovery,
before the compliance dates of the Provider Access,Payer-to-Payer, and Prior Authorization
APIs. A commenter stated that a CMS NDH should be initiated to help find provider and payer
endpoints. Another commenter stated that the lack of an authoritative central directory could
create a significant gap in the ability for industry to move many critical interoperability
initiatives forward. Another commenter stated the proposed technical standards for APIs is a
helpful step to greater interoperability; however, CMS failed to properly account for the
complexity of this implementation. The commenter recommended that CMS should implement a
national directory so that each plan and provider must maintain only one incoming/outgoing
connection.
Response: We acknowledge commenter concerns that there is not a monitored
mechanism for contacting a payer about implementation issues or implementation questions. We
thank the commenters for their concern that the lack of an authoritative central directory is a gap
in the ability to move forward with interoperability initiatives. We do understand that a directory
of payer and provider digital endpoints would be highly beneficialto facilitate our Payer-to- Payer, Provider Access, and Prior Authorization APIs policies, and as discussed in section I.D.
of this final rule we are committing to exploring an NDH that contains payers digital endpoints
in support of the Payer-to-Payer API and providers digital endpoints. We will also explore
including payer contact information, including whom to contact regarding API implementation
issues or questions, in any NDH we propose.
Comment: A commenter stated that adding standard data classes and data elements
around high-priority use cases is an effective strategy to make data more accessible to
consumers. The commenter noted that the Provider Directory and Patient Access APIs can serve
as a base for the other proposed APIs. The commenter provided recommendations to help CMS
achieve this goal such as establishing operational standards to help developers, requiring payers
to register app developers and grant authorization to production access without regard to out-of-
band consent standards payers choose to implement, and establishing stronger requirements for
payers to make this information available. The commenter also recommended that (1) CMS
require impacted payers to establish sandbox environments; (2) CMS impose a reasonable time
standard to mitigate implementation delays; (3) CMS require impacted payers to perform
conformance tests and report results to the public; and (4) CMS require that impacted payers
technical documentation for the Patient Access API notes what USCDI data are made available.
Another commenter recommended thatCMS should develop a roadmap in partnership with the
private sector for all the technical use cases outlined in the proposed rule.
Response: We appreciate the additional suggestions, however, many of those were not
proposed and therefore, we cannot include such provisions in the final rule. We also understand
the value of a sandbox environment and acknowledge the value of payers establishing sandbox
environments for implementers to test; however, we realize there are industry costs to doing so.
Comment: Multiple commenters encouraged CMS to consider alternative approaches to
achieving data exchange. A commenter recommended that CMS consider other types of
interoperability technology beyond APIs and request/response data exchange, which can lead to multiple copies of data. The commenter suggested CMS consider services that provide virtual
real-time data updates. Another commenter recommended that CMS work with ONC to develop
a future-looking approach to allow consumers to direct the sharing of claims data with third-
party entities via a national exchange platform. A commenter recommended that CMS, ONC,
and HL7 work together to build the infrastructure for a standard for ADT data.
Response: While we appreciate the commenters who asked us toconsider services that
provide virtual real-time data updates and we recognize the importance of needing the patient
information as soon as possible or in real time, we also believe thatrequiring that at this time
would cause undue burden on impacted payers. We nonetheless encourage payers to make data
available to requesting providers as soon as they are able.We understand the concern over
duplicative information, and it is not our intention to increase provider burden sharing data
through the APIs referenced in this final rule. There are IT solutions available for providers
EHRs or practice management systems, such as SMART on FHIR apps, which can make the
data received via the APIs actionable and avoid duplicative information. We also note that
standards for ADT data are outside the scope of this final rule.
Comment: A commenter highlighted that health IT challenges can sometimes be larger
than they appear. The commenter stated that regulatory requirements can be tailored to coincide
with health IT functionalities that are currently available to support organizations in
accomplishing interoperability in a more affordable way.
Response: We thank the commenter for their input and will continue to closely
coordinate with industry to decrease implementation burden wherever possible.
Comment: A commenter urged CMS not to finalize the interoperability proposals until
stakeholders have had a chance to review and comment on ONCs HTI-1 proposed rule, which
was still under review at the Office of Management and Budget (OMB) at the time of publication
of the CMS Interoperability and Prior Authorization proposed rule. Response: We recognize that commenters are interested in ONC policies that relate to the
policies in the proposed rule. ONC has since published the HTI-1 final rule. While related, these
rules address separate areas of CMS and ONC authority. We are not finalizing any modifications
from the proposed rule based on HTI-1 other than updating our regulatory citations and
incorporating expiration dates ONC has finalized for particular standards at 45 CFR 170.215.
Therefore, we did not offer an additional comment period.
Comment: Multiple commenters expressed appreciation for CMS not requiring health IT
certification for the interoperability requirements outlined in this proposed rule. A commenter
stated that establishing certification criteria based on the current HL7 Da Vinci IGs is premature.
The commenter noted that providers must use data from CEHRT for the electronic prior
authorization measure, which will serve as a spur for adoption of certified health IT. Another
commenter noted that some of the proposed APIs require multiple health IT systems to interact
and support a complex workflow and stated that establishing a certification approach using
functional capabilities would be challenging, and encouraged CMS to engage with providers and
payers to gather information to establish a well-defined and scalable set of guidelines and
capabilities.
Opposite to that, a commenter recommended that CMS work with ONC to incorporate
new standards and requirements for API use by EHR vendors as certification criteria in the ONC
Health IT Certification Program.
Response: We did not propose and are not finalizing any other requirements related to
certification under the ONC Health IT Certification Program in this finalrule. However, we note
that the Unified Agenda, at the time of this final rules publication, includes an entry for a
proposed rule from ONC (RIN 0955-AA06).181 The description indicates that that proposed rule
aims to advance interoperability, including proposals to expand the use of certified APIs for
181OfficeofInformationandRegulatoryAffairs(n.d.).HealthData,Technology,andInteroperability:Patient
Engagement,InformationSharing,andPublicHealthInteroperability.Retrievedfrom
https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202304&RIN=0955-AA06. electronic prior authorization. We plan to continue to explore how potential updates to the ONC
Health IT Certification Program could support our policies and will address any updates to our
requirements related to the Certification Program in future rulemaking.
Comment: A commenter recommended that CMS should establish a consistent set of
technical standards between the TEFCA and CMS-required APIs so that the industry does not
have to implement multiple different standards depending upon the exchange partner or
mechanism for exchange.
Response: We refer readers to section II.B. of this final rule for a discussion on the
interaction between policies that require API development or enhancement and TEFCA.
Comment: A commenter recommended CMS consider a policy requiring third-party
payers, benefit managers, and any other party conducting utilization management to accept and
respond to standard electronic prior authorization transactions forpharmacy benefits that use a
nationally recognized format, such as the NCPDP SCRIPT standard. Similarly, another
commenter stated that CMS should encourage health IT vendors and developers to provide retail
pharmacies with technical IT infrastructure to bridge the gap between pharmacy claim systems
and medical benefit claims systems and noted that many retail pharmacies only utilize the
NCPDP standards and do not have the capability to enroll as DME suppliers and submit claims
using X12 transactions. Another commenter recommended that CMS explore the need to
designate an electronic transaction standard for drugs covered under a medical benefit.
Response: We appreciate stakeholders interest in pharmacy standards and bridging the
gap between pharmacy and medical benefit systems and we recognize the need to do so in the
future. However, as noted in section I.D.3., standards for data exchange for any pharmacy claims
and drugs covered under medical benefits are excluded from our policies and out of scope for
this rule.
Comment: A commenter stated that under the ONC Health IT Certification Program,
APIs must be registered within 15 days (45 CFR 170.315(g)(10)). However, the commenter stated that CMS did not impose any registration requirements for the proposed payer APIs. The
commenter recommended that CMS should consider imposing a reasonable registration period
for APIs to address delays reported by CARIN members throughout the onboarding and
authorization process to acquire test accounts, sandbox access to test API connections, and
troubleshooting support.
Response: We did not propose registration deadlines as a requirement for payer APIs in
the same fashion as the health IT certification criterion at 45 CFR 170.315(g)(10), such that
Health IT Modules certified to 45 CFR 170.315(g)(10) must register patient-facing applications
within 15 days (per associated requirements at 45 CFR 170.404(b)); however, we acknowledge
that such requirements can help to support the usability of APIs. We may further explore how to
incorporate registration deadlines into our API requirements in future rulemaking.
Comment: A commenter recommended setting an implementation date before January 1,
2026, and mandating HL7 FHIR Release 4.0.1. The commenter also recommended operational
enhancements for payers such as payers allowing longer lifespans on access tokens, payers not
imposing unsupported security and authentication workflows, and payers supporting test
accounts and synthetic data in production environments. The commenter noted that these
recommendations would dramatically improve access to data from available open APIs while
setting standards for payers and theirinteroperability vendors to follow.
Response: HL7 FHIR Release 4.0.1 has already been adopted by HHS in the ONC Cures
Act finalrule at 45 CFR 170.215 (85 FR 25521). We will continue to work with payers on
testing and implementation of their interoperability APIs through FHIR Connectathons and
encourage stakeholders to participate in FHIR workgroups. We will explore additional
enhancements through future rulemaking.
Comment: A commenter recommended using the most recently approved HL7 Da Vinci
IG that supports HL7 FHIR Release 4.0.1. The commenter stated that the SMART App Launch
IG does not support HL7 FHIR Release 4.0.1. Response: We thank the commenter for their recommendation, but we disagree that the
SMART App Launch IG does not support HL7 FHIR Release 4.0.1, as the SMART App Launch
IG is built on top of the FHIR Release 4.0.1 specification itself. The SMART App Launch IG
specifies a number of capabilities, including user authentication and authorization, back-end
service authentication, application launch, and context sharing,that systems can use to interact
within the FHIR R4 standard.
Comment: A commenter sought clarification on the use case for the Bulk Data Access IG
for the Patient Access API, since one of the biggest challenges for EHR vendors today is
determining how to handle inbound data exchanged via the FHIR standard.
Response: We did not propose, nor are we finalizing, a requirement to require the Bulk
Data Access IG for the Patient Access API.
b. Additional Implementation Guide Discussion
In the proposed rule, we discussed that several of the recommended IGs, such as HL7
FHIR Da Vinci Payer Data Exchange (PDex) IG, build on specific profiles within the US Core
IG (87 FR 7615). Following the publication of the HTI-1 final rule, at 45 CFR 170.215(b)(1)
there are two adopted versions of the US Core IG: the US Core IG STU 3.1.1 (at45 CFR
170.215(b)(1)(i)), until this standard expires on January 1, 2026, and the US Core IG STU 6.1.0
(at 45 CFR 170.215(b)(1)(ii)). We only proposed to require US Core STU 3.1.1 because it was
the only version adopted at the time of the proposed rule. However, we recognize that some of
the recommended IGs (and subsequent versions) may use profiles added in US Core IG STU
6.1.0. Payers can use updated versions of the recommended IGs that rely on newer versions of
the US Core IG, if those updated versions meet our existing requirements finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25532), as discussed further below.
Specifically, in the proposed rule, we recognized that the data content for each API may
only require a subset of the profiles defined within the US Core IG and gave examples (87 FR
76314-76315). While we want to ensure that implementers systems create FHIR resources conformant to the US Core IG, where applicable, to support interoperability across
implementations, we also do not want to require payers to engage in unnecessary development.
Therefore, we proposed and are finalizing that impacted payers are only required to use
technology conformant with the US Core IG, where applicable (that is, where there is a
corresponding FHIR resource to the data content requirements for the API). If a FHIR resource is
part of the required data content and has been profiled by the US Core IG, then the payer must
support the FHIR resource according to the FHIR resource profiles Structure Definition in the
US Core IG. For example, because the Patient FHIR resource is required in the Patient Access
API, the Patient FHIR resource must conform with the US Core Patient Profile, including all
the mandatory and must support requirements specified in the US Core IG.
c. Using Updated Versions of Required Standards
In the CMS Interoperability and Patient Access final rule (85 FR 25510), we established
that impacted payers could use an updated version of a required standard for the Patient Access
or Provider Directory APIs under certain conditions. Payers may use updated versions of
standards at 45 CFR 170.213 and 170.215 if the following conditions are met: (1) the National
Coordinator has approved the updated version for use in the ONC Health IT Certification
Program, (2) the updated version of the standard does not disrupt an end users ability to access
the required data via that API, and (3) the updated standard is not prohibited by law (85 FR
25522). Payers may use an updated version if required by other applicable law. We proposed to
extend this policy to allow payers to use updated versions of a standard to the Provider Access,
Payer-to-Payer, and Prior Authorization APIs. Under that proposal, impacted payers could
upgrade to newer versions of the required standards, subject to those limiting conditions (87 FR
76315).
One of those conditions for using updated versions of the standards at 45 CFR 170.213
and 170.215 is that the NationalCoordinator has approved the updated version for use in the
ONC Health IT Certification Program. The National Coordinator approves updated versions of standards in the ONC Health IT Certification Program through SVAP, pursuant to 45 CFR
170.555, which was finalized in the ONC Cures Act final rule as a Maintenance of Certification
flexibility included in the real-world testing Condition of Certification (85 FR 25775). This
flexibility permits health IT developers to voluntarily use, in certain certified Health IT Modules,
newer versions of adopted standards so long as specific conditions are met, providing a
predictable and timely approach within the ONC Health IT Certification Program to keep pace
with the industry's standards development efforts.
Under SVAP, after a standard has been adopted through notice and comment rulemaking,
ONC engages in an open and transparent process to timely ascertain whether a more recent
version of an adopted standard or implementation specification should be approved by the
National Coordinator for developers voluntary use in the ONC Health IT Certification Program.
ONC publishes updated versions of standards under consideration forSVAP and lists the
updated versions of standards that the National Coordinator has approved as part of the
Interoperability Standards Advisory on HealthIT.gov.182 Members of the public can use this
resource to review standards that may be approved through SVAP in the future, as well as
provide input on which updated versions should be approved. We encourage impacted payers to
review these resources to better understand how updated versions of the standards at 45 CFR
170.213 and 170.215 may be approved by the National Coordinator through SVAP and become
available for payers to use in their APIs, provided other specified conditions for using updated
standards are met. Several updated versions of the standards currently at 45 CFR 170.213 and
170.215 have been approved by the National Coordinator through SVAP,183 including USCDI v2
and v3; US Core IG STU 4.0.0, 5.0.1, and 6.1.0; SMART App Launch IG Release 2.0.0; and
Bulk Data Access IG v2.0.0: STU 2. As soon as the National Coordinator approves updated
182OfficeoftheNationalCoordinatorforHealthInformationTechnology(n.d.).SVAP.Retrievedfrom
https://www.healthit.gov/isa/standards-version-advancement-process.
183OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap. versions through SVAP, we consider the updated versions to have met this condition for use by
impacted payers for our API requirements. We emphasize that if impacted payers choose to use
updated standards, it must not disrupt an end users ability to access the required data. We are
finalizing this proposal, as proposed.
Comment: Multiple commenters expressed support for CMSs proposal to allow
flexibility for payers to use updated versions of certain standards and specifications required for
APIs in the proposed rule. A commenter expressed support for aligning standards between the
Patient Access, Provider Access, and Payer-to-Payer APIs, as this ensures data compatibility
between use cases. Another commenter stated that the standards and specifications at 45 CFR
170.215 are more advanced and better aligned with present efforts to streamline prior
authorization workflows by leveraging HL7's FAST work. Another commenter stated that these
standards support widespread interoperability, ease implementation, and minimize complexity
and costs. A commenter expressed strong support for CMS's efforts to promote portability of
patients' EHI between providers and payers to assure continuity of care by further building on the
common standards platform of FHIR APIs using USCDI, where applicable. Multiple
commenters expressed support for the continued alignment between CMS and ONC regarding
updates to technical standards and specifications through the rulemaking process.
Response: We acknowledge and thank commenters for their support of our policies.
Comment: A commenter stated that CMSs approach to mandating technical standards by
referencing specific standards in regulation is novel for health information exchange. The
commenter stated that prior data exchanges, such as the HIPAA standard transactions or the
machine-readable files, have everything defined in the named specifications and not defined by
reference to another standard in regulation. The commenter stated that having standards specified
elsewhere allows for the referenced standards to be changed which would then have the
cascading effect of requiring changes in allthe APIs on the timeframe of the standard change for
the APIs to remain conformant. The commenter disagreed with this regulatory approach and stated that it is better to have each API specified separately and to be self-contained (that is, not
having referenced standards). The commenter stated that this way individual APIs could be
evaluated for change on their own merits, as standards in the HIPAA Standards for Health Care
Attachments proposed rule are currently being evaluated with the potential change in the version
for the X12 278 transaction standard for attachments under HIPAA (version 6020) or for the X12
837 transaction standard for claims, and the X12 835 transaction standard for remittance advice
being recommended by X12 for consideration to X12 8020 transaction standard for plan
premium payments, or the recommended upgrade of three other X12 transactions to version
8030, including claim status, health plan enrollment, and health plan premium payments.
Response: We appreciate the commenters concerns regarding the timing of updates to
required standards via reference to other regulations. We intend to collaborate with ONC to
ensure updates to standards are deployed with reasonable timeframes and sufficient advance
notice for payers to make any required updates to their APIs. Aligning with the HHS-adopted
API standards and associated implementation specifications at 45 CFR 170.215 is important to
ensure consistency. We are finalizing the versions of the required standards that were at 45 CFR
170.215 at the time of this proposed rule. However, ONC has since finalized the HTI-1 final rule
(89 FR 1192), which adopted updated versions of certain standards including the US Core IG
STU 6.1.0 (at 45 CFR 170.215(b)(1)(ii)) and the SMART App Launch IG Release 2.0.0 (at 45
CFR 170.215(c)(2)). Additionally, ONC has finalized expiration dates for the US Core IG STU
3.1.1 (at 45 CFR 170.215 (b)(1)(i)) and the SMART App Launch Framework IG Release 1.0.0
(at 45 CFR 170. 215(c)) to indicate when a version of a standard may no longer be used. We
intend to align with the updated versions finalized at 45 CFR 170.215 through future rulemaking
prior to the API compliance dates. While we did not propose to require those updated versions,
we emphasize that impacted payers are permitted to use them based on our policy to allow
updated versions of required standards, as discussed below. The update and review process for HIPAA transaction standards follows a statutory
review process but does not include the same testing and balloting process we require for the
standards and IGs. Furthermore, the HL7 standards and IGs adopted by ONC may be updated for
use in the ONC Health IT Certification Program through the SVAP. We rely on this flexibility in
our update policy by allowing payers to use versions of standards at 45 CFR 170.213 and
170.215 that have been approved by the National Coordinator, enabling a nimble approach to
industry testing and innovation. This does not currently exist under the HIPAA standard
transaction reference model process.
Comment: Multiple commenters recommended that CMS update the clinical data
requirements to USCDI v2. The commenters also recommended that CMS give guidance on if
and when USCDI v3 and v4 may be required. The commenters noted that use of these updated
standards would advance health equity and public health work. A commenter strongly
recommended that impacted payers incorporate data elements identified in a newer version of the
USCDI, specifically USCDI v3, instead of the proposed USCDI v1. The commenter noted that
USCDI v1 does not constitute an elaborated list of data elements compared to the most recent
versions, which incorporate elements that play a critical role in electronic data exchange.
Another commenter requested CMS and ONC provide guidance regarding using newer versions
of USCDI and associated US Core IG. The commenter noted that this guidance will be helpful
when multiple versions of the USCDI are available for use, so all third-party app developers
have clear expectations and understanding regarding what data they need to be able to share and
receive.
Response: As discussed in section II.A.2.d., we are finalizing a change to the required
data content for the Patient Access, Provider Access and Payer-to-Payer APIs to a standard listed
at 45 CFR 170.213. At the time of the CMS Interoperability and Prior Authorization proposed
rule, USCDI v1 was the only version of the USCDI adopted at 45 CFR 170.213. However, ONC
has since published the HTI-1 final rule, which establishes a January 1, 2026, expiration date for USCDI v1 and adopts USCDI v3 at 45 CFR 170.213. After January 1, 2026, USCDI v3 would
be the only version specified at 45 CFR 170.213 that has not expired (89 FR 1192). In this way,
the required version of the USCDI for the APIs in this final rule will advance in alignment with
versions adopted by ONC in 45 CFR 170.213. When more than one version of USCDI is adopted
at 45 CFR 170.213 and have not expired, payers may conform to either version.
As stated previously in this section, we are also finalizing our proposal that an updated
version of a standard could be used if it is required by other law, or if ONC has approved the
updated version for use in the ONC Health IT Certification Program, users are able to access the
required data via the API, and it is not prohibited by other law. In order to identify updated
standards that have been approved for use in the ONC Health IT Certification Program, payers
can review the standards approved through the SVAP on ONCs website
https://www.healthit.gov/isa/standards-version-advancement-process, as well as standards that
are being considered for approval through SVAP (new standards for SVAP are approved
annually).
We note that USCDI v2 was approved in the 2022 SVAP cycle, while USCDI v3 was
approved as part of the 2023 SVAP cycle.184 We also note that several updated versions of the
US Core IG subsequent to the required US Core IG STU 3.1.1 have been approved by the
National Coordinator through the SVAP and are available for payers to use under this policy,
including US Core IG STU 4.0.0, 5.0.1, and 6.1.0.185
The US Core IG is updated annually to reflect changes to the USCDI, and each US Core
IG version is built to a specific version of the USCDI. For instance, US Core IG STU 3.1.1 is
built to USCDI v1 and the US Core IG STU 6.1.0 is built to USCDI v3. As the recommended
IGs continue to be refined and advance, they may reference different versions of the US Core IG
184OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap.
185OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap. based on updated versions of the USCDI. Implementers are encouraged to adopt the newer
versions of the recommended IGs as they are published. Consistent with our final policies to
allow payers to use updated standards at 42 CFR 170.215 if they have been approved by the
National Coordinator for use in the ONC Health IT Certification Program and other conditions,
implementers may use updated versions of US Core referenced to the specifications in
recommended IGs. HL7 and the FHIR Accelerators are aware of these concerns and are working
on an approach to enable greater version support for IGs.
Comment: Multiple commenters supported flexibility to use updated standards, such as
ONCs SVAP for certified health IT developers, to allow payers to use the most current
recognized versions of vocabulary standards and interoperability standards or specifications used
in the certification. A commenter stated that CMS should only require new versions of standards,
specifications, and IGs after testing and adequate time for implementation. Another commenter
stated that the mechanism to allow implementers to advance versions of standards in this rule as
long as using an updated standard does not impair access to data through the API can be used for
any or all IGs used to support these APIs or related auxiliary processes (for example, patient
attribution).
Response: We appreciate the support for this policy. The standards we are requiring in
this finalrule are those that we believe are sufficiently mature. We intend for future rulemaking
to operate similarly. As stated, payers can implement the latest versions of the required standards
and IGs as long as they meet the specified conditions, such as not impairing access to data
through the API.
Comment: Multiple commenters stated that use of specific FHIR-based standards,
specifications, and IG versions should align with those approved by ONC through SVAP. A
commenter stated that CMS requirements and adoption timelines should remain coordinated with
ONCs progression. The commenter suggested that CMS use a more general reference to the
ONC Health IT Certification Program and SVAP. Another commenter stated that ONC will be providing a more current set of standards and specification versions soon through ONC Health
IT Certification Program updates. The commenter stated that it is imperative that CMS require
developed APIs to conform to the most recently approved SVAP standards within 12 months of
approval. The commenter also recommended that CMS coordinate with ONC to include more
standards and IGs in the SVAP to align with the rule. The commenter also recommended that
CMS include a transition period (for example, 12 months).
Response: We appreciate the commenters feedback and remind readers that under this
final rule, in addition to our coordination with ONC, payers are permitted to voluntary use
updated standards provided it does not disrupt an end users ability to access the data available
through the API. In addition, implementers may advance to those standard versions approved by
the ONC through SVAP.
We decline at this time to set a timeline by which we would require impacted payers to
use the updated version of the standard rather than the adopted version of the standard. We
believe the voluntary nature of the SVAP supports a transitional periodalso a request from
commentersby allowing for a flexible implementation of standards versions between regulatory
cycles during which ONC revises the adopted version to the latest update for each standard. We
will continue to engage with patients, providers, payers, health IT developers, and our Federal
partners to ensure that this approach balances the need to advance standards with the need for
flexible transition periods for updates. We will also continue to work with ONC in their efforts to
support HHS and the health care industry through the advancement and adoption of interoperable
standards and implementation specifications for a wide range of health IT use cases.
We support innovation and continued efforts to refine standards in a way that will
leverage the most recent technological advancements. Thus, we also sought comment on the
process we should use to adopt or allow new versions of standards and implementation
specifications over time. We received many comments in response to our request for comment
and will consider this feedback for future rulemaking and guidance. We are finalizing the proposal to allow payers to use an updated standards, specifications, or IGs if required by law, or
if the updated standard, specification, or IG is approved for use in the ONC Health IT
Certification Program, do not disrupt an end user's ability to access the required data, and is not
prohibited by law for each of the APIs at the CFR sections listed in Table H2.
3. Recommended Standards to Support APIs
In the CMS Interoperability and Patient Access final rule (85 FR 25529), we noted that
there are publicly available IGs that provide implementation information that impacted payers
can use to meet the regulatory requirements for these APIs. Using those IGs supports
interoperability and allows impacted payers to avoid developing an approach independently,
which could save time and resources. In this final rule, we are recommending specific IGs that
are relevant to each of the APIs, which may be used in addition to the required standards at 45
CFR 170.215.
In the December 2020 CMS Interoperability proposed rule, we proposed to require
impacted payers to use certain IGs, including the CARIN IG for Blue Button, HL7 FHIR
Da Vinci PDex IG, HL7 FHIR Da Vinci PDex U.S. Drug Formulary IG, HL7 FHIR Da
Vinci PDex Plan Net IG, HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG,
HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) IG, and HL7 FHIR Da
Vinci Prior Authorization Support (PAS) IG (85 FR 82586) to support the APIs in that proposed
rule. As discussed in section I.A. of this final rule,we are withdrawing the December 2020 CMS
Interoperability proposed rule. We also noted that these IGs continue to be developed and refined
through the HL7 ballot and standard advancement process to better support the Patient Access,
Provider Access, Payer-to-Payer, and Prior Authorization APIs.
a. Recommending vs. Requiring Implementation Guides
In the CMS Interoperability and Prior Authorization proposed rule, we proposed to
recommend CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD,
DTR, and PAS IGs for specific APIs, as listed in Table 10 of the proposed rule (87 FR 76320). We also solicited comments on whether CMS should propose to require these recommended IGs
in future rulemaking and other ways that we could support innovation and interoperability. We
emphasize that while we are not requiring payers to use the recommended IGs listed in Table
H3, we may propose requiring payers to use these and other IGs in future rulemaking, should
they reach sufficient maturity.
After careful consideration of the versions of the IGs that were available at the time of the
proposed rule, we determined that we were not ready to propose them as requirements. We stated
that we believed these IGs would continue to be refined over time as interested parties have
opportunities to test and implement them, and as such, we chose to recommend them rather than
require them. Specifically, we stated we would continue to monitor and evaluate the IG
development and consider whether to propose them as a requirementat some future date. In this
final rule, we are finalizing our recommendation to use the CARIN for Blue Button, PDex, PDex
U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs for the Patient Access, Provider
Access, Provider Directory, Payer-to-Payer, and Prior Authorization APIs, as applicable and
listed in Table H3. We also note that several of the recommended IGs have had updated versions
published since the CMS Interoperability and Prior Authorization proposed rule. Thus, we have
updated Table H3 accordingly to represent the most recent published versions of the
recommended IGs. Because these are only recommended IGs, we do notcodify version updates
through rulemaking.
We acknowledge that by recommending rather than requiring certain IGs, there is
potential for implementation variation that could limit interoperability and ultimately lead to
rework for implementers if requirements are introduced later. However, we concluded at the time
of the proposed rule that it was more important to not require the IG versions available at that
time due to the maturity of the versions available. We recommended, but did not propose to
require, these IGs because we wanted to ensure that implementers can use subsequent versions of
these IGs without being restricted to the version available when we issued the notice of proposed rulemaking. As discussed in section II.G.2.c. of this final rule, we are finalizing a provision to
allow payers the flexibility to use updated versions of certain standards required for the APIs in
this finalrule. In the CMS Interoperability and Prior Authorization proposed rule (87 FR 76316),
we acknowledged that subsequent versions of the recommended IGs may include substantial
changes that would not be consistent with the requirement that an updated standard must not
impair access to data through the API. We intend to monitor IG development and may propose to
require specific IGs at a future date and/or allow for voluntary updates under our flexibility
policies. We received comments on our decision to recommend, rather than require the listed IGs
in the proposed rule.
Comment: Multiple commenters appreciated CMSs decision to recommend rather than
require the CARIN for Blue Button, PDex, PDex U.S. Drug Formulary, PDex Plan Net, CRD,
DTR, and PAS IGs. A commenter supported CMSs decision to recommend instead of requiring
IGs given that some of the standards and IGs are not yet mature enough for industry adoption.
Another commenter appreciated CMSs decision to recommend rather than require IGs due to
the interplay between this rule and the HIPAA Standards for Health Care Attachments proposed
rule.
Response: We thank commenters for their support of our decision to recommend certain
IGs in the proposed rule, which we believe balanced the need to provide guidance and flexibility
to industry as standards advance.
Comment: Multiple other commenters supported the recommended IGs, but noted
concern that these IGs do not have enough outside involvement in the development phase, which
could result in gaps in workflows. However, the commenters noted that they are confident that
the HL7 Accelerator workgroups will provide the necessary maturity if given sufficient time.
Response: These standards development activities do have outside parties involved
throughout the standards development process. We encourage all interested parties, especially
those who already have the experience implementing the APIs, to engage with the process. HL7 and the Accelerators welcome and solicit feedback for all of their IGs and specifications.
Meeting participation is largely open to the public, and one does not have to be a member to
participate in testing events and many other standards development activities.
Comment: Multiple commenters disagreed with CMSs decision to recommend rather
than require the IGs and expressed concern for CMSs decision to not require certain IGs, with
one concerned that not requiring the IGs will impact the level of interoperability necessary to
support data exchange. Commenters urged CMS to consider the potential for implementation
variation in APIs and limit industry-wide interoperability. Multiple commenters expressed that it
is important that adherence to IG requirements is required, not just encouraged, to ensure the
industry adopts these to obtain the benefits of the near real-time Prior Authorization API
transactions. Another commenter recommended that CMS adopt and require IGs as quickly as
possible. The commenters stated that without IGs, there is a risk that early work done by health
IT developers and the health care community will have to be refactored or restarted to meet the
IG guidelines. A commenter stated that CMS should act swiftly to encourage the creation of
more appropriate IGs and recommended that CMS work with payers to create electronic systems
and interfaces that are consistent and easy to use.
Another commenter stated that not requiring certain IGs is not in line with the
interoperability goals and prior authorization initiatives outlined in this rule to obligate providers
to report on their adoption of this technology if that technology will not be uniformly adopted
and implemented between different payers. A commenter stated that it is critical that all data
contributors be held to the same set of rules and required to adopt the same standards and IGs.
To ameliorate this, the commenter recommended that the IGs be required rather than
recommended, and that a mere recommendation may result in more burden and duplicative
work. A commenter stated that because CMS is not requiring certain IGs, it is unfair and
contrary to the goals of these interoperability and prior authorization initiatives to obligate MIPS eligible clinicians, eligible hospitals, and CAHs to report on their adoption of this technology
when that technology will not be uniformly adopted and implemented between different payers.
Multiple commenters recommended that CMS require impacted payers to use the CARIN
for Blue Button, HL7 FHIR Da Vinci Patient Coverage Decisions Exchange (PCDE), PDex,
PDex U.S. Drug Formulary, PDex Plan Net, CRD, DTR, and PAS IGs while allowing for
adaptability and advancement of those IGs over time. A commenter stated that requiring certain
IGs would move payers toward standardized data exchange. A commenter noted that most of the
IGs have been around for several years, and most have been tested in multiple Connectathons,
pilot projects, and in production environments. The commenter believes having consistent, well-
understood data fields with clear meaning that everyone uses the same way is a key element of
any API or any successful data exchange. The commenter stated that using standard IGs would
move industry toward interoperable data exchange.
Response: We received a significant number of comments on both sides regarding
requiring IGs and not requiring IGs, which indicates that there is not broad agreement across the
industry. In the proposed rule, we sought to strike a balance by requiring the standards and IGs
adopted at 45 CFR 170.215 in alignment with ONC and recommending additional IGs for each
API implementation. We acknowledge that by not requiring all the available IGs, there is
potential for implementation variation in these APIs that could limit interoperability and
ultimately lead to re-work for implementers if requirements are introduced later. However, at the
time of the proposed rule, we believed it was more important not to require these IGs while they
were still undergoing additional enhancements. We disagree with the concern that our decision to
not propose to require certain IGs is unfair and contrary to the goals of these interoperability and
prior authorization initiatives of this final rule. The required standards at 45 CFR170.215 mean
that impacted payers must implement these APIs using the FHIR standard, which will advance
interoperability. We continue to strongly recommend using the other recommended IGs listed in
Table H3. As stated previously, we also believe that the approach in the proposed rule of
recommending, but not requiring, the specific IGs and versions provided directional guidance
with flexibility to the industry in order to allow for additional improvements to be made without
locking implementers into versions of the IGs available at the time of the proposed rule. Under
the recommendations in the proposed rule, as these IGs progress, industry could continue to
harmonize on common approaches that work, eventually culminating in a required set of
specifications when ready through updates to CMS policy. To not identify any specific IGs
would have meant a more diverse set of proprietary solutions with little to no interoperability.
Our recommendations provide direction to implementers.
Comment: A commenter stated that the development and maintenance of standards and
IGs are an extension of Federal policy that does not go through the rulemaking process. They
noted that it is critical that this development and maintenance process be consensus-based, fair,
transparent, and open to allstakeholders. The commenter continued by stating that the IG
creation process is currently driven by a limited number of volunteers that do not broadly
represent the industry, which results in IG resource and profile versioning issues. The commenter
stated that CMS should ensure there is no fee to fully participate in the process for the
regulatorily required exchanges and relying on an American National Standards Institute
(ANSI)-accredited process to develop the IGs would improve the approach.
Response: We acknowledge that standards and IGs are not developed through the
rulemaking process. Rather, standards and IGs go through the rulemaking process if and when
they are proposed to be adopted. We also appreciate that commenters are invested in the quality
of the IGs and the SDO, and affirm, as we stated in the CMS Interoperability and Patient Access
final rule (85 FR 25540), that development and maintenance of standards are the purview of
SDOs, and that interested parties, including Federal agencies, participate in that process.
Stakeholders have the opportunity for review and comment on the standards both at the time they
are being developed, as well as during the proposed rule comment period. HL7 is an ANSI- accredited186 SDO, and Da Vinci is an accelerator workgroup under the umbrella of HL7 and
operates under the same rules of all ANSI accredited SDOs in the manner in which they obtain
consensus on standards. Furthermore,HL7 standards are free and open-source, and
documentation is available to anyone to ensure that all developers can equally access
information. Using these freely available materials will reduce the development burden for both
payers and app developers and facilitate industry-wide interoperability. Similarly, participation
in online working meetings and providing feedback as part of the standards development process
is free, and diverse organizational representation is critical to the quality of the standards and
IGs. Thus, we encourage as many organizations as possible with a stake in the development and
quality of these guides to participate. HHS uses different authorities to adopt and require
standards that are developed and maintained by organizations such as HL7 using the processes
described previously. For instance, ONC has adopted the standards and implementation
specifications at 45 CFR 170.215 cross-referenced in this final rule under the authority of section
3004 of the Public Health Service Act.
Comment: A commenter suggested CMS emphasize that using the IGs is not limited to
literal use, but also interpretive use to model interactions within the respective health IT
configuration in a way that is illustrative rather than prescriptive.
Response: IGs contain both SHALL and SHOULD statements, which respectively
indicate whether health IT systems must meet certain requirements to conform to the IG or are
just strongly recommended to. While implementers will be required to conform with the required
IGs we are finalizing, we remind readers that the recommended IGs can be implemented as they
see fit as long as they meet the requirements of the API.
b. Implementation Guide Maturity
186ANSIoverseesstandardsandconformanceofprocessesforallSDOs.SeeAmericanNationalStandardsInstitute
(2023).ANSI.Retrievedfromhttps://ansi.org/. In the proposed rule, we welcomed further information about the maturity of the
recommended IGs, including considerations about further development that may be needed prior
to us proposing to require the IGs we recommended (87 FR 76317).
Comment: Multiple commenters expressed concern regarding the maturity, scalability,
and real-world testing of the IGs recommended in the proposed rule. Multiple commenters were
concerned that there may be compatibility issues between the current and future versions of the
IGs given that the IG versions are not currently finalized. A commenter stated that slight
variations in API implementation could significantly increase burden placed on the provider
community. A commenter recommended that CMS and ONC issue guidance on what could be
expected in the IG guidelines to inform early work and to encourage as much fidelity to these
IGs as possible.
Response: We are committed to continuing to work with HL7, the Accelerators, and
interested parties within the industry to define, participate in, and convene testing events, as well
as developing and maintaining the specifications, thereby moving them toward greater maturity.
We acknowledge that, as with any standard, potential compatibility issues could arise throughout
development. These standards are subject to a standards development process where changes are
reviewed and compatibility is an important consideration, increasing with the level of use and
adoption. As IGs mature, the number of potential compatibility issues between versions is
expected to decrease. Likewise, as IGs continue through the standards development process, they
will be enhanced to address areas of variance among payers that are barriers to interoperability.
We determined that it was important to recommend these IGs to move the industry and provide
direction towards a common setof specifications, as opposed to not including these
recommendations, which would lead to a greater number of variations and cause a greater
burden.
Comment: A commenter recommended that CMS explain that support for SMART
Backend Services specification is also required with the Bulk Data Access IG. Another commenter stated that significant limitations exist for the Bulk Data Access IG and OpenID
Connect Core standard. The commenter noted that it is unknown when the Bulk Data Access IG
will be ready for implementation and use on a large scale.
Response: The Bulk Data Access IG v1.0.0: STU 1 includes the option for SMART
Backend Services specification to enable system-to-system authentication and authorization of
backend services. The Backend Services specification that was included in Bulk Data Access IG
v1.0.0: STU 1 was moved to SMART App Launch IG Release 2.0.0. Therefore, we strongly
recommend that the SMART Backend Services specification of the SMART App Launch IG
Release 2.0.0 be supported and thus have included this recommendation for both the Provider
Access and Payer-to-Payer APIs in Table H3. We acknowledge that not all connections may use
backend services, but when such services are available, payers may wish to use the HL7 SMART
Framework. More recent versions of the SMART App Launch IG specification, starting with
Release 2.0.0, incorporate the SMART Backend Services, which ONC has adopted in the HTI-1
final rule at 45 CFR 170.215(c). We further remind readers that though we are requiring
impacted payers to support Bulk Data Access IG for the Provider Access and Payer-to-Payer
APIs in this final rule (Table H3), payers are free to set their own criteria for using bulk data
exchange.
Comment: A commenter recommended that CMS delay API implementation until the
recommended IGs are ready to be required. The commenter noted that the proposed APIs are not
feasible without standardized adoption and expressed concern that the necessary IGs to
implement the APIs are not mature, tested, or ready to scale. A commenter suggested that CMS
should work with interested parties across the health IT community to propose and finalize IGs
that are not mature prior to mandating their use.
Response: We remind readers that we are finalizing 2027 compliance dates for the
policies that require API development and enhancement partly to allow industry additional time
to implement the needed functionality within their internal systems. By requiring some IGs and recommending others, we believe that we achieved the appropriate balance between moving
industry forward, while allowing flexibility for continued development of IGs that were not
sufficiently mature at the time of the proposed rule to propose to require.
Comment: A commenter encouraged CMS to take on an active role in the continued
development and testing of the HL7 Da Vinci IGs. The commenter recommended that CMS
review and release a formal assessment of the technology development no later than July 1,
2024.
Response: We are a member of HL7 and monitor their activities by attending the HL7 Da
Vinci workgroups, providing contract support for the development of the IGs, and tracking the
ballot process. Through these efforts, we are continuously engaged in IG development and
maintenance. We thank commenters for their suggestion but note that the request to release a
formal assessmentof technology development no later than July 1, 2024, is outof scope for this
final rule.
Comment: Multiple commenters urged CMS to identify a baseline or floor version of
the technical standards and IGs, and multiple other commenters recommended CMS develop a
formal standards advancement process, like the SVAP, to give industry the opportunity to
continue refining, testing, and deploying new versions. Multiple commenters noted that requiring
an updated version of an IG as a baseline requirement must be done officially through
government regulation. Another commenter recommended CMS develop a strategy or a process
to decide which version of IGs or standards should be required. A commenter believed that all
interested parties should agree upon IGs for each of the APIs. The commenter stated that in the
final rule, CMS should identify the requirements, including IGs, for all interested parties.
Another commenter recommended thatCMS explain the functionalities of specific IGs they
would like applied to each of the APIs.
Multiple commenters urged CMS to work with interested parties to identify a limited
number of IGs to require so industry is not overwhelmed with too many IGs. Moreover, multiple commenters expressed concern about requiring more than one IG for specific API
implementations and requested that CMS only require one IG. A commenter noted they support
clear and unambiguous standards to achieve true interoperability.
Response: The required standards and recommended IGs for each of the APIs are listed
in Table H3 and represent the minimum expected of impacted payers. The FHIR IGs have been
developed to fulfill a specific purpose and therefore requiring more than one IG for a specific
API is appropriate. Specifically, the IGs we are recommending all have individual purposes and
we are only recommending those relevant to each API as listed in Table H3. We also remind
interested parties that the IGs go through a consensus-based process and participation in the
online meetings and providing feedback is free, thus, we encourage as many organizations as
possible with an investment in the development and quality of these guides to participate.
Comment: Multiple commenters recommended that CMS explain how technical
standards and IGs will be mapped to specific API functionalities.
Response: We refer readers to Table H3 for an outline of which standards and IGs pertain
to which APIs. We also remind readers that our recommended IGs can support the required
standards for the specific API we are recommending them for.
Comment: Multiple commenters expressed support for work done by the CARIN
Alliance, which provides a method for all payers to make submitted and processed claims data
available to patients and has sufficient maturity to ensure a successful implementation. Multiple
commenters requested that CMS consider mandating the CARIN IG for Blue Button. A
commenter stated that otherwise, stakeholders will have to support multiple IGs, which adds
burden and increases technology complexity making development and implementation
challenging. Multiple commenters expressed support for clear and unambiguous standards.
A commenter stated the CARIN IG for Blue Button already produces an EOB for in-
patient, out-patient, professional, pharmacy, dental, and vision services through a setof FHIR
profiles. The commenter noted that these same profiles could provide the required non-financial view of the EOBs to meet the requirements outlined in this proposed rule by using the Summary
View returned by FHIRs summary parameter search.
Response: We agree about the importance of the CARIN Alliances work. However, for
reasons explained in section II.G.3.a. of this final rule, we did not propose to require several IGs
which are listed in Table H3 as Recommended IGs, including the CARIN IG for Blue Button.
Regarding the recommendation to leverage the non-financial view of a CARIN IG for Blue
Button, we note that in order to do this, the CARIN IG for Blue Button would need to be
updated, or other guidance provided to support this requirement, and that the data be made
available through the appropriate API. Work is currently underway in CARIN and in
coordination with HL7 Da Vinci PDex workgroup to define this guidance.
Comment: A commenter noted that a September 2021 Frequently Asked Questions
(FAQ)187 document published by CMS states that payers would be compliant with the Patient
Access API requirements if they used the CMS-recommended IG (CARIN for Blue Button IG
v1.1.0: STU 1) to build their APIs, but that that IG version does not enable the inclusion of
dental or vision claims, which were added in the most recent version. Multiple commenters
supported guidance or rulemaking to support oral and vision claims using the CARIN IG for
Blue Button v2.0.0: STU 2 version.
A commenter recommended that CMS reaffirm that impacted payers would be compliant
with the requirements for the Patient Access and Provider Access, and Payer-to-Payer APIs if
they follow the CMS recommended IGs. The commenter also recommended that CMS further
explain that the absence of dental and vision claims information in the proposed APIs would not
result in payer noncompliance given that the recommended CARIN IG for Blue Button does not
include dental and vision claims.
187HealthInformaticsandInteroperabilityGroup(2021).PatientAccessAPIFAQ.Retrievedfrom
https://www.cms.gov/priorities/key-initiatives/burden-reduction/faqs/patient-access-api. Response: At the time the proposed rule was drafted, the CARIN IG for Blue Button
v1.1.0: STU 1 was the latest published version for use. Since then, CARIN IG for Blue Button
v2.0.0: STU 2 was released, which indeed includes dental and vision (vision as part of the
professional and non-clinician profile). We are therefore modifying our recommendation listed in
Table H3 to HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button)
IG v2.0.0: STU 2. In addition to the required standards listed in Table H3, if impacted payers
use the recommended IGs also listed in Table H3 for the APIs and follow the IGs to specification
to build their APIs, they would be conformant with the technical requirements.
Comment: A commenter expressed support for exchanging data via FHIR APIs and noted
that the PDex IG STU 2.0.0 includes a prior authorization profile to share prior authorization
information, but this profile is not yet published. However, another commenter noted that the
HL7 Da Vinci PDex workgroup is actively completing an initial set of updates to the PDex IG to
facilitate sharing prior authorization information and that the workgroup will make any necessary
revisions to support the provisions outlined in the proposed rule to include any related
administrative and clinical documentation. Another commenter was concerned that some of the
proposed data elements for prior authorization have not yet been profiled within FHIR IGs.
A commenter stated that payers should already have familiarity with the PDex IG as it
was recommended as part of the Patient Access API. The commenter continued that using the
PDex IG to support the new set of information will also reduce burden.
Response: The recently published PDex IG STU 2.0.0 specification188 does include a
Prior Authorization profile that enables payers to communicate prior authorization decisions and
changes to the status of a prior authorization requests. Based on feedback and developments in
the industry, in addition to the required IGs and previously recommended IGs, we are now
recommending the PDex IG STU 2.0.0. for the Patient Access, Provider Access, and Payer-to-
188HealthLevelSevenInternational(2020).DaVinciPayerDataExchange.Retrievedfromhttp://hl7.org/fhir/us/
davinci-pdex/STU1/. Payer APIs, as listed in Table H3. We are delaying the compliance dates for the APIs finalized in
this rule to 2027, which allows for additional time for the FHIR standard and IGs to continue to
be refined and advanced to support all of the policies in this final rule.
Comment: A commenter noted that the proposed rule suggested that the Provider
Directory API finalized in the CMS Interoperability and Patient Access final rule will be
conformant with the PDex Plan Net IG STU 1.1.0. A commenter stated their belief in standards-
based methods for the electronic transmission of health information. The commenter continued
that successful standards-based conveyance of digital health care information relies on clear and
unambiguous standards that apply across the industry. The commenter stated that the PDex Plan
Net IG meets this requirement.
Response:We agree with commenters on the utility of the PDex Plan Net IG,and are thus
recommending its use for the Provider Directory API.
Comment: Multiple commenters recommended CMS and HL7 ensure the CRD, DTR,
and PAS IGs are fully tested prior to the effective date of the final rule, as the IGs have not been
adequately or widely tested in real-time clinical settings. A commenter expressed concern with
required versus situational data elements in the current versions of the recommended IGs
outlined in the proposed rule. The commenter noted that the CRD, DTR, and PAS IGs have data
elements and processes that are listed as optional despite their utility for automation. Another
commenter provided the example that the CRD IG does not require the return of documentation
templates and rules, so the provider would be required to initiate a separate transaction to
determine the requirements for a prior authorization. Additionally, this commenter stated that the
CRD IG allows for hyperlinks to be returned to the provider. The commenter stated that this
means that a valid response to a coverage requirements discovery request can be a hyperlink to a
third-party prior authorization vendor where the provider would have to initiate a prior
authorization request through a provider portal and drop to a manual process outside of their
EHR and practice management system. Response: The HL7 Da Vinci IGs that we recommend specifically for the Prior
Authorization API are the CRD, DTR, and PAS IGs. These were created as three distinct IGs
that were loosely coupled instead of created as a single IG in order to provide implementation
flexibility and the ability to disconnect the processes where necessary. A number of optional or
situational elements are included in these guides to connectthem into a single workflow where
needed. While we value the specificity of other comments regarding the functions of the IGs,
such as hyperlinks and connecting to external portals, these are the purview of the HL7
Implementation division. We will work with HL7 and implementers to coordinate appropriate
support for such questions prior to the compliance dates.
Comment: A commenter stated that it was their understanding that the HL7 Da Vinci
PCDE IG was developed with minimal payer input. The commenter stated that there may be a
need for additional time for impacted payers to understand and implement the IG. Furthermore,
the commenter expressed concern that the PCDE IG only addresses the movement of data
between the provider and payer and does not address the back-end systems that will need to
ingest and process new information for continuity of care. The commenter urged CMS to
continue exploring other opportunities to promote data exchange. The commenter acknowledged
that there are many industry solutions being developed to facilitate the coordination of benefits
between providers. The commenter stated that these options could prove to be better solutions
for the industry in the future and recommended that CMS continue to monitor and enable
technical innovation in this area.
A commenter noted that CMS has included two mentions of the PCDE IG. They stated
that there is one reference in the preamble of the proposed rule (87 FR 76336); however, in the
preamble Payer Coverage Decision Exchange is followed by a parentheticalreference to
PDex. The commenter stated that the PCDE IG was also listed in Table 10 (87 FR 76321),
though, there are no additional or substantive mentions of the PCDE IG in the proposed rule. The
commenter believes that it is possible the mention of the PCDE IG was unintentional. Response: We acknowledge that the PDex IG has expanded to include prior authorization
data and development of PCDE IG is not currently active. Thus, while we acknowledge the
drafting error the commenter previously noted, we are no longer recommending the PCDE IG for
the Payer-to-Payer API.
Comment: A commenter suggested that CMS consider recommending the HL7 FHIR
Member Attribution (ATR) List IG, which is currently in the publication process.The
commenter stated this IG focuses on attribution lists for risk-based contracts and it could serve as
an exchange standard for all payers.
Response: While we did not include the ATR List IG as one of recommendations listed in
Table H3, we note that industry expects that the next version will be published well before the
compliance dates for API development and enhancement policies in this final rule. Payers are
permitted to use the ATR List IG, and we will explore including it, either as a recommendation
or requirement, in future rulemaking.
Comment: Multiple commenters recommended that CMS consider leveraging the HL7
FHIR Da Vinci Reducing Clinician Burden (RCB) IGs. A commenter shared that revisions to the
RCB IGs are underway to make prior authorization documentation supporting medical necessity,
which is assembled by the ordering provider, available to the performing provider. The updated
IG is currently titled FHIR Orders Exchange (FOE), and updates should be balloted in the
September 2023 SVAP cycle. Another commenter stated that they believe RCB IGs would help
industry work towards future readiness for a certified Health IT Module(s) to be included within
the ONC Health IT Certification Program.
Response: We thank commenters for their suggestions and will consider them for future
rulemaking.
Comment: A commenter stated that the HL7 FHIR Da Vinci Clinical Data Exchange
(CDex) IG would enable providers to obtain additional information that may have been missing
or not yet available on the initial order request. Response: Though we neither proposed nor recommended the CDex IG, we recognize
that the CDex IG is being developed to exchange attachments via the Prior Authorization API.
Impacted payers are permitted to use the CDex IG and are encouraged to participate in the
ongoing testing as the IG is further developed. Though HL7 has included the ability to exchange
attachments in its suite of IGs, and this would be available for use voluntarily, this final rule does
not address health care attachments. We will consider either requiring or recommending the
CDex IG in future rulemaking.
Comment: A commenter recommended using the HL7 Da Vinci DTR IG to specify how
payers codify their rules in clinical quality language for real-time determination.
Response: Weare currently recommending the DTR IG for the Prior Authorization API.
We will continue to monitor and evaluate the development of the recommended IGs listed in
Table H3 and consider whether to propose them as a requirement at some future date.
c. Authentication and Authorization
Comment: Multiple commenters encouraged CMS to work with HL7 to integrate the
UDAP into the IGs created by HL7. A commenter stated that a security framework based on a
tiered OAuth security specification is required to enable the scalable exchange within trust
frameworks. The commenter stated that industry will not be able to implement at scale based on
how the standards were proposed and suggested CMS focus on making sure this work is in place
prior to making the APIs in the proposed rule mandatory. In addition, the commenter stated that
the HL7 Da Vinci PDex IG depends on mTLS to establish the identity of each of the
organizations involved in the exchange while other payer-to-provider and payer-to-patient
exchanges rely on OAuth and the SMART framework.
Response: We thank the commenters for their responses and understand their concerns.
As discussed in section II.B. of this final rule, we are currently supporting efforts to define the
specifications for authentication at scale throughUDAP via the FAST Security IG and mTLS
through the PDex IG. We acknowledge that authentication and authorization via user credentials, using means
such as OpenID Connect Core and OAuth 2.0, is a requirement for APIs in which individually
identifiable user access is necessary, such as the Patient Access API. In order to use OpenID
Connect Core, each user would need to have credentials with the payer (or delegated
authentication/authorization entity) to access the API. Thus, we are maintaining OpenID Connect
Core 1.0 as a required standard for the Patient Access API.
We recognize that while protocols involving specific user credentials as managed by a
payer could be used for the Provider Access and Prior Authorization APIs, other protocols,such
as SMART Backend Services, mTLS, UDAP, or other trust community-specified means, may be
easier to implement at scale. Likewise, protocols requiring user levelcredentials, managed by the
payer, are generally not appropriate for business-to-business data exchanges like the Payer-to-
Payer API where an individual may not be directly initiating the exchange. Therefore, upon
further consideration of our proposals, we are not finalizing OpenID Connect Core (at 45 CFR
170.215(b)) as either a required or recommended standard for the Provider Access, Payer-to-
Payer, and Prior Authorization APIs.
We are recommending SMART Backend Services Authorization for both the Provider
Access and the Payer-to-Payer APIs. However, payers will be able to choose the protocols or
combination of protocols they deem appropriate as long as they meet appropriate security and
privacy requirements. We acknowledge that payers will likely use different protocols, which
could represent a barrier to enabling data exchange at scale. Specifications such as UDAP and
the tiered OAuth profile is an available option for payers and may enable data exchange in a
scalable way by providing dynamic client registration and delegated authentication potentially
within and across trust communities. We appreciate the comments, will continue to monitor the
progress of UDAP development and implementation, and will consider including it in future
rulemaking. Comment: A commenter stated that the HL7 FHIR Da Vinci Health Record Exchange
(HRex) IG Coverage Profile allows for UDAP, which may be viable solution for authentication.
The commenter stated that the HL7 FAST STU 1 Security IG should be considered foundational
in the future for all IGs that require registration, authentication, and authorization. Additionally,
the commenter suggested that CMS should explain that requiring handwritten signatures
continues to be appropriate when the impacted payer deems it necessary. The commenter
recommended that CMS should support industry discussions and actions toward UDAP
alignment across IGs, when and where appropriate.
Response: We recognize that methods including, but not limited to UDAP, may be
appropriate depending on the payers specific needs and the API. We believe that appropriate
security controls can be implemented without requiring handwritten signatures, unless required
by other applicable law. We continue to monitor the progress of IG development and remind
readers that this final rule does not restrict payers from using other IGs (assuming they are not an
earlier version than we specify). We will continue to monitor IG development and consider
requiring or recommending additional IGs in future rulemaking.
4. Required Standards and Recommended Implementation Guides to Support APIs
Using standards and IGs supports consistent implementations across the industry. In
Table H1 of this final rule, we list the CFR citations that require impacted payers to use API
technology conformant with the standards and specifications outlined in this section of the rule.
We also include Table H3 to provide a clear outline of which standards we require and which
IGs we recommend for each API. Es b)
F (
F 23
ontheR1(c)(1) R2(a)(1) R2(b)(1) R156.2
HPsCF6.22 CF6.22 A CF6.22 CF
Q4515 4515 N/ 4515 45
IREDAPIs CHIPManagedCareThroughexistingcrossreferenceto42CFR438.242at42CFR457.1233(d)
U
EQ 1) FR b)
RDSFORR mpactedPayer CHIPFFS42CFR457.730(c)( 42CFR457.731(a)(1) Throughcrossreferenceto42C457.730(c)at42CFR457.760(a)42CFR457.731(b)(1) 42CFR457.732(
I
A h
BILITYSTAND RegulationsforEacMedicaidManagedCareThroughcrossreferenceto42CFR431.60at42CFR438.242(b)(5)Throughcrossreferenceto42CFR431.61(a)at42CFR438.242(b)(7) Throughcrossreferenceto42CFR431.70at42CFR438.242(b)(6)Throughcrossreferenceto42CFR431.61(b)(1)at42CFR438.242(b)(7) Throughcrossreferenceto42CFR431.80(b)at42CFR438.242(b)(7)
A
R RR
INTEROPE MedicaidFFS42CFR431.60(c)(1) 42CFR431.61(a)(1) Throughcrossreferenceto42CF431.60(c)at42CF431.70(a)42CFR431.61(b)(1) 42CFR431.80(b)
F
1:USEO Advantage2.119(c)(1) 2.121(a)(1) ossreference422.119(c)at2.120(a) 2.121(b)(1) 2.122(b)
ABLEH Medicare42CFR42 42CFR42 Throughcrto42CFR42CFR42 42CFR42 42CFR42
T
RequirementPatientAccessAPI(Effectivedateofthefinalrule)ProviderAccessAPI(CompliancedateJanuary1,2027)ProviderDirectoryAPI(Effectivedateofthefinalrule)Payer-to-PayerAPI(CompliancedataJanuary1,)2027PriorAuthorizationAPI(CompliancedateJanuary1,2027)
n
ctioG.2. G.2. G.2. G.2. G.2.
SeII. II. II. II. II. 5R 5R 5R
4F 4F 4F
oC oC oC
FEs cet45 cet45 cet45
ntheF21(c)(4) referenc)(4)at referenc)(4)at referenc)(4)at
QHPso45CFR156.2 ThroughcrossCFR156.221(156.222(a)(1) N/A ThroughcrossCFR156.221(156.222(b)(1) ThroughcrossCFR156.221(156.223(b)
s es
I rs
AP CacroFRR
dgCF
EQUIRED yer CHIPManageThroughexistinreferenceto42438.242at42C457.1233(d)
R a
P
)
RDSFORTHE sforEachImpacted CHIPFFS42CFR457.730(c)(4 Throughcrossreferenceto42CFR457.730(c)(4)at42CFR457.731(a)(1) Throughcrossreferenceto42CFR457.730(c)(4)at42CFR457.760(a) Throughcrossreferenceto42CFR457.730(c)(4)at42CFR457.731(b)(1) Throughcrossreferenceto42CFR457.730(c)(4)at42CFR457.732(b)
A n
ATEDSTAND RegulatioMedicaidManagedCareroughcrosserenceto42CFR1.60at42CFR8.242(b)(5)roughcrosserenceto42CFR1.61(a)at42CFR8.242(b)(7) roughcrosserenceto42CFR1.70at42CFR8.242(b)(6) roughcrosserenceto42CFR1.61(b)(1)at42CFR8.242(b)(7) roughcrosserenceto42CFR1.80(b)at42CFR8.242(b)(7)
D Thref4343Thref4343 Thref4343 Thref4343 Thref4343
P
U S 4) 4) 4) 4) 4)
2:USEOF MedicaidFF42CFR431.60(c)( Throughcrossreferenceto42CFR431.60(c)(at42CFR431.61(a)(1) Throughcrossreferenceto42CFR431.60(c)(at42CFR431.70(a) Throughcrossreferenceto42CFR431.60(c)(at42CFR431.61(b)(1) Throughcrossreferenceto42CFR431.60(c)(at42CFR431.80(b)
H
TABLE MedicareAdvantage42CFR422.119(c)(4) Throughcrossreferenceto42CFR422.119(c)(4)at42CFR422.121(a)(1)Throughcrossreferenceto42CFR422.119(c)(4)at42CFR422.120(a)Throughcrossreferenceto42CFR422.119(c)(4)at42CFR422.121(b)(1) Throughcrossreferenceto42CFR422.119(c)(4)at42CFR(b)422.122
RequirementPatientAccessAPI(Effectivedateof)thefinalruleProviderAccessAPI(CompliancedateJanuary1,2027) ProviderDirectoryAPI(Effectivedateofthefinalrule) Payer-to-PayerAPI(CompliancedateJanuary1,2027) PriorAuthorizationAPI(CompliancedateJanuary1,2027)
n
ctioG.2. G.2. G.2. G.2. G.2.
SeII. II. II. II. II. TABLE H3: REQUIRED STANDARDS AND RECOMMENDED IMPLEMENTATION
GUIDES TO SUPPORT API IMPLEMENTATION
API RequiredStandards* RecommendedImplementationGuides
PatientAccess 45CFR170.215(a)(1)HL7FHIR HL7FHIRCARINConsumerDirectedPayerData
API Release4.0.1 Exchange(CARINIGforBlueButton)IGSTU2.0.0.
URL:http://hl7.org/fhir/us/carin-bb/history.html.
45CFR170.215(b)(1)(i)HL7
FHIRUSCoreIGSTU3.1.1.*** HL7FHIRDaVinciPayerDataExchange(PDex)IG
STU2.0.0.URL:http://hl7.org/fhir/us/davinci-
45CFR170.215(c)(1)HL7 pdex/history.html.
SMARTApplicationLaunch
FrameworkIGRelease1.0.0.*** HL7FHIRDaVinci-PayerDataExchange(PDex)US
DrugFormularyIGSTU2.0.1.URL:
45CFR170.215(e)(1)OpenID http://hl7.org/fhir/us/Davinci-drug-
ConnectCore1.0,incorporating formulary/history.html.
errataset1
Provider 45CFR170.215(a)(1)HL7FHIR HL7FHIRCARINConsumerDirectedPayerData
AccessAPI Release4.0.1 Exchange(CARINIGforBlueButton)IGSTU2.0.0.
URL:http://hl7.org/fhir/us/carin-bb/history.html.
45CFR170.215(b)(1)(i)HL7
FHIRUSCoreIGSTU3.1.1.*** HL7FHIRDaVinciPayerDataExchange(PDex)IG
STU2.0.0.URL:http://hl7.org/fhir/us/davinci-
45CFR170.215(c)(1)HL7 pdex/history.html.
SMARTApplicationLaunch
FrameworkIGRelease1.0.0.*** 45CFR170.215(c)(2)HL7SMARTAppLaunchIG,
Release2.0.0tosupportBackendServices
45CFR170.215(d)(1)FHIRBulk Authorization.URL:https://hl7.org/fhir/smart-app-
DataAccess(FlatFHIR)IG launch/STU2/backend-services.hotml
(v1.0.0:STU1)
Provider 45CFR170.215(a)(1)HL7FHIR HL7FHIRDaVinciPayerDataExchange(PDex)Plan
Directory Release4.0.1 NetIGSTU1.1.0.URL:
API** http://www.hl7.org/fhir/us/davinci-pdex-plan-
45CFR170.215(b)(1)(i)HL7 net/history.html.
FHIRUSCoreIGSTU3.1.1.***
Payer-to-Payer 45CFR170.215(a)(1)HL7FHIR HL7FHIRConsumerDirectedPayerDataExchange
API Release4.0.1 (CARINIGforBlueButton)IGSTU2.0.0.URL:
http://hl7.org/fhir/us/carin-bb/history.html.
45CFR170.215(b)(1)(i)HL7
FHIRUSCoreIGSTU3.1.1.*** HL7FHIRDaVinciPayerDataExchange(PDex)IG
STU2.0.0.URL:http://hl7.org/fhir/us/davinci-
45CFR170.215(d)(1)FHIRBulk pdex/history.html.
DataAccess(FlatFHIR)IG
(v1.0.0:STU1) 45CFR170.215(c)(2)HL7SMARTAppLaunchIG,
Release2.0.0tosupportBackendServices
Authorization.URL:https://hl7.org/fhir/smart-app-
launch/STU2/backend-services.html
Prior 45CFR170.215(a)(1)HL7FHIR HL7FHIRDaVinci-CoverageRequirements
Authorization Release4.0.1 Discovery(CRD)IGSTU2.0.1.URL:
API http://hl7.org/fhir/us/davinci-crd/history.html.
45CFR170.215(b)(1)(i)HL7
FHIRUSCoreIGSTU3.1.1.*** HL7FHIRDaVinci-DocumentationTemplatesand
Rules(DTR)IGSTU2.0.0.URL:
45CFR170.215(c)(1)HL7 http://hl7.org/fhir/us/davinci-dtr/history.html.
SMARTApplicationLaunch
FrameworkIGRelease1.0.0.*** HL7FHIRDaVinciPriorAuthorizationSupport(PAS)
IGSTU2.0.1.URL:http://hl7.org/fhir/us/davinci-
pas/history.html. *Wehavemademodificationstotherequiredstandardslistedinthistablefromwhatwasoriginallylisted
inTable10oftheCMSInteroperabilityandPriorAuthorizationproposedrule(87FR76320).
**Wehaveremovedthereferencesto45CFR170.215(c)SMARTAppLaunchIGand45CFR170.215(e)
OpenIDConnectCorefortheProviderDirectoryAPIthatweremistakenlyincludedintheproposedrule.Security
protocolsrelatedtouserauthenticationandauthorizationareexcludedfromtherequirementsfortheProvider
DirectoryAPI(forMAorganizationsat42CFR422.120(a),forMedicaidat42CFR431.70(a),andforCHIPat42
CFR457.760(a)).FormoreinformationseethediscussionintheCMSInteroperabilityandPatientAccessfinalrule
at85FR25560.
***IntheHTI-1finalrule,ONCfinalizedexpirationdatesforseveraloftheserequiredstandardsto
indicatewhenaversionofastandardmaynolongerbeused(89FR1192).Weintendtoalignwithupdatedversions
finalizedat45CFR170.215throughfuturerulemakingpriortotheAPIcompliancedates.
5. Final Action
After considering the comments received, and for the reasons discussed in the CMS
Interoperability and Prior Authorization proposed rule (87 FR 76238) and our response to those
comments (as summarized previously), we are finalizing our proposals regarding interoperability
standards for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior
Authorization APIs.
We are finalizing greater specificity for the standards at 45 CFR 170.215 that are
applicable to each API, with some modifications. Specifically, impacted payers will only be
required to use the applicable standards and specifications that we have identified as necessary
for the Patient Access, Provider Access, Provider Directory, Payer-to-Payer, and Prior
Authorization APIs. Those standards are listed as required in Table H3. We are also finalizing
a modification to incorporate the expiration dates ONC adopted at 45 CFR 170.215(b)(1)(i) and
(c)(1) since the CMS Interoperability and Prior Authorization proposed rule was published.
We are finalizing our proposal to allow impacted payers to use updated standards,
specifications, or IGs for each of these APIs, under the following conditions: the updated version
of the standard is required by other applicable law; or (1) the updated version of the standard is
not prohibited under other applicable law, (2) the NationalCoordinator has approved the updated
version for use in the ONC Health IT Certification Program, and (3) the updated version does not
disrupt an end users ability to access the data required to be available through the API. We note
that for the required standards at 45 CFR 170.215, several updated versions have been approved by the National Coordinator for use in the ONC Health IT Certification Program,189 including,
but not limited to, the US Core IGSTU 6.1.0, the SMART App Launch IGRelease 2.0.0, and the
Bulk Data Access IG (v2.0.0: STU 2).
Finally, we are recommending specific IGs, listed as recommended in Table H3, which
we encourage payers to use in addition to the required standards at 45 CFR 170.215.
189OfficeoftheNationalCoordinatorforHealthInformationTechnology(2023,September11).StandardsVersion
AdvancementProcess(SVAP).Retrievedfromhttps://www.healthit.gov/topic/standards-version-advancement-
process-svap. III. Collection of Information Requirements
Under the Paperwork Reduction Act (PRA) of 1995, we are required to provide 60-day
notice in the Federal Register and solicit public comment before a collection of information
requirement is submitted to the OMB for review and approval. To fairly evaluate whether an
information collection should be approved by OMB, section 3506(c)(2)(A) of the PRA of 1995
requires that we solicit comment on the following issues:
 The need for information collection and its usefulness in carrying out the proper
functions of our agency.
 The accuracy of our estimate of the information collection burden.
 The quality, utility, and clarity of the information to be collected.
 Recommendations to minimize the information collection burden on the affected
public, including automated collection techniques.
We requested public comment on areas of this document that contain information
collection requirements (ICRs).
A. Background
Payers and providers should be able to take advantage of new technologies that improve
their ability to exchange information efficiently, enhance operations, and streamline processes to
benefit patient care. Payers should share prior authorization rules in more transparent ways to
enable providers to meet their requirements, and thereby, avoid care delays. To continue
advancements in our commitment to interoperability, we are finalizing our proposals for certain
impacted payers to implement FHIR APIs and make other process improvements to help
streamline prior authorizations and improve data exchange between payers, providers, and
patients. Impacted payers will be required to report metrics for the information about how often
patients use the Patient Access API and about prior authorization processes to assess
implementation of our policies. The final rule includes provisions that will reduce the amount of
time to process prior authorization requests and improvements for communications about denied prior authorizations. Combined, these provisions should reduce the burden on providers, payers,
and patients and enhance patient care coordination.
To incentivize provider use of the Prior Authorization API, we are finalizing a policy to
add a new measure for MIPS eligible clinicians under the MIPS Promoting Interoperability
performance category and foreligible hospitals and CAHs under the Medicare Promoting
Interoperability Program. Beginning with the CY 2027 performance period/2029 MIPS payment
year (rather than the CY 2026 performance period/2028 MIPS payment year), we are finalizing
this measure as an attestation (yes/no response); we intend to propose a scoring methodology for
the measure in future rulemaking. This new measure will be included in a PRA package related
to this final rule.
B. Wage Estimates
To derive average costs, we used data from the U.S. Bureau of Labor (BLS) Statistics
National Occupational Employment and Wage Estimates190 and aligned our analysis with other
CMS regulatory actions. Table J1 presents the mean hourly wage, the cost of fringe benefits and
overhead (calculated at 100 percent of salary), and the adjusted hourly wage.
TABLE J1: HOURLY WAGE ESTIMATES
Adjusted
MeanHourly Fringeand Hourly
Wage OverheadBenefits Wage
OccupationTitle OccupationCode ($/Hour) ($/Hour) ($/Hour)
BusinessOperationsSpecialists 13-1000 $37.66 $37.66 $75.32
Clerical(OfficeandAdministrativeSupportOperations) 43-3000 $20.38 $20.38 $40.76
ComputerandInformationAnalysts 15-1210 $48.40 $48.40 $96.80
ComputerandInformationSystemsManagers 11-3021 $77.76 $77.76 $155.52
ComputerSystemsAnalysts 15-1211 $47.61 $47.61 $95.22
DatabaseAdministratorsandArchitects 15-1245 $48.60 $48.60 $97.20
Designers,AllOther 27-1029 $34.30 $34.30 $68.60
Engineers,AllOther 17-2199 $51.47 $51.47 $102.94
GeneralandOperationsManagers 11-1021 $60.45 $60.45 $120.90
MedicalRecordsSpecialists 29-2098* $23.21 $23.21 $46.42
RegisteredNurses 29-1141 $38.47 $38.47 $76.94
OperationsResearchAnalysts 15-2031 $44.37 $44.37 $88.74
Physicians,AllOther 29-1228 $105.22 $105.22 $210.44
SoftwareandWebDevelopers 15-1250 $52.86 $52.86 $105.72
TechnicalWriters 27-3042 $37.78 $37.78 $75.56
*TableJ1reportsmeanhourlywages.ForMedicalRecordSpecialists,themedianwageis$21.20($42.40whenmultipliedbytwoto
reflectfringebenefitsandoverhead).ThismedianwillbeusedinICR#8toprovideanalternateaggregateestimate,which,afterrounding,does
notdifferfromtheestimateusingthemean.
190U.S.BureauofLaborStatistics(2021,March31).May2020NationalOccupationalEmploymentandWage
Estimates.Retrievedfromhttps://www.bls.gov/oes/2020/may/oes_nat.htm. We adjusted the employee hourly wage estimates by a factor of 100 percent or doubling
of the BLS wage estimates. This is a rough adjustment because fringe benefits and overhead
costs vary significantly across employers based on the age of employees, location, years of
employment, education, vocations, and other factors.
C. Information Collection Requirements
Consistent with our approach in the CMS Interoperability and Patient Access final rule
(85 FR 25622), we determined ICRs by evaluating cost and burden at the impacted payer level.
We determined that 365 impacted payers together represent the possible plans, entities,issuers,
and state programs impacted by these proposals. The increase in impacted payers from the first
CMS Interoperability and Patient Access final rule (85 FR 25510) corresponds to the average
annual increase in impacted payers for new market entries. The total estimated burden on these
impacted payers is described in detail in the following ICRs and Table J9 at the end of this
section. We estimated the total number of burden hours across allimpacted payers in the first
year of implementation at 6.9 million hours; assuming a total cost to impacted payers to begin at
approximately $182 million in the first and second years, increasing to $199 million in the third
year and decreasing to $142 million by the fourth and subsequent years.
We requested comments on each ICR described in the proposed rule (87 FR 76330), and
on the assumptions made in deriving these burden estimates. We received a few comments on
the burden of the proposals and acknowledge those comments with responses later in this
section. Since we did not receive specific data to include to modify estimates, no revisions have
been made.
1. Information Collection Requirements Regarding Reporting of Patient Access API Metrics to
the Centers for Medicare and Medicaid Services (42 CFR 422.119, 431.60, 438.242, 457.730,
and 457.1233 and 45 CFR 156.221)
CMS does not currently collect data on using the Patient Access API and does not have
industry data on the extent to which patients are requesting to download their data from their payer into an app. We are finalizing the requirement that impacted payers annually report certain
metrics to CMS about usage of the Patient Access API. Specifically, we will collect 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. We estimate
that impacted payers will conduct two major work phases: (1) implementation, which includes
defining requirements and system design to generate and compile reports; and (2) maintenance,
which we define as including the compilation and transmission of annual reports to CMS. During
the implementation phase, impacted payers will need to prepare their systems to capture the data
to be transmitted to CMS.
The burden estimate related to the requirements reflects the time and effort needed to
identify, collect, and disclose the information. The costs include an initial set of one-time costs
associated with implementing the reporting infrastructure and ongoing annual maintenance costs
to report after the reporting infrastructure has been established.
Table J2 includes our computational estimates for first-year implementation and ongoing
maintenance costs and was used to develop the official statement of burden found in Table J9. In
finalizing these calculations, we assumed a two-person team of software/web developers and a
business operations specialist spending an aggregate of 160 and 40 hours, respectively, for the
first and subsequent years, at a total cost per impacted payer (rounded) of $15,000 and $3,000.
The aggregate burden (rounded) for 365 impacted payers will be 60,000 hours and 15,000 hours
for the first and subsequent years at a cost of $5.5 million and $1 million.
TABLE J2: AGGREGATE BURDEN FOR COMPLYING WITH THE PATIENT
ACCESS API REPORTING REQUIREMENTS
Development Maintenance 1stYear Annual
Labor HoursFirst HoursPer Development Maintenance
Occupation Cost YearOnly Year Cost Cost
OccupationTitle Code ($/Hour) (Hour) (Hour) ($) ($)
Software/WebDevelopers 15-1250 $105.72 100 0 $10,572 $0.00
BusinessOperationsSpecialists 13-1000 $75.32 60 40 $4,519 $3,012.80
TotalsperImpactedPayer 160 40 $15,091 $3,013
TotalsforAllRelevantImpactedPayers 58,400 14,600 $5,508,288 $1,099,672 *ThistablecontainscomputationsusedforcreatingTableJ9;theyarenotdefinitivestatementsofburden.TableJ9istheofficial
collectionofinformationstatementofburden,includingthenumberofrespondentsandresponses.PleaseseetheBLSforthewageestimates
used.191
We did not receive comments specific to the estimates for the Patient Access API metrics
reporting.
2. Information Collection Requirements Regarding the Provider Access API (42 CFR 422.121,
431.61, 438.242, 457.731, and 457.1233 and 45 CFR 156.221)
Research shows that patients achieve better outcomes when their medical records are
more complete and there are more data available to the health care provider at the point of
care.192 Making comprehensive information available to providers could thus improve the care
experience for patients. Ensuring that providers have access to relevant patient data could also
reduce the burden on patients to recall and relay information during an appointment and provide
confirmation that the patients recollection of prior care is accurate. This has not always been
possible in a disconnected health care system. However, interoperable standards and technology
now make it possible for providers to access more patientdata for a more comprehensive view of
their patients health history and status. We are finalizing the Provider Access API requirements
as described in section II.B.2. of this final rule which permits providers to receive standardized
patient data to coordinate care. Cost estimates for this API were developed based on the
methodology finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510).
In that rule, we estimated that impacted payers would conduct three major work phases: initial
design, development and testing, and long-term support and maintenance (85 FR 25605). In this
final rule, we assume the same major phases of work will take place for each of the new APIs,
with a different level of effort during each work phase.
In the initial design phase, tasks include determining available resources (for example,
personnel, hardware, cloud storage space, etc.), assessing whether to use in-house or contracted
191U.S.BureauofLaborStatistics(2021,March31).May2020NationalOccupationalEmploymentandWage
Estimates.Retrievedfromhttps://www.bls.gov/oes/2020/may/oes_nat.htm.
192OfficeoftheNationalCoordinatorforHealthInformationTechnology(2019,June4).ImprovedDiagnostics&
PatientOutcomes.Retrievedfromhttps://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-
outcomes. resources to facilitate an API connection, convening a team to scope, build, test, and maintain the
API, gap analysis, and gap mitigation. During the development and testing phase, impacted
payers will conduct mapping of existing data to the FHIR standards, hardware allocation for the
necessary environments (development, testing, production), building a new FHIR-based server
or leveraging existing FHIR servers, determining the frequency and method by which internal
data are populated on the FHIR server, building connections between the databases and the FHIR
server, performing capability and security testing, and vetting provider requests.
Table J3 summarizes the aggregate burden for complying with the Provider Access API
requirements. We provide illustrative points to explain the calculations within the table and the
terms used for the headings. The occupational categories on the left side of the table include the
titles of the types of labor categories who will perform the work, for example, Database
Administrators and Architects, Engineers, and ComputerSystem Analysts.
On the top row, under the label Database Administrators, the labor cost of $97.20 per
hour was obtained from the BLS. The $97.20 represents the mean wage for this occupational
title. The calculations in Table J3 reflect time over the period of the project. We estimate that a
Database Administrator mightspend 480 hours in total to complete this task. The 480 hours are
found in the column titled Primary Hours. The word primary, as used in the CMS
Interoperability and Patient Access final rule (85 FR 25510), refers to the amount of time most
organizations would require for this work. The total cost of $46,656 for each organization is
obtained by multiplying the 480 hours by the $97.20 per hour wage. This $46,656 is found in the
column labeled Total Cost, Primary.
We provide low and high estimates representing a range of possible time and costs across
allorganizations. The low estimate is half the primary estimate, which is 240 hours. The high
estimate is 720 hours. These numbers are found in the low and high columns (hours) of the top
row. The corresponding low and high costs are obtained by multiplying the low and high estimates of hours by the $97.20 per hour wage. This is a reasonable range that captures the
amount of time and cost all organizations may spend on completing this work.
The explanation provided for the top row applies to each of the ten occupational titles.
The sum of the total hours and costs provides a typical organization's total cost. This number is
found in the Totals for a Single Impacted Payer row. As depicted, the typical organization
might take a total of 2,800 hours at a cost of $270,045. We estimate the impact by organization
rather than by payer since many organizations may have entities in several of the programs to
which this final rule applies: MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.
To arrive at the total cost of the final rule, we multiplied the single organization cost by
365 payers  that is, the number of organizations hosting plans across the programs. For
example, the total primary hourly burden of the rule is 1,022,000 (365 organizations  2,800 for
a single organization).
Similar to the methodology used in the CMS Interoperability and Patient Access final
rule (85 FR 25510), we estimate maintenance costs for future years after the API is established at
25 percent of the aggregate cost. We arrived at 25 percent based on our experience with the
industry. Rather than list more columns or create another table, we provide a footnote indicating
that maintenance is estimated to be 25 percent of the cost. For example, the primary aggregate
burden over all 365 organizations is $98.6 million, implying that the annual maintenance costs
are expected to be $24.6 million (25 percent  $98.6 million).
TABLE J3: AGGREGATE BURDEN FOR COMPLYING WITH THE PROVIDER
ACCESS API REQUIREMENTS
TotalCost TotalCost TotalCost
Labor (Wages* (Wages* (Wages*
Occupational Cost Hours Hours Hours Hours) Hours) Hours)
OccupationTitle Title ($/Hour) (Low) (Primary) (High) (Low) (Primary) (High)
DatabaseAdministratorsandArchitects 15-1245 $97.20 240 480 720 $23,328 $46,656 $69,984
Engineers,AllOther 17-2199 $102.94 160 320 480 $16,470 $32,941 $49,411
ComputerSystemsAnalysts 15-1211 $95.22 80 160 240 $7,618 $15,235 $22,853
GeneralandOperationsManagers 11-1021 $120.90 160 320 480 $19,344 $38,688 $58,032
OperationsResearchAnalysts 15-2031 $46.42 160 320 480 $7,427 $14,854 $22,282
SoftwareandWebDevelopers 15-1250 $105.72 120 240 360 $12,686 $25,373 $38,059
ComputerandInformationSystemsManagers 11-3021 $155.52 120 240 360 $18,662 $37,325 $55,987
Designers,AllOther 27-1029 $68.60 160 320 480 $10,976 $21,952 $32,928
TechnicalWriters 27-3042 $75.56 40 80 120 $3,022 $6,045 $9,067
ComputerandInformationAnalysts 11-3021 $96.80 160 320 480 $15,488 $30,976 $46,464 TotalCost TotalCost TotalCost
Labor (Wages* (Wages* (Wages*
Occupational Cost Hours Hours Hours Hours) Hours) Hours)
OccupationTitle Title ($/Hour) (Low) (Primary) (High) (Low) (Primary) (High)
Totalsforasingleimpactedpayer 1,400 2,800 4,200 $135,022 $270,045 $405,067
Totalsforallrelevantimpactedpayers 511,000 1,022,000 1,533,000 $49,283,176 $98,566,352 $147,849,528
*Estimatedburdenisthetotalburdenofimplementation.Theburdenisapportionedover36monthsinTableJ9.Annualmaintenancecostsare25
percentoftotalimplementationcosts.Thetimeframeof36monthsrepresentsthelagbetweenthepublicationofthefinalruleandthecompliance
datefortheAPIofJanuary1,2027.
*ThistablecontainspreparatorycomputationsusedforcreatingTableJ9;theyarenotdefinitivestatementsofburden.TableJ9istheofficial
COIstatementofburden,includingthenumberofrespondentsandresponses.ThisisthesameformatusedintheCMSInteroperabilityand
PatientAccessfinalrule.
*Note:TableJ3(asothertablesinthissection)reflectscalculationsbyspreadsheet;therefore,minorinconsistenciesareduetorounding.
Although compliance with this provision will be required on January 1, 2027, we believe
it is reasonable to assume that this API will have to be under development before this date to
conduct testing and ensure compliance. Acknowledging that impacted payers will have varying
technological and staffing capabilities, as we did in the first CMS Interoperability and Patient
Access final rule (85 FR 25606), we are finalizing our estimate that the development of this API
will require 1,400 to 4,200 hours of work. We have distributed the cost over 3 calendar years to
give impacted payers the flexibility to complete the necessary work (see Table J9).
Comment: A few commenters disagreed with CMSs calculations for the total burden
regarding hours and costs across all impacted payers and stated that the estimates are
significantly understated. These commenters stated that they were not confident that the
proposed rule captured the true cost of transitioning to the technical standards.
Response: We acknowledge comments about our calculations capturing the costs of
transitioning to the technical standards, however, the commenters who made these statements did
not include any supporting data which we could analyze or include in the final rule. We are
aware of and have included available information in our estimates and analysis to address
connections, testing, security, and onboarding of third parties, to accommodate the potential
costs and burden for each API implementation. Additionally, we believe our estimates are the
best possible, without additional information, and reasonable assumptions of staff and time, with
ranges to account for low and high costs. We welcome continued input from payers and
developers based on implementation of the Patient Access and Provider Directory APIs from the CMS Interoperability and Patient Access final rule, as well as the requirements finalized in this
final rule. Such information will also be informative for purposes of future rulemaking.
Comment:A commenter noted that it is unrealistic for CMS to expect that the industry
can obtain the resources necessary to comply with the provisions outlined in the proposed rule
within the current budget year when the requirements will not be finalized until the final rule is
issued. The commenter recommended that CMS revise the compliance dates of these provisions
to be 36 months after issuance of the final rule and scheduled on a date other than the end of a
calendar year.
Response: We have acknowledged the constraints on both budget cycles for certain
impacted payers such as state Medicaid and CHIP agencies, as well as the technical complexities
of implementation, and are finalizing a compliance date in 2027 for policies in this finalrule that
require API development or enhancement. As explicitly noted previously, the hours of work
needed to build the API as indicated in Table J3, acknowledges that impacted payers will have
varying technological and staffing capabilities.
a. API Maintenance Costs  All APIs
The third phase for implementation is long-term support and maintenance. Here we
discuss our methodology for the development of the costs in aggregate for all APIs outlined in
this finalrule. As relevant to the APIs discussed in sections III.C.2., 3., and 6. of this final rule,
we estimate ongoing maintenance costs for the Provider Access, Payer-to-Payer, and Prior
Authorization APIs, in aggregate. The costs of the API development are split into three phases:
initial design, development and testing, and long-term support and maintenance. We assume that
maintenance costs only account for the cost associated with the technical requirements as
outlined in this rule. Any changes to requirements would add burden, which would be discussed in future rulemaking. Throughout this section, we discuss the initial design, development, and
testing costs per API. This final rule addresses the total maintenance cost for all three APIs.
As discussed in the first CMS Interoperability and Patient Access final rule (85 FR
25606), once the API is established, there will be an annual cost to maintain the FHIR server,
including the cost of maintaining the necessary patient data and performing capability and
security testing. We believe there are efficiencies to be gained in implementation and
maintenance since the APIs rely on several of the same underlying foundational technical
specifications and content. For example, the same standards will be used to implement the new
APIs as were used to implement the Patient Access and Provider Directory APIs, including
FHIR and complementary security and app registration protocols. We also believe that
maintenance costs will be higher than whatwe estimated for the CMS Interoperability and
Patient Access final rule for the new APIs in this final rule, as our estimates also account for new
data mapping needs, standards upgrades,additional data storage, system testing, initial bug fixes,
fixed-cost license renewals, contracting costs, and ongoing staff education and training.
To account for these maintenance costs, we based our estimates on input from industry
experience piloting and testing APIs for provider access, prior authorization, and payer to payer
data exchange. We estimated an annual cost averaging approximately 25 percent of the primary
estimate for one-time API costs. In Table J9, we accountfor this maintenance cost separately for
each API (at 25 percent of the one-time API cost). As discussed previously, the overlap in some
of the recommended IGs across the APIs should result in shared efficiency that we believe
supports the assumption that maintenance should be accounted for in aggregate and is presented
in this section as such.
We requested public comment on our approach and assumptions for the aggregate
maintenance cost of the APIs, including whether our estimate was reasonable or should be
modified, and did not receive specific comments on the aggregate maintenance costs. 3. Information Collection Requirements Regarding the Prior Authorization API (42 CFR
422.122, 431.80, 438.242, 457.732, and 457.1233 and 45 CFR 156.223)
This API addresses ongoing challenges of the prior authorization process, including
identifying whether a prior authorization is required for an item or service; identifying the payer
documentation requirements for prior authorization; compiling the necessary data elements to
populate the HIPAA-compliant priorauthorization transactions; and enabling payers to provide a
specific response regarding the status of the prior authorization, including information about the
reason for denial. We are finalizing the requirement for impacted payers to implement and
maintain a Prior Authorization API in this final rule. Use of the Prior Authorization API will
begin 2027 (by January 1, 2027, for MA organizations and Medicaid and CHIP FFS programs;
by the rating period beginning on or after January 1, 2027, for Medicaid managed care plans and
CHIP managed care entities; and for plan years beginning on or after January 1, 2027, for QHP
issuers on the FFEs).
As discussed previously, with respectto the Provider Access API, we estimate that
impacted payers will need to conduct three major work phases to implement the requirements for
the Prior Authorization API: initial design, development and testing, and long-term support and
maintenance. Furthermore, for the Prior Authorization API, additionaltasks are necessary to
accomplish the requirements. For the costs for the third phaselong-term support and
maintenanceour methodology for the development of those costs in aggregate for all APIs is
presented in section III.D. of this final rule.
We based our estimate on feedback from industry experts on the anticipated burden of
implementing the Prior Authorization API and on current pilots. We continue to believe the
estimates to be reasonable regarding the implementation burdens on impacted payers to develop
APIs that can facilitate the prior authorization process. In addition to implementing this API,
impacted payers will be required to send a specific reason for prior authorization requests that
are denied. As discussed in section II.D. of this final rule, while the Prior Authorization API will use the FHIR standard to support its basic capabilities, covered entities must also use the adopted
X12 278 transaction standard and remain HIPAA-compliant. Given the added complexity of
accounting for the HIPAA standards, we have accounted for the multiple skill sets required and
licensing costs for accessing the X12 standards in developing the burden estimates. The
recommended HL7 IGs are freely available, as HL7 provides access to all IGs as open-source
materials. This makes the HL7 standards, IGs, reference implementations, and test scripts
available free of charge to the health care and developer community but requires usage and
possibly transaction costs for the X12 standards. We have accounted for the necessary engineers,
subject matter experts, and health informaticists in our estimates. These personnel resources will
need to convert payers prior authorization rules into computable, structured formats, create
provider questionnaires regarding whether a patient had a medical necessity for a medical item or
service, create formats that can interface with the providers EHR or practice management
system, create and execute mapping between the HL7 and X12 codes, and integrate the Prior
Authorization API with external systems or servers.
Though this provision will be effective on January 1, 2027, this API will be under
development before that date. Acknowledging that impacted payers have varying technological
and staffing capabilities, we estimate that the development of the API will require 5,440 to
16,320 hours of work. In Table J9, we have distributed the cost over approximately 3 calendar
years to give impacted payers the flexibility to complete the necessary work.
Table J4 presents total burden estimates for the Prior Authorization API (initial design,
followed by development and testing). This table presents the calculations associated with the
total costs. The numbers from this table are used in Table J9 to present costs per year for 3 years.
Based on the same assumptions as those included in the CMS Interoperability and Patient Access
final rule (85 FR 25510), we used the medium estimate as the primary estimate. The narrative description provided for Table J3 also applies to Table J4. Both tables
estimate API costs for 365 organizations and indicate follow-up annual maintenance costs by
analyzing costs for a single payer using a team spanning approximately ten occupational titles. THEPRIORAUTHORIZATIONAPI* CostCostCost(LaborCost*(LaborCost*(LaborCostWages*Hours)Hours)Hours)(Low)(Primary)(High)$373,192$746,383$1,119,575$32,941$65,882$98,822$23,328$46,656$69,984$63,180$126,360$189,540$18,135$36,270$54,405$30,470$60,941$91,411$30,976$61,952$92,928$572,222$1,144,444$1,716,665$208,860,957$417,721,914$626,582,871ms,Medicaidmanagedcareplans,CHIPmanagedcareentities,and maintenancecostsare25percentoftotalimplementationcosts.burden.TableJ9istheofficialCOIstatementofburden,including
TABLEJ4:TOTALBURDENESTIMATESFORIMPACTEDPAYERSFOR LaborOccupationalHoursHoursHoursCostTitlesOccupationTitle($/Hour)(Low)(Primary)(High)SoftwareandWebDevelopers15-1250$105.723,5307,06010,590Engineers,AllOther17-2199$102.94320640960ComputerandInformationSystemsManagers11-3021$155.52150300450DatabaseAdministratorsandArchitects15-1245$97.206501,3001,950GeneralandOperationsManagers11-1021$120.90150300450ComputerSystemsAnalysts15-1211$95.22320640960ComputerandInformationAnalysts15-1210$96.80320640960TotalsperImpactedPayer5,44010,88016,320TotalsforallrelevantImpactedPayers**1,985,6003,971,2005,956,800**Thistotalisbasedonourestimateof365entitiesbetweentheMAorganizations,stateMedicaidandCHIPFFSprograHPissuersontheFFEs.NOTES:+Estimatedburdenisthetotalburdenofimplementation.Thisburdenisapportionedover36monthsinTableJ9.Annual++TablesJ2throughJ8containpreparatorycomputationsusedforcreatingTableJ9;theyarenotdefinitivestatementsofenumberofrespondentsandresponses.
Q h
t We requested public comment on our approach and assumptions for the implementation
cost of the Prior Authorization API, including whether our estimates and ranges are reasonable
or should be modified. We did not receive any comments on this section.
4. Information Collection Requirements Regarding Requirements to Send Prior Authorization
Decisions Within Certain Timeframes (42 CFR 422.568, 422.570, 422.631, 438.210, 440.230,
457.495, and 457.1230)
Patients need to have timely access to care, and providers need to receive timely
responses to their requests for authorization to requests for services for their patients, particularly
when waiting for answers can delay the pursuit of alternatives. To increase transparency and
reduce burden, we are finalizing our proposal to require that certain impacted payers, not
including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for
expedited requests and 7 calendar days for standard requests. Impacted payers will have to
comply with these provisions beginning January 1, 2026. We note that Medicaid managed care
plans and CHIP managed care entities will have to comply with these provisions by the rating
period beginning on or after January 1, 2026.
To implement this policy, there will be up-front costs for impacted payers to update their
policies and procedures. We anticipate this burden per payer is 8 hours of work by a general and
operations manager to update the policies and procedures, reflecting two half-days of work at a
per-entity cost of $967. Therefore, the totalburden for all 365 impacted payers is 2,920 hours of
work at a first-year cost of $0.4 million (rounded). These calculations are summarized in Table
J5.
TABLE J5: FIRST-YEAR COST TO UPDATE POLICIES AND PROCEDURES TO
SEND PRIOR AUTHORIZATION DECISIONS WITHIN CERTAIN TIMEFRAMES
LaborCost Cost
Item Hours ($/Hour) (Hours*Labor)
ImpactperImpactedPayer 8 $120.90 $967
TotalsforallrelevantImpactedPayers 2,920 $120.90 $353,028
*TablesJ2throughJ8containpreparatorycomputationsusedforcreatingTableJ9;theyarenotdefinitivestatementsofburden.Table
J9istheofficialCOIstatementofburdenincludingthenumberofrespondentsandresponses. We requested public comment on our assumptions, estimates, and approach but received
no comments on this proposal and therefore are finalizing these estimates without modification.
5. Information Collection Requirements Regarding the Requirement for Public Reporting of
Prior Authorization Metrics (42 CFR 422.122, 438.210, 440.230, 457.732, and 457.1230 and 45
CFR 156.223)
To support transparency for patients to understand prior authorization processes, provide
some assistance in choosing health coverage, and for providers when selecting or evaluating
payer networks we are finalizing our proposal to require that impacted payers publicly report
certain prior authorization metrics on their websites. Impacted payers will be required to report
aggregated data annually for the previous calendar years data, beginning March 31, 2026.
We estimate that impacted payers will conduct two major work phases: implementation,
which includes defining requirements, system design, and updates to generate and compile
reports; and maintenance, including an annual compilation of reports and public reporting of
metrics on a website. In the first phase, impacted payers will need to define requirements
concerning the types and sources of data that need to be compiled regarding prior authorization
activities and data, build the capability for a system to generate reports, and update or create a
public webpage to post the data. In the second phase, impacted payers will need to create the
reports and post them to a public webpage annually.
Table J6 itemizes the activities, hours, and dollar burdens for the first-year
implementation and estimated annual maintenance costs. We assumed a team of two staff
consisting of a software and web developer with a business operations specialist.
 First-year implementation will impose a burden of 320 hours for the first year and 120
hours for subsequent years, at the cost of $30,000 and $9,000 (rounded), for the first and
subsequent years, respectively.  The aggregate burden of the first-year implementation across 365 impacted payers will
be 117,000 hours and 44,000 hours (rounded) for the first and subsequent years, respectively, at
a cost of $10.8 million and $3.3 million (rounded) for the first and subsequent years.
TABLE J6: AGGREGATE BURDEN FOR COMPLYING WITH PUBLIC REPORTING
OF PRIOR AUTHORIZATION METRICS
Development
Labor Hours Maintenance 1stYear Annual
Cost (1stYear Hoursper Development Maintenance
Occupational ($/ Only) Year Cost Cost
OccupationTitle Titles Hour) (Hours) (Hours) ($) ($)
SoftwareandWebDevelopers 15-1250 $105.72 180 0 $19,029.60 $0.00
BusinessOperationsSpecialists 13-1000 $75.32 140 120 $10,544.80 $9,038.40
TotalsperImpactedPayer 320 120 $29,574 $9,038
TotalsforallrelevantImpactedPayers 116,800 43,800 $10,794,656 $3,299,016
*ThistablecontainspreparatorycomputationsusedforcreatingTableJ9;theyarenotdefinitivestatementsofburden.TableJ9isthe
officialCOIstatementofburdenincludingthenumberofrespondentsandresponses.
6. Information Collection Requirements Regarding the Payer-to-Payer API Implementation (42
CFR 422.121, 431.61, 438.242, 42 CFR 457.731, and 457.1233 and 45 CFR 156.222)
Patients may wish to carry certain health information with them when they change
payers, in part so that they can track the services they have received, and to ensure that a new
payer has information about their past health history for purposes of managing their care with
new or current providers. We are finalizing the requirements for impacted payers to implement
and maintain a Payer-to-Payer API as described in section II.C. of this final rule. These
provisions will improve care coordination among payers by requiring payers to exchange, at a
minimum, adjudicated claims and encounter data (excluding provider remittances and patient
cost-sharing information), all data classes and data elements included in a content standard at 45
CFR 170.213 (USCDI), and certain information about prior authorizations. This exchange will
be required via a Payer-to-Payer API beginning in 2027 (by January 1, 2027, for MA
organizations and Medicaid and CHIP FFS programs; by the rating period beginning on or after
January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for plan
years beginning on or after January 1, 2027, for QHP issuers on the FFEs). As discussed for the other APIs in this rule, impacted payers will conductthree major
work phases: initial design, development and testing, and long-term supportand maintenance.
There will be some costs for impacted payers to implement the Payer-to-Payer API that
are unique to this API. There could be costs to test and integrate the Payer-to-Payer API with
payer systems, albeit potentially lower costs than those estimated for the ProviderAccess API.
We estimate the one-time implementation costs at about one-third the cost of a full de novo
Provider Access API implementation based on input from developers who have implemented
and piloted prototype APIs using the required standards. We accounted for the necessary skill
sets of staff required as we also believe there will be unique costs for implementing the PDex IG
so that payers can exchange active and pending prior authorization decisions and related
documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer.
Table J7 presents the total activities, hours, and dollar burdens for implementing the
Payer-to-Payer API given our assumptions on the initial design phase and the development and
testing phase. Based on the same assumptions as those published in the CMS Interoperability and
Patient Access final rule (85 FR 25510), we have the medium estimate as the primary estimate.
We provide the following narrative explanation of Table J7:
 For the primary estimate, one-time implementation efforts for the first two phases will
require, on average, a total of 916 hours per organization at an average cost of $96,072 per
organization.
 The aggregate burden of the one-time implementation costs across 365 impacted
payers will be 334,000 hours (rounded) at the cost of $35.1 million (rounded).This corresponds
to the primary estimate; the low and high estimates are obtained by multiplying the primary
estimate by factors of one-half and one and one-half, respectively.
TABLE J7: TOTAL BURDEN ESTIMATES FOR THE PAYER-TO-PAYER API*
TotalCost TotalCost TotalCost
Labor (Wages* (Wages* (Wages*
Occupational Cost Hours Hours Hours Hours) Hours) Hours)
OccupationTitle Titles ($/Hour) (Low) (Primary) (High) (Low) (Primary) (High)
Generaland
Operations
Managers 11-1021 $120.90 48 96 144 $5,803 $11,606 $17,410 Computerand
InformationAnalysts 11-3021 $96.80 43 86 129 $4,162 $8,325 $12,487
SoftwareandWeb
Developers 15-1250 $105.72 415 830 1245 $43,874 $87,748 $131,621
TotalsperImpacted
Payer 458 916 1374 $48,036.20 $96,072 $144,109
Totalsforall
relevantImpacted
Payers 167,170 334,340 501,510 $17,533,213 $35,066,426 $52,599,639
*Estimatedburdenisthetotalburdenofimplementation.
Though this provision will be effective on January 1, 2027, the API will be under
development before that date. Acknowledging that impacted payers will have varying
technological and staffing capabilities, the development of the API will require 458 to 1,374
hours of work. In Table J9, we have distributed the cost estimates over 3 calendar years to give
impacted payers the flexibility to complete the work.
We requested public comment on our approach and assumptions for the cost of the Payer-
to-Payer API, including whether our estimates and ranges are reasonable or should be modified,
and received none.
7. Information Collection Requirements Regarding the Electronic Prior Authorization Measure
for Merit-based Incentive Payment System and the Medicare Promoting Interoperability Program
The estimates in this section have been submitted to OMB in a PRA package (OMB
control number 0938-1278). The burden associated with the proposed requirement for eligible
hospitals and CAHs to report the Electronic Prior Authorization measure for the Medicare
Promoting Interoperability Program will be captured in the next revision to the PRA package
currently approved under OMB control number 0938-1278 (CMS-10552).
As explained in section II.F. of this final rule, in response to the December 2020 CMS
Interoperability proposed rule (85 FR 82586), commenters indicated that provider reporting
would be an appropriate lever by which CMS could encourage using the APIs to enable
enhanced electronic documentation discovery and facilitate electronic prior authorization. Thus,
to encourage MIPS eligible clinicians, eligible hospitals, and CAHs to implement and use
electronic prior authorization and the corresponding API, we proposed to add a new measure,
called the Electronic Prior Authorization measure, for MIPS eligible clinicians under the MIPS Promoting Interoperability performance category and for eligible hospitals and CAHs under the
Medicare Promoting Interoperability Program. After consideration of public comments,we have
modified the Electronic Prior Authorization measure requirements which are further described
and addressed in section II.F. of this final rule.
We are finalizing that MIPS eligible clinicians would report the Electronic Prior
Authorization measure beginning with the CY 2027 performance period/2029 MIPS payment
year (rather than the CY 2026 performance period/2028 MIPS payment year) and that eligible
hospitals and CAHs would report the Electronic Prior Authorization measure beginning with the
CY 2027 EHR reporting period (rather than the CY 2026 EHR reporting period). For the CY
2027 performance period/2029 MIPS payment year for MIPS eligible clinicians and the CY
2027 EHR reporting period for eligible hospitals and CAHs, we are finalizing with a
modification that the Electronic Prior Authorization measure be structured as an attestation
(yes/no), instead of a numerator and denominator measure as originally proposed for both MIPS
eligible clinicians, and eligible hospitals and CAHs. As an attestation measure, MIPS eligible
clinicians, eligible hospitals, and CAHs are required to report a yes or no response or report
an applicable exclusion, for the Electronic Prior Authorization measure. Additionally, we are
finalizing that this measure will not be assigned points.
For the MIPS Promoting Interoperability performance category, satisfactory performance
on this measure can be demonstrated only by reporting a yes response or claiming an
applicable exclusion. A no response will result in the MIPS eligible clinician failing to meet
the minimum reporting requirements, and therefore not being considered a meaningful EHR user
for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined in 42 CFR 414.1305, for
the MIPS payment year. MIPS eligible clinicians who do not report a yes response or claim an
applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do
not submit the measure or report a no response on the attestation without claiming an
applicable exclusion) will not earn a score for the MIPS Promoting Interoperability performance category (a score of zero for the category). A MIPS eligible clinicians score in the Promoting
Interoperability performance category is generally worth 25 percent of their total final score for
MIPS (42 CFR 414.1375(a);414.1380(c)(1)).
For the Medicare Promoting Interoperability Program, only a yes response on the
attestation, or claiming an applicable exclusion, will fulfill the minimum requirements of this
measure. A no response will result in the eligible hospital or CAH failing to meet the
minimum program requirements, and therefore would not be considered a meaningful user of
CEHRT, as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR
495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program
requirements are subject to a downward payment adjustment.
The burden in implementing these requirements consists of reporting an attestation (a
yes or no response) or claiming an exclusion. In the RIA, section IV. of this final rule, we
estimate burden based on the effort it takes to report a response for the measure. This estimated
burden to report would be the same whether it is to reporta yes or no response or to report a
numerator and denominator as initially proposed. Therefore, modifying the measure to be
reported as an attestation does not change the overall cost estimates included in the RIA for this
provision. System maintenance is an umbrella term that includes all activities needed to keep a
system running. The two main components of system maintenance are preventive and corrective
maintenance, which include software tasks such as fixing bugs, updating data sources, deleting
old software tasks, adding new tasks, testing, and verification. Maintenance requirements for
systems were estimated at 25 percent of total software creation costs, reflecting updates and bug
fixes, as well as deletion and creation of software tasks (85 FR 82649). There will be a moderate
software update to implement the provisions of this final rule, and there will be no added burden
over and above the burden of maintaining already existing software.
The data for the reports on prior authorizations and related claims should already be
stored in the system software of health care providers who may be required to retain such data for compliance and regulatory reasons. To report the Electronic Prior Authorization attestation
(yes/no) measure as specified by CMS, the provisions in this rule should not impose a significant
burden of denoting the information in the system.
For the added burden of extracting, compiling, reviewing, and submitting the attestation,
we assume that for each report, a Medical Records Specialist will spend about half a minute
(0.0083 hours) extracting the already-existing data at a cost of $0.39 (1/120 hour (12 minute) 
$46.42 per hour). To obtain the aggregate burden, we multiply by the number of entities. This is
done separately for eligible hospitals and CAHs, and MIPS eligible clinicians in Table J8.
TABLE J8: AGGREGATE ESTIMATES FOR THE ELECTRONIC PRIOR
AUTHORIZATION MEASURE
MIPSPromotingInteroperability
MedicarePromotingInteroperability PerformanceCategoryMIPSEligible
ItemEstimate Program-EligibleHospitalsandCAHs Clinicians
NumberofEntities 4,500 54,770
MeanHourlyWageforaMedicalRecords
$46.42 $46.42
Specialist
HourlyBurdenPerEntity 1/120Hour 1/120Hour
(1/2minute) (1/2minute)
0.00833Hour 0.00833Hour
TotalHourlyBurden 37.5 456.4
AggregateCostinDollars $1,741 $21,186
AggregateCostinMillionsofDollars $0.002 $0.021
*ThetableestimatesusemeanhourlywagesforamedicalrecordsspecialistfortheMedicarePromotingInteroperabilityProgramand
MIPS.TableJ9recordsthisas$0.0millionconsistentwithRIAaccountingrules.
The following items provide support and rationale for the entries in Table J8:
 The hourly burden estimates of 12 minute (1/120 = 0.00833 hour) for transmission of
the Electronic Prior Authorization attestation (yes/no) response to CMS are consistent with the
revised estimates of burden presented in the FY 2024 IPPS/LTCH proposed rule (88 FR 27204).
The hourly burden estimates forthe Electronic Prior Authorization measure are based on the
collection of burden estimates calculated for the Query of Prescription Drug Monitoring Program
measure.
 The estimate of 4,500 hospitals (including eligible hospitals and CAHs) is consistent
with the revised estimates presented in the FY 2024 IPPS/LTCH final rule (88 FR 27205).
 The existing MIPS reporting policies allow MIPS eligible clinicians to report at the
individual or group level. As noted in the CY 2024 PFS proposed rule (88 FR 52666), CMS did
not propose any submission changes for the MIPS Promoting Interoperability performance category and therefore refers to previous rules for respondent and burden estimates. In Table 132
of the CY 2023 PFS final rule (87 FR 70163), the estimated number of respondents submitting
MIPS Promoting Interoperability performance data was based on 2021 participation data
collected during the PHE for the COVID-19 pandemic. We anticipate that participation will
change over the next 10 years and volumes will rebound to pre-pandemic numbers. We
determined that the respondent estimates in Table 122 of the CY 2023 PFS proposed rule (87 FR
46370) are more representational of what we anticipate participation will look like when the
Prior Authorization API and associated Electronic Prior Authorization measure provisions are
implemented given that these estimates are based on pre-pandemic participation data from CY
2019. Therefore, we maintain that an estimated 54,770 individual or group MIPS eligible
clinicians will submit an attestation for the Electronic Prior Authorization measure under the
MIPS Promoting Interoperability performance category for the CY 2027 performance
period/2029 MIPS payment year. The 54,770 is the sum of the 43,117 individual MIPS eligible
clinicians, 11,633 groups, and 20 subgroups estimated to submit MIPS Promoting
Interoperability performance data.The ICRs currently approved under OMB control number
0938-1314 are approved through January 31, 2025.
 The FY 2024 IPPS/LTCH proposed rule uses mean hourly wage estimates (88 FR
27204), consistent with this final rule and the CMS Interoperability and Patient Access final rule
(85 FR 25605). For purposes of clarification, we have provided both mean and median estimates.
++ For eligible hospitals and CAHs, the total cost is $1,741 (4,500 hospitals and CAHs 
12 minute  $46.42 per hour), which equals $0.002 million as shown in Table J9. This rounds to
$0.0 million. Calculations using the median instead of the average after rounding are identical.
This shows that the bottom-line rounded figure would not change if we used the median instead
of the average. The entries in Table J9 are rounded numbers while the actual dollar amounts are
provided in Table J8. ++ For MIPS eligible clinicians, the total cost is $21,186 (54,770 clinicians  12 minute
 $46.42 per hour). Since Table J9 relates to Table K6 in the RIA, we expressed the $21,186
using RIA accounting standards, which require rounding to the nearest tenth of a million. It
follows that $21,186 is equivalent to $0.021 million, as shown in Table J9. This value is rounded
to $0.0 in the RIA.
Comment: A commenter stated the calculation for the aggregate estimates for the
Electronic Prior Authorization measure costs is unreasonable and lacks a reasonable basis. This
commenter stated there is no way for an employee to run a report in half a minute, as logging
into the computer system with two-factor authentication alone can take 1 to 2 minutes. The
commenter stated getting to the report in the EHR can take 12 to 1 minute and running a large
report can easily take 12 to 2 minutes. The report then needs to be verified and transmitted. The
commenter stated instead of half a minute, the process is closer to 5 to 10 minutes. Another
commenter stated that the analysis does not account for the payer burden of connecting and
testing with all EHRs and practice management systems, specifically the high costs and time
commitments. The commenter requested CMSs clarification on whether payers are only
required to share with EHR systems certified under the ONC Health IT Certification Program.
Response: We appreciate concerns about the timing for reporting but respectfully
disagree, particularly because we have modified the reporting specifications for the Electronic
Prior Authorization measure. We are finalizing this measure with modifications such that,
beginning with the CY 2027 performance period/2029 MIPS payment year and the CY 2027
EHR reporting period, a MIPS eligible clinician, eligible hospital, or CAH will reporta yes or
no response for the Electronic Prior Authorization measure or claim an exclusion, instead of a
numerator and denominator measure as originally proposed. If the MIPS eligible clinician,
eligible hospital, or CAH does not report a yes response for the Electronic Prior Authorization
measure or claim an exclusion, they will receive a zero score for the MIPS Promoting
Interoperability performance category or the Medicare Promoting Interoperability Program, respectively. We are finalizing reporting of the Electronic Prior Authorization measure as an
attestation (yes/no) measure beginning with the CY 2027 performance period/2029 MIPS
payment year and the CY 2027 EHR reporting period. With these modifications, completing and
reporting the attestation for the Electronic Prior Authorization measure will not take 10 minutes,
but significantly less time to enter into the reporting system. We are explicitly describing time
spent reporting the Electronic Prior Authorization measure in this final rule, and half a minute is
more representational for reporting a single attestation measure. The entire reporting process for
these programs may take longer to complete, for example, 5-to-10 minutes. The amount of time
it takes to report data to CMS is dependent on whether the person reporting the data needs to
establish their accountcredentials, the amount of data being reported, and the method through
which the data is being submitted. However, this calculation does notintend to calculate the
amount of time it takes to conduct the entire process or report all performance data, rather it is
solely evaluating the estimated amount of time a person would spend on reporting the Electronic
Prior Authorization measure.
We also acknowledge this commenters concern about the basis for the aggregate
estimates for the Electronic Prior Authorization measure. However, this commenter did not
provide additional data to which we could compare our estimates. Furthermore, we disagree with
the commenter as we used information from other interested parties as well as studies to
determine that the cost savings will be substantial after a period of years because of the
improvements in the prior authorization process for reducing manual effort and delays in
services.
We did notreceive any other comments on this section of the rule. After consideration of
public comments, we are finalizing the estimates without modification.
D. Summary of Information Collection Burdens
We have explained the costs of individual provisions in this section. Table J9 summarizes
costs for the first and subsequent years of these provisions and is based on the following assumptions:
 Modified compliance dates for the policies in this final rule that require API
development or enhancement, Medicare Promoting Interoperability Program, and MIPS
Promoting Interoperability performance category until the CY 2027 performance period/2029
MIPS payment year or CY 2027 EHR reporting period to give 3 years (36 months) for
appropriate implementation activities.
 Maintenance costs for the three APIs are, as indicated in the tables of this section,
assumed to be 25 percent of total costs; these maintenance costs will be incurred in CY 2027 and
subsequent years.
 Certain provisions will be effective in January 2026; thus, no costs are reflected from
2023 through 2025. However, for the building of the API systems, we assume impacted payers
will be performing these updates in CY 2024 through 2026 to be prepared for the CY 2027
compliance date.
 Labor costs in Table J9 are either BLS wages when a single staff member is involved
or a weighted average representing a team effort, which is obtained by dividing the aggregate
cost by the aggregate hours.
 Table J9 reflects the primary estimate. The full range of estimates for all provisions is
presented in the RIA section of this final rule. SubsequentYearCosts(Millions$) $1.1 $24.6 $104.4 $3.3 $8.8 $0.021 $0.002 $142
5 5 8 4 8 6 9
S* rd3YearCost(Millions$) $5. $32. $137. $0. $10. $11. $19
N
O 5 8 6 2
OVISI nd2YearCost(Millions$) $32. $137. $11. $18
R
ALLP st1YearCost(Millions$) $32.5 $137.8 $11.6 $182
NFOR EstimatedAnnualBurden(Hour) 58,400 14,600 1,022,000 255,500 3,971,200 992,800 2,920 116,800 43,800 334,340 83,585 456 37 6,896,438 R156.223.
E F
D C
BUR LaborCost($) $94.32 $75.32 $96.44 96.44 $105.19 $105.19 $120.90 $92.42 $75.32 $104.88 $104.88 $46.42 $46.42 Varies 3and45
3
N 2
1
ATIO meperpondentHour) 160 40 2,800 700 10,880 2,720 8 320 120 916 229 0.0083 0.0083 and457.
M Ties( 2,
R 730.
TABLEJ9:SUMMARYOFANNUALINFOR NumberofItemNotespondentsres porting,1styearCost(1)365PatientAccessAPIMetricsRe porting,subsequentyearcosts(1)365PatientAccessAPIMetricsRe ProviderAccessAPI,Development(2)365 ProviderAccessAPI,Maintenance(2)365 pment(3)365PriorAuthorizationAPI,Develo ,Maintenance(3)365PriorAuthorizationAPIUpdatePoliciesforCommunicatingDenialsforPriorAuthorization(4)365andTimeframesforPriorAuthorizationDecisions PublicReportingofPriorAuthorizationMetrics,1stYear(5)365 portingofPriorAuthorizationMetrics,subsequentyears(5)365PublicRe Payer-to-PayerAPI,Development(6)365 yer-to-PayerAPI,Maintenance(6)365PaAttestationforMIPSPromotingInteroperability,MIPSeligible,770clinicians54AttestationforMedicarePromotingInteroperabilityProgram,Eligiblepitals,andCAHs4,500HosTotalcombinedcostbyyearinmillionstoall365Organizations59,635(Payers),all54,770MIPSeligibleclinicians,andall4,500eligiblehospitalsandCAHs.*Thenumberofresponsesperrespondentisuniformly1andthereforeomitted.NOTES:(1)42CFR422.119,431.60,438.242,457.730,and457.1233and45CFR156.221.(2)42CFR422.121,431.61,438.242,457.731,and457.1233and45CFR156.222.(3)42CFR422.122,431.80,438.242,457.732,457.1233,422.122,431.80,438.242,457.(4)42CFR422.566,422.568,422.570,422.631,438.210,440.230,457.495,and457.123(5)42CFR422.122,438.210,440.230,457.732,and457.1233and45CFR156.223.(6)42CFR422.121,431.61,438.242,457.731,and457.1233and45CFR156.22. E. Conclusion
The provisions of this final rule are expected to improve data sharing across impacted
payers and providers by facilitating access, receipt, and exchange of patient data. We are
committed to providing patients, providers, and payers with timely access to patient health
information. We requested comments on our approaches for estimating cost burden and cost
savings and received a few comments which have been incorporated herein.
The requirements of this final rule are extensions of the requirements of the CMS
Interoperability and Patient Access final rule (85 FR 22510). Therefore, the ICRs have been
submitted to OMB for review and approval. IV. Regulatory Impact Analysis
A. Statement of Need
As described in prior sections of this final rule, the changes to 42 CFR parts 422, 431,
435, 438, 440, and 457 and 45 CFR part 156 further support CMSs efforts to empower patients
by increasing electronic access to health care data, while keeping that information safe and
secure. The provisions in this final rule build on the foundation we laid out in the CMS
Interoperability and Patient Access final rule to move the health care system toward increased
interoperability by enabling better data sharing capabilities of impacted payers, encouraging
health care providers use of new capabilities, and making health-related data more easily
available to patients through standards-based technology.
The provisions in this final rule place new requirements on MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs to further improve the electronic exchange of health-related data
and streamline prior authorization processes. We believe these provisions will improve health
information exchange and facilitate appropriate patient, provider, and payer access to health
information via APIs, while the policies related to prior authorization should improve certain
administrative processes. The final rule also adds a new attestation measure for eligible hospitals
and CAHs under the Medicare Promoting Interoperability Program and for MIPS eligible
clinicians under the MIPS Promoting Interoperability performance category.
B. Overall Impact
We examined the impacts of this final rule as required by Executive Order12866 on
Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving
Regulation and Regulatory Review (January 18, 2011), Executive Order 14094, entitled
Modernizing Regulatory Review (April 6, 2023), the Regulatory Flexibility Act (RFA)
(September 19, 1980, Pub. L. 96-354), Executive Order 13272 on Proper Consideration of Small
Entities in Agency Rulemaking (August 13, 2002), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (March 22, 1995, Pub. L. 104-4),and
Executive Order 13132 on Federalism (August 4, 1999) and the Congressional Review Act (5
U.S.C. 804(2)).
Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of
available regulatory alternatives and, if regulation is necessary, to select regulatory approaches
that maximize net benefits (including potential economic, environmental, public health, and
safety effects, distributive impacts, and equity). Executive Order 14094, entitled Modernizing
Regulatory Review, amends section 3(f)(1) of Executive Order 12866 (Regulatory Planning and
Review). The amended section 3(f) of Executive Order 12866 defines a significant regulatory
action as an action that is likely to result in a rule: (1) having an annual effect on the economy
of $200 million or more in any 1 year (adjusted every 3 years by the Administrator of the Office
of Information and Regulatory Affairs (OIRA) for changes in gross domestic product), or
adversely affect in a material way the economy, a sector of the economy, productivity,
competition, jobs, the environment, public health or safety, or state, local, territorial, or tribal
governments or communities; (2) creating a serious inconsistency or otherwise interfering with
an action taken or planned by another agency; (3) materially altering the budgetary impacts of
entitlementgrants, user fees, or loan programs or the rights and obligations of recipients thereof;
or (4) raise legal or policy issues for which centralized review would meaningfully further the
Presidents priorities or the principles set forth in this Executive order, as specifically authorized
in a timely manner by the Administrator of OIRA in each case.
Based on our estimates, OMBs OIRA has determined this rulemaking to be significant
per section 3(f)(1) as measured by having an annual effect of $200 million in at least 1 year, and
hence is also a major rule under Subtitle E of the Small Business Regulatory Enforcement
Fairness Act of 1996 (also known as the Congressional Review Act). Accordingly, we have
prepared an RIA that, to the best of our ability, presents the costs and benefits of this final rule. These provisions will result in some financial burden for impacted payers and certain
providers as discussed in section III. of this final rule. In the proposed rule,we weighed the
potential burdens against the potential benefits and believe the benefits outweigh the costs (87
FR 76340). Based on our estimates, the total burden across all providers would be reduced by at
least 220 million hours over 10 years, resulting in a total cost savings of at least $16 billion over
10 years as seen in Table K6. We did not include these savings in the 10-year Summary Table
(Table K9), nor in the Monetized Table (Table K11), as explained later on in this section of the
final rule.
Comment: Some commenters disagreed with CMSs calculated cost to implement the
provisions outlined in the proposed rule and expressed that the actual cost will be much higher
than estimated. A commenter stated that they fail to see how the estimated total burden across all
providers would be reduced by the proposed rules estimates of 206 million hours resulting in the
total cost saving of $15 billion that CMS asserted in the proposed rule.
Response: While we appreciate that commenters do not concur with the cost estimates,
we used the best available data to us at the time we developed the rule and made related
assumptions about the reduction in hours for clerical, nursing, and provider staff as a result of the
final policies. We are re-stating our assessments of those assumptions and calculations in this
final rule. Though commenters and implementers did not submit new data for consideration, we
did make a slight revision in the total cost savings to say at least $16 billion which includes
adjustments of where some of the savings would occur. The potential savings are significant, and
we firmly believe that the policies in this final rule will streamline operations, improve
efficiencies, and pave the way for substantial changes in the way staff use technology to
exchange data and conduct business, particularly for prior authorization. We welcome tangible
data from commenters which we could use for comparative analysis of costs and savings.
Comment: A commenter raised concerns with the impact analysis and cost calculations
CMS included in the proposed rule, taking issue with CMS using data that includes the cost of all prior authorizations, which includes prescription drugs (accounting for 70 percent of prior
authorizations), to calculate the savings potential of the proposed rule, as the policies do not
apply to all prior authorizations. The commenter stated that accurate calculations would likely
reveal that the rule as proposed is too costly to implement unless CMS modifies it to include
prior authorization for prescription drugs, as well as allhealth plans.
Response: We emphasize that this rule does not apply to prescription drugs that may be
self-administered, administered by a provider, or that may be dispensed or administered in a
pharmacy or hospital, or OTC drugs. We explicitly note that estimates do not include all prior
authorizations and that formulary prior authorizations are excluded from our calculation of
savings. In addition, this rule does not apply to all health plans and services, but rather to certain
impacted payers, including MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We
welcome alternative data to support further analysis and will continue to collect information as
the final rule is implemented.
C. Regulatory Flexibility Act
Executive Order 13272 requires that HHS thoroughly review rules to assess and take
appropriate account of their potential impact on small businesses, small governmental
jurisdictions, and small organizations (as mandated by the RFA). HHS considers a significant
impact to be 3 to 5 percent or more of the affected entities costs or revenues. For background on
the RFA references in the proposed rule, please see 87 FR 76340.
We confirm our analysis of the impacted entities as described in section IV.C. of this
final rule.
1. Payers
The 365 payer organizations will perform updates to systems to implement the required
APIs and prepare for reporting requirements. As in the proposed rule, we use the term parent organizations in this final rule to refer to the impacted payers (87 FR 76238). The combined
parent organizations administer MA plans, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the FFEs.
The North American Industry Classification System (NAICS) category relevant to these
provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, which has a $47.0
million threshold for small size. 75 percent of payers in this category have under 500 employees,
thereby meeting the definition of small businesses.
The 365 parent organizations, including state Medicaid and CHIP agencies, are
responsible for implementing and maintaining three new APIs, updating policies and procedures
to accommodate revised timeframes for making prior authorization decisions, and reporting
certain metrics either to CMS or making information available to the public. We determined that
state Medicaid and CHIP agencies, as well as many MA organizations, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs are not considered small
entities. Furthermore, MA organizations and Medicaid managed care plans and CHIP managed
care entities have many of their costs covered through capitation payments from the Federal
Government, and thus we conclude there is no significantburden on small entities in this final
rule.
We are finalizing the provisions that require API development or enhancement as
proposed. We also note that some QHP issuers on the FFEs will be able to apply for an exception
to these requirements, and certain states operating Medicaid and CHIP FFS programs will be
able to apply for an extension or exemption, under which they will not be required to meet the
new provisions of this final rule that require API development or enhancement on the
compliance dates, provided certain conditions are met, as discussed in section II.E. further
mitigating potential burden for those payers. a. Medicare Advantage
On an annual basis, MA organizations estimate their costs forthe upcoming year and
submit bids and proposed plan benefit packages to CMS. Upon approval, the plan commits to
providing the proposed benefits, and CMS commits to paying the plan either the full amount of
the bid, if the bid is below the benchmark (a ceiling on bid payments annually calculated from
Original Medicare data); or the benchmark amount, if the bid amount is greater than the
benchmark. Thus, there is a cost to plans to bid above the benchmark that is not funded by
government payments. Additionally, if an MA organization bids above the benchmark for any of
its plans, section 1854 of the Act requires the MA organization to charge enrollees a premium for
that amount. In the proposed rule, we provided a further explanation regarding MA
organizations bids and government payment processes for MA plans and MA plans with
prescription drug coverage (MA-PDs) and refer readers to that discussion for additional detail
(87 FR 76341).
Table K1 reports the percentage of MA organizations bidding above the benchmark,
along with the percentage of affected enrollees in recent years. This table reports aggregates of
proprietary bid data collected by the Office of the Actuary (OACT). The CMS threshold for what
constitutes a substantial number of small entities for purposes of the RFA is 3 to 5 percent. As
shown in Table K1, both the percentage of plans and the percentage of affected enrollees are
below this 3 to 5 percent threshold. Consequently, we conclude that the number of plans bidding
above the benchmark is not substantial for purposes of the RFA.
TABLE K1: PERCENTAGE OF PLANS BIDDING ABOVE BENCHMARK BY
YEAR
Projected
Enrollmentin
PlansthatBid
Numberof Abovethe Projected
UniqueBidIDs Benchmark Numberof Enrollment
thatBidAbove (Member UniqueBid (Member BidID Enrollment
Year theBenchmark Months) IDs Months) Percentage Percentage
2020 100 2,108,026 4,270 231,754,722 2.30% 0.90%
2021 66 1,167,779 4,837 259,609,169 1.40% 0.40%
2022 30 328,621 5,298 288,151,395 0.60% 0.10%
2023 12 101,297 5,660 313,317,522 0.21% 0.03% The preceding analysis shows that meeting the direct costs of this final rule does not have
a significant economic impact on a substantial number of small entities as required by the RFA.
There are certain indirect consequences of the finalpolicies, which will also have an
economic impact. We explained that at least 98 percent of MA organizations bid below the
benchmark. Thus, we estimate that their projected costs for providing services to Medicare
beneficiaries for the coming year are fully paid by the Federal Government. However, the
government additionally pays the plan a beneficiary rebate amount that is an amount equal to a
percentage (between 50 and 70 percent, depending on a plans quality rating) multiplied by the
amount by which the benchmark exceeds the bid. The rebate is used to provide additional
benefits to enrollees in the form of reduced cost-sharing or other supplemental benefits or to
lower the Part B or Part D premiums for enrollees (supplemental benefits may also partially be
paid by enrollee premiums). If the provisions of this final rule cause the MA organizations bids
to increase and if the benchmark remains unchanged or increases by less than the bid does, the
result will be a reduced rebate and, possibly fewer supplemental benefits, or higher premiums for
the health plans enrollees. However, as noted previously, the number of plans bidding above the
benchmark to whom this burden applies does not meet the RFA criteria of a significant number
of plans.
It is possible that if the provisions of this final rule cause bids to increase, MA
organizations will reduce their profit margins, rather than substantially change their benefit
packages. This may be in part due to market forces; a plan lowering supplemental benefits even
for 1 year may lose enrollees to competing plans that offer these supplemental benefits. Thus, it
can be advantageous to the plan to reduce profit margins, rather than reduce supplemental
benefits. With this, plans would balance competitive pressures with profit targets immediately
following a new regulation. As the regulations are typically finalized within a few months of the
bid submission deadline, plans may have more time to enact strategies that do not require large
benefit changes in subsequent years, such as negotiations for supplemental benefit offerings. However, it may be inappropriate to consider the relevant regulatory impacts (and thus the profit
considerations) as temporary because the issuance of a series of regulations sustains the
effects.193 As a result, changes in benefits packages may be plausible. We did not receive any
comments on this section of the RIA regarding small entities, nor on our assumptions about the
impact or the general summary of the structure for MA bids. We are therefore finalizing this
analysis as is. Based on the previously discussed considerations, the Secretary has certified that
this finalrule will not have a significant impact on a substantial number of small entities.
b. Medicaid and CHIP
Title XIX of the Act established the Medicaid program as a Federal-state partnership to
provide and finance medical assistance to specified groups of eligible individuals. States claim
Federal matching funds quarterly based on their program expenditures.Since states are not small
entities under the RFA, we need not discuss the burden imposed on them by this final rule.
Medicaid managed care plans and CHIP managed care entities receive 100 percent
capitation from the state; we expect that the projected costs associated with the provisions of this
final rule will be included in their capitation rates. Consequently, we assert that there will be no
substantial impact on a significant number of these entities.
As discussed in section II.E. of this final rule for the provisions that require API
development or enhancement, states operating Medicaid and CHIP FFS programs may apply for
an extension of 1 year to come into compliance with the requirements of this final rule. These
same organizations may also apply for an exemption from the requirements if certain conditions
are met.
193Seesimilardiscussioninpreviousregulatoryanalyses:ContractYear2023PolicyandTechnicalChangestothe
MedicareAdvantageandMedicarePrescriptionDrugBenefitPrograms,87FR27704(May9,2022).Retrieved
fromhttps://www.federalregister.gov/d/2022-09375;andChangestotheMedicareAdvantageandtheMedicare
PrescriptionDrugBenefitProgramforContractYear2021and2022,87FR22290(April14,2022).Retrievedfrom
https://www.federalregister.gov/d/2022-07642. Comments pertaining to the Medicaid and CHIP explanation of Federal matching funds
are addressed in that section of this final rule, as are those related to the extension and exemption
processes.
c. Qualified Health Plan Issuers on the Federally-Facilitated Exchanges
Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds
for a small business established by the SBA. Consistent with previous CMS analysis in the
SHOP/QHP final rule (78 FR 33233), we estimated that any issuers considered small businesses
would likely be subsidiaries of larger issuers that would not be considered small businesses (78
FR 33238), and thus would not share the same burdens as an independent small business.
Therefore, even though QHP issuers do not receive Federal reimbursement for the costs of
providing care, we do not conclude that there would be a significant small entity burden for these
issuers. In addition, an exception process is available to QHP issuers on the FFEs, which could
further help to address regulatory burden that could otherwise prohibit a QHP issuer from
participating in an FFE.
We did not receive any comments specific to the QHP summary section of this RFA.
Comments related to the exception process for QHPs are addressed in section II.E.
2. Providers
In response to public comments on the December 2020 CMS Interoperability proposed
rule (85 FR 82586), CMS proposed a new Electronic Prior Authorization measure for MIPS
eligible clinicians under the MIPS Promoting Interoperability performance category, and for
eligible hospitals and CAHs under the Medicare Promoting Interoperability Program. CMS
proposed that the Electronic Prior Authorization measure would be required for MIPS eligible
clinicians beginning with the CY 2026 performance period/2028 MIPS payment year and for
eligible hospitals and CAHs beginning with the CY 2026 EHR reporting year. However, after
consideration of substantial feedback from commenters described in section II.F. of this final
rule, we are finalizing a modification to the Electronic Prior Authorization measure proposal. Rather than requiring MIPS eligible clinicians, eligible hospitals, and CAHs to report a
numerator and denominator for the Electronic Prior Authorization measure, we are finalizing the
measure structured as an attestation (yes/no) measure for both MIPS eligible clinicians, and
eligible hospitals and CAHs. As an attestation measure, MIPS eligible clinicians, eligible
hospitals, and CAHs will report a yes or no response or report an applicable exclusion for
the Electronic Prior Authorization measure. Additionally, we are finalizing that this measure will
not be assigned points.
For the MIPS Promoting Interoperability performance category, satisfactory performance
on this measure can be demonstrated only by reporting a yes response or claiming an
applicable exclusion. A no response will result in the MIPS eligible clinician failing to meet
the minimum reporting requirements, and therefore not being considered a meaningful EHR user
for MIPS, as set forth in section 1848(o)(2)(A) of the Act and defined at 42 CFR 414.1305, for
the MIPS payment year. MIPS eligible clinicians that do not report a yes response or claim an
applicable exclusion for the Electronic Prior Authorization measure as specified (that is, they do
not submit the measure or report a no response on the attestation without claiming an
applicable exclusion)will not earn a score for the MIPS Promoting Interoperability performance
category (a score of zero for the category). A MIPS eligible clinicians score in the Promoting
Interoperability performance category is generally worth 25 percent of their total final score for
MIPS (42 CFR 414.1375(a);414.1380(c)(1)).
For the Medicare Promoting Interoperability Program, only a yes response on the
attestation, or claim of an applicable exclusion, will fulfill the minimum requirements of this
measure. A no response will result in the eligible hospital or CAH failing to meet the
minimum program requirements, therefore not being considered a meaningful user of CEHRT,
as defined in section 1886(n)(3) of the Act for an EHR reporting period (42 CFR 495.24(f)(1)(i)(A)). Eligible hospitals and CAHs that do not meet the minimum program
requirements are subject to a downward payment adjustment.
With regard to MIPS eligible clinicians, eligible hospitals, and CAHs, a discussion of the
burden is provided in section III., and supporting data are shown in Table J8. As noted
previously, we modified the provision forthe Electronic Prior Authorization measure in this final
rule based on comments indicating that the denominator calculation would impose a significant
burden on providers. We have calculated the burden per individual provider at under $2.50 per
year (12 minute of labor times an hourly wage of under $50).
Based on all information provided herein, we conclude that the requirements of the RFA
have been met by this final rule.
We did not receive comments on this subject in the RFA. The modification to the
Electronic Prior Authorization measure was not determined to have a significant financial effect
on this RIA because there is no need to re-calculate the numerator and denominator and the
information will be reported as an attestation. We are finalizing this section as is.
D. Unfunded Mandates Reform Act and Executive Order 13132 Requirements
Section 202 of the UMRA also requires that agencies assess anticipated costs and
benefits before issuing any rule whose mandates require spending in any 1 year of $100 million
in 1995 dollars, updated annually for inflation. In 2023, that threshold is approximately $177
million. This final rule will not impose an unfunded mandate that results in the expenditure by
state, local, and tribal governments, in the aggregate, or by the private sector, of more than $177
million in any 1 year.
Executive Order 13132 establishes certain requirements that an agency must meet when it
publishes a final rule that imposes substantial direct costs on state and local governments,
preempts state law, or otherwise has federalism implications. As previously outlined, while the
provisions that require API development or enhancement will be a requirement for state
Medicaid and CHIP agencies as described in this final rule, the cost per beneficiary for implementation is expected to be negligible when compared with the overall cost per beneficiary.
The analysis we conducted did not consider Federal matching funds provided to state Medicaid
and CHIP agencies, and the conclusion was the same: there is not expected to be a significant
cost impact on state entities.
For Medicaid and CHIP, we are unaware of any provisions in this final rule that conflict
with state law, and no commenters raised a pre-emption issue otherthan the timeframe issue
discussed later in this section. Therefore, we do not anticipate any preemption of state law. As
discussed in section II.D. of this final rule, some state laws regarding timeframes for prior
authorization decisions may be different than the provisions in this final rule. However, an
impacted payer will be able to comply with both state and Federal requirements by complying
with whichever imposes the shorter timeframe. We invited states to commenton the proposed
rule if they believed that any proposal in this rule would conflict with state law. We received a
few comments from states and other organizations regarding the preemption of state law
regarding timeframes and addressed these comments regarding prior authorization decision
timeframes and compliance with state law in section II.D. of this final rule.
As noted previously in this section, we considered whether the provisions in this final
rule imposed substantial costs on state or localgovernments, preempted state law, or had
federalism implications and concluded that the rule does not. Therefore, the requirements of
Executive Order 13132 are not applicable.
E. Regulatory Review Costs
If regulations impose administrative costs on private entities, such as the time needed to
read and interpret this final rule, we are required to estimate the cost associated with regulatory
review. We modeled our estimates of this burden based on similar estimates presented in the
CMS Interoperability and Patient Access final rule (85 FR 25510). In the proposed rule, we cited
three numbers that were needed to calculate this estimate: (1) number of staff per entity
performing the reading; (2)number of hours of reading; and (3) number of entities reviewing the final rule. We estimated a one-time aggregated total review cost of $1.3 million ($128.71 x 10
hours of reading time x 500 entities x two staff per entity). We requested comments on our
estimate and assumptions. However, we did not receive any comments. For further details on
this matter, refer to the proposed rule at 87 FR 76343. Therefore, we are finalizing the analysis
as presented.
F. Impact of Individual Proposals
The provisions of this final rule all have information collection-related burdens. This
information is provided in Table J9 in section III. of this final rule. Table K2 provides a list of
the ICRs by number and title, as well as the table numbers in which we provided an impact
assessment.
TABLE K2: CROSS-REFERENCES TO IMPACTS IN THE INFORMATION
COLLECTION REQUIREMENTS OF THIS FINAL RULE
Table
Number
forICRs
with
Impact
ICRNumber ICRTitle Analysis
1 PatientAccessAPIMetricsReportingtoCMSProvision TableJ2
2 ProviderAccessAPI TableJ3
3 PriorAuthorizationAPI TableJ4
4 TimeframesforPriorAuthorizationDecisionsProvision TableJ5
5 PublicReportingofPriorAuthorizationMetricsProvision TableJ6
6 Payer-to-PayerAPI TableJ7
7 ElectronicPriorAuthorizationMeasure(EligibleHospitals,CAHs,andMIPSeligibleclinicians)Provision TableJ8
SummaryTable 3-YearAnalysisofCostImpactofProvisions TableJ9
Additionally, this RIA section provides an analysis of expected savings to providers
arising from the replacement of paper documents related to prior authorization and other plan
requirements with EHRs. Although these savings are neither included in the Monetized Table
(Table K11) nor in the Summary Table (Table K9), we believe that these large savings are an
important consideration in understanding this final rule. We have identified our assumptions for
savings at the end of this section.
Comment: Severalcommenters sought clarification regarding CMSs analysis of how the
proposed rule would impact industry. Commenters stated that the discussion of the costs and
benefits of the proposed rule was not specific enoughand disagreed with CMSs claim thatthe benefits of the provisions are greater than the costs. Additionally, a commenter noted that the
costs estimated in the proposed rule vastly underestimate the true cost of implementing and
complying with the provisions. The commenters provided recommendations on certain concepts
and ideas that CMS should take into consideration when assessing the regulatory impact of this
rule.
A few commenters expressed concerns over the calculations associated with prior
authorization. For example, one commenter noted that CMS failed to account for the increase in
prior authorization burden since the publication of the Casalino report in 2009. Another
commenter noted that CMS failed to include a 2.5 percent fee for electronic prior authorization
transactions and the costs healthcare providers expect to incur. A commenter agreed that some
upfront costs would be incurred but noted that new burdens and costs would be imposed on
payers, which must be considered. Another commenter noted that there is little to no quantitative
or qualitative data to justify CMSs approach to calculating cost and savings associated with the
provisions in this rule.
Several commenters recommended that CMS work with payers and providers to develop
protocols to help identify specific cost savings and efficiencies from automating the prior
authorization process.
Response: CMS bases the impact analysis on data we can obtain from past research and
other available information. During development of the proposed rule, we made certain
assumptions about implementation and development costs. However, based on the number of
pilots in the launch phase, we are optimistic that we will have additional data following
implementation. To the extent feasible, we encourage industry to share data with us, which
would be subject to all requested confidentiality and proprietary protections afforded under the
Freedom of Information Act.194 We will look for opportunities to engage with impacted entities
194OfficeofInformationPolicy,U.S.DepartmentofJustice(n.d.).FreedomofInformationActHomepage.
Retrievedfromhttps://www.foia.gov/. to identify both cost savings and expenditures based on automation of prior authorization
processes which would support the publication of the findings.
Comment: A commenter noted that it is unrealistic for CMS to expect that industry can
obtain the resources necessary to comply with these policies within the current budget year when
the requirements will not be finalized until the final rule is issued. The commenter recommended
that CMS revise the compliance dates for these provisions to be 36 months after issuance of the
final rule and scheduled on a date otherthan the end of a calendar year. Another commenter
recommended that CMS reconsider the proposed timeline of certain provisions in the rule given
the critiques on the RIA and consider reshaping this rule into a roadmap with milestones along
the journey that would signal that a new requirement was ready for implementation. A
commenter recommended that CMS adjust the RIA to account for changes in the FHIR-based
standards and recommended IGs.
Response: We appreciate concerns about implementation costs and timing, as they pertain
to this impact analysis, forstates which are dependent on state fiscal timelines for approvals and
procurements. We also remind readers that some impacted payers may be eligible to apply for
extensions, exceptions, and exemptions under certain circumstances, as described in section II.E.
of this final rule. We believe that the finalized extensions, exceptions, and exemptions will
adequately address any contingencies faced by individual payers and other affected entities.
Finally, as stated in section I.D. of this final rule, we are finalizing compliance dates in 2027 for
the policies in this final rule that require API development or enhancement, in recognition of the
need for analysis, procurement, training, testing, and development. We appreciate the
commenters feedback on updating our impact analyses to account for changes to the FHIR
standards, specifications, and IGs. However, we disagree that updates to standards,
specifications, and IGs should be accounted for in the impact analysis. Changes to standards,
specifications, and IGs do not have any bearing on the calculation of an impact analysis. We
acknowledge that it will be important for implementers to remain engaged in the HL7 workgroups and implementation forums. We are requiring entities to use certain IGs specified in
this finalrule and the ONC Cures Act final rule (85 FR 25642); those standards will remain
consistent. Should there be updates to any of those standards or IGs, changes will be made
available to implementers through SVAP, as they are tested and approved by ONC. Industry is
strongly encouraged to participate in that process to ensure awareness and readiness, but we do
not believe that the changes or process for those changes is of significance for the impact
analysis.
Finally, as discussed earlier in this final rule, some commenters wrote regarding the
potential costs that might be passed on to providers from EHR vendors or payers for use of the
APIs, in the form of user fees. We recognize that EHR vendors, providers, and payers have costs
of doing business, particularly for the development and implementation of the APIs, as described
in this RIA. We strongly encourage EHR vendors to only charge reasonable fees for any initial
or periodic system configurations required to access payers API endpoints.We did not include
information regarding user fees for APIs in this impact analysis because of the lack of available
data on the costs incurred between payers, developers, EHRs and providers. However, we are
committed to monitoring and evaluating the expanding landscape of API usage and will consider
opportunities to provide future guidance on this topic, to ensure that we can provide
comprehensive and up-to-date information for our industry partners.
The Summary Table (Table K9) of this section, using Table J9 as a basis, provides a 10-
year impact estimate. Table K9 includes impact by year, by type (parent organizations, including
state Medicaid and CHIP agencies), as well as the cost burden to the Federal Government,
allocations of cost by program, and payments by the Federal Government to MA organizations,
Medicaid, and CHIP, as well as the premium tax credits (PTCs) paid to certain enrollees in the
individual market. G. Alternatives Considered
We stated in the proposed rule that we are continuing to build on the efforts initiated with
the CMS Interoperability and Patient Access final rule (85 FR 25510) and the work we have
done to advance interoperability, improve care coordination, and empower patients with access
to their data. This final rule covers several provisions aimed at achieving these goals. We
described alternatives to our proposals in the proposed rule and the reasons we did not select
them as proposed provisions. The details for each of those alternatives and the rationale behind
not including them are available in the proposed rule at 87 FR 76344.
1. Alternatives Considered for the Patient Access API Enhancements
We are finalizing modifications to our proposals to require payers to make enhancements
to the Patient Access API, which was finalized in the CMS Interoperability and Patient Access
final rule (85 FR 25510). We are requiring payers to make additional information available to
patients through the Patient Access API and to report certain metrics about patient use of the
Patient Access API to CMS annually. We considered several policy alternatives for the Patient
Access API. These are described in the proposed rule at 87 FR 76344, and relevant comments
regarding the Patient Access API are addressed in section II.A. of this final rule.
Regarding reporting Patient Access API metrics, we considered requiring impacted
payers to publicly report these metrics more frequently than annually. For example, we
considered a quarterly requirement. Public comments on the December 2020 CMS
Interoperability proposed rule (85 FR 82586) indicated a preference for less frequent reporting to
reduce burden on payers. Annual statistics on such utilization should be sufficient to accomplish
our goal of understanding patient utilization of the API. Comments regarding reporting on
Patient Access API metrics are addressed in section II.A. of this final rule.
The quantitative effect of quarterly reporting will likely not change the bottom line of
$1.6 billion cost over 10 years shown in Table K9. However, we acknowledge it may change
marginally to $1.7 billion. As shown in the various tables of section III. of this final rule, the annual cost of reporting is estimated at $3.2 million based on hours of work required by a
business operations specialist. If we required quarterly reporting this would quadruple the
estimate or add about $10 million annually  or a little under $100 million over 10 years. This
would raise the $1.558 billion cost to at most $1.658 which, when rounded, would be either $1.6
or $1.7 billion.
We also considered earlier compliance dates for the proposed enhancements to the
Patient Access API. In the proposed rule, we stated it would be more appropriate, and less
burdensome on impacted payers to propose compliance dates for these provisions in 2026 (by
January 1, 2026, for MA organizations and state Medicaid and CHIP FFS programs; by the
rating period beginning on or after January 1, 2026, for Medicaid managed care plans and CHIP
managed care entities; and for plan years beginning on or after January 1, 2026, for QHP issuers
on the FFEs), which would have provided a 2-year implementation timeframe. However, based
on public comments, we are finalizing a compliance dates in 2027 (by January 1, 2027, for MA
organizations and state Medicaid and CHIP FFS programs; by the rating period beginning on or
after January 1, 2027, for Medicaid managed care plans and CHIP managed care entities; and for
plan years beginning on or after January 1, 2027, for QHP issuers on the FFEs) for the policies in
this finalrule that require API development or enhancement. Additional information regarding
the updated compliance dates for the APIs is available in sections I.D., II.A., II.B., II.C., and
II.D. of this final rule.
Had we implemented the rule a year earlier, the aggregate $1.6 billion over 10 years
would change to $1.7 billion over 10 years. The total cost for creating the various APIs would
not change; rather, they would be apportioned over 2 years rather than 3 years. However, if we
required compliance a year earlier, then the maintenance costs of $142 million per year would
begin in year 3 rather than in year 4. This would add an extra $142 million per year of cost
raising the aggregate 10-year cost of $1.55 billion to $1.69 billion or $1.7 billion after rounding.
2. Alternatives Considered for the Provider Access API To better facilitate the coordination of care across the health care continuum, we are
finalizing our proposal to require impacted payers to implement and maintain a Provider Access
API. This API will require payers to make available to certain providers the same types of data
they make available to patients via the enhanced Patient Access API.
As noted in the proposed rule at, we considered other data types that could be exchanged
via the Provider Access API and considered only requiring the exchange of all data classes and
data elements included in a content standard at 45 CFR 170.213 (USCDI) (87 FR 76345). While
this would have required that less data be exchanged and, thus, be less burdensome for impacted
payers to implement, we believed that claims and encounter information would complement the
content standard and offer a broader and more holistic understanding of a patients interactions
with the health care system. Furthermore, the data that we proposed to be made available through
the Provider Access API aligns with the data that we proposed to be made available to individual
patients through the Patient Access API. We also considered including additional data elements
as required for the Provider Access API, requiring a complete set of data available from the
payers system. However, we did not receive such suggestions from industry, including patients,
and such a large volume of data types might have been overwhelming for providers, would have
been an excessive cost, and would likely not have met minimum necessary provisions. A more
robust description of the alternatives and our rationale for not selecting those are set out in the
proposed rule (87 FR 76346). We did not receive comments specifically on the alternatives
considered in this section. Other comments regarding the Provider Access API are addressed in
section II.B. of this final rule.
3. Alternatives Considered for the Payer-to-Payer API
We are finalizing our proposal to require impacted payers to implement and maintain a
Payer-to-Payer API that makes certain data available to other payers via a FHIR API. This
provision will make the same data that is being made available to patients and providers also
available to other payers when a patient changes plans. This will allow patients to take their data with them as they move from one payer to another. Before finalizing this provision, we
considered several alternative provisions which we described in detail in the proposed rule (87
FR 76346).
For example, in the CMS Interoperability and Patient Access final rule, we finalized a
policy to require payers to exchange data with other payers but did not require a specific
mechanism for the payer to payer data exchange to occur. Rather, we required impacted payers
to receive data in whatever format it was sent and accept data in the form and format it was
received, which ultimately complicated implementation by requiring payers to accept data in
different formats. The cost to implement these various formats cannot be calculated because
there are endless possibilities and combinations of ways the data could have been exchanged
under the previously finalized policy.
Unlike the policy finalized in the CMS Interoperability and Patient Access final rule, the
use of an API would reduce the amount of implementation cost needed for this data exchange.
Importantly, for the Payer-to-Payer API, once an organization implements the other APIs of this
final rule, less additional investment will be necessary to implement the payer to payer data
exchange, as payers would be able to leverage the infrastructure already established for the
Patient Access and Provider Access APIs. The updated background information for the
recommended IGs is found in section II.G. and explains how the existing resources can be
tailored to meet the provisions set out in this final rule. Given this available infrastructure and the
efficiencies of sharing standardized data via the API, we determined it was most advantageous
for payers to implement an API for this enhanced data exchange. We did not receive any
comments on this section, but comments specific to the proposal for the Payer-to-Payer API are
addressed in section II.C. of this final rule. 4. Alternatives Considered for the Prior Authorization API and Other Prior Authorization
Process Requirements
We are finalizing our proposals for several important policies to improve the prior
authorization process, which we described in the proposed rule (87 FR 76346). Our final policy
to require that all impacted payers implement and maintain a Prior Authorization API will
ultimately help patients receive the items and services they need in a timely fashion, and support
streamlined communication between providers and payers. The Prior Authorization API aims to
improve care coordination by providing more structured information about when a prior
authorization is required, information that is required to approve a prior authorization, and
facilitating electronic prior authorization. The API will be accessible to providers to integrate
directly into their workflow while maintaining compliance with the mandatory HIPAA
transaction standard. The standards and IGs that support the development of this API are already
being tested and piloted with some success between providers and payers, and we believe as
enhancements to the IGs are made over the next few years, more organizations will see the
benefit for their programs.
As noted previously, we described our considerations for a phased approach, or partial
implementation of the API over time, and explained why we did not propose those options. We
did not receive comments in support of a partial implementation in part because of the risk that
such an option might result in inconsistent implementations and increase burden for providers.
As indicated, though quantitative data from current prior authorization pilots have been shared
informally with the public, it has not yet been submitted to CMS for use in official evaluations or
analysis. CMS anticipates receipt of the pilot results in CY 2024.
Though we do not have specific data, we believe the quantitative effects of a phased in
implementation option would be negligible. The total cost of developing the Prior Authorization
API would not change; however, such an approach could mean delaying the 25 percent
maintenance costs by 1 or 2 years, as well as the overall benefits of the API. We are finalizing our requirement that impacted payers publish certain data about their
performance on prior authorization, on a public website, and though we considered options for
this reporting, we believe in the first few years of program implementation it will be important to
gather feedback from payers, providers and patients as to the usability of the information being
made available before modifying the requirement. As explained in section II.D. of this final rule,
CMS is committed to working with impacted entities on best practices for reporting.
We considered using only the X12 278 transaction standard adopted under HIPAA rather
than requiring the implementation of a FHIR API to support the Prior Authorization API. While
the adopted X12 278 transaction standard defines the content and format for the exchange of data
for prior authorization, it does not have the functionality of the FHIR standard or IGs to support
the requirements of the Prior Authorization API. This includes the ability to accommodate all of
a payers business rules, indicate which supporting documents are required, create a
questionnaire, and conduct an end-to-end transaction via FHIR for real-time responses. We
received confirmation through many comments that the X12 standard is not designed to enable
using SMART on FHIR apps connected to the providers EHR system, nor is it designed for the
scope envisioned in this rule, including extraction of payer rules, a compilation of data into
electronic-based questionnaires, or communication with EHRs. The substantive comments on
this subject are addressed in section II.D. of this final rule.
We are finalizing the operational, non-technical provisions related to prior authorization
processes, including requirements for certain impacted payers to respond to expedited prior
authorization requests within 72 hours, and to standard prior authorization requests within 7
calendar days. We received many comments suggesting that the response timeframes be
shortened because of the potential impact on patient care, and those comments are addressed in
section II.D. of this final rule.
Understanding the importance of providers and patients getting decisions as quickly as
possible, we believe that the timeframes outlined in the proposed rule are a significant step to help increase reliability in the prior authorization process and establish clear expectations
without being overly burdensome for payers.
H. Savings Through the Adoption of the Prior Authorization Provisions by Health Care
Providers
1. Overview
As described in section II.D. of this final rule, we have finalized new requirements
related to prior authorization for impacted payers, and in section II.F. of this final rule, we
described a new Electronic Prior Authorization measure and the associated reporting
requirements for MIPS eligible clinicians, eligible hospitals, and CAHs.
In section III.C. of this final rule, we discussed the ICRs regarding cost estimates for
reporting and the potential burden specifically for the MIPS eligible clinicians, eligible hospitals,
and CAHs. Here we address the anticipated cost savings of these provisions for the broader
health care provider population, which is inclusive of, but not limited to the MIPS eligible
clinicians, eligible hospitals, and CAHs.
We believe that all health care providers can benefit from the provisions for impacted
payers to implement the APIs in this final rule and base these cost-savings estimates over 10
years. We use the estimated total number of providers, with estimates described in this section of
the final rule. To conduct this analysis, we used available resources and invited comments on our
assumptions, the data, and our citations.
The savings estimated in this final rule are true savings, not transfers,since they reflect
savings in reducing the administrative costs required to process prior authorizations. However,
these savings will be an indirect consequence of the final rule, not direct savings. This final rule
supports efforts to significantly reduce time spent on manual activities. In general, it is only
appropriate to claim that a regulatory provisions benefits are greater than its costs after a
substantive and preferably quantitative, assessment of the pre-existing market failure and the
provisions suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment, the illustrative savings estimates are neither included
in the Monetized Table (Table K11) nor the Summary Table (Table K9) of this final rule.
Nevertheless, the savings could be significant, and we believe should be a factor in the industrys
assessment of this final rule. In the proposed rule, we requested comments on how CMS might
attribute savings benefits to avoid double-counting, and how CMS could account for both costs
and benefits from policy interactions but did not receive specific comments in response.
We are only quantifying savings of reduced paperwork for health care providers.
However, the improved efficiencies outlined in this rule have potential positive consequences,
which could lead to savings. Several surveys by the AMA cited in section II.D.of this final rule,
list adverse qualitative consequences of the current paper-based prior authorization system,
including life-threatening adverse medical events, missed, or abandoned treatments,
hospitalization, and permanent bodily damage, however, we do nothave specific data related to
outcomes.
2. Methodology for Savings Analysis
The approach adopted in quantifying savings is to quantify those that we can reliably
estimate and note that they are minimal savings. The provisions of this rule potentially affect
individual physicians, physician groups, hospitals, and CAHs. However,for purposes of
quantification, we initially estimate a reduced paperwork burden for individual physicians and
physician groups, which shows a savings of several billion dollars over 10 years. We base the
estimate on the number of hours per week spent on prior authorization, using information about
individual physicians and physician groups from survey data we believe to be reliable (three
surveys of several thousand groups from 2006, 2021, and 2022 cited in this section of the final
rule). To calculate our estimates, we used the same physician information and made certain
assumptions of its applicability to hospitals. The purpose of using this comprehensive provider
information from three different periods was that no other comprehensive data set was available to identify savings from reduced paperwork. Our initial estimate was for savings of several
billion dollars for individual physicians and physician groups.
To estimate reductions in spending on paperwork for prior authorization for hospitals, we
assumed that hospitals perform similar prior authorization activities to individual physicians and
physician groups. We made this assumption because we do not have a basis for making a more
accurate assumption; that is, we do not have survey data of similar quality for hospitals on the
number of hours per week spent on prior authorization and the proportion of hours per week
spent by physicians, nurses, and clerical staff.
To support the assumptions on potential benefits for hospitalprior authorization, we rely
on data from previously published rules. To avoid repetition of numbers and sources we
summarize all updates in this final rule, along with the estimates of the proposed rule, subtotals,
and sources in Table K3. Throughout this section, numbers without specified sources, come from
this table. TABLE K3. NUMBERS AND SOURCES USED IN SAVINGS CALCULATIONS
Category(Bold)/ CMS-0057-P CMS-0057-F
CMS-0057-PValueSources CMS-0057-FValueSources
Subcategory(Non-Bold) Value Value
HOSPITALS
AcuteCareHospital 3,150 FY2023IPPS/LTCHproposed 3,150 FY2024IPPS/LTCHproposed
rule(87FR28637) rule(88FR27205)
CriticalAccessHospital(CAH) 1,350 FY2023IPPS/LTCHproposed 1,350 FY2023IPPS/LTCHproposed
rule(87FR28637) rule(88FR27205)
OutpatientHospital 3,411 FY2023OPPS/ASCproposed 3,472 FY2024OPPS/ASCproposed
rule(87FR44810) rule(88FR49552)
TOTAL 7,911 7,9721
MIPSELIGIBLEPARTICIPANTSREPORTINGONTHEPROMOTINGINTEROPERABILITYPERFORMANCECATEGORY
IndividualMIPSEligibleClinicians 43,117 CY2023PFSproposedrule(87 43,117 SourceUnchanged
FR46370TABLE122)
Groups(MIPSEligibleClinicians 11,633 CY2023PFSproposedrule(87 11,633 SourceUnchanged
withgroupeligibility) FR46370TABLE122)
MVPSubgroups 20 CY2023PFSproposedrule(87 20 SourceUnchanged
FR46370TABLE122)
TOTAL 54,770 54,770
TOTALNUMBEROFCLINICIANS
NumberofClinicians(MIPSand 1,596,340 CY2023PFSproposedrule(87 1,596,340 SourceUnchanged
NOTMIPSeligible) FR46410TABLE144)
MEDIANNUMBEROFPHYSICIANSPERPHYSICIANPRACTICE
MedianNumberofCliniciansper 8 Muhlestein,D.andSmith,N., 8 SourceUnchanged
Practice 2016.PhysicianConsolidation:
RapidMovementfromSmallto
LargeGroupPractices,201315.
HealthAffairs,35(9),pp.1638-
1642.
doi/10.1377/hlthaff.2016.0130.
EstimatedPhysicianGroups* 199,543 N/A 199,543 N/A
TOTALHOURSPERWEEKSPENTBYPHYSICIANPRACTICESONPRIORAUTHORIZATION
TotalHoursperWeek 13 2021,AmericanMedical 142 2022,AMAPAPhysicianSurvey
Association(AMA)Prior accessibleathttps://www.ama-
Authorization(PA)Physician assn.org/system/files/prior-
Surveyaccessibleat authorization-survey.pdf
https://www.documentcloud.org/d
ocuments/23710821-ama-2021-
prior-authorization-survey-results
NOTES:
*Totalnumberofcliniciansdividedbythemediannumberofcliniciansperpractice.
(1)Anincreaseof71intotalhospitalsfromtheestimateintheFY2024proposedrules.
(2)A7.7percentincreaseintotalhoursspentonpriorauthorizationsperweek.
To calculate the burden and savings for the final rule, we are using the data from the FY
2024 IPPS/LTCH proposed rule (88 FR 27205), FY 2024 OPPS proposed rule (88 FR 49552),
and CY 2023 PFS proposed rule (87 FR 46370) rather than the CY 2023 PFS final rule (87 FR
69404) or CY 2024 PFS final rule (88 FR 78818), as these sources more accurately reflect the
anticipated number of hospitals and providers impacted by our provisions beginning on January
1, 2027. We believe these sources are more reflective of the eligible hospitals and CAHs who
will participate in the Medicare Promoting Interoperability Program and the MIPS eligible
clinicians participating in the MIPS Promoting Interoperability performance category over time.
We elected to use MIPS eligible clinician participation data from the CY 2023 PFS proposed
rule, rather than the CY 2023 PFS final rule or CY 2024 PFS final rule, to estimate the number of MIPS eligible clinicians reporting MIPS Promoting Interoperability data to CMS because the
45 percent reduction in the estimated number of individual MIPS eligible clinicians reporting
MIPS Promoting Interoperability data between the CY 2023 PFS proposed rule (based on CY
2019 participation data) and the CY 2023 PFS final rule (based on CY 2021 participation data)
appear to be lower due to the effects of the COVID-19 PHE. Likewise, the number of individual
MIPS eligible clinicians reporting MIPS Promoting Interoperability data as estimated in the CY
2024 PFS final rule (based on CY 2022 participation data) remain impacted by the COVID-19
PHE,195 which formally ended on May 11, 2023. We do not believe this reduction in MIPS
eligible clinicians reporting MIPS Promoting Interoperability data will be persistent and believe
it is reasonable that participation numbers in future years may revert to their former levels
(before the COVID-19 PHE).
Additionally, we modified another assumption for this final rule, acknowledging an
increase in hours spent on prior authorization from 13 hours per week spent on prior
authorization in 2021 to 14 hours per week spent on prior authorization in 2022. We did so using
AMA survey data results which we believe are more reasonable. This change in data encouraged
us to update our estimations accordingly.
To account for these changes, and to avoid injecting our own subjective biases on the
changes, we have included calculations using both years of the AMA prior authorization survey
data.The two total savings estimates are based on the AMA prior authorization survey data, one
using 2021 survey data and the other using 2022 survey data, which differed by about 10 percent.
Both resulted in estimated savings of several billion dollars over 10 years. The amount and effect
of these changes as well as the deviation from the proposed rule estimates are set out below.
195U.S.DepartmentofHealthandHumanServices(2023,May9).FactSheet:EndoftheCOVID-19PublicHealth
Emergency.Retrievedfromwww.hhs.gov.https://www.hhs.gov/about/news/2023/05/09/fact-sheet-end-of-the-
covid-19-public-health-emergency.html. Additionally, given that estimates for MIPS eligible clinicians reporting MIPS Promoting
Interoperability data in the CY 2023 PFS final rule were based on CY 2021 participation data
collected during the COVID-19 PHE, we are using data published in the CY 2023 PFS proposed
rule as cited in Table K3 for our calculations. We believe that this is reasonable because the
MIPS eligible clinician estimates from the CY 2023 PFS proposed rule are based on pre-
pandemic participation data from CY 2019. As noted previously, we do not believe the
reductions in participation in the MIPS Promoting Interoperability performance category will
continue long term. We believe it reasonable to assume that participation numbers will continue
to increase, at a minimum, by the compliance dates for the policies that require API development
or enhancement (beginning on January 1, 2027).
3. Physicians and Hospitals
The approach presented in the proposed rule, and finalized here, computes aggregate
savings for physician or group physician practices by first estimating the savings for a single
individual physician or group physician practice based on supporting surveys, and then
multiplying this single savings by the number of practices. Using the updated numbers from
Table K3 results in savings of at least$15.8 billion over 10 years for individual and physician
groups.
We assume hospitals are conducting the prior authorization process in a manner similar
to physicians. Thus, the individual physician and group physician practices would save at least
$15.8 billion over 10 years, as shown in Table K6, and the combined physician practices and
hospitals (207,515 practices consisting of 199,543 individual physician and group physician
practices plus 7,972 hospitals and CAHs) would save at least $16.5 billion (207,515/199,543 
$15.8 billion). To the nearest billion, both $15.8 and $16.5 round to $16 billion. The numerical
savings are the same whether we include or exclude hospitals. 4. Base Estimates of Paperwork Savings to Providers
In calculating the potential savings, uncertainties arise in four areas. The result of this
illustrative analysis is that we find a minimal potential savings point estimate of $15 billion
(using 2021 AMA prior authorization survey data) and $16 billion (using 2022 AMA prior
authorization survey data) over 10 years. To provide credibility to this savings analysis we have,
where we lacked better data, underestimated any unknown quantities with minimal estimates and
additionally studied the effect of a range of estimates.
In the next few paragraphs, we summarize the four uncertainties and indicate how we
approached the estimation. We refer readers to a more detailed discussion of these assumptions
in the proposed rule (87 FR 76348). We received one comment on the quantitative estimate for
providers and have responded to that comment elsewhere in the final rule. However, because no
additional data was provided, we are not changing general assumptions in this final rule, except
that we are updating numbers based on Table K3.
a. Assumptions on the Relative Proportion of Current Workload Hours and Costs by Staff for
Prior Authorization
 For labor costs, we used the mean hourly wages from the BLS.
 For total hours spent per week on prior authorization by staff overall we use the latest
2022 AMA survey (Table K3) rather than the estimate used in the proposed rule, which was
based on the 2021 AMA prior authorization survey.
 For the estimates of the current proportions by the staff of paperwork involved in prior
authorization processes, the type of staff involved, and the type of physician offices, we used
numbers in a survey presented by Casalino et al. (2009),196 which gave a detailed analysis based
on a validated survey instrument employed in 2006. By dividing, for each staff type, the total
prior authorization time spent per week across all physician practices, over the total prior
196Casalino,L.P.,Nicholson,S.,Gans,D.,Hammons,T.,Morra,D.,Karrison,T.,&Levinson,W.(May2009).
WhatDoesItCostPhysicianPracticestoInteractwithHealthInsurancePlans?HealthAffairs,28(4):w533w543.
doi:10.1377/hlthaff.28.4.w533. authorization time spent across all practices and all staff types, we obtained the proportion of
time each staff type spent per week on prior authorization. These proportions were applied to the
updated total time per week spent on prior authorization as given in Table K3.
The updated results are presented in Table K4 which shows that individual and group
physician practices annually used, on average, at least 728 hours per year at a cost of at least
$52,642 on prior authorization.
TABLE K4: TOTAL ANNUAL CURRENT COST OF PRIOR AUTHORIZATION
PAPERWORK FOR INDIVIDUAL PHYSICIANS AND GROUP PRACTICES
LaborCost TotalCostperStaff
OccupationTitle Hours/Week Hours/Year
($/Hour) (Hours*Labor)
Physicians 0.7 35.7 $210.44 $7,510
RegisteredNurses 9.0 467.5 $76.94 $35,969
Clerical 4.3 224.8 $40.76 $9,164
Total 14.0 728.0
TotalCostPerIndividualandGroupPhysicianPracticePerYear $52,6421
NOTE: The$52,642representsa7.7percentincreaseovertheestimateintheproposedrule.This7.7percentincreasearisesfromthe
corresponding7.7percentincreaseintotalhoursspentperweek(TableK3). Sincethesole2022estimateaffectingthistableisusing14hours
versus13hoursitfollowsthathadweused13hoursthetotalcostperindividualandgroupphysicianpracticeperyearis13/14hours$52,642
=$48,882asstatedintheproposedrule.
Here, we provide information on the row on registered nurses for demonstration
purposes. Registered nurses are estimated to spend at least 9 hours per week on prior
authorization, and hence, spend 467.5 hours per year (9 hours per week  52 weeks per year). By
multiplying the 467.5 hours per year spent on prior authorization by the mean wages per hour for
registered nurses, $76.94, obtained from the BLS, we obtain an aggregate annual cost of $35,969
for registered nurses dealing with prior authorization. The other rows are interpreted following
the same process.
b. Assumptions on the Total Number of Individual and Group Physician Practices
Table K4 presents the current hour and dollar burden for a single physician group and
single physician office. To obtain the aggregate annual burden of prior authorizations for all
physician practices, we use the data in Table K3, which includes a reference to 199,543 total
individual and group physician practices. This number is used to inform Table K6 which
represents a 10-year summary of annual costs. c. Assumptions on the Reduction in Hours Spent on Prior Authorization as a Result of the
Provisions of this Final Rule
Table K4 provides current hours spent on prior authorizations. To calculate potential
savings, we assume how much these hours will be reduced as a result of the provisions of this
final rule.
A detailed discussion driving our assumptions was presented in the proposed rule (87 FR
76350). Based on the provisions in this final rule, we assume that physicians, nurses,and clerical
staff will reduce the time they spend on prior authorization by 10 percent, 50 percent, and 25
percent respectively. Having received no comments on our estimates, we have retained these
estimates for purposes of the final calculations. The savings, updated with the numbers from
Table K3, is presented in Table K5.
The narrative following Table K5 presents the total 10-year savings with different
reduction assumptions; however, these different reduction assumptions do not materially change
the range of estimates.
TABLE K5: TOTAL SAVINGS FOR A SINGLE INDIVIDUAL AND GROUP
PHYSICIAN PRACTICE ADOPTING THE PROVISIONS OF THIS FINAL RULE
(2)
Assumed (5)=(3)x(4)Total
Percent (3)=(1)x(2) (4) ReducedDollar
(1) Reductionin TotalReduced LaborCost($/ SpendingPerYear
OccupationTitle Hours/Year Hours HoursperYear Hour) ($)
Physicians 35.7 10% 3.6 $210.44 751
RegisteredNurses 467.5 50% 233.7 $76.94 17,984
Clerical 224.8 25% 56.2 $40.76 2,291
TotalsperPhysicianPractice 728 293.5 21,0261
NOTE:A7.7percentincreaseintheproposedruleamountduetoa7.7percentincreaseintotalhoursonpriorauthorizationactivities.The2021
and2022estimatesdidnotaffecttheassumedpercentreductioninhours,10percent,50percent,25percent.Itfollowsthatifwemultiplythe
$21,025by13/14theestimatedhoursofpriorauthorizationin2021dividedbytheestimatedhoursspentofpriorauthorizationin2022,wearrive
atthe$19,524estimatepresentedintheproposedrule.
To provide an explanation of Table K4, we use registered nurses as an example.
registered nurses spend 467.5 hours per year on prior authorization (see Table K3). If we assume
that registered nurses, as a result of the finalized provisions of this rule, reduce the number of
hours per week by 50 percent (about half a day, or 4 hours, per week) then they would save
233.7 hours per year (50 percent  467.5 hours). Multiplying the hours saved, 233.7 hours, by the mean hourly wage for registered nurses, $76.94, the annual aggregate savings per physician
practice is $17,984. The other rows may be interpreted similarly.
d. Assumptions on the Number of Individual and Group Physician Practices Adopting the
Provisions of this Final Rule
As in the proposed rule, we are not assuming that over 10 years all 199,543 individual
and group physician practices would adopt the provisions outlined in this final rule. Instead, we
assume the following:
 Because of the payment consequences for not adopting the provisions of this finalrule,
we assume all 54,770 MIPS eligible clinicians (individual and group), a subset of the 199,543
estimated individual and group physician practices, would adopt the provisions in this rule in CY
2027 (the first year for payer compliance). This assumption of compliance by all MIPS eligible
clinicians (individual and group) in the first year of payer compliance is consistent with the
assumptions in the proposed rule (87 FR 76351).
 As in the proposed rule, by 2036, we assume 50 percent of all individual and physician
practices will adopt the provisions of this final rule. The reasons for this assumption are fully
discussed in the proposed rule (87 FR 76351). However, we acknowledge that 78 percent of
providers have adopted EHRs, in part to meet ONC requirements.197 Therefore, this estimate of
50 percent is already an underestimate of the percent of individual and physician practices who
would adopt and benefit from the provisions of this rule.
 We do not assume a constant increase per year but rather a gradual increase per year,
starting with the participation of 54,770 MIPS eligible clinicians in 2027 and growing
exponentially to 99,772 (50 percent of 199,543) individual and physician group practices in
2036.
197OfficeoftheNationalCoordinatorforHealthInformationTechnology(n.d.).NationalTrendsinHospitaland
PhysicianAdoptionofElectronicHealthRecords.Retrievedfromhttps://www.healthit.gov/data/quickstats/national-
trends-hospital-and-physician-adoption-electronic-health-
records#:~:text=Office%20of%20the%20National%20Coordinator,IT%20Quick%2DStat%20%2361.&text=As%20
of%202021%2C%20nearly%204,%25)%20adopted%20a%20certified%20EHR. Applying these assumptions, based on the 2022 estimates results (as shown in Table K6),
is at least a $15.8 billion ($15,829.3 million) savings over 10 years for individual and group
physician practices. If we include hospitals by increasing the amount by 4 percent, the estimate
would be at least $16.5 billion ($16,461.7 million). The estimate rounded to the nearest billion is
at least $16 billion. Had we used the 2021 estimates we would obtain $15 billion in savings.
This $16 billion revised estimate differs from the $15 billion estimate presented in the
proposed rule is due to the change noted in Table K3: a 7.7 percent increase in hours per week
spent on prior authorization (14 hours in 2022 versus 13 hours in 2021 based on the AMA
survey). This result is consistent with comments from industry who thought our estimates were
too low regarding the impact of prior authorization on practices and hospitals. After adjusting for
this change estimate, and as noted in Tables K4 and K5, we obtain the additional savings
potential. Note that the range of savings based on different assumptions of savings per staff, $13
to $20 billion over 10 years, still includes the estimate of $15 billion as noted in the proposed
rule.
TABLE K6: TOTAL HOURS (MILLIONS) AND DOLLARS (MILLIONS)
SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS AND HOSPITALS
ADOPTING PROPOSALS OF THIS FINAL RULE
(6) (7)
(2) (3) (2)*(4)*(5)/ (3)*(4)*(5)/1,0
(1) (TableK5) (TableK5) (4) (5) 1000000 00,000,000
Savingsper Savingsper Percentageof TotalNumberof ReducedHours ReducedCost
Practice Single PracticesAdopting IndividualandGroup perYear perYear
Year (Hour) Practice($) thisProposedRule PhysicianPractices (Millions$) (Billions$)
2027 294 21,026 27.45% 199,543 16.1 1,151.6
2028 294 21,026 29.34% 199,543 17.2 1,231.0
2029 294 21,026 31.36% 199,543 18.4 1,315.8
2030 294 21,026 33.52% 199,543 19.6 1,406.5
2031 294 21,026 35.83% 199,543 21.0 1,503.4
2032 294 21,026 38.30% 199,543 22.4 1,607.0
2033 294 21,026 40.94% 199,543 24.0 1,717.7
2034 294 21,026 43.76% 199,543 25.6 1,836.1
2035 294 21,026 46.78% 199,543 27.4 1,962.6
2036 294 21,026 50.00% 199,543 29.3 2,097.8
Total 220.97 15,829.3
Grandtotal
including 229.27 16,461.7
hospitals
The headers of Table K6 show the logic and sources of the column entries. The reduced
hours per year per practice spent on prior authorization for 2027 is calculated as shown here: 16.1 million hours equals 294 hours per year per practice  199,543 practices  27.45 percent
participation. Similarly, the dollar savings per year per practice resulting from reduced time
spent on prior authorization, $21,026, obtained from Table K5, when multiplied by 27.45 percent
of all 199,543 group and physician practices yields $1.2 billion ($1,151.6 million) reduced dollar
spending in 2027.
By summing the reduced hours and dollars per year we obtain an aggregate reduction of
at least 220.97 million hours and at least $15.8 billion ($15,829.3 million) in reduced spending
on paperwork activities. Finally, by adding 4 percent of these numbers to account for hospitals,
we obtain a total annual reduction of at least 229.27 million hours and at least a $16.5 billion
($16,461.7 million) reduction.
As in the proposed rule, we obtained a range of estimates by varying the assumptions of
Table K5 which assume that physicians, nurses, and clerical staff save 10, 50, and 25 percent
respectively. If we assume that all staff types uniformly reduce hours spent by 33 percent, then
dollar spending is reduced by $13.2 billion without hospitals to $13.7 billion with hospitals
factored in over 10 years. If we assume that all staff types uniformly reduce hours spent by 50
percent, then dollar spending is reduced by about $19.8 billion without hospitals to $20.6 billion
with hospitals factored in. Thus, the range of savings, $10 billion to $20 billion presented in the
proposed rule, is slightly narrowed in this final rule to $13 to $20 billion, including providers and
hospitals.
I. Summary of Costs to the Federal Government
In this section, we present a 10-year Summary Table of costs (Table K9), an analysis of
Federal impacts, and the Monetized Table (Table K11).
To analyze the cost of this final rule to the Federal Government, we utilize a method of
allocating costs by program (MA, Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is
shared by the 365 parent organizations, including state Medicaid and CHIP agencies, there is no
readily available way to allocate costs per parent organization across programs since the percentage of each parent organizations expenditures on the different programs is not publicly
available.
To address this, we utilize the same method used in the CMS Interoperability and Patient
Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio
(MLR) files, which break out total premiums among the various programs. The advantages and
disadvantages of such an approach are fully discussed in that rule. Table K7 presents the 2021
MLR data of premiums by program and the resulting percentages by program. We use these
percentages to allocate costs by program. This allocation of cost by program forms a basis to
calculate the Federal Governments cost for the proposed provisions of this rule.
TABLE K7: ALLOCATION OF PREMIUM BY PROGRAM
Premium Percentageby
Program (Billions$) Program
Total 506
MedicareAdvantage(MA) 237 46.89%
MedicaidandCHIP 167 32.99%
IndividualMarketPlans 102 20.13%
To calculate Federal costs for MA organizations, we use the CMS internal data used to
produce the CMS Trustees Report. This internal data indicates that the Trust Fund will pay
about 34 percent of plan costs over the next 10 years. The remaining costs (for the 98 to 99
percent of plans bidding below the benchmark) are borne by the plans. Similarly, we can
calculate the Federal Medicaid payments using the percentages in Table K8.
TABLE K8: PERCENT OF COST INCURRED BY THE FEDERAL GOVERNMENT
FOR MEDICAID SPENDING
Year 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033
ManagedCare*shareofMedicaid 56.50% 56.80% 57.30% 57.60% 57.30% 57.60% 57.90% 58.50% 58.80% 59.00%
FederalshareofMedicaidManagedCare* 57.80% 58.10% 58.50% 58.80% 58.40% 58.70% 59.00% 59.50% 59.80% 60.00%
Weightedcostbyyear 71.81% 65.40% 65.55% 65.67% 65.49% 65.61% 65.74% 65.93% 66.06% 66.15%
*DataobtainedfromCMSOACT.
Table K8 is based on the most recent projections of the CMS OACT for the FY 2024
Budget.
We illustrate the interpretation of the column by explaining the items in the 2025 column.
The number at the bottom of the column, 65.40 percent, answers the question What proportion of the interoperability systems costs for Medicaid is the Federal Government expected to pay?
There are two components to this calculation.
The first is the share of Medicaid managed care. Those costs are directly paid by the
MCOs, which in turn would be expected to raise administrative costs for those plans. The
Federal share of that is: Federal Medical Assistance Percentage (FMAP)198  the managed care
(MC) share of Medicaid; for 2025, this is 58.10 percent  56.80 percent. The second is the share
of the FFS program costs. The FFS program side of Medicaid would have higher administrative
costs. The Federal share of this would be 90 percent in year 1 and 75 percent after year 1. For
2025, this is equal to 75 percent  (1  56.8 percent). The sum of these two components, 58.10
percent  56.80 percent + 75 percent  (1 56.8 percent), equals 65.40 percent as shown in the
bottom row. When we multiply, in Table K9, the total annual cost of interoperability for
Medicaid by 65.40 percent we obtain the amount the Federal Government is expected to pay for
the interoperability system costs for Medicaid.
It should be noted that although the compliance dates for policies in this final rule that do
not require API development or enhancement are in 2026, and the compliance dates for policies
that require API development or enhancement are in 2027. We expect plans to begin
constructing software systems for the provisions that require API development or enhancement
upon publication of this final rule.
Based on the discussion presented in Tables K7 and K8, Table K9 presents the
calculation of all numerical impacts of this final rule by program, government, and QHP issuers
on the FFEs.
198FederalMedicalspendingisdeterminedbytheamountthatstatesspend.TheFederalshareformosthealthcare
servicesisdeterminedbytheFMAP.TheFMAPisbasedonaformulathatprovideshigherreimbursementtostates
withlowerpercapitaincomesrelativetothenationalaverage. ,
S
L
OSPITA$) yersby RemainingCosttoIssuersofQHPsontheFFEs31437374029292929292929
a
DERS,HLLIONS ngCoststoPgramPro RemainingCosttoMedicaid17317212316161616161616
II ni
ROVT(M Remai ainingsttogsOr48356566144444444444444
moA
PN eCM
,E R
MM
OGRAVERN gramGov'tPayments(PTC)relatedtoQHPsontheFFEs22326262820202020212121
RO o
r
YER,PRALG nmentbyP Gov'tPaymentstoMedicaid34143394331313131313131
AE er
R,PFED toGov Gov'tymentsoMA24729293223232323222222
EAE osts Pat
H C
YYOT TotalCosttoGov'tbyYear793879710473727272727272
B
T
E 47709999999
LRULSAND ogram CosttoIssuersofQHPsonFFEs313342222222
L r
A P
SFINSPITA Costsby CosttoMedicaidPlansandStates51460606647474747474747
IO al
FTHSSH Tot CosttoMAgsOr73185859367676767676767
O
E
SC g 82292222222
OTALLAC TotalCosttoPayersIncludinStates 1,5518181914141414141414
A
T
YEARCRITIC TotalCosttoMIPSEligibleClinicians,EligibleHospitalsandCAHs 0.090000.0130.0130.0130.0130.0130.0130.013
-
9:10AND TotalCostofRule 1,558182182199142142142142142142142
K
BLE Year Totals2024202520262027202820292030203120322033
A
T For Table K9:
 As explained in connection with Table J9 in the Collection of Information section, the
data in Table K9 is based on 2027 compliance dates for policies that require API development or
enhancement and the Electronic Prior Authorization measure for MIPS and the Medicare
Promoting Interoperability Program and compliance dates in 2026 for the policies that do not
require API development or enhancement.
 The bottom-line totals in the columns of Table J9 labeled 1st Year Cost through 4th
Year Cost are the totals found in the Total Cost column of Table K9 in rows 2024 through
2027 respectively. The totals in the column 4th and Subsequent Year Costs in Table J9 are
found in the rows labeled 2028 through 2033 in the Total Cost column of Table K9.
 The Total Cost to MIPS Eligible Clinicians, Eligible Hospitals and CAHs column
reflects the aggregate cost of producing reports for MIPS eligible clinicians (including individual
clinicians and groups), eligible hospitals, and CAHs, as found in Table J9 for years 2027 and
further.
 The total 10-year cost (excluding PTC payments and savings from prior authorization)
is, as shown in Table K9, $1.6 billion. This number uses the primary estimates for the provisions
that require API development or enhancement. The low and high 10-year total costs are $0.8
billion and $2.3 billion, respectively.
 The Cost of Final Rule to Payers by Program columns: We applied the percentages
from Table K7 to obtain the cost of the rule to payers by program (MA, Medicaid,CHIP, and
QHP issuers on the FFEs).
 The Cost of Final Rule to Government by Program columns: For the QHP issuers on
the FFEs, the government does not pay anything. For managed care the Government pays
approximately 34 percent (the exact amount varying slightly from year to year and was obtained
from projections by OACT). For Medicaid, we applied the percentages of payment by the
Federal Government discussed in the narrative in Table K8 to obtain the cost by program.  PTC Payments: The Government does not reimburse QHP issuers on the FFEs, neither
prospectively nor retrospectively, for their expenses in furnishing health benefits. However, the
government offers QHP enrollees PTCs to help cover the cost of premiums for the plans. QHP
issuers on the FFEs have the option to deal with increased costs by either temporarily absorbing
them (for purposes of market competitivenesssee, however, a caveat elsewhere in this RIA),
increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that
issuers increase premiums for individual market QHPs on the FFEs, there would be Federal PTC
impacts. The purpose of the PTC is to assist enrollees in paying premiums. Because PTC is
available only if an individual purchases a QHP on an Exchange and the individual generally has
a household income between 100 and 400 percent of the Federal Poverty Level, the PTC
estimates apply only to Exchange plans. Note, the Inflation Reduction Act of 2022 (IRA)199
extended the expanded PTC eligibility provision set forth in the American Rescue Plan Act of
2021 (ARP) through the 2025 plan year.
In the PTC estimate, we have accounted for the fact that some issuers have both
Exchange and non-Exchange plans, and some issuers have only non-Exchange plans. We
reflected these assumptions with global adjustments, so we believe the estimates are reasonable
in aggregate. Specifically, the methodology to estimate the PTC impact of the projected expense
burden is consistent with the method used to estimate the PTC impact in the CMS
Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the
estimated expense burden would impact premium rates in the individual market and is spread
across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are
calculated as a function of the second lowest-cost silver plan and the eligible individuals
household income. The estimate of these impacts uses the assumption that the industry would
increase the second lowest-cost silver plan premium rate in the same amount as the overall
199H.R.5376-117thCongress(2021-2022):InflationReductionActof2022(2022,August16).Retrievedfrom
https://www.congress.gov/bill/117th-congress/house-bill/5376. premium rate increase. This assumption allows the application of the overall rate increase to the
projected PTC payments in the FFE states to estimate the impact on PTC payments.
 The total cost to the government is the sum of payments related to each program. This
payment is a transfer from the Government to payers for MA and Medicaid, CHIP, and QHP
enrollees.
 For MA organizations, Medicaid and CHIP, the remaining costs are the difference
between the total cost to payers and what the Federal Government pays. For the individual
market, the remaining costs to payers would be the total cost absorbed by the payers and not
passed on through premium increases. Since the PTC is paid on behalf of individuals and not the
payers, it therefore does not reduce the expenses of the payers.
The dollar savings from reduced paperwork burden for an increase in using electronic
prior authorization (Tables K4 and K5) is not included in Table K9.
Table K10 describes how the various plans (and states) would bear the costs remaining
after federal payments. We follow the same methodology and discussion presented in the CMS
Interoperability and Patient Access final rule (85 FR 25612). In the table we explain the possible
ways payers may manage extra implementation costs. We emphasize that Table K10 only
includes possibilities. The impacted payers would make decisions about how to defray these
remaining costs based on marketdynamics and internal business decisions;we have no uniform
way of predicting what these actual behaviors and responses will be. TABLE K10: HOW PAYERS COULD DEFRAY REMAINING COSTS
Program AvenuesofDealingwithRemainingCosts
TherearetwoprimaryalternativesavailabletoQHPs:Anissuermayincreaseitspremiumratesoritmaydecideto
absorbthecosts.Thedecisionanyparticularissuermakeswilldependonhowthatissuerconsiderseachofthefollowing
QHPIssuers issueswhentheyaresettingtheirrates.i)Competition,ii)Regulatoryrequirements,iii)Expectedclaimscosts,iv)
Expectednon-benefitexpenses,v)Profitmargins.SomeQHPissuersmayrequestanexceptionfromthefinalprovisions
thatrequireAPIdevelopment.
StateMedicaidandCHIPagencieswouldbearthecost(underadollarperbeneficiaryrelativetotheannualexpenditures
ofseveralthousanddollarsperbeneficiary).MedicaidmanagedcareplansandCHIPmanagedcareentitiesarefully
Medicaid/CHIP capitatedbutmayhavetodeferfirstyearcostsiftheyobtainanexceptionorextension.Undercertaincircumstances,
statesoperatingMedicaidandCHIPFFSprogramscanrequestanextensionoranexemptionfromthefinalprovisions
thatrequireAPIdevelopment.
MAorganizationsintheirJune-submittedbidswouldaddressthereducedrebates(arisingfromincreasedbidcostsdueto
theincreasedcostsofthisfinalrulebeingincludedinthebid)byeither:(1)temporarilyabsorbingcostsbyreducing
Medicare profitmargins;(see,however,acaveatelsewhereinthisRIA);(2)reducingsupplementalbenefitspaidforbytherebates;
Advantage(MA) or(3)raisingenrolleecost-sharing(orreducingadditional,rebate-fundedbenefits).Taxdefermentandamortizationas
applicableamelioratescost.Capitalcostsarespreadovertheentireparentorganizationenrollees.Newplansareallowed
toenterwithinitialnegativemarginswiththeexpectationthattheywillstabilizeoverthefirstfewyears.
 Individual Market Plans: Individual market plans have the option of absorbing costs or
passing costs to enrollees in the form of higher premiums. In some cases, for reasons of market
competitiveness, plans may absorb the increased costs rather than increase premiums.
 Medicaid and CHIP: Assuming roughly 71 million patients enrolled nationally
(inclusive of state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities), Medicaid and CHIP would see an added cost of under a dollar per
beneficiary per year; this contrasts with a total cost per beneficiary per year for the Medicaid and
CHIP programs of several thousand dollars.200
 Medicare Advantage: In their bids (submitted in the month of June prior to the
beginning of the coverage year), MA plans would address the reduced rebates (arising from
increased bid costs due to the increased costs of this final rule being included in the bid) by
either: temporarily absorbing costs by reducing profit margins, reducing the supplemental
benefits paid for by the rebates, or raising enrollee cost-sharing or premium. We believe many
plans, for competitive reasons, would choose to retain a zero-dollar premium increase and either
absorb losses for 1 year or reduce rebate-funded supplemental benefits.
We received no comments specific to Table K10 or the methods impacted payers will use
to deal with the costs of this rule and are therefore finalizing it as is.
200CentersforMedicareandMedicaidServicesNewsroom(2020,January30).MedicaidFactsandFigures|CMS.
Retrievedfromhttps://www.cms.gov/newsroom/fact-sheets/medicaid-facts-and-figures. J. Accounting Statement and Table
As required by OMB Circular A-4 (available at https://www.whitehouse.gov/wp-
content/uploads/legacy_drupal_files/omb/circulars/A4/a-4.pdf), the following table, Table K11,
summarizes the classification of annualized costs associated with the provisions of this final rule
for the 10 years, 2024 through 2033. This accounting table is based on Table K9 and includes the
costs of this final rule to certain providers, including hospitals and CAHs, MA organizations,
state Medicaid and CHIP programs, and QHP issuers on the FFEs. It does not include the
potential savings from Table K6 arising from reduced burden due to providers, hospitals, and
CAHs using electronic prior authorization. Minor discrepancies in totals reflect use of underlying
spreadsheets, rather than intermediate rounded amounts. Table K11 is stated in 2023 dollars,
with expected compliance dates in 2027 for the provisions of this final rule that require API
development or enhancement.
TABLE K11: MONETIZED ACCOUNTING TABLE (MILLIONS $)
Annualized
Annualized Annualized Monetized
MonetizedCost MonetizedCost Cost(as
(asPositive (asPositive Positive
Numbersin Numbersin Numbersin
2023Dollars), 2023Dollars), 2023Dollars),
DiscountRate LowEstimate PrimaryEstimate HighEstimate Period WhoisImpacted
ContractYears StateMedicaidandCHIPentities;MA
Annualizedat7% $81.9 $159.0 $236.2 2024-2033 plans,Individualmarketplans
ContractYears StateMedicaidandCHIPentities;MA
Annualizedat3% $81.0 $157.2 $233.4 2024-2033 plans,Individualmarketplans
Transfers(PTCPayments)
DiscountRate AnnualizedTransfer(In2023dollars) Period FromWhomtoWhom
Annualizedat7% 22.7 2024-2033 Federalgovernmenttoenrollees
Annualizedat3% 22.5 2024-2033 Federalgovernmenttoenrollees
In accordance with the provisions of Executive Order 12866, this final rule was reviewed
by OMB.
Chiquita Brooks-LaSure, Administrator of the Centers for Medicare & Medicaid
Services, approved this document on January 12, 2024. List of Subjects
42 CFR Part 422
Administrative practice and procedure, Health facilities, Health maintenance
organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements.
42 CFR Part 431
Grant programs-health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping
requirements, State fair hearings.
42 CFR Part 435
Aid to Families with Dependent Children, Grant programs-health, Medicaid,Notices,
Reporting and recordkeeping requirements, Supplemental Security Income (SSI), Wages.
42 CFR Part 438
Grant programs-health, Medicaid, Reporting and recordkeeping requirements.
42 CFR Part 440
Grant programs-health, Medicaid.
42 CFR Part 457
Administrative practice and procedure, Grant programs-health, Health insurance,
Reporting and recordkeeping requirements.
45 CFR Part 156
Administrative practice and procedure, Advertising, Brokers, Conflict of interests,
Consumer protection, Grant programs-health, Grants administration, Health care, Health
insurance, Health maintenance organizations (HMO), Health records, Hospitals, Indians,
Individuals with disabilities, Intergovernmental relations, Loan programs-health, Medicaid,
Organization and functions (Government agencies), Prescription drugs, Public assistance
programs, Reporting and recordkeeping requirements, Technical assistance, Women, Youth. For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services
amends 42 CFR chapter IV and the Department of Health and Human Services amends 45 CFR
part 156 as set forth below:
Title 42  Public Health
PART 422  MEDICARE ADVANTAGE PROGRAM
1. The authority citation for part 422 continues to read as follows:
Authority: 42 U.S.C. 1302, 1306, 1395w22 through 1395w28, and 1395hh.
2. Section 422.119 is amended by
a. In paragraph (b)(1)(ii), removing the word and at the end of the paragraph;
b. Revising paragraph (b)(1)(iii);
c. Adding paragraphs (b)(1)(iv) and (v); and
d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (h).
The revisions and additions read as follows:
 422.119 Access to and exchange of health data and plan information.
* * * * *
(b) * * *
(1) * * *
(iii) All data classes and data elements included in a content standard in 45 CFR 170.213
that are maintained by the MA organization no later than 1 business day after the MA
organization receives the data; and
(iv) Beginning January 1, 2027, the information in paragraph (b)(1)(iv)(A) of this section
about prior authorizations for items and services (excluding drugs, as defined in paragraph
(b)(1)(v) of this section), according to the timelines in paragraph (b)(1)(iv)(B) of this section.
(A) The prior authorization request and decision, including all of the following, as
applicable:
(1) The prior authorization status. (2) The date the prior authorization was approved or denied.
(3) The date or circumstance under which the prior authorization ends.
(4) The items and services approved.
(5) If denied, a specific reason why the request was denied.
(6) Related structured administrative and clinical documentation submitted by a
provider.
(B) The information in paragraph (b)(1)(iv)(A) of this section must
(1) Be accessible no later than 1 business day after the MA organization receives a prior
authorization request;
(2) Be updated no later than 1 business day after any status change; and
(3) Continue to be accessible for the duration that the authorization is active and at least 1
year after the prior authorizations last status change.
(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and
alldrugs covered by the MA organization, including any products that constitute a Part D drug,
as defined by  423.100 of this chapter, and are covered under the Medicare Part D benefit.
* * * * *
(c) * * *
(1) Must implement and maintain API technology conformant with 45 CFR
170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification
does not disrupt an end user's ability to access the data specified in paragraph (b) of this section
or  422.120, 422.121, and 422.122 through the required APIs.
* * * * * (e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly
and consistently across all apps and developers through which parties seek to access electronic
health information, as defined in 45 CFR 171.102, including but not limited to, criteria that rely
on automated monitoring and risk mitigation tools.
(f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 following
any calendar year that it offers an MA plan, an MA organization must report to CMS the
following metrics, in the form of aggregated, de-identified data, for the previous calendar year at
the contract levelin the form and manner specified by the Secretary:
(1) The total number of unique enrollees whose data are transferred via the Patient
Access API to a health app designated by the enrollee.
(2) The total number of unique enrollees whose data are transferred more than once via
the Patient Access API to a health app designated by the enrollee.
* * * * *
(h) Applicability. An MA organization must comply with the requirements of this section
beginning in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, unless
otherwise specified, and with the requirements in paragraph (f) of this section beginning in 2026,
with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the MA organization.
3. Section 422.121 is added to read as follows:
 422.121 Access to and exchange of health data for providers and payers.
(a) Application programming interface to support data exchange from payers to
providers  Provider Access API. Beginning January 1, 2027, an MA organization must do the
following: (1) API requirements. Implement and maintain an application programming interface
(API) conformant with all of the following:
(i) Section 422.119(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).
(2) Provider access. Make the data specified at  422.119(b) with a date of service on or
after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, that
are maintained by the MA organization available to in-network providers via the API required in
paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a
provider, if all the following conditions are met:
(i) The MA organization authenticates the identity of the provider that requests access
and attributes the enrollee to the provider under the attribution process described in paragraph
(a)(3) of this section.
(ii) The enrollee does not opt out as described in paragraph (a)(4) of this section.
(iii) Disclosure of the data is not prohibited by other applicable law.
(3) Attribution. Establish and maintain a process to associate enrollees with their in-
network providers to enable data exchange via the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and maintain a process to
allow an enrollee or the enrollees personalrepresentative to opt out of the data exchange
described in paragraph (a)(2) of this section and to change their permission at any time.That
process must be available before the first date on which the MA organization makes enrollee
information available via the Provider Access API and at any time while the enrollee is enrolled
with the MA organization.
(ii) Provide information to enrollees in plain language about the benefits of API data
exchange with their providers, their opt out rights, and instructions both for opting out of data
exchange and for subsequently opting in, as follows: (A) Before the first date on which the MA organization makes enrollee information
available through the Provider Access API.
(B) No later than 1 week after the coverage start date or no later than 1 week after
receiving acceptance of enrollment from CMS, whichever is later.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other appropriate provider
communications, information in plain language explaining the process for requesting enrollee
data using the Provider Access API required in paragraph (a)(1) of this section. The resources
must include information about how to use the MA organizations attribution process to
associate enrollees with their providers.
(b) Application programming interface to support data exchange between payers 
Payer-to-Payer API. Beginning January 1, 2027, an MA organization must do the following:
(1) API requirements. Implement and maintain an API conformant with all of the
following:
(i) Section 422.119(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow enrollees or their personal
representatives to opt into the MA organizations payer to payer data exchange with the
enrollees previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with
concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission
at any time.
(i) The opt in process must be offered as follows:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than 1 week after the coverage start date or no later than 1
week after receiving acceptance of enrollment from CMS, whichever is later. (ii) If an enrollee does not respond or additional information is necessary, the MA
organization must make reasonable efforts to engage with the enrollee to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain a process to identify
a new enrollees previous and concurrent payer(s) to facilitate the Payer-to-Payer API data
exchange. The information request process must start as follows:
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than 1 week after the coverage start date or no later than 1
week after receiving acceptance of enrollment from CMS, whichever is later.
(iii) If an enrollee does not respond or additional information is necessary, the MA
organization must make reasonable efforts to engage with the enrollee to collect this information.
(4) Exchange request requirements. Exchange enrollee data with other payers, consistent
with the following requirements:
(i) The MA organization must request the data listed in paragraph (b)(4)(ii) of this section
through the enrollees previous payers API, if all the following conditions are met:
(A) The enrollee has opted in, as described in paragraph (b)(2) of this section.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date of service within 5 years
before the request:
(A) Data specified in  422.119(b) excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation submitted by a provider
related to prior authorizations.
(iii) The MA organization must include an attestation with this request affirming that the
enrollee is enrolled with the MA organization and has opted into the data exchange.
(iv) The MA organization must complete this request as follows: (A) No later than 1 week after the payer has sufficient identifying information about
previous payers and the enrollee has opted in.
(B) At an enrollees request, within 1 week of the request.
(v) The MA organization must receive, through the API required in paragraph (b)(1) of
this section, and incorporate into its records about the enrollee, any data made available by other
payers in response to the request.
(5) Exchange response requirements. Make available the data specified in paragraph
(b)(4)(ii) of this section that are maintained by the MA organization to other payers via the API
required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the
following conditions are met:
(i) The payer that requests access has its identity authenticated and includes an
attestation with the request that the patient is enrolled with the payer and has opted into the data
exchange.
(ii) Disclosure of the data is not prohibited by other applicable law.
(6) Concurrent coverage data exchange requirements. When an enrollee has provided
sufficient identifying information about concurrent payers and has opted in as described in
paragraph (b)(2) of this section, an MA organization must do the following, through the API
required in paragraph (b)(1) of this section:
(i) Request the enrollees data from allknown concurrent payers as described in
paragraph (b)(4) of this section, and at least quarterly thereafter while the enrollee is enrolled
with both payers.
(ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a
request from any concurrent payers. If agreed upon with the requesting payer, the MA
organization may exclude any data that were previously sent to or originally received from the
concurrent payer. (7) Patient educationalresources. Provide information to enrollees in plain language,
explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt
in or withdraw that permission, and instructions for doing so. The MA organization must provide
the following resources:
(i) When requesting an enrollees permission for Payer-to-Payer API data exchange, as
described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it ordinarily
communicates with current enrollees.
(iii) In an easily accessible location on its public website.
4. Section 422.122 is added to read as follows:
 422.122 Prior authorization requirements.
(a) Communicating a reason for denial. Beginning January 1, 2026, if the MA
organization denies a prior authorization request (excluding request for coverage of drugs as
defined in  422.119(b)(1)(v)), in accordance with the timeframes established in 
422.568(b)(1) and 422.572(a)(1), the response to the provider must include a specific reason for
the denial, regardless of the method used to communicate that information.
(b) Prior Authorization Application Programming Interface (API). Beginning January 1,
2027, an MA organization must implement and maintain an API conformant with
 422.119(c)(2) through (4), (d), and (e), and the standards in 45 CFR 170.215(a)(1), (b)(1)(i),
and (c)(1) that--
(1) Is populated with the MA organizations list of covered items and services (excluding
drugs, as defined in  422.119(b)(1)(v)) that require prior authorization;
(2) Can identify all documentation required by the MA organization for approval of any
items or services that require prior authorization;
(3) Supports a Health Insurance Portability and Accountability Act (HIPAA)-compliant
prior authorization request and response, as described in 45 CFR part 162; and (4) Communicates the following information about prior authorization requests:
(i) Whether the MA organization
(A) Approves the prior authorization request (and the date or circumstance under which
the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the MA organization denies the prior authorization request, it must include a
specific reason for the denial.
(5) In addition to the requirements of this section, an MA organization using prior
authorization polices or making prior authorization decisions must meetall other applicable
requirements under this part, including  422.138 and the requirements in subpart M of this part.
(c) Publicly reporting prior authorization metrics. Beginning in 2026, following each
calendar year that it offers an MA plan, an MA organization must report prior authorization data,
excluding data on drugs as defined in  422.119(b)(1)(v), at the MA contract level by March 31.
The MA organization must make the following data from the previous calendar year publicly
accessible by posting them on its website:
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved,
aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated
for all items and services.
(4) The percentage of standard prior authorization requests that were approved after
appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review
was extended, and the request was approved, aggregated for all items and services. (6) The percentage of expedited prior authorization requests that were approved,
aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied,
aggregated for all items and services.
(8) The average and median time that elapsed between the submission of a requestand a
determination by the MA plan, for standard prior authorizations, aggregated for all items and
services.
(9) The average and median time that elapsed between the submission of a requestand a
decision by the MA plan for expedited prior authorizations, aggregated for all items and services.
5. Section 422.568 is amended by
a. Revising paragraph (b)(1);
b. Redesignating paragraph (b)(2) as paragraph (b)(3);
c. Adding new paragraph (b)(2); and
d. In newly redesignated paragraph (b)(3), removing the phrase under the provisions in
paragraph (b)(1)(i) of this section and adding in its place the phrase under the provisions in
paragraph (b)(2) of this section.
The revision and addition read as follows:
 422.568 Standard timeframes and notice requirements for organization determinations.
* * * * *
(b) * * *
(1) Requests for service or item. Except as provided in paragraph (b)(2) of this section,
when a party has made a request for an item or service, the MA organization must notify the
enrollee of its determination as expeditiously as the enrollees health condition requires but no
later than either of the following:
(i) For a service or item not subject to the prior authorization rules in  422.122, 14
calendar days after receiving the request for the standard organization determination. (ii) Beginning on or after January 1, 2026, for a service or item subject to the prior
authorization rules in  422.122, 7 calendar days after receiving the request for the standard
organization determination.
(2) Extensions; requests for service or item(i) Extension of timeframe on a request for
service or item. The MA organization may extend the timeframe by up to 14 calendar days under
any of the following circumstances:
(A) The enrollee requests the extension.
(B) The extension is justified and in the enrollee's interest due to the need for additional
medical evidence from a noncontract provider that may change an MA organization's decision to
deny an item or service.
(C) The extension is justified due to extraordinary, exigent, or other non-routine
circumstances and is in the enrollee's interest.
(ii) Notice of extension. (A) When the MA organization extends the timeframe, it must
(1) Notify the enrollee in writing of the reasons for the delay; and
(2) Inform the enrollee of the right to file an expedited grievance if the enrollee disagrees
with the MA organization's decision to grant an extension.
(B) The MA organization must notify the enrollee of its determination as expeditiously as
the enrollee's health condition requires, butno later than upon expiration of the extension.
* * * * *
 422.570 [Amended]
6. Section 422.570 is amended in paragraph (d)(1) by removing the phrase request to
the standard timeframe and make the determination within the 72-hour or 14-day timeframe, as
applicable, established and adding in its place the phrase request to a standard organization
determination and make the determination within the applicable timeframe, established.
7. Section 422.631 is amended by revising paragraphs (d)(2)(i)(B), (d)(2)(iv)(B)(1), and
(d)(2)(iv)(B)(2)(i) to read as follows:  422.631 Integrated organization determinations.
* * * * *
(d) * * *
(2) * * *
(i) * * *
(B) Except as described in paragraph (d)(2)(i)(A) of this section, the applicable integrated
plan must send a notice of its integrated organization determination as expeditiously as the
enrollees health condition requires but no later than either of the following:
(1) For a service or item not subject to the prior authorization rules in  422.122, 14
calendar days after receiving the request for the standard integrated organization determination.
(2) Beginning on or after January 1, 2026, for a service or item subject to the prior
authorization rules in  422.122, 7 calendar days after receiving the request for the standard
integrated organization determination.
* * * * *
(iv) * * *
(B) * * *
(1) Automatically transfer a request to the standard timeframe and make the
determination within the applicable timeframe established in paragraph (d)(2)(i)(B) of this
section for a standard integrated organization determination. The timeframe begins the day the
applicable integrated plan receives the request for expedited integrated organization
determination.
(2) * * *
(i) Explains that the applicable integrated plan will process the request using the
timeframe for standard integrated organization determinations;
* * * * *
PART 431STATE ORGANIZATION AND GENERAL ADMINISTRATION 8. The authority citation for part 431 continues to read as follows:
Authority: 42 U.S.C. 1302.
9. Section 431.60 is amended by
a. Revising paragraph (b)(3);
b. Adding paragraphs (b)(5) and (6);
c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);
d. Removing paragraph (g);
e. Redesignating paragraph (f) as paragraph (g); and
f. Adding new paragraph (f) and paragraph (h).
The revisions and addition read as follows:
 431.60 Beneficiary access to and exchange of data.
* * * * *
(b) * * *
(3) All data classes and data elements included in a content standard in 45 CFR 170.213
that are maintained by the State no later than 1 business day after the State receives the data; and
* * * * *
(5) Beginning January 1, 2027, the information in paragraph (b)(5)(i) of this section
about prior authorizations for items and services (excluding drugs as defined in paragraph (b)(6)
of this section), according to the timelines in paragraph (b)(5)(ii) of this section.
(i) The prior authorization request and decision, including all of the following, as
applicable:
(A) The prior authorization status.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the prior authorization ends.
(D) The items and services approved.
(E) If denied, a specific reason why the request was denied. (F) Related structured administrative and clinical documentation submitted by a
provider.
(ii) The information in paragraph (b)(5)(i) of this section must
(A) Be accessible no later than 1 business day after the State receives a prior
authorization request;
(B) Be updated no later than 1 business day after any status change; and
(C) Continue to be accessible for the duration that the authorization is active and at least
1 year after the prior authorizations last status change.
(6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all
drugs covered by the State.
* * * * *
(c) * * *
(1) Must implement and maintain API technology conformant with 45 CFR
170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification
does not disrupt an end users ability to access the data specified in paragraph (b) of this section
or  431.61, 431.70, and 431.80, through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and
consistently across all apps and developers through which parties seek to access electronic health
information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on
automated monitoring and risk mitigation tools. * * * * *
(f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 of each year,
a State must report to CMS the following metrics, in the form of aggregated, de-identified data,
for the previous calendar year at the State levelin the form and manner specified by the
Secretary:
(1) The total number of unique beneficiaries whose data are transferred via the Patient
Access API to a health app designated by the beneficiary; and
(2) The total number of unique beneficiaries whose data are transferred more than once
via the Patient Access API to a health app designated by the beneficiary.
* * * * *
(h) Applicability. A State must comply with the requirements in paragraphs (a) through
(e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f)
of this section beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the State.
10. Section 431.61 is added to read as follows:
 431.61 Access to and exchange of health data for providers and payers.
(a) Application programming interface to support data exchange from payers to
providers  Provider Access API. Beginning January 1, 2027, unless granted an extension or
exemption under paragraph (c) of this section, a State must do the following:
(1) API requirements. Implement and maintain an application programming interface
(API) conformant with all of the following:
(i) Section 431.60(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).
(2) Provider access. Make the data specified in  431.60(b) with a date of service on or
after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information, that are maintained by the State available to enrolled Medicaid providers via the API required in
paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a
provider, if all the following conditions are met:
(i) The State authenticates the identity of the provider that requests access and attributes
the beneficiary to the provider under the attribution process described in paragraph (a)(3) of this
section.
(ii) The beneficiary does not opt out as described in paragraph (a)(4) of this section.
(iii) Disclosure of the data is not prohibited by other applicable law.
(3) Attribution. Establish and maintain a process to associate beneficiaries with their
enrolled Medicaid providers to enable data exchange via the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and maintain a process to
allow a beneficiary or the beneficiarys personal representative to opt out of the data exchange
described in paragraph (a)(2) of this section and to change their permission at any time. That
process must be available before the first date on which the State makes beneficiary information
available via the Provider Access API and at any time while the beneficiary is enrolled with the
State.
(ii) Provide information to beneficiaries in plain language about the benefits of API data
exchange with their providers, their opt out rights, and instructions both for opting out of data
exchange and for subsequently opting in, as follows:
(A) Before the first date on which the State makes beneficiary information available
through the Provider Access API.
(B) No later than 1 week after enrollment.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other appropriate provider
communications, information in plain language explaining the process for requesting beneficiary data using the Provider Access API required in paragraph (a)(1) of this section. The resources
must include information about how to use the States attribution process to associate
beneficiaries with their providers.
(b) Application programming interface to support data exchange between payers 
Payer-to-Payer API. Beginning January 1, 2027, unless granted an extension or exemption under
paragraph (c) of this section, a State must do the following:
(1) API requirements. Implement and maintain an API conformant with all of the
following:
(i) Section 431.60(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow beneficiaries or their personal
representatives to opt into the States payer to payer data exchange with the beneficiarys
previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent
payer(s), described in paragraph (b)(6) of this section, and to change their permission at any
time.
(i) The opt in process must be offered as follows:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than 1 week after enrollment.
(ii) If a beneficiary has coverage through any Medicaid MCO, prepaid inpatient health
plan (PIHP), or prepaid ambulatory health plan (PAHP) within the same State while enrolled in
Medicaid, the State must share their opt in permission with those MCO, PIHP, or PAHP to allow
the Payer-to-Payer API data exchange described in this section.
(iii) If a beneficiary does not respond or additional information is necessary, the State
must make reasonable efforts to engage with the beneficiary to collect this information. (3) Identify previous and concurrent payers. Establish and maintain a process to identify
a new beneficiarys previous and concurrent payer(s) to facilitate the Payer-to-Payer API data
exchange. The information request process must start as follows:
(i) For current beneficiaries, no later than the compliance date.
(ii) For new beneficiaries, no later than 1 week after enrollment.
(iii) If a beneficiary does not respond or additional information is necessary, the State
must make reasonable efforts to engage with the beneficiary to collect this information.
(4) Exchange request requirements. Exchange beneficiary data with other payers,
consistent with the following requirements:
(i) The State must request the data specified in paragraph (b)(4)(ii) of this section through
the beneficiarys previous payers API, if all the following conditions are met:
(A) The beneficiary has opted in, as described in paragraph (b)(2) of this section, except
for data exchanges between a State Medicaid agency and its contracted MCOs, PIHPs, or
PAHPs, which do not require a beneficiary to opt in.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date of service within 5 years
before the request:
(A) Data specified in  431.60(b), excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation submitted by a provider
related to prior authorizations.
(iii) The State must include an attestation with this request affirming that the beneficiary
is enrolled with the State and has opted into the data exchange.
(iv) The State must complete this request as follows: (A) No later than 1 week after the payer has sufficient identifying information about
previous payers and the beneficiary has opted in.
(B) At a beneficiarys request, within 1 week of the request.
(v) The State must receive, through the API required in paragraph (b)(1) of this section,
and incorporate into its records about the beneficiary, any data made available by other payers in
response to the request.
(5) Exchange response requirements. Make available the data specified in paragraph
(b)(4)(ii) of this section that are maintained by the State to other payers via the API required in
paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following
conditions are met:
(i) The payer that requests access has its identity authenticated and includes an attestation
with the request that the patient is enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable law.
(6) Concurrent coverage data exchange requirements. When a beneficiary has provided
sufficient identifying information about concurrent payers and has opted in as described in
paragraph (b)(2) of this section, a State must do the following, through the API required in
paragraph (b)(1) of this section:
(i) Request the beneficiarys data from all known concurrent payers as described in
paragraph (b)(4) of this section, and at least quarterly thereafter while the beneficiary is enrolled
with both payers.
(ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a
request from any concurrent payers. If agreed upon with the requesting payer, the State may
exclude any data that were previously sent to or originally received from the concurrent payer.
(7) Patient educationalresources. Provide information to applicants or beneficiaries in
plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt in or withdraw that permission, and instructions for doing so. The State must
provide the following resources:
(i) When requesting a beneficiarys permission for Payer-to-Payer API data exchange, as
described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it ordinarily
communicates with current beneficiaries.
(iii) In an easily accessible location on its public website.
(c) Extensions and exemptions(1) Extension. (i) A State may submit a written
application to requesta one-time, 1-year extension of the requirements in paragraph (a) or (b) of
this section (or paragraphs (a) and (b)) for its Medicaid fee-for-service (FFS) program. The
written application must be submitted as part of the States annual Advance Planning Document
(APD) for Medicaid Management Information System (MMIS) operations expenditures
described in part 433, subpart C, of this chapter, and approved before the compliance date forthe
requirements to which the State is seeking an extension. It must include all the following:
(A) A narrative justification describing the specific reasons why the State cannot satisfy
the requirement(s) by the compliance date and why those reasons result from circumstances that
are unique to the agency operating the Medicaid FFS program.
(B) A report on completed and ongoing State activities that evidence a good faith effort
towards compliance.
(C) A comprehensive plan to meet the requirements no later than 1 year after the
compliance date.
(ii) CMS grants the States request if it determines,based on the information provided,
that
(A) The request adequately establishes a need to delay implementation; and
(B) The State has a comprehensive plan to meet the requirements no later than 1 year
after the compliance date. (2) Exemption. (i) A State operating a Medicaid program in which at least 90 percent of
the States Medicaid beneficiaries are enrolled in Medicaid managed care organizations, as
defined in 438.2 of this chapter, may request an exemption for its FFS program from either or
both of the following requirement(s):
(A) Paragraph (a) of this section.
(B) Paragraphs (b)(1) and (3) through (7) of this section.
(ii) The States exemption request must:
(A) Be submitted in writing as part of a States annual APD for MMIS operations
expenditures before the compliance date for the requirements to which the State is seeking an
exemption.
(B) Include both of the following:
(1) Documentation that the State meets the threshold for the exemption, based on
enrollment data from the most recent CMS Medicaid Managed Care Enrollment and Program
Characteristics (or successor) report.
(2) An alternative plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMSs satisfaction that the
State
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means while the exemption is in
effect.
(iv) The States exemption expires if either
(A) Based on the 3 previous years of available, finalized Medicaid Transformed
Medicaid Statistical Information System (T-MSIS) managed care and FFS enrollment data, the
States managed care enrollment for 2 of the previous 3 years is below 90 percent; or (B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that
would significantly reduce the percentage of beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first available, finalized
Medicaid T-MSIS managed care and FFS enrollment data.
(v) If a States exemption expires under paragraph (c)(2)(iv) of this section, the State is
required to do both of the following
(A) Submit written notification to CMS that the State no longer qualifies for the
exemption within 90 days of the finalization of annual Medicaid T-MSIS managed care
enrollment data that demonstrates that there has been the requisite shift from managed care
enrollment to FFS enrollment resulting in the States managed care enrollment falling below the
90 percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the requirements in
paragraph (a) or (b) (or paragraphs (a) and (b)) of this section within 2 years of the expiration of
the exemption.
11. Section 431.80 is added to subpart B to read as follows:
 431.80 Prior authorization requirements.
(a) Communicating a reason for denial. Beginning January 1, 2026, if the State denies a
prior authorization request (excluding a request for coverage of drugs as defined in 
431.60(b)(6)), in accordance with the timeframes established in  440.230(e)(1) of this chapter,
the response to the provider must include a specific reason for the denial, regardless of the
method used to communicate that information.
(b) Prior Authorization Application Programming Interface (API). Unless granted an
extension or exemption under paragraph (c) of this section, beginning January 1, 2027, a State
must implement and maintain an API conformant with  431.60(c)(2) through (4), (d), and (e),
and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that-- (1) Is populated with the States list of covered items and services (excluding drugs, as
defined in  431.60(b)(6)) that require prior authorization;
(2) Can identify all documentation required by the State for approval of any items or
services that require prior authorization;
(3) Supports a HIPAA-compliant prior authorization request and response, as described
in 45 CFR part 162; and
(4) Communicates the following information about prior authorization requests:
(i) Whether the State
(A) Approves the prior authorization request (and the date or circumstance under which
the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the State denies the prior authorization request, it must include a specific reason
for the denial.
(c) Extensions and exemptions(1) Extension. (i) A State may submit a written
application to requesta one-time, 1-year extension of the requirements in paragraph (b) of this
section for its Medicaid FFS program. The written application must be submitted as part of the
States annual APD for MMIS operations expenditures described in part 433, subpart C, of this
chapter; and approved before the compliance date in paragraph (b) of this section. It must include
allthe following:
(A) A narrative justification describing the specific reasons why the State cannot satisfy
the requirement(s) by the compliance date and why those reasons result from circumstances that
are unique to the agency operating the Medicaid FFS program.
(B) A report on completed and ongoing State activities that evidence a good faith effort
towards compliance. (C) A comprehensive plan to meet the requirements no later than 1 year after the
compliance date.
(ii) CMS grants the States request if it determines,based on the information provided,
that
(A) The request adequately establishes a need to delay implementation; and
(B) The State has a comprehensive plan to meet the requirements no later than 1 year
after the compliance date.
(2) Exemption. (i) A State operating a Medicaid program in which at least 90 percent of
the States Medicaid beneficiaries are enrolled in Medicaid managed care organizations, as
defined in 438.2 of this chapter, may request an exemption for its FFS program from the
requirements in paragraph (b) of this section.
(ii) The States exemption request must:
(A) Be submitted in writing as part of a States annual APD for MMIS operations
expenditures before the compliance date in paragraph (b) of this section.
(B) The States request must include both of the following:
(1) Documentation that the State meets the threshold for the exemption, based on
enrollment data from the most recent CMS Medicaid Managed Care Enrollment and Program
Characteristics (or successor) report.
(2) An alternative plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMSs satisfaction that the
State
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means while the exemption is in
effect. (iv) The States exemption expires if either
(A) Based on the 3 previous years of available, finalized Medicaid Transformed
Medicaid Statistical Information System (T-MSIS) managed care and FFS enrollment data, the
States managed care enrollment for 2 of the previous 3 years is below 90 percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that
would significantly reduce the percentage of beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first available, finalized
Medicaid T-MSIS managed care and FFS enrollment data.
(v) If a States exemption expires under paragraph (c)(2)(iv) of this section, the State is
required to do both of the following
(A) Submit written notification to CMS that the State no longer qualifies for the
exemption within 90 days of the finalization of annual Medicaid T-MSIS managed care
enrollment data that demonstrates that there has been the requisite shift from managed care
enrollment to FFS enrollment resulting in the States managed care enrollment falling below the
90 percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the requirements in
paragraph (b) of this section within 2 years of the expiration of the exemption.
12. Section 431.201 is amended by revising the definition of Action to read as follows:
 431.201 Definitions.
* * * * *
Action means one of the following:
(1) A termination, suspension of, or reduction in covered benefits or services, including
benefits or services for which there is a current approved prior authorization;
(2) A termination, suspension of, or reduction in Medicaid eligibility, or an increase in
beneficiary liability, including a determination that a beneficiary must incur a greater amount of medical expenses to establish income eligibility in accordance with  435.121(e)(4) or  435.831
of this chapter;
(3) A determination that a beneficiary is subject to an increase in premiums or cost-
sharing charges under subpart A of part 447 of this chapter; or
(4) A determination by a skilled nursing facility or nursing facility to transfer or
discharge a resident and an adverse determination by a State regarding the preadmission
screening and resident review requirements of section 1919(e)(7) of the Act.
* * * * *
13. Section 431.220 is amended by
a. In paragraph (a)(1)(iv), removing the term or from the end of the paragraph;
b. In paragraph (a)(1)(v), removing the period from the end of the paragraph and adding
in its place ; or; and
c. Adding paragraph (a)(1)(vi).
The addition reads as follows:
 431.220 When a hearing is required.
(a) * * *
(1) * * *
(vi) A prior authorization decision.
* * * * *
PART 435ELIGIBILITY IN THE STATES, DISTRICT OF COLUMBIA, THE
NORTHERN MARIANA ISLANDS, AND AMERICAN SAMOA
14. The authority citation for part 435 continues to read as follows:
Authority: 42 U.S.C. 1302.
15. Section 435.917 is amended by
a. Revising the headings of paragraphs (a) and (b); and
b. Revising paragraph (b)(2). The revisions read as follows:
 435.917 Notice of agencys decision concerning eligibility, benefits, or services.
(a) Notice of determinations. * * *
(b) Content of notice* * *
(2) Notice of adverse action. Notice of adverse action including denial, termination, or
suspension of eligibility or change in benefits or services. Any notice of denial, termination, or
suspension of Medicaid eligibility, or, in the case of beneficiaries receiving medical assistance,
denial of or change in benefits or services must be consistent with  431.210 of this chapter.
* * * * *
PART 438MANAGED CARE
16. The authority citation for part 438 continues to read as follows:
Authority: 42 U.S.C. 1302.
17. Section 438.9 is amended by revising paragraph (b)(7) to read as follows:
438.9 Provisions that apply to non-emergency medical transportation PAHPs.
* * * * *
(b) * * *
(7) The PAHP standards in  438.206(b)(1), 438.210, 438.214, 438.224, 438.230, and
438.242, excluding the requirement in  438.242(b)(7), to comply with  431.61(a) and (b) of
this chapter.
* * * * *
 438.62 [Amended]
18. Section 438.62 is amended by removing paragraphs (b)(1)(vi) and (vii).
19. Section 438.210 is amended by
a. Revising paragraphs (d)(1) and (d)(2)(i);
b. Redesignating paragraph (f) as paragraph (g); and
c. Adding new paragraph (f). The addition and revision read as follows:
 438.210 Coverage and authorization of services.
* * * * *
(d) * * *
(1) Standard authorization decisions. (i) For standard authorization decisions, provide
notice as expeditiously as the enrollees condition requires and:
(A) For rating periods that start before January 1, 2026, within state established time
frames that may not exceed 14 calendar days after receiving the request forservice.
(B) For rating periods that start on or after January 1, 2026, within state established time
frames that may not exceed 7 calendar days after receiving the requestfor service.
(ii) Standard authorization decisions may have an extension to the timeframes in
paragraph (d)(1)(i) of this section up to 14 additional calendar days if
(A) The enrollee or the provider requests the extension; or
(B) The MCO, PIHP, or PAHP justifies (to the State agency upon request) a need for
additional information and how the extension is in the enrollees interest.
(2) * * *
(i) For cases in which a provider indicates, or the MCO, PIHP, or PAHP determines,that
following the standard timeframe could seriously jeopardize the enrollees life or health or
ability to attain, maintain, or regain maximum function, the MCO, PIHP, or PAHP must make an
expedited authorization decision and provide notice as expeditiously as the enrollees health
condition requires and no later than 72 hours after receipt of the request for service.
* * * * *
(f) Publicly reporting prior authorization metrics. Beginning January 1, 2026, following
each calendar year it has a contract with a State Medicaid agency, the MCO, PIHP, or PAHP
must report prior authorization data, excluding data on any and all drugs covered by the MCO,
PIHP, or PAHP, at the plan level by March 31. The MCO, PIHP, or PAHP must make the following data from the previous calendar year publicly accessible by posting them on its
website:
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved,
aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated
for all items and services.
(4) The percentage of standard prior authorization requests that were approved after
appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review
was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved,
aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated
for all items and services.
(8) The average and median time that elapsed between the submission of a request and a
determination by the MCO, PIHP or PAHP, for standard prior authorizations, aggregated for all
items and services.
(9) The average and median time that elapsed between the submission of a request and a
decision by the MCO, PIHP or PAHP, for expedited prior authorizations, aggregated for all
items and services.
* * * * *
20. Section 438.242 is amended by revising paragraph (b)(5) and adding paragraphs
(b)(7) through (9) to read as follows:  438.242 Health information systems.
* * * * *
(b) * * *
(5) Subject to paragraph (b)(8) of this section, implement and maintain a Patient Access
Application Programming Interface (API) required in  431.60 of this chapter as if such
requirements applied directly to the MCO, PIHP, or PAHP and:
(i) Include all encounter data, including encounter data from any network providers the
MCO, PIHP, or PAHP is compensating based on capitation payments and adjudicated claims and
encounter data from any subcontractors.
(ii) Exclude covered outpatient drugs as defined in section 1927(k)(2) of the Act.
(iii) Report metrics specified in  431.60(f) of this chapter at the plan level.
* * * * *
(7) By the rating period beginning on or after January 1, 2027, comply with  431.61(a),
(b)(1) and (4) through (6), and (b)(7)(ii) and (iii) and 431.80(b) of this chapter as if such
requirements applied directly to the MCO, PIHP, or PAHP
(8) By the rating period beginning on or after January 1, 2026, comply with  431.80(a)
of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP according to
the decision timeframes in  438.210(d).
(9) The following timeframes apply to paragraph (b)(5) of this section:
(i) Except for the requirements in  431.60(b)(5), (g), and (h) of this chapter, comply with
the requirements of  431.60 of this chapter by January 1, 2021.
(ii) Comply with the requirements in  431.60(b)(5) and (g) of this chapter by the rating
period beginning on or after January 1, 2026.
(iii) Beginning in 2026, by March 31 following any year the MCO, PIHP, or PAHP
operates, comply with the reporting requirements in  431.60(h) of this chapter for the previous
calendar years data, in the form of aggregated, de-identified metrics, at the plan level. * * * * *
PART 440  SERVICES: GENERAL PROVISIONS
21. The authority citation for part 440 continues to read as follows:
Authority: 42 U.S.C. 1302.
22. Section 440.230 is amended by adding paragraph (e) to read as follows:
 440.230 Sufficiency of amount, duration, and scope.
* * * * *
(e) For prior authorization requests for items and services (excluding drugs, as defined in
 431.60(b)(6) of this chapter), the State Medicaid agency must
(1) Beginning January 1, 2026, make prior authorization decisions within the following
timeframes:
(i) For a standard determination, as expeditiously as a beneficiarys health condition
requires, but in no case later than 7 calendar days after receiving the request, unless a shorter
minimum timeframe is established under State law. The timeframe for standard authorization
decisions can be extended by up to 14 calendar days if the beneficiary or provider requests an
extension, or if the State agency determines that additional information from the provider is
needed to make a decision.
(ii) For an expedited determination, as expeditiously as a beneficiarys health condition
requires, but in no case later than 72 hours after receiving the request, unless a shorter minimum
timeframe is established under State law.
(2) Provide the beneficiary with notice of the agencys prior authorization decision in
accordance with  435.917 of this chapter and provide fair hearing rights, including advance
notice, in accordance with part 431, subpart E, of this chapter.
(3) Beginning in 2026, annually report prior authorization data, excluding data on drugs,
as defined in  431.60(b)(6) of this chapter, at the State level by March 31. The State must make the following data from the previous calendar year publicly accessible by posting them on its
website:
(i) A list of all items and services that require prior authorization.
(ii) The percentage of standard prior authorization requests that were approved,
aggregated for all items and services.
(iii) The percentage of standard prior authorization requests that were denied, aggregated
for all items and services.
(iv) The percentage of standard prior authorization requests that were approved after
appeal, aggregated for all items and services.
(v) The percentage of prior authorization requests for which the timeframe for review
was extended, and the request was approved, aggregated for all items and services.
(vi) The percentage of expedited prior authorization requests that were approved,
aggregated for all items and services.
(vii) The percentage of expedited prior authorization requests that were denied,
aggregated for all items and services.
(viii) The average and median time that elapsed between the submission of a request and
a determination by the State Medicaid agency, for standard prior authorizations, aggregated for
allitems and services.
(ix) The average and median time that elapsed between the submission of a request and a
decision by the State Medicaid agency for expedited prior authorizations, aggregated for all
items and services.
PART 457  ALLOTMENTS AND GRANTS TO STATES
23. The authority citation for part 457 continues to read as follows:
Authority: 42 U.S.C. 1302.
24. Section 457.495 is amended by revising paragraph (d) to read as follows:  457.495 State assurance of access to care and procedures to assure quality and
appropriateness of care.
* * * * *
(d) That decisions related to the prior authorization of health services are completed as
follows:
(1) Before January 1, 2026. (i) In accordance with the medical needs of the patient,
within 14 days after receipt of a request for services. A possible extension of up to 14 days may
be permitted if the enrollee requests the extension or if the physician or health plan determines
that additional information is needed; or
(ii) In accordance with existing State law regarding prior authorization of health services.
(2) On or after January 1, 2026. (i) In accordance with the medical needs of the enrollee,
but no later than 7 calendar days after receiving the request for a standard determination and by
no later than 72 hours after receiving the request for an expedited determination. A possible
extension of up to 14 days may be permitted if the enrollee requests the extension or if the
physician or health plan determines the additional information is needed; or
(ii) In accordance with existing State law regarding prior authorization of health services.
(3) Enrollee notification. Provide the enrollee with
(i) Notice of the States priorauthorization decision; and
(ii) Information on the enrollees right to a review process, in accordance with 
457.1180.
25. Section 457.700 is amended by revising paragraph (c) to read as follows:
 457.700 Basis, scope, and applicability.
* * * * *
(c) Applicability. The requirements of this subpart apply to separate child health
programs and Medicaid expansion programs, except that  457.730, 457.731, and 457.732 do
not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care entities may meet the requirements of  457.730, 457.731,
and 457.732 by requiring the managed care entities to meet the requirements of  457.1233(d).
26. Section 457.730 is amended by
a. Revising paragraph (b)(3);
b. Adding paragraphs (b)(5) and (6);
c. Revising paragraphs (c)(1), (c)(4)(ii)(C), and (e)(2);
d. Removing paragraph (g);
e. Redesignating paragraph (f) as paragraph (g); and
f. Adding new paragraph (f) and paragraph (h).
The revisions and additions read as follows:
 457.730 Beneficiary access to and exchange of data.
* * * * *
(b) * * *
(3) All data classes and data elements included in a content standard in 45 CFR 170.213
that are maintained by the State no later than 1 business day after the State receives the data; and
* * * * *
(5) Beginning January 1, 2027, the information in paragraph (b)(5)(i) of this section
about prior authorizations for items and services (excluding drugs as defined in paragraph (b)(6)
of this section), according to the timelines in paragraph (b)(5)(ii) of this section.
(i) The prior authorization request and decision, including all of the following, as
applicable:
(A) The prior authorization status.
(B) The date the prior authorization was approved or denied.
(C) The date or circumstance under which the prior authorization ends.
(D) The items and services approved.
(E) If denied, a specific reason why the request was denied. (F) Related structured administrative and clinical documentation submitted by a
provider.
(ii) The information in paragraph (b)(5)(i) of this section must
(A) Be accessible no later than 1 business day after the State receives a prior
authorization request;
(B) Be updated no later than 1 business day after any status change; and
(C) Continue to be accessible for the duration that the authorization is active and at least
1 year after the prior authorizations last status change.
(6) Drugs are defined for the purposes of paragraph (b)(5) of this section as any and all
drugs covered by the State.
(c) * * *
(1) Must implement and maintain API technology conformant with 45 CFR
170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * *
(C) Using the updated version of the standard, implementation guide, or specification
does not disrupt an end users ability to access the data specified in paragraph (b) of this section
or  457.731, 457.732, and 457.760 through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and
consistently across all apps and developers through which parties seek to access electronic health
information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on
automated monitoring and risk mitigation tools.
* * * * * (f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 of each year,
a State must report to CMS the following metrics, in the form of aggregated, de-identified data,
for the previous calendar year at the State levelin the form and manner specified by the
Secretary:
(1) The total number of unique beneficiaries whose data are transferred via the Patient
Access API to a health app designated by the beneficiary; and
(2) The total number of unique beneficiaries whose data are transferred more than once
via the Patient Access API to a health app designated by the beneficiary.
* * * * *
(h) Applicability. A State must comply with the requirements in paragraphs (a) through
(e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f)
of this section beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the State.
27. Section 457.731 is added to read as follows:
 457.731 Access to and exchange of health data for providers and payers.
(a) Application programming interface to support data exchange from payers to
providers  Provider Access API. Beginning January 1, 2027, unless granted an extension or
exemption under paragraph (c) of this section, a State must do the following:
(1) API requirements. Implement and maintain an application programming interface
(API) conformant with all of the following:
(i) Section 457.730(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).
(2) Provider access. Make the data specified in  457.730(b) with a date of service on or
after January 1, 2016, excluding provider remittances and beneficiary cost-sharing information,
that are maintained by the State, available to enrolled CHIP providers via the API required in paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a
provider, if all the following conditions are met:
(i) The State authenticates the identity of the provider that requests access and attributes
the beneficiary to the provider under the attribution process described in paragraph (a)(3) of this
section.
(ii) The beneficiary does not opt out as described in paragraph (a)(4) of this section.
(iii) Disclosure of the data is not prohibited by other applicable law.
(3) Attribution. Establish and maintain a process to associate beneficiaries with their
enrolled CHIP providers to enable data exchange via the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and maintain a process to
allow a beneficiary or the beneficiarys personal representative to opt out of the data exchange
described in paragraph (a)(2) of this section and to change their permission at any time. That
process must be available before the first date on which the State makes beneficiary information
available via the Provider Access API and at any time while the beneficiary is enrolled with the
State.
(ii) Provide information to beneficiaries in plain language about the benefits of API data
exchange with their providers, their opt out rights, and instructions both for opting out of data
exchange and for subsequently opting in, as follows:
(A) Before the first date on which the State makes beneficiary information available
through the Provider Access API.
(B) No later than 1 week after enrollment.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other appropriate provider
communications, information in plain language explaining the process for requesting beneficiary
data using the Provider Access API required in paragraph (a)(1) of this section. The resources must include information about how to use the States attribution process to associate
beneficiaries with their providers.
(b) Application programming interface to support data exchange between payers 
Payer-to-Payer API. Beginning January 1, 2027, unless granted an extension or exemption under
paragraph (c) of this section a State must do the following:
(1) API requirements. Implement and maintain an API conformant with all of the
following:
(i) Section 457.730(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow beneficiaries or their personal
representatives to opt into the States payer to payer data exchange with the beneficiarys
previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent
payer(s), described in paragraph (b)(6) of this section, and to change their permission at any
time.
(i) The opt in process must be offered as follows:
(A) To current beneficiaries, no later than the compliance date.
(B) To new beneficiaries, no later than 1 week after enrollment.
(ii) If a beneficiary has coverage through any CHIP managed care entities within the
same State while enrolled in CHIP, the State must share their opt in permission with those
managed care entities to allow the Payer-to-Payer API data exchange described in this section.
(iii) If a beneficiary does not respond or additional information is necessary, the State
must make reasonable efforts to engage with the beneficiary to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain a process to identify
a new beneficiarys previous and concurrent payer(s) to facilitate the Payer-to-Payer API data
exchange. The information request process must start as follows:
(i) For current beneficiaries, no later than the compliance date. (ii) For new beneficiaries, no later than 1 week after enrollment.
(iii) If a beneficiary does not respond or additional information is necessary, the State
must make reasonable efforts to engage with the beneficiary to collect this information.
(4) Exchange request requirements. Exchange beneficiary data with other payers,
consistent with the following requirements:
(i) The State must request the data specified in paragraph (b)(4)(ii) of this section through
the beneficiarys previous payers API, if all the following conditions are met:
(A) The beneficiary has opted in, as described in paragraph (b)(2) of this section, except
for data exchanges between a State CHIP agency and its contracted managed care entities, which
do not require a beneficiary to opt in.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date of service within 5 years
before the request:
(A) Data specified in  457.730(b), excluding the following:
(1) Provider remittances and enrollee cost-sharing information.
(2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation submitted by a provider
related to prior authorizations.
(iii) The State must include an attestation with this request affirming that the beneficiary
is enrolled with the State and has opted into the data exchange.
(iv) The State must complete this request as follows:
(A) No later than 1 week after the payer has sufficient identifying information about
previous payers and the beneficiary has opted in.
(B) At a beneficiarys request, within 1 week of the request. (v) The State must receive, through the API required in paragraph (b)(1) of this section,
and incorporate into its records about the beneficiary, any data made available by other payers in
response to the request.
(5) Exchange response requirements. Make available the data specified in paragraph
(b)(4)(ii) of this section that are maintained by the State to other payers via the API required in
paragraph (b)(1) of this section within 1 business day of receiving a request, if all the following
conditions are met:
(i) The payer that requests access has its identity authenticated and includes an attestation
with the request that the patient is enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable law.
(6) Concurrent coverage data exchange requirements. When a beneficiary has provided
sufficient identifying information about concurrent payers and has opted in as described in
paragraph (b)(2) of this section, a State must do the following, through the API required in
paragraph (b)(1) of this section:
(i) Request the beneficiarys data from all known concurrent payers as described in
paragraph (b)(4) of this section, and at least quarterly thereafter while the beneficiary is enrolled
with both payers.
(ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a
request from any concurrent payers. If agreed upon with the requesting payer, the State may
exclude any data that were previously sent to or originally received from the concurrent payer.
(7) Patient educationalresources. Provide information to applicants or beneficiaries in
plain language, explaining at a minimum: the benefits of Payer-to-Payer API data exchange,
their ability to opt in or withdraw that permission, and instructions for doing so. The State must
provide the following resources:
(i) When requesting a beneficiarys permission for Payer-to-Payer API data exchange, as
described in paragraph (b)(2) of this section. (ii) At least annually, in appropriate mechanisms through which it ordinarily
communicates with current beneficiaries.
(iii) In an easily accessible location on its public website.
(c) Extensions and exemptions(1) Extension. (i) A State may submit a written
application to requesta one-time, 1-year extension of the requirements in paragraph (a) or (b) (or
paragraphs (a) and (b)) of this section for its CHIP fee-for-service program. The written
application must be submitted as part of the States annual Advance Planning Document (APD)
for Medicaid Management Information System (MMIS) operations expenditures, as described in
part 433, subpart C, of this chapter, and approved before the compliance date for the
requirements to which the State is seeking an extension. It must include all the following:
(A) A narrative justification describing the specific reasons why the State cannot satisfy
the requirement(s) by the compliance date and why those reasons result from circumstances that
are unique to the agency operating the CHIP fee-for service program.
(B) A report on completed and ongoing State activities that evidence a good faith effort
towards compliance.
(C) A comprehensive plan to meet the requirements no later than 1 year after the
compliance date.
(ii) CMS grants the States request if it determines,based on the information provided,
that
(A) The request adequately establishes a need to delay implementation; and
(B) The State has a comprehensive plan to meet the requirements no later than 1 year
after the compliance date.
(2) Exemption. (i) A State operating a separate CHIP in which at least 90 percent of the
States CHIP beneficiaries are enrolled in CHIP managed care organizations, as defined in
457.10, may request an exemption for its fee-for-service program from either or both of the
following requirements: (A) Paragraph (a) of this section.
(B) Paragraphs (b)(1) and (3) through (7) of this section.
(ii) The States exemption request must:
(A) Be submitted in writing as part of a States annual APD for MMIS operations
expenditures before the compliance date for the requirements to which the State is seeking an
exemption.
(B) Include both of the following:
(1) Documentation that the State meets the threshold for the exemption, based on
enrollment data from section 5 of the most recently accepted CHIP Annual Report Template
System (CARTS).
(2) An alternative plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMSs satisfaction that the
State
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that enrolled providers will have
efficient electronic access to the same information through other means while the exemption is in
effect.
(iv) The States exemption expires if either--
(A) Based on the 3 previous years of available, finalized CHIP CARTS managed care
and fee-for-service enrollment data, the States managed care enrollment for 2 of the previous 3
years is below 90 percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that
would significantly reduce the percentage of beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first available, finalized
CARTS managed care and fee-for-service enrollment data. (v) If a States exemption expires under paragraph (c)(2)(iv) of this section, the State is
required to do both of the following:
(A) Submit written notification to CMS that the State no longer qualifies for the
exemption within 90 days of the finalization of annual CARTS managed care enrollment data
that demonstrates that there has been the requisite shift from managed care enrollment to fee-for-
service enrollment resulting in the States managed care enrollment falling below the 90 percent
threshold.
(B) Obtain CMS approval of a timeline for compliance with the requirements in
paragraph (a) or (b) (or paragraphs (a) and (b)) of this section within 2 years of the expiration of
the exemption.
28. Section 457.732 is added to read as follows:
 457.732 Prior authorization requirements.
(a) Communicating a reason for denial. Beginning January 1, 2026, if the State denies a
prior authorization request (excluding a request for coverage of drugs as defined in 
457.730(b)(6)), in accordance with the timeframes established in  457.495(d), the response to
the provider must include a specific reason forthe denial,regardless of the method used to
communicate that information.
(b) Prior Authorization Application Programming Interface (API). Unless granted an
extension or exemption under paragraph (d) of this section, beginning January 1, 2027, a State
must implement and maintain an API conformant with  457.730(c)(2) through (4), (d), and (e),
and the standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (c)(1) that--
(1) Is populated with the States list of covered items and services (excluding drugs as
defined in  457.730(b)(6)) that require prior authorization;
(2) Can identify all documentation required by the State for approval of any items or
services that require prior authorization; (3) Supports a HIPAA-compliant prior authorization request and response, as described
in 45 CFR part 162; and
(4) Communicates the following information about prior authorization requests:
(i) Whether the State
(A) Approves the prior authorization request (and the date or circumstance under which
the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information.
(ii) If the State denies the prior authorization request, it must include a specific reason
for the denial.
(c) Publicly reporting prior authorization metrics. Beginning in 2026, a State must
annually report prior authorization data, excluding data on drugs as defined in  457.730(b)(6), at
the State level by March 31. The State must make the following data from the previous calendar
year publicly accessible by posting them on its website:
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved,
aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated
for all items and services.
(4) The percentage of standard prior authorization requests that were approved after
appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review
was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved,
aggregated for all items and services. (7) The percentage of expedited prior authorization requests that were denied, aggregated
for all items and services.
(8) The average and median time that elapsed between the submission of a request and a
determination by the State, for standard prior authorizations, aggregated for all items and
services.
(9) The average and median time that elapsed between the submission of a request and a
decision by the State for expedited prior authorizations, aggregated for all items and services.
(d) Extensions and exemptions(1) Extension. (i) A State may submit a written
application to requesta one-time, 1-year extension of the requirements in paragraph (b) of this
section for its CHIP fee-for-service program. The written application must be submitted and
approved as part of the States annual Advance Planning Document (APD) for Medicaid
Management Information System (MMIS) operations expenditures described in part 433, subpart
C, of this chapter, and approved before the compliance date in paragraph (b) of this section. It
must include all the following:
(A) A narrative justification describing the specific reasons why the State cannot satisfy
the requirement(s) by the compliance date and why those reasons result from circumstances that
are unique to the agency operating the CHIP fee-for service program;
(B) A report on completed and ongoing State activities that evidence a good faith effort
toward compliance.
(C) A comprehensive plan to meet the requirements no later than 1 year after the
compliance date.
(ii) CMS grants the States request if it determines,based on the information provided,
that
(A) The request adequately establishes a need to delay implementation; and
(B) The State has a comprehensive plan to meet the requirements no later than 1 year
after the compliance date. (2) Exemption. (i) A State operating a separate CHIP in which at least 90 percent of the
States CHIP beneficiaries are enrolled in CHIP managed care organizations, as defined in
457.10, may request an exemption for its fee-for-service program from the requirements in
paragraph (b) of this section.
(ii) The States exemption request must:
(A) Be submitted in writing as part of a States annual APD for MMIS operations
expenditures before the compliance date in paragraph (b) of this section.
(B) Include both of the following:
(1) Documentation that the State meets the threshold for the exemption, based on
enrollment data from section 5 of the most recently accepted CARTS.
(2) An alternative plan to ensure that enrolled providers will have efficient electronic
access to the same information through other means while the exemption is in effect.
(iii) CMS grants the exemption if the State establishes to CMSs satisfaction that the
State
(A) Meets the threshold for the exemption; and
(B) Has established an alternative plan to ensure that its enrolled providers will have
efficient electronic access to the same information through other means while the exemption is in
effect.
(iv) The States exemption expires if either
(A) Based on the 3 previous years of available, finalized CHIP CARTS managed care
and fee-for-service enrollment data, the States managed care enrollment for 2 of the previous 3
years is below 90 percent; or
(B)(1) CMS has approved a State plan amendment, waiver, or waiver amendment that
would significantly reduce the percentage of beneficiaries enrolled in managed care; and
(2) The anticipated shift in enrollment is confirmed by the first available, finalized
CARTS managed care and fee-for-service enrollment data. (v) If a States exemption expires under paragraph (d)(2)(iv) of this section, the State is
required to do both of the following:
(A) Submit written notification to CMS that the State no longer qualifies for the
exemption within 90 days of the finalization of annual CARTS managed care enrollment data
that demonstrates that there has been the requisite shift from managed care enrollment to
fee-for-service enrollment resulting in the States managed care enrollment falling below the 90
percent threshold.
(B) Obtain CMS approval of a timeline for compliance with the requirements in
paragraph (b) of this section within 2 years of the expiration of the exemption.
29. Section 457.1206 is amended by revising paragraph (b)(6) to read as follows:
 457.1206 Non-emergency medical transportation PAHPs.
* * * * *
(b) * * *
(6) The PAHP standards in  438.206(b)(1) of this chapter, as cross-referenced by
 457.1230(a) and (d) and 457.1233(a), (b), and (d), excluding the requirement in
 438.242(b)(7) of this chapter to comply with  431.61(a) of this chapter.
* * * * *
30. Section 457.1230 is amended by revising paragraph (d) to read as follows:
 457.1230 Access standards.
* * * * *
(d) Coverage and authorization of services. The State must ensure, through its contracts,
that each MCO, PIHP, or PAHP complies with the coverage and authorization of services
requirements in accordance with the terms of  438.210 of this chapter, except that the following
do not apply:
(1) Section 438.210(a)(5) of this chapter (related to medical necessity standard). (2) Section 438.210(b)(2)(iii) of this chapter (related to authorizing long term services
and supports (LTSS)).
Title 45  Public Welfare
PART 156HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE
CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES
31. The authority citation for part 156 continues to read as follows:
Authority: 42 U.S.C. 18021-18024, 18031-18032, 18041-18042, 18044, 18054, 18061,
18063, 18071, 18082, and 26 U.S.C. 36B.
32. Section 156.221 is amended by
a. In paragraph (b)(1)(ii), removing the word and at the end of the paragraph;
b. Revising paragraph (b)(1)(iii);
c. Adding paragraphs (b)(1)(iv) and (v); and
d. Revising paragraphs (c)(1), (c)(4)(ii)(C), (e)(2), (f), and (i).
The revisions and addition read as follows:
 156.221 Access to and exchange of health data and plan information.
* * * * *
(b) * * *
(1) * * *
(iii) All data classes and data elements included in a content standard in 45 CFR 170.213
that are maintained by the Qualified Health Plan (QHP) issuer no later than 1 business day after
the QHP issuer receives the data; and
(iv) For plan years beginning on or after January 1, 2027, the information in paragraph
(b)(1)(iv)(A) of this section about prior authorizations for items and services (excluding drugs, as
defined in paragraph (b)(1)(v) of this section), according to the timelines in paragraph
(b)(1)(iv)(B) of this section. (A) The prior authorization request and decision, including all of the following, as
applicable:
(1) The prior authorization status.
(2) The date the prior authorization was approved or denied.
(3) The date or circumstance under which the prior authorization ends.
(4) The items and services approved.
(5) If denied, a specific reason why the request was denied.
(6) Related structured administrative and clinical documentation submitted by a
provider.
(B) The information in paragraph (b)(1)(iv)(A) of this section must
(1) Be accessible no later than 1 business day after the QHP issuer receives a prior
authorization request;
(2) Be updated no later than 1 business day after any status change; and
(3) Continue to be accessible for the duration that the authorization is active and at least 1
year after the prior authorizations last status change.
(v) Drugs are defined for the purposes of paragraph (b)(1)(iv) of this section as any and
alldrugs covered by the QHP issuer.
* * * * *
(c) * * *
(1) Must implement and maintain API technology conformant with 45 CFR
170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1);
* * * * *
(4) * * *
(ii) * * * (C) Using the updated version of the standard, implementation guide, or specification
does not disrupt an end users ability to access the data specified in paragraph (b) of this section
or  156.221, 156.222, and 156.223 through the required APIs.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria that are applied fairly and
consistently across all apps and developers through which parties seek to access electronic health
information, as defined in 45 CFR 171.102, including but not limited to criteria that rely on
automated monitoring and risk mitigation tools.
(f) Reporting on Patient Access API usage. Beginning in 2026, by March 31 following
any calendar year that it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must
report to CMS the following metrics, in the form of aggregated, de-identified data, for the
previous calendar year at the issuer levelin the form and manner specified by the Secretary:
(1) The total number of unique enrollees whose data are transferred via the Patient
Access API to a health app designated by the enrollee.
(2) The total number of unique enrollees whose data are transferred more than once via
the Patient Access API to a health app designated by the enrollee.
* * * * *
(i) Applicability. A QHP issuer on an individual market Federally-facilitated Exchange,
not including QHP issuers offering only stand-alone dental plans, must comply with the
requirements in paragraphs (a) through (e) and (g) of this section beginning with plan years
beginning on or after January 1, 2021, and with the requirements in paragraph (f) of this section
beginning in 2026, with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the QHP issuer for enrollees in QHPs.
33. Section 156.222 is added to read as follows:  156.222 Access to and exchange of health data for providers and payers.
(a) Application programming interface to support data exchange from payers to
providers  Provider Access API. Unless granted an exception under paragraph (c) of this
section, forplan years beginning on or after January 1, 2027, QHP issuers on a Federally-
facilitated Exchange must do the following:
(1) API requirements. Implement and maintain an application programming interface
(API) conformant with all of the following:
(i) Section 156.221(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (d)(1).
(2) Provider access. Make the data specified in  156.221(b) with a date of service on or
after January 1, 2016, excluding provider remittances and enrollee cost-sharing information, that
are maintained by the QHP issuer to available in-network providers via the API required in
paragraph (a)(1) of this section no later than 1 business day after receiving a request from such a
provider, if all the following conditions are met:
(i) The QHP issuer authenticates the identity of the provider that requests access and
attributes the enrollee to the provider under the attribution process described in paragraph (a)(3)
of this section.
(ii) The enrollee does not opt out as described in paragraph (a)(4) of this section.
(iii) Disclosure of the data is not prohibited by other applicable law.
(3) Attribution. Establish and maintain a process to associate enrollees with their in-
network providers to enable data exchange via the Provider Access API.
(4) Opt out and patient educational resources. (i) Establish and maintain a process to
allow an enrollee or the enrollees personalrepresentative to opt out of data exchange described
in paragraph (a)(2) of this section and to change their permission at any time. That process must
be available before the first date on which the QHP issuer makes enrollee information available
via the Provider Access API and at any time while the enrollee is enrolled with the QHP issuer. (ii) Provide information to enrollees in plain language about the benefits of API data
exchange with their providers, their opt out rights, and instructions both for opting out of data
exchange and for subsequently opting in, as follows:
(A) Before the first date on which the QHP issuer makes enrollee information available
through the Provider Access API.
(B) No later than 1 week after the after the coverage start date or no later than 1 week
after the effectuation of coverage, whichever is later.
(C) At least annually.
(D) In an easily accessible location on its public website.
(5) Provider resources. Provide on its website and through other appropriate provider
communications, information in plain language explaining the process for requesting enrollee
data using the Provider Access API required in paragraph (a)(1) of this section. The resources
must include information about how to use the QHP issuers attribution process to associate
enrollees with their providers.
(b) Application programming interface to support data exchange between payers 
Payer-to-Payer API. Unless granted an exception under paragraph (c) of this section, for plan
years beginning on or after January 1, 2027, QHP issuers on a Federally-facilitated Exchange
must do the following:
(1) API requirements. Implement and maintain an API conformant with all of the
following:
(i) Section 156.221(c)(2) through (4), (d), and (e).
(ii) The standards in 45 CFR 170.215(a)(1), (b)(1)(i), and (d)(1).
(2) Opt in. Establish and maintain a process to allow enrollees or their personal
representatives to opt into the QHP issuers payer to payer data exchange with the enrollees
previous payer(s), described in paragraphs (b)(4) and (5) of this section, and with concurrent payer(s), described in paragraph (b)(6) of this section, and to change their permission at any
time.
(i) The opt in process must be offered as follows:
(A) To current enrollees, no later than the compliance date.
(B) To new enrollees, no later than 1 week after the coverage start date or no later than 1
week after the effectuation of coverage, whichever is later.
(ii) If an enrollee does not respond or additional information is necessary, the QHP issuer
must make reasonable efforts to engage with the enrollee to collect this information.
(3) Identify previous and concurrent payers. Establish and maintain a process to identify
a new enrollees previous and concurrent payer(s) to facilitate the Payer-to-Payer API data
exchange. The information request process must start as follows:
(i) For current enrollees, no later than the compliance date.
(ii) For new enrollees, no later than 1 week after the coverage start date or no later than 1
week after the effectuation of coverage, whichever is later.
(iii) If an enrollee does not respond or additional information is necessary, the QHP
issuer must make reasonable efforts to engage with the enrollee to collect this information.
(4) Exchange request requirements. Exchange enrollee data with other payers, consistent
with the following requirements:
(i) The QHP issuer must request the data specified in paragraph (b)(4)(ii) of this section
through the enrollees previous payers API, if all the following conditions are met:
(A) The enrollee has opted in, as described in paragraph (b)(2) of this section.
(B) The exchange is not prohibited by other applicable law.
(ii) The data to be requested are all of the following with a date of service within 5 years
before the request:
(A) Data specified in  156.221(b) excluding the following:
(1) Provider remittances and enrollee cost-sharing information. (2) Denied prior authorizations.
(B) Unstructured administrative and clinical documentation submitted by a provider
related to prior authorizations.
(iii) The QHP issuer must include an attestation with this request affirming that the
enrollee is enrolled with the QHP issuer and has opted into the data exchange.
(iv) The QHP issuer must complete this request as follows:
(A) No later than 1 week after the payer has sufficient identifying information about
previous payers and the enrollee has opted in.
(B) At an enrollees request, within 1 week of the request.
(v) The QHP issuer must receive, through the API required in paragraph (b)(1) of this
section, and incorporate into its records about the enrollee, any data made available by other
payers in response to the request.
(5) Exchange response requirements. Make available the data specified in paragraph
(b)(4)(ii) of this section that are maintained by the QHP issuer to other payers via the API
required in paragraph (b)(1) of this section within 1 business day of receiving a request, if all the
following conditions are met:
(i) The payer that requests access has its identity authenticated and includes an attestation
with the request that the patient is enrolled with the payer and has opted into the data exchange.
(ii) Disclosure of the data is not prohibited by other applicable law.
(6) Concurrent coverage data exchange requirements. When an enrollee has provided
sufficient identifying information about concurrent payers and has opted in as described in
paragraph (b)(2) of this section, a QHP issuer on a Federally-facilitated Exchange must do the
following, through the API required in paragraph (b)(1) of this section:
(i) Request the enrollees data from all known concurrent payers as described in
paragraph (b)(4) of this section, and at least quarterly thereafter while the enrollee is enrolled
with both payers. (ii) Respond as described in paragraph (b)(5) of this section within 1 business day of a
request from any concurrent payers. If agreed upon with the requesting payer, the QHP issuer
may exclude any data that were previously sent to or originally received from the concurrent
payer.
(7) Patient educationalresources. Provide information to enrollees in plain language,
explaining at a minimum: the benefits of Payer-to-Payer API data exchange, their ability to opt
in or withdraw that permission, and instructions for doing so. The QHP issuer must provide the
following resources:
(i) When requesting an enrollees permission for Payer-to-Payer API data exchange, as
described in paragraph (b)(2) of this section.
(ii) At least annually, in appropriate mechanisms through which it ordinarily
communicates with current enrollees.
(iii) In an easily accessible location on its public website.
(c) Exception. (1) If a plan applying for QHP certification to be offered through a
Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (a) or (b)
(or paragraphs (a) and (b)) of this section, the issuer must include a narrative justification in its
QHP application that describes all of the following:
(i) The reasons why the issuer cannot reasonably satisfy the requirements for the
applicable plan year.
(ii) The impact of non-compliance upon providers and enrollees.
(iii) The current or proposed means of providing health information to payers.
(iv) Solutions and a timeline to achieve compliance with the requirements in paragraph
(a) or (b) of this section (or paragraphs (a) and (b)).
(2) The Federally-facilitated Exchange may grantan exception to the requirements in
paragraph (a) or (b) (or paragraphs (a) and (b)) of this section if the Exchange determines that
making QHPs of such issuer available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates, and an exception is warranted
to permit the issuer to offer QHPs through the FFE.
34. Section 156.223 is added to read as follows:
 156.223 Prior authorization requirements.
(a) Communicating a reason for denial. Beginning January 1, 2026, if the QHP issuer
denies a prior authorization request (excluding a request for coverage of drugs as defined in 
156.221(b)(1)(v)), the response to the provider must include a specific reason for the denial,
regardless of the method used to communicate that information.
(b) Prior Authorization Application Programming Interface (API). Unless granted an
exception under paragraph (d) of this section, for plan years beginning on or after January 1,
2027, a QHP issuer on a Federally-facilitated Exchange must implement and maintain an API
conformant with  156.221(c)(2) through (4), (d), and (e), and the standards in 45 CFR
170.215(a)(1), (b)(1)(i), and (c)(1) that--
(1) Is populated with the QHP issuers list of covered items and services (excluding drugs
as defined in  156.221(b)(1)(v)) that require prior authorization;
(2) Can identify all documentation required by the QHP issuer for approval of any items
or services that require prior authorization;
(3) Supports a HIPAA-compliant prior authorization request and response, as described
in 45 CFR part 162; and
(4) Communicates the following information about prior authorization requests:
(i) Whether the QHP issuer
(A) Approves the prior authorization request (and the date or circumstance under which
the authorization ends);
(B) Denies the prior authorization request; or
(C) Requests more information. (ii) If the QHP issuer denies the prior authorization request, it must include a specific
reason for the denial.
(c) Publicly reporting prior authorization metrics. Beginning in 2026, following each
year it offers a QHP on a Federally-facilitated Exchange, a QHP issuer must report prior
authorization data, excluding data on drugs as defined in  156.221(b)(1)(v), at the issuer level
by March 31. The QHP issuer must make the following data from the previous calendar year
publicly accessible by posting them on its website:
(1) A list of all items and services that require prior authorization.
(2) The percentage of standard prior authorization requests that were approved,
aggregated for all items and services.
(3) The percentage of standard prior authorization requests that were denied, aggregated
for all items and services.
(4) The percentage of standard prior authorization requests that were approved after
appeal, aggregated for all items and services.
(5) The percentage of prior authorization requests for which the timeframe for review
was extended, and the request was approved, aggregated for all items and services.
(6) The percentage of expedited prior authorization requests that were approved,
aggregated for all items and services.
(7) The percentage of expedited prior authorization requests that were denied, aggregated
for all items and services.
(8) The average and median time that elapsed between the submission of a request and a
determination by the QHP issuer, for standard prior authorizations, aggregated for all items and
services.
(9) The average and median time that elapsed between the submission of a request and a
decision by the QHP issuer for expedited prior authorizations, aggregated for all items and
services. (d) Exception. (1) If a plan applying for QHP certification to be offered through a
Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (b) of this
section, the issuer must include a narrative justification in its QHP application that describes all
of the following:
(i) The reasons why the issuer cannot reasonably satisfy the requirements for the
applicable plan year.
(ii) The impact of non-compliance upon providers and enrollees.
(iii) The current or proposed means of providing health information to providers.
(iv) Solutions and a timeline to achieve compliance with the requirements in paragraph
(b) of this section.
(2) The Federally-facilitated Exchange (FFE) may grant an exception to the requirements
in paragraph (b) of this section if the Exchange determines that making QHPs of such issuer
available through such Exchange is in the interests of qualified individuals in the State or States
in which such Exchange operates and an exception is warranted to permit the issuer to offer
QHPs through the FFE.
__________________________________
XavierBecerra,
Secretary,
DepartmentofHealthandHumanServices.
[FRDoc.2024-00895Filed:1/18/20244:15pm;PublicationDate: 2/8/2024]