Proposed Rule2022-26479
Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
December 13, 2022
Issuing agencies
Health and Human Services DepartmentCenters for Medicare & Medicaid Services
Abstract
This proposed rule would place new requirements on Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs) to improve the electronic exchange of healthcare data and streamline processes related to prior authorization, while continuing CMS' drive toward interoperability in the healthcare market. This proposed rule would also add a new measure for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program and for Merit-based Incentive Payment System (MIPS) eligible clinicians under the Promoting Interoperability performance category of MIPS. These policies taken together would play a key role in reducing overall payer and provider burden and improving patient access to health information.
Full Text
<html>
<head>
<title>Federal Register, Volume 87 Issue 238 (Tuesday, December 13, 2022)</title>
</head>
<body><pre>
[Federal Register Volume 87, Number 238 (Tuesday, December 13, 2022)]
[Proposed Rules]
[Pages 76238-76371]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2022-26479]
[[Page 76237]]
Vol. 87
Tuesday,
No. 238
December 13, 2022
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
Centers for Medicare & Medicaid Services
-----------------------------------------------------------------------
42 CFR Parts 422, 431, 435, et al.
-----------------------------------------------------------------------
Office of the Secretary
-----------------------------------------------------------------------
45 CFR Part 156
Medicare and Medicaid Programs; Patient Protection and Affordable Care
Act; Advancing Interoperability and Improving Prior Authorization
Processes for Medicare Advantage Organizations, Medicaid Managed Care
Plans, State Medicaid Agencies, Children's Health Insurance Program
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, Merit-Based
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible
Hospitals and Critical Access Hospitals in the Medicare Promoting
Interoperability Program; Proposed Rule
Federal Register / Vol. 87, No. 238 / Tuesday, December 13, 2022 /
Proposed Rules
[[Page 76238]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 422, 431, 435, 438, 440, and 457
Office of the Secretary
45 CFR Part 156
[CMS-0057-P]
RIN 0938-AU87
Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Advancing Interoperability and Improving Prior Authorization
Processes for Medicare Advantage Organizations, Medicaid Managed Care
Plans, State Medicaid Agencies, Children's Health Insurance Program
(CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, Merit-Based
Incentive Payment System (MIPS) Eligible Clinicians, and Eligible
Hospitals and Critical Access Hospitals in the Medicare Promoting
Interoperability Program
AGENCY: Centers for Medicare & Medicaid Services (CMS), Department of
Health and Human Services (HHS).
ACTION: Proposed rule.
-----------------------------------------------------------------------
SUMMARY: This proposed rule would place new requirements on Medicare
Advantage (MA) organizations, state Medicaid fee-for-service (FFS)
programs, state Children's Health Insurance Program (CHIP) FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
Qualified Health Plan (QHP) issuers on the Federally-facilitated
Exchanges (FFEs) to improve the electronic exchange of healthcare data
and streamline processes related to prior authorization, while
continuing CMS' drive toward interoperability in the healthcare market.
This proposed rule would also add a new measure for eligible hospitals
and critical access hospitals (CAHs) under the Medicare Promoting
Interoperability Program and for Merit-based Incentive Payment System
(MIPS) eligible clinicians under the Promoting Interoperability
performance category of MIPS. These policies taken together would play
a key role in reducing overall payer and provider burden and improving
patient access to health information.
DATES: To be assured consideration, comments must be received at one of
the addresses provided below, no later than 5 p.m. on March 13, 2023.
ADDRESSES: In commenting, please refer to file code CMS-0057-P.
Comments, including mass comment submissions, must be submitted in
one of the following three ways (please choose only one of the ways
listed):
1. Electronically. You may submit electronic comments on this
regulation to <a href="https://www.regulations.gov">https://www.regulations.gov</a>. Follow the ``Submit a
comment'' instructions.
2. By regular mail. You may mail written comments to the following
address ONLY: Centers for Medicare & Medicaid Services, Department of
Health and Human Services, Attention: CMS-0057-P, P.O. Box 8013,
Baltimore, MD 21244-8013.
Please allow sufficient time for mailed comments to be received
before the close of the comment period.
3. By express or overnight mail. You may send written comments to
the following address ONLY: Centers for Medicare & Medicaid Services,
Department of Health and Human Services, Attention: CMS-0057-P, Mail
Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.
For information on viewing public comments, see the beginning of
the SUPPLEMENTARY INFORMATION section.
FOR FURTHER INFORMATION CONTACT: Alexandra Mugge, (410) 786-4457, for
general questions related to any of the policies in this proposed rule,
or questions related to CMS interoperability initiatives.
Lorraine Doo, (443) 615-1309, for issues related to the prior
authorization process policies, or the Prior Authorization
Requirements, Documentation, and Decision (PARDD) Application
Programming Interface (API).
Shanna Hartman, (410) 786-0092, for issues related to the Payer-to-
Payer API, the Electronic Prior Authorization measure for the MIPS
Promoting Interoperability performance category and Medicare Promoting
Interoperability Program, or any of the API standards and
implementation guides (IGs) included in this proposed rule.
David Koppel, (303) 844-2883, for issues related to the Patient
Access API policies, or patient privacy.
Scott Weinberg, (410) 786-6017, for issues related to the Provider
Access API policies, or the Requests for Information.
Amy Gentile, (410) 786-3499, for issues related to Medicaid managed
care.
Kirsten Jensen, (410) 786-8146, for issues related to Medicaid FFS.
Joshua Bougie, (410) 786-8117, for issues related to CHIP.
Natalie Albright, (410) 786-1671, for issues related to MA
organizations.
Ariel Novick, (301) 492-4309, for issues related to QHPs.
Elizabeth Holland, (410) 786-1309, for issues related to MIPS and
the Medicare Promoting Interoperability Program.
Russell Hendel, (410) 786-0329, for issues related to the
Collection of Information and Regulatory Impact Analysis.
SUPPLEMENTARY INFORMATION:
Inspection of Public Comments: All comments received before the
close of the comment period are available for viewing by the public,
including any personally identifiable or confidential business
information that is included in a comment. We post all comments
received before the close of the comment period on the following
website as soon as possible after they have been received: <a href="https://www.regulations.gov">https://www.regulations.gov</a>. Follow the search instructions on that website to
view public comments. CMS will not post on <a href="http://Regulations.gov">Regulations.gov</a> public
comments that make threats to individuals or institutions or suggest
that the individual will take actions to harm the individual. CMS
continues to encourage individuals not to submit duplicative comments.
We will post acceptable comments from multiple unique commenters even
if the content is identical or nearly identical to other comments.
Table of Contents
I. Background and Summary of Provisions
A. Purpose and Background
B. Summary of Major Proposals
II. Provisions of the Proposed Rule
A. Patient Access API
B. Provider Access API
C. Payer to Payer Data Exchange on FHIR
D. Improving Prior Authorization Processes
E. Electronic Prior Authorization for the Merit-Based Incentive
Payment System (MIPS) Promoting Interoperability Performance
Category and the Medicare Promoting Interoperability Program
F. Interoperability Standards for APIs
III. Requests for Information
A. Request for Information: Accelerating the Adoption of
Standards Related to Social Risk Factor Data
B. Request for Information: Electronic Exchange of Behavioral
Health Information
C. Request for Information: Improving the Electronic Exchange of
Information in Medicare Fee-for-Service
D. Request for Information: Advancing Interoperability and
Improving Prior Authorization Processes for Maternal Health
[[Page 76239]]
E. Request for Information: Advancing the Trusted Exchange
Framework and Common Agreement (TEFCA)
IV. Collection of Information Requirements
V. Response to Comments
VI. Regulatory Impact Analysis
Regulations Text
I. Background and Summary of Provisions
A. Purpose and Background
In the May 1, 2020, Federal Register, we published a final rule
implementing the first phase of CMS interoperability rulemaking in the
``Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Interoperability and Patient Access for MA Organization and
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and
CHIP Managed Care Entities, Issuers of Qualified Health Plans on the
Federally-Facilitated Exchanges, and Health Care Providers'' final rule
(85 FR 25510) (hereinafter referred to as the ``CMS Interoperability
and Patient Access final rule'').
On December 18, 2020, we published a proposed rule (85 FR 82586)
(hereinafter referred to as the ``December 2020 CMS Interoperability
proposed rule'') in which we proposed new requirements for state
Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs to
improve the electronic exchange of healthcare data and streamline
processes related to prior authorization, while continuing CMS' drive
toward interoperability and reducing burden in the healthcare market.
In addition, on behalf of the Department of Health and Human Services
(HHS), the Office of the National Coordinator for Health Information
Technology (ONC) proposed the adoption of certain specified
implementation guides (IGs) needed to support the proposed Application
Programming Interface (API) policies in that proposed rule.
We received approximately 251 individual comments on the December
2020 CMS Interoperability proposed rule by the close of the comment
period on January 4, 2021. While commenters largely supported the
intent of the proposals and the proposals themselves, many noted and
emphasized that MA organizations were not included among the impacted
payers. The National Association of Medicaid Directors and state
Medicaid programs expressed concerns about the implementation
timeframes, states' constraints to secure the funding necessary to
implement the requirements of the rule in a timely manner, and states'
ability to recruit staff with necessary technical expertise. Commenters
also raised concerns that the relatively short comment period inhibited
more thorough analyses of the proposals and, for membership
organizations, the ability to receive input from and gain consensus
among their members. The December 2020 CMS Interoperability proposed
rule will not be finalized; we considered whether to issue a final rule
based on that proposed rule, but considering the concerns raised by the
commenters, we have opted not to do so. Instead, we are withdrawing the
December 2020 CMS Interoperability proposed rule and issuing this new
proposed rule that incorporates the feedback we received from
stakeholders on that proposed rule. This approach will allow us to
incorporate the feedback we have already received and provide
additional time for public comment.
Some of the changes we have incorporated in this proposed rule were
influenced by the comments we received on the December 2020 CMS
Interoperability proposed rule. For example, unlike in that proposed
rule, we now propose to require impacted payers to use those health
information technology (IT) standards at 45 CFR 170.215 that are
applicable to each set of API requirements proposed in this rule,
including the HL7 Fast Healthcare Interoperability Resources (FHIR)
standard, the HL7 FHIR US Core Implementation Guide, and the HL7 SMART
Application Launch Framework Implementation Guide. Also, in this
proposed rule, we include MA organizations as impacted payers and
propose that the policies included herein would have a longer
implementation timeline.
Most of the implementation dates for the proposals included in this
proposed rule would begin in 2026, including those for the API
proposals, prior authorization decision timeframes for certain impacted
payers, and certain reporting proposals. We believe a three-year
timeline to recruit and train staff, update or build the APIs, and
update operational procedures would be sufficient for these proposals,
particularly based on the information we have from some payers and
providers regarding similar initiatives already in progress. In
addition to the proposed three-year implementation timeframe, we
propose to give state Medicaid and CHIP FFS programs an opportunity to
seek an extension of proposed implementation deadlines, or an exemption
from meeting certain proposed requirements, in certain circumstances.
Additionally, we include a proposal to provide an exceptions process
for issuers of QHPs on the FFEs. We believe the three-year timeframe
would offer sufficient time for these impacted payers to evaluate their
qualifications to participate in the API proposals in this proposed
rule and to prepare the necessary documentation to request an
extension, exemption, or exception.
We are proposing some clarifications to existing Medicaid
beneficiary notice and fair hearing regulations which apply to Medicaid
prior authorization decisions. Because these are clarifications and
improvements to existing regulations, these policies would become
effective upon the effective date of a final rule if these proposals
are finalized as proposed. We are also proposing terminology changes in
section II.A.2.e related to the Patient Access API that would take
effect with the effective date of the final rule, should these
proposals be finalized as proposed.
We are proposing a new Electronic Prior Authorization measure for
eligible hospitals and CAHs under the Medicare Promoting
Interoperability Program and for MIPS eligible clinicians under the
Promoting Interoperability performance category of MIPS, which is in
direct response to comments we received on the December 2020 CMS
Interoperability proposed rule.
We are re-issuing two requests for information (RFIs) that were
included in the December 2020 CMS Interoperability proposed rule. We
are also issuing three new RFIs: one to solicit information related to
opportunities for improving the electronic exchange of medical
documentation between providers to support prior authorization programs
for Medicare FFS, a second to gather public feedback regarding data
standardization and use of prior authorization to improve maternal
health care, and a third to solicit comment regarding enabling exchange
under the Trusted Exchange Framework and Common Agreement (TEFCA).
With this new proposed rule, we are taking an active approach to
move certain participants in the healthcare market toward
interoperability by proposing policies for the MA program, Medicaid,
CHIP, and QHP issuers on the FFEs, as well as eligible hospitals and
CAHs under the Medicare Promoting Interoperability Program and for MIPS
eligible clinicians under the Promoting Interoperability performance
category of MIPS.
Our proposals emphasize improving health information exchange and
facilitating appropriate and necessary
[[Page 76240]]
patient, provider, and payer access to information in health records.
We also include several proposals intended to reduce payer, provider,
and patient burden by improving prior authorization processes and
helping patients remain at the center of their own care. Prior
authorization refers to the process through which a healthcare
provider, such as an individual clinician, acute care hospital,
ambulatory surgical center, or clinic, obtains approval from a payer
before providing care. Prior authorization requirements are established
by payers to help control costs and ensure payment accuracy by
verifying that an item or service is medically necessary, meets
coverage criteria, and is consistent with standards of care before the
item or service is provided.
For purposes of this proposed rule, references to QHP issuers on
the FFEs exclude issuers offering only stand-alone dental plans
(SADPs). Likewise, we are also excluding QHP issuers offering only QHPs
in the Federally-facilitated Small Business Health Options Program
Exchanges (FF-SHOPs) from the proposed provisions of this rule. We
believe that the proposed standards would be overly burdensome for both
SADP and SHOP issuers. Requiring issuers offering only SADPs and QHPs
in the FF-SHOPs, which have relatively lower enrollment and premium
intake compared to individual market QHPs, to comply with the proposals
in this rule could result in those issuers no longer participating in
the FFEs, which would not be in the best interest of the enrollees. The
categorical exclusion of these issuers is consistent with CMS' approach
to some other QHP requirements. We also propose offering an exceptions
process for QHP issuers on the FFEs for the API requirements proposed
in this rule, that would be conditioned upon approval of a narrative
justification that meets CMS requirements. The proposed exceptions
processes could apply to small issuers, financially vulnerable issuers,
or new entrants to the FFEs that demonstrate that deploying standards-
based API technology consistent with the proposed policies would pose a
significant barrier to the issuers' ability to provide coverage or
service to patients and that not certifying the issuers QHP or QHPs
would result in patients having few or no plan options in certain
areas. This approach is consistent with the exceptions process
finalized for the Patient Access API in the CMS Interoperability and
Patient Access final rule. Were we to apply the proposed standards to
such issuers, we believe it could result in those issuers no longer
participating in the FFEs, which would not be in the best interest of
enrollees. We note that, in this proposed rule, FFEs include FFEs in
states that perform plan management functions. State-based Exchanges on
the Federal Platform (SBE-FPs) are not FFEs, even though patients in
those states enroll in coverage through <a href="http://HealthCare.gov">HealthCare.gov</a>. Hence, QHP
issuers in SBE-FPs would not be subject to the requirements in this
proposed rule. We encourage SBE-FPs and State-based Exchanges operating
their own platforms (SBEs) to consider adopting similar requirements
for QHPs on their Exchanges.
Throughout this proposed rule, we use terms such as ``patient,''
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' Every
reader of this proposed rule is a patient and has received, or will
receive, medical care at some point in their life. In this proposed
rule, we use the term ``patient'' as an inclusive term. We understand
that, historically, we have referred in our regulations to patients
using the other terms previously noted. However, for the proposals
herein, we will use additional, specific terms applicable to
individuals covered under the healthcare programs that we administer
and regulate. We also note that when we discuss patients, the term
includes, where applicable, a patient's personal representative. For
example, a patient or their personal representative may consent to
certain types of information exchange under our proposals. But when we
refer to a patient's medical needs or health records, we are not
including the medical needs or health records of the patient's personal
representative. Per the Privacy, Security, and Breach Notification
Rules (HIPAA Rules) \1\ issued under the Health Insurance Portability
and Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted on
August 21, 1996), as modified, at 45 CFR 164.502(g), and related
guidance thereof, a personal representative, generally and for purposes
of access to protected health information (PHI), defined at 45 CFR
160.103, is someone authorized under state or other applicable law to
act on behalf of an individual in making healthcare-related decisions
(such as a parent, guardian, or person with a medical power of
attorney).\2\ As permitted by the HIPAA Rules, a patient's personal
representative could act on a patient's behalf using the processes
within this proposed rule.
---------------------------------------------------------------------------
\1\ See 45 CFR parts 160 and 164.
\2\ See HHS Office of Civil Rights (OCR) guidance regarding
personal representatives at <a href="https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html</a> and <a href="https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html</a>.
---------------------------------------------------------------------------
We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in
this proposed rule. Certain portions of this proposed rule are
applicable to MA organizations, state Medicaid FFS programs, state CHIP
FFS programs, Medicaid managed care plans (managed care organizations
(MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory
health plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and
PAHPs), and QHP issuers on the FFEs. Where certain proposed provisions
may not be applicable to specific plan or provider types, we have
identified them separately from the aforementioned categories. We use
the term ``payer'' in the preamble of this proposed rule as an
inclusive term for all these programs and, in the case of plans, plan
types, but we also use specific terms as applicable in various sections
of this proposed rule. We are proposing at 42 CFR 457.700(c) that
states that have a Medicaid expansion CHIP (a program under which a
state receives Federal funding to expand Medicaid eligibility to
optional targeted low-income children that meets the requirements of
section 2103 of the Social Security Act), the proposals in this rule
for Medicaid would apply to those programs rather than our proposals
for a separate CHIP. Functionally, our proposals are the same; however,
for clarity, we are making explicit that the Medicaid requirements at
Sec. Sec. 431.60, 431.61, and 431.80 would apply to those programs
rather than the separate CHIP requirements at Sec. Sec. 457.730,
457.731, and 457.732.
We use the term ``items and services'' when discussing prior
authorization in this proposed rule, and note that, unless otherwise
stated, the proposals for prior authorization APIs and processes do not
apply to drugs of any type, meaning any drugs that could be covered by
the impacted payers in this proposed rule (for example, this would
include outpatient drugs, drugs that may be prescribed, those that may
be administered by a physician, or that may be administered in a
pharmacy or hospital), because the processes and standards for prior
authorization applicable to drugs differ from the other ``items and
services'' for which we propose regulation. In the CMS Interoperability
and Patient Access final rule, we finalized policies that would require
payers to send claims data
[[Page 76241]]
related to prescription and other drug claims via an API, and we make
several proposals related to claims data in this proposed rule. For
example, Medicare Advantage Prescription Drug (MA-PD) plans that cover
Part A, Part B, and Part D benefits, as well as supplemental benefits,
are required to provide access to information about all those covered
benefits through the Patient Access API at 42 CFR 422.119(b).
Prescription and other drug information is part of a patient's
longitudinal record and giving patients, providers, and payers access
to claims data for prescription and other drugs can offer valuable
insights into a patient's healthcare, provide benefits for care
coordination, and help avoid potentially harmful drug interactions. We
acknowledge that there are existing laws and regulations that may apply
to prior authorization for drugs for the impacted payers in this
proposed rule. Thus, while the claims data included in our proposed and
previously finalized policies did include prescription and other drug
claims, our proposals related to prior authorization in this proposed
rule do not include standards or policies for any drugs (as previously
described), including covered outpatient drugs under Medicaid, and
Medicare Part B or Part D drugs.
Additionally, we use the terms ``provider'' and ``supplier'' as
inclusive terms composed of individuals, organizations, and
institutions that provide health services, such as clinicians (that is,
physicians and other practitioners), hospitals, skilled nursing
facilities, home health agencies, hospice settings, laboratories,
suppliers of durable medical equipment, prosthetics, orthotics, and
supplies (DMEPOS), community-based organizations, as appropriate in the
context used. When specifically discussing policies related to the
Medicare Promoting Interoperability Program and the Promoting
Interoperability performance category of MIPS, we refer to MIPS
eligible clinicians, eligible hospitals, and CAHs.
Throughout this proposed rule we make several API-related proposals
in which we refer to the functionality as a singular API, or API
gateway, though we acknowledge that this functionality may be made up
of one or multiple APIs. For example, while we refer to the Patient
Access API (discussed in section II.A. of this proposed rule) as a
single API for the purpose of describing the functionality, the same
functionality may be achieved with one or multiple APIs, depending on
the implementation approach chosen by the applicable payer.
An API is a set of commands, functions, protocols, or tools
published by one software developer (``A'') that enables other software
developers to create programs (applications or ``apps'') that can
interact with A's software without needing to know the internal
workings of A's software, while maintaining data security and patient
privacy, if properly implemented. This is how API technology enables
the seamless user experiences associated with applications, which are
familiar in other aspects of patients' daily lives, such as travel and
personal finance. Standardized, secure, transparent, and pro-
competitive API technology can enable similar benefits for patients of
healthcare services.\3\
---------------------------------------------------------------------------
\3\ ONC released an overview of APIs in context of consumers'
access to their own medical information across multiple providers'
electronic health record (EHR) systems, which is available at the
<a href="http://HealthIT.gov">HealthIT.gov</a> website at <a href="https://www.healthit.gov/api-education-module/story_html5.html">https://www.healthit.gov/api-education-module/story_html5.html</a>.
---------------------------------------------------------------------------
Health Level 7 (HL7[supreg]) is the standards development
organization which develops the Fast Healthcare for Interoperability
Resources (FHIR[supreg]) standard and IGs referenced throughout this
proposed rule. HL7 requires the registered trademark with the first use
of its name in a document, for which policies are available on its
website at <a href="http://www.HL7.org">www.HL7.org</a>.\4\
---------------------------------------------------------------------------
\4\ CMS does not use the trademark symbol elsewhere in the
preamble unless necessary when naming specific IGs. For HL7
Trademark policy, see <a href="http://www.hl7.org/legal/trademarks.cfm?ref=nav">http://www.hl7.org/legal/trademarks.cfm?ref=nav</a>.
---------------------------------------------------------------------------
Finally, we note that throughout this proposed rule we discuss the
APIs in relation to the proposed programmatic requirements to share
data between payers, between payers and providers, and between payers
and patients under specific rules. However, these APIs could be used
for a multitude of transactions, aside from those currently described
by section 1173(a)(1) of the Social Security Act, beyond those proposed
in this rule. For instance, a patient could request data outside the
scope of this proposed rule, or program integrity entities could
request data from payers or providers (such as under the Inspector
General Act of 1978). Nothing in this proposed rule would prevent the
requested data from being shared via the APIs discussed in this
proposed rule, if technologically feasible, for appropriate purposes.
In fact, we encourage the use of these standards-based APIs for
purposes beyond the proposed requirements to improve the
interoperability of health data regardless of the use case.
B. Summary of Major Proposals
To drive interoperability, improve care coordination, reduce burden
on providers and payers, and empower patients, we are proposing several
requirements for MA organizations, state Medicaid FFS programs, state
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, as well as MIPS eligible
clinicians participating in the MIPS Promoting Interoperability
performance category, and eligible hospitals and CAHs in the Medicare
Promoting Interoperability Program. We are also including RFIs to
gather information that may support future rulemaking or other
initiatives.
Executive Order (E.O.) 13985 of January 20, 2021, entitled
``Advancing Racial Equity and Support for Underserved Communities
Through the Federal Government,'' set Administration policy that the
``Federal Government should pursue a comprehensive approach to
advancing equity for all.'' \5\ CMS is committed to pursuing a
comprehensive approach to advancing health equity for all, and we
believe the proposals in this rule are aligned with this E.O. because
they represent efforts to mitigate existing inefficiencies in policies,
processes, and technology which affect many patient populations. Some
patient populations are more negatively affected by existing processes
than others and thus might realize greater benefits through the
improvements we propose. One of the main components of this proposed
rule is continued support for the individual's ability to select an app
of their choice when accessing their health information. We want to
ensure that members of all communities can access their health
information and benefit from this technology. However, we are
interested in the best ways to ensure that apps are available and
accessible for individuals with disabilities, individuals with limited
English proficiency, individuals with low literacy or low health
literacy, and individuals with geographic, economic, or other social
risk factors that may create barriers to accessing or using technology
and apps. We are soliciting comments from the public, particularly
individuals who have knowledge about how underserved populations use
healthcare apps and technology, such as researchers, policy advocates,
social service agency staff, providers who serve underserved
populations, and others who may be able to provide insight about
accessibility, readability, and other relevant factors for
consideration. Our goal is to ensure that these proposed policies do
not
[[Page 76242]]
exacerbate current disparities or create unintended inequities that
leave some communities or populations unable to benefit from this
information sharing. Further, we seek to ensure that patient privacy
considerations are built into the implementation of these proposed
policies through the use of secure technologies, such as OAuth 2.0 and
OpenID Connect for authentication, and as further discussed in the CMS
Interoperability and Patient Access final rule (85 FR 25516). While we
have proposed policies that we believe would address some healthcare
inequities, we are soliciting comment about how to help ensure that
individuals from all communities and populations can actively benefit
from our healthcare interoperability proposals.
---------------------------------------------------------------------------
\5\ E.O. 13985, sec. 1, 86 FR 7009 (January 20, 2021).
---------------------------------------------------------------------------
In the CMS Interoperability and Patient Access final rule, we
required impacted payers (MA organizations, state Medicaid FFS
programs, state CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs) to implement and
maintain a standards-based Patient Access API. The Patient Access API
must allow patients, through the health applications of their choice,
to easily access their claims and encounter information as well as
clinical data, including laboratory results, and provider remittances
and enrollee cost-sharing pertaining to such claims, if maintained by
the impacted payer, (85 FR 25558). In this proposed rule, we are
proposing to require that impacted payers (MA organizations, state
Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs) include
information about prior authorizations in the data that are available
through the Patient Access API. In addition, we are proposing to
require these impacted payers to annually report to CMS certain metrics
about patient data requests via the Patient Access API.
To improve coordination across the care continuum and movement
toward value-based care, we are proposing to require that impacted
payers implement and maintain a Provider Access API that, consistent
with the technical standards finalized in the CMS Interoperability and
Patient Access final rule (85 FR 25558), utilizes HL7 FHIR version
4.0.1. That API can be used to exchange current patient data from
payers to providers, including all data classes and data elements
included in a standard adopted at 45 CFR 170.213 (currently USCDI
version 1), adjudicated claims and encounter data (not including
provider remittances and enrollee cost-sharing information), and the
patient's prior authorization decisions.
In the CMS Interoperability and Patient Access final rule, CMS
required certain payers (MA organizations, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs) to exchange a
patient's health data with other payers at the patient's request,
beginning on January 1, 2022, or plan years beginning on or after
January 1, 2022, as applicable (85 FR 25568). We also required those
payers to incorporate the data they receive through this payer to payer
data exchange into patient records, with the goal of creating
longitudinal records that would follow patients as they move from payer
to payer throughout their healthcare journey. However, we did not
require a standards-based API for the payer to payer data exchange.
Since the rule was finalized in May 2020, multiple impacted payers
reported to CMS that the lack of technical specifications for the payer
to payer data exchange requirement in the CMS Interoperability and
Patient Access final rule was creating challenges for implementation,
which, they stated, could lead to incompatible implementations across
the industry, poor data quality, operational challenges, and increased
administrative burdens. They were concerned that different
implementation approaches could create gaps in patient health
information, which would directly conflict with the intended goal of
interoperable payer to payer data exchange.
After considering stakeholder concerns about implementing the payer
to payer data exchange requirement finalized in the CMS
Interoperability and Patient Access final rule, we announced in a
December 10, 2021 Federal Register notification (86 FR 70412) that we
would not enforce the payer to payer data exchange requirements until
further rules are finalized.\6\ In this proposed rule, we are proposing
to rescind our previous payer to payer data exchange requirements and
replace them with a new policy. The CMS Interoperability and Patient
Access final rule also did not apply the payer to payer data exchange
requirements to Medicaid and CHIP FFS programs. We are now proposing to
apply our newly proposed Payer-to-Payer API requirements to Medicaid
and CHIP FFS programs, in addition to other impacted payers as
discussed further in section II.C.4.a. The new proposed policy would
require impacted payers to build a Payer-to-Payer API to facilitate the
exchange of patient information between payers, both at a patient's
request and at the start of coverage with a new payer. Specifically,
that data exchange would include all data classes and data elements
included in a standard adopted at 45 CFR 170.213 (currently USCDI
version 1), adjudicated claims and encounter data (not including
provider remittances and enrollee cost-sharing information), and the
patient's prior authorization decisions.
---------------------------------------------------------------------------
\6\ Centers for Medicare & Medicaid Services (2021, December
10). CMS-9115-N2. Notification of Enforcement Discretion. <a href="https://www.govinfo.gov/content/pkg/FR-2021-12-10/pdf/2021-26764.pdf">https://www.govinfo.gov/content/pkg/FR-2021-12-10/pdf/2021-26764.pdf</a>.
---------------------------------------------------------------------------
To improve the patient experience and access to care, we are also
proposing several new requirements for prior authorization processes
that we believe would ultimately reduce burden on patients, providers,
and payers. To streamline the prior authorization process, we are
proposing to require all impacted payers to implement and maintain a
FHIR Prior Authorization Requirements, Documentation, and Decision API
(PARDD API). The API would streamline the prior authorization process
by automating the process to determine whether a prior authorization is
required for an item or service, thereby eliminating one of the major
pain points of the existing prior authorization process. The API would
then be able to query the payer's prior authorization documentation
requirements and make those requirements available within the
provider's workflow as well as support the automated compilation of
certain information from the provider's system. Finally, the API would
support an automated approach to compiling the necessary data elements
to populate the HIPAA-compliant prior authorization transactions and
enable payers to compile specific responses regarding the status of the
prior authorization, including information about the reason for a
denial. For the exchange of the prior authorization transaction,
covered entities would continue to use the HIPAA-mandated transaction
standards. Use of the FHIR API integrates identification of prior
authorization and documentation requirements as well as information
about prior authorization requests and decisions into a provider's
workflow while maintaining compliance with the adopted HIPAA standard.
We are proposing to require that impacted payers send information
to providers regarding the specific reason for denial when a prior
authorization request is denied, regardless of the mechanism used to
submit the prior authorization request. We are proposing
[[Page 76243]]
to require impacted payers, except for QHP issuers on the FFEs, to
respond to prior authorization requests within certain timeframes. In
addition, we are proposing to require impacted payers to publicly
report certain metrics about their prior authorization processes for
transparency.
We are proposing a new measure for electronic prior authorization
for MIPS eligible clinicians under the Promoting Interoperability
performance category of MIPS and for eligible hospitals and CAHs under
the Medicare Promoting Interoperability Program. To promote PARDD API
adoption, implementation, and use among MIPS eligible clinicians,
eligible hospitals, and CAHs, we are proposing to add a new measure
titled ``Electronic Prior Authorization'' under the Health Information
Exchange (HIE) objective in the MIPS Promoting Interoperability
performance category and the Medicare Promoting Interoperability
Program, beginning with the performance period/EHR reporting period in
calendar year (CY) 2026. For this measure, we are proposing that a MIPS
eligible clinician, eligible hospital, or CAH must report a numerator
and denominator or (if applicable) an exclusion.
Although these proposals do not directly pertain to Medicare FFS,
we want to ensure that people with Medicare can benefit from the
policies we are proposing, regardless of their coverage or delivery
system. We intend for the Medicare FFS program to be a market leader on
data exchange, including through the Provider Access, Payer-to-Payer,
and Prior Authorization APIs. and therefore, seek comment throughout on
how these proposals could apply to Medicare FFS. Similarly, we
encourage other payers not directly impacted by this proposed rule to
evaluate our proposals for voluntary adoption to reduce burden and
support greater interoperability. Further information about CMS
initiatives to achieve the desired level of data exchange with
patients, providers and other payers can be found in those sections in
this proposed rule.
We are also including five RFIs to gather information that may
support future rulemaking or other initiatives. Specifically, we
request information on barriers to adopting standards, and
opportunities to accelerate the adoption of standards, for social risk
data. We recognize that social risk factors (for example, housing
instability and food insecurity) influence patient health and
healthcare utilization. In addition, we understand that providers in
value-based payment arrangements rely on comprehensive, high-quality
social risk data. Given the importance of these data, we want to
understand how we can better standardize and promote the exchange of
these data in accordance with the law.
Additionally, we are seeking comment on how CMS could leverage APIs
(or other technology) to facilitate electronic data exchange between
and with behavioral healthcare providers, which generally have lower
rates of EHR adoption than other provider types.
Furthermore, in the Medicare FFS program, the ordering provider can
be different than the rendering provider of items or services, which
creates unique obstacles to the coordination of patient care and
exchange of medical information needed to ensure an accurate and timely
payment. We are interested in public comments regarding how Medicare
FFS could support improved medical documentation exchange between and
among providers, suppliers, and patients as we believe it could enable
better care for beneficiaries if covered services are not delayed by
inefficiencies.
We also seek comment on how using data standards and electronic
health records can improve maternal health outcomes. Additionally, we
include questions related to how prior authorization can be improved
and what special considerations should be given to support data sharing
in maternal health care.
Finally, we seek comment on how to encourage providers and payers
to enable exchange under TEFCA to make patient information more readily
available for access and exchange in a variety of circumstances. We
wish to understand how CMS can support enabling exchange under TEFCA
and what concerns commenters have about potential requirements related
to enabling exchange under TEFCA.
II. Provisions of the Proposed Rule
A. Patient Access API
1. Background
In the CMS Interoperability and Patient Access final rule (85 FR
25558), in order to give patients access to their own health
information in a way most meaningful and useful to them, we required
impacted payers to share, via FHIR APIs, certain information including
patient claims, encounter data, and a subset of clinical data that
patients can access via health apps. Claims and encounter data, used in
conjunction with clinical data, can offer a broad picture of an
individual's healthcare experience. In the CMS Interoperability and
Patient Access final rule (85 FR 25523), we gave examples of how claims
data can be used to benefit patients and providers. For example,
inconsistent benefit utilization patterns in an individual's claims
data, such as a failure to fill a prescription or receive recommended
therapies, can indicate to a provider or payer that the individual has
had difficulty financing a treatment regimen and may require less
expensive prescription drugs or therapies, additional explanation about
the severity of their condition, or other types of assistance.
Patients tend to receive care from multiple providers, leading to
fragmented patient health records where various pieces of an
individual's longitudinal record are locked in disparate, siloed data
systems. With patient data scattered across these disconnected systems,
it can be challenging for providers to get a clear picture of the
patient's care history, and patients may forget or be unable to provide
critical information to their provider. This lack of comprehensive
patient data can impede care coordination efforts and access to
appropriate care.
As stated in section I.A. of this proposed rule, we are withdrawing
the December 2020 CMS Interoperability proposed rule and issuing this
new proposed rule that incorporates feedback we received from
stakeholders. We understand that many readers may be familiar with that
proposed rule, and, in an effort to distinguish the differences between
that proposed rule and our proposals herein, we refer readers to
section I.A. of this proposed rule outlining the overarching
differences between them. In this proposed rule, we are again proposing
to require impacted payers to report Patient Access API metrics to CMS.
However, we have changed the proposal to require reporting annually, as
opposed to quarterly. In addition, we are no longer proposing that
impacted payers maintain a process for requesting an attestation from
health app developers when the developers register their app with the
payer's Patient Access API. Instead, we are seeking comment on a
variety of privacy considerations. Finally, we propose to extend the
compliance date for our proposed policies to January 1, 2026.
As mentioned in section I.A. of this proposed rule, the proposals
in this rule do not directly pertain to Medicare FFS. However, if our
proposals are finalized, we plan to implement these provisions for
Medicare FFS so that people with Medicare FFS could also benefit from
their data availability. Through Blue
[[Page 76244]]
Button 2.0,\7\ CMS makes Parts A, B, and D claims data available
electronically via an API to people with Medicare FFS and those
enrolled in Part D. To align with the API provisions included in the
CMS Interoperability and Patient Access final rule, we have updated the
Blue Button 2.0 API to FHIR Release 4, and begun using the CARIN
Consumer Directed Payer Data Exchange IG for Blue Button 2.0. If we
finalize our proposals, we plan to further align and enhance Blue
Button 2.0 accordingly, as feasible. We seek comment on any
considerations for applying these requirements to apply to Medicare
FFS, if we finalize these proposals.
---------------------------------------------------------------------------
\7\ Blue Button 2.0 allows Medicare beneficiaries to download
claims data to their computer or device to print it or share it with
others. They can also easily link health apps to their account to
share their data with providers, pharmacies, caregivers, or others.
See Centers for Medicare & Medicaid Services. Share your Medicare
claims (Medicare's Blue Button). Retrieved from <a href="https://www.medicare.gov/manage-your-health/share-your-medicare-claims-medicares-blue-button">https://www.medicare.gov/manage-your-health/share-your-medicare-claims-medicares-blue-button</a>.
---------------------------------------------------------------------------
2. Enhancing the Patient Access API
In the CMS Interoperability and Patient Access final rule (85 FR
25558-25559), we adopted regulations that require certain payers,
specifically MA organizations, state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs, to implement and maintain APIs that permit
enrollees to use health apps to access data specified at 42 CFR
422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR
156.221, respectively. The Patient Access API must make available, at a
minimum, adjudicated claims (including provider remittances and
enrollee cost-sharing), encounters with capitated providers, and
clinical data, including laboratory results, with a date of service on
or after January 1, 2016, as maintained by the payer. We finalized a
policy that payers must make those data available via the Patient
Access API no later than 1 business day after a claim is adjudicated or
encounter or clinical data are received.
a. Prior Authorization Information
To enhance our policy by improving the usefulness of the
information available to patients, we are proposing to add information
about prior authorizations to the categories of data required to be
made available to patients through the Patient Access API. In this
section, we refer to the provider's workflow and associated information
and documentation as the ``prior authorization request'' and the
payer's processes and associated information and documentation as the
``prior authorization decision.'' This proposal would apply to all
prior authorization requests and decisions for items and services
(excluding drugs) for which the payer has data, whether the decision is
still pending, active, denied, expired, or is in another status, as
discussed further in this section. The primary goal of the Patient
Access API is to give patients access to their health information. By
expanding patient access to prior authorization information, we intend
to help patients be more informed decision makers and true partners in
their healthcare.
As discussed in section I.A. of this proposed rule, our proposals
for prior authorization APIs and processes do not apply to drugs of any
type that could be covered by an impacted payer, including, for
example, outpatient drugs, drugs that may be prescribed, drugs that may
be administered by a provider, or drugs that may be administered in a
pharmacy or hospital. In section II.D. of this proposed rule, we
propose several provisions focused on making the prior authorization
process less burdensome for providers and payers, which we anticipate
would reduce care delays and improve patient outcomes. We believe that
giving patients access to information about prior authorization
requests and decisions would enable patients to take a more active role
in their own healthcare. As a result, we are proposing to require
impacted payers to provide patients with access to information about
the prior authorization requests made for their care through the
Patient Access API.
We propose to require that via the Patient Access API, impacted
payers make information about prior authorization requests and
decisions (and related administrative and clinical documentation) for
items and services (excluding drugs) available to patients no later
than 1 business day after the payer receives the prior authorization
request or there is another type of status change for the prior
authorization. Examples of status changes include: a payer approves or
denies a pending prior authorization request, a provider or patient
updates a denied prior authorization request with additional
information for reconsideration, or the count of the items or services
used under the prior authorization decision is updated. We expect that
impacted payers use a variety of terminology, but, generally, any
meaningful change to the payer's record of the prior authorization
request or decision would require an update to the information
available to the patient. For the requirement to include prior
authorization information in the data available via the Patient Access
API, we propose a January 1, 2026 compliance date (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026).
The required information available through the API would include
the prior authorization status, the date the prior authorization was
approved or denied, the date or circumstance under which the
authorization ends, the items and services approved, and the quantity
used to date under the authorization. The documentation required to be
shared includes any materials that the provider sends to the payer to
support a decision, for example, structured or unstructured clinical
data including laboratory results, scores or assessments, past
medications or procedures, progress notes, or diagnostic reports. In
section II.D.4.a. of this proposed rule, we propose that in the case of
a prior authorization denial, the payer must provide a specific reason
for the denial. We propose that impacted payers would have to make that
specific reason for denying a prior authorization request available to
the patient via the Patient Access API as well. This information can
help patients understand both why a payer denied a prior authorization
request and/or what items and services were authorized for the
patient's recent care.
As further discussed in sections II.B. and II.C. of this proposed
rule, we are proposing to require impacted payers to share the same
information about prior authorization requests and decisions with a
patient's provider via the Provider Access API and via the Payer-to-
Payer API. In this way, these prior authorization data can potentially
be available to all relevant parties. We note that the requirement to
share information about prior authorization via the API is in addition
to any notice requirement that applies to prior authorization requests
and decisions, such as the proposals to require notice of a decision
within certain timeframes discussed in section II.D.5.b. of this
proposed rule.
We believe that 1 business day is appropriate, as patients need
timely access to the information to understand prior authorization
processes and their available care options. As discussed further in
section II.D. of this proposed rule, we are proposing to require payers
to make much of the same information about prior authorization requests
and decisions available via the PARDD API during the decision-making
process. In
[[Page 76245]]
addition, because impacted payers would be required to exchange prior
authorization information electronically, we believe it would be
reasonable for them to share prior authorization information and
documentation with patients within 1 business day of any update to the
prior authorization request or decision.
We are also proposing to require that information about prior
authorizations (and related administrative and clinical documentation)
be available via the Patient Access API for as long as the
authorization is active and at least 1 year after the last status
change. We note that we are formulating our proposal for at least 1
year after any status change, but this provision would be particularly
relevant to denied and expired prior authorizations, to ensure that
they would be available for at least a year after expiring or being
denied. We do not propose to require that payers share a patient's full
prior authorization history because that could comprise a significant
amount of information that may no longer be clinically relevant.
Claims, encounter, and/or clinical data can provide important
information about a patient's health history. With those data available
through the Patient Access API, we believe that process-related
information about long-expired or denied prior authorizations would be
redundant. Also, as prior authorization rules may change over time, we
believe that this information has a limited lifespan of usefulness to a
patient's current care. At the same time, the API should include
information about all active authorizations for as long as they are
active and therefore may be related to ongoing care.
We anticipate that requiring payers to make prior authorization
information accessible through the Patient Access API would help
patients better understand the lifecycle of a prior authorization
request, the items and services that require prior authorization, the
information being considered, and specific clinical criteria their
payer uses to make a determination. We believe that more transparency
would better equip patients to engage with their payer(s) and/or
provider(s). For example, by having access to certain prior
authorization information via the Patient Access API, a patient could
see that prior authorization is needed and has been submitted for a
particular item or service, which could help them better understand the
timeline for the process and plan accordingly. Supporting documentation
could give patients better visibility into what the payer is evaluating
so they could help providers get the best and most accurate information
to payers to facilitate a successful request, thus potentially avoiding
unnecessary care delays and reducing burden on providers and payers.
The proposed requirement could also reduce the need for patients to
make repeated calls to their providers and payers to understand the
status of requests, or to inquire why there are delays in care.
We believe that this proposal would enable patients to participate
in their care more and reduce burden on both providers and payers to
allow them to more efficiently navigate the prior authorization
process. The proposal may also add an additional layer of
accountability for payers to make timely prior authorization decisions,
as patients would be able to follow the prior authorization process
from initiation to conclusion. As with all information made available
via the Patient Access API, we believe industry is in the best position
to develop apps for patients to effectively use this information, and
to make sure that the apps are accessible to people with disabilities.
We look to industry innovators to produce apps that will help patients
understand their health information and access it in a manner that is
useful to them.
In summary, we propose that, beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs, for plan years beginning on or after January 1,
2026), impacted payers would be required to make information available
to patients via the Patient Access API about prior authorization
requests and decisions (and related administrative and clinical
documentations), including, as applicable, the status of the prior
authorization; the date the prior authorization was approved or denied;
the date or circumstance under which the authorization ends; the items
and services approved; the quantity used to date; and, if the prior
authorization was denied, a specific reason why the request was denied,
no later than 1 business day after the payer receives a prior
authorization request for items and services (excluding drugs) or there
is another type of status change for the prior authorization. We are
also proposing that, beginning January 1, 2026 (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs,
for plan years beginning on or after January 1, 2026), impacted payers
must make prior authorization information (and related administrative
and clinical documentation), available to patients via the Patient
Access API for the duration it is active and at least 1 year after the
last status change. These proposals would apply to MA organizations,
state Medicaid FFS and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs at the CFR
sections identified in Table 1.
The requirements for a Patient Access API imposed on Medicaid
managed care plans and CHIP managed care entities are set forth at 42
CFR 438.242(b)(5) and 457.1233(d), respectively. Through an amendment
to paragraph (b)(5) and by adding a new paragraph (b)(8) at 42 CFR
438.242, we are proposing to require Medicaid managed care plans (and
through Sec. 457.1233(d), CHIP managed care entities) to include
information about prior authorization requests and decisions and
related administrative and clinical documentation in the data available
via to the Patient Access API by the rating period beginning on or
after January 1, 2026. We request comment on this proposal.
We request comment on how we could or should apply these
requirements to Medicare FFS and its existing prior authorization
requirements and standards.
As stated earlier in this preamble, the proposals in this proposed
rule do not apply to any drugs. However, we also request comments on
whether we should consider policies to require impacted payers to
include information about prior authorizations for drugs, when the
payer covers drugs, via the Patient Access API, the Provider Access
API, and the Payer-to-Payer API. We request comments on how future
rulemaking to make information about prior authorizations for drugs
available through these APIs might interact with existing prior
authorization requirements and standards.
b. Interaction With HIPAA Right of Access Provisions
Previous proposals have elicited numerous comments regarding the
interaction between the Patient Access API and HIPAA Privacy Rule
requirements for individual access.\8\ Per 45 CFR 164.524, an
individual patient generally has a right of access to inspect and
obtain a copy of protected health information (PHI) about themselves in
a designated record set for as long as the PHI is maintained in the
designated record set by a covered entity. This includes the right to
inspect or obtain a
[[Page 76246]]
copy, or both, of the PHI. Our Patient Access API proposals would
complement that right by requiring payers to make the PHI that patients
already have a right to access available through a standards-based and
interoperable Patient Access API. It is critical that individuals have
access to their information and the ability to share it with others who
are involved in their care, particularly when it could involve care
coordination between providers and prior authorization for certain
items and services.
---------------------------------------------------------------------------
\8\ See CMS Interoperability and Patient Access final rule (85
FR 25516-19) and December 2020 CMS Interoperability proposed rule
(85 FR 82586).
---------------------------------------------------------------------------
When an individual requests an electronic copy of PHI that a
covered entity maintains electronically (ePHI), per 45 CFR
164.524(c)(2)(ii), the covered entity must provide the individual with
access to the information in the requested electronic form and format,
if it is readily producible in that form and format. When the ePHI is
not readily producible in the electronic form and format requested,
then the covered entity must provide access to an agreed upon
alternative readable electronic format.\9\ As health apps become more
common, we believe that it behooves us to require that all impacted
payers be able to provide individuals' ePHI via an industry standard
FHIR API, as demonstrated by both our current requirements and our
proposals in this section. We believe that, in addition to the other
benefits described in this proposed rule, ensuring that patients can
receive their ePHI in a standard, interoperable format that they can
use with the latest technologies would reduce instances of an
individual requesting ePHI in an electronic format that is not readily
producible.
---------------------------------------------------------------------------
\9\ See 45 CFR 164.524(c)(2)(ii) and U.S. Department of Health
and Human Services. Individuals' Right under HIPAA to Access their
Health Information 45 CFR 164.524. Retrieved from <a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html</a>.
---------------------------------------------------------------------------
Individuals have the right under the HIPAA Privacy Rule to request
access to PHI in the form and format requested by the individual, if it
is readily producible in the manner requested.\10\ For example, the
covered entity must transfer or transmit the PHI to the individual even
where the requested mode of transfer or transmission is unsecure as
long as the PHI is ``readily producible'' in such manner, the covered
entity is capable of transmitting the PHI in the manner the individual
requests, and the manner of transmission would not present an
unacceptable level of security risk to the PHI on the covered entity's
systems.\11\ In the CMS Interoperability and Patient Access final rule,
we specifically cited this security risk exception as the only reason
payers could deny API access to a health app that a patient wishes to
use. These risks include, for example, insufficient authentication or
authorization controls, poor encryption, or reverse engineering. The
payer must make that determination using objective, verifiable criteria
that are applied fairly and consistently across all apps and developers
through which patients seek to access their electronic health
information. See 42 CFR 422.119(e) for MA organizations; 42 CFR
431.60(e) for state Medicaid FFS programs, through the existing cross
reference at 42 CFR 438.242(b)(5) for Medicaid managed care plans; 42
CFR 457.730(e) for state CHIP FFS programs, through the existing cross
reference at 42 CFR 457.1233(d) for CHIP managed care entities; and 45
CFR 156.221(e) for QHP issuers on the FFEs.
---------------------------------------------------------------------------
\10\ See 45 CFR 164.524(c)(2).
\11\ U.S. Department of Health and Human Services. Individuals'
Right under HIPAA to Access their Health Information 45 CFR 164.524.
Retrieved from <a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html</a>.
---------------------------------------------------------------------------
Disagreement with the individual about the worthiness of a health
app as a recipient of PHI, or even concerns about what the app might do
with the requested PHI, would not be acceptable reasons to deny an
individual's request.\12\ Therefore, as we also noted in the CMS
Interoperability and Patient Access final rule, covered entities and
business associates would be free to offer advice to patients on the
potential risks involved with requesting data transfers to an app or
entity not covered by HIPAA, but such efforts generally must stop at
education and awareness or advice related to a specific app. For
instance, if a payer noted that the app a patient was using to access
their data did not explain in its privacy policy specifically how the
patient's personal data would be used or sold (a possibility for apps
not covered by HIPAA), the payer could choose to inform the patient
that they may not want to share their data with that app without a
clear understanding of how the app may use the data, including details
about the app's secondary data use policy. If the patient still wants
their data to be shared, or does not respond to the payer's warning,
the payer would need to share their data via the API, absent an
unacceptable security risk to the payer's own system. For more
information on this ability to inform patients, see the CMS
Interoperability and Patient Access final rule at 85 FR 25550. The
requirements we are proposing do not affect or alter any obligations
under the HIPAA Privacy and Security Rules.
---------------------------------------------------------------------------
\12\ Office for Civil Rights (OCR) (2019, April 18). Can a
covered entity refuse to disclose ePHI to an app chosen by an
individual because of concerns about how the app will use or
disclose the ePHI it receives? Retrieved from <a href="https://www.hhs.gov/hipaa/for-professionals/faq/3012/can-a-covered-entity-refuse-to-disclose-ephi.html">https://www.hhs.gov/hipaa/for-professionals/faq/3012/can-a-covered-entity-refuse-to-disclose-ephi.html</a>.
---------------------------------------------------------------------------
We discussed privacy and safety concerns in the context of APIs in
the CMS Interoperability and Patient Access final rule (85 FR 25516).
We note that while the FHIR standard itself does not define security-
related functions, when used in combination with appropriate security
controls (such as authentication and access control), a FHIR API can
and should be implemented and maintained to comply with the HIPAA
Security Rule for secure data exchange.\13\ Furthermore, the covered
entity is not liable for what happens to the PHI once the designated
third party receives the information as directed by the individual.\14\
---------------------------------------------------------------------------
\13\ HL7 International (2022, May 28). HL7 FHIR Release 4. 6.1.0
FHIR Security. Retrieved from <a href="http://www.hl7.org/Fhir/security.html">http://www.hl7.org/Fhir/security.html</a>.
\14\ Office for Civil Rights (OCR) (2020, January 31). What is
the liability of a covered entity in responding to an individual's
access request to send the individual's PHI to a third party?
Retrieved from <a href="https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html">https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/index.html</a>.
---------------------------------------------------------------------------
Our proposals in this section address how a payer must make
patients' data available to them; however, we do not have the authority
to regulate health apps that individuals may wish to use, or what those
apps do with PHI. As discussed, per the CMS Interoperability and
Patient Access final rule, impacted payers may only deny or discontinue
an app's connection to their APIs if an impacted payer makes a
determination using objective, verifiable criteria that the specific
health app would present a danger to the impacted payer's own systems,
such as increasing the risk of cyber-attack.
Regardless of whether HIPAA applies to a health app, other Federal
laws may apply, even where HIPAA does not apply, such as the Federal
Trade Commission (FTC) Act. Under section 5 of the FTC Act (15 U.S.C.
45(a)), the FTC has authority to challenge unfair or deceptive trade
practices, including those related to the privacy and security of
personal health information that apps collect, use, maintain, or share.
For example, if an app discloses an individual's health information in
a manner inconsistent with the app's privacy policy, terms of use, or
an individual's reasonable expectations, or fails to take reasonable
measures to assess and address privacy or data security risks, the
developer of that app may be violating the FTC Act. The FTC has applied
its section 5 authority to a
[[Page 76247]]
wide variety of entities, including health apps.\15\ For more
information about what laws may apply to health apps, see <a href="https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool">https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool</a>.
---------------------------------------------------------------------------
\15\ See, for example, Federal Trade Commission (2021, June 22).
Flo Health, Inc. Retrieved from <a href="https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc">https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3133-flo-health-inc</a>.
---------------------------------------------------------------------------
The FTC also enforces the FTC Health Breach Notification Rule,
which covers most health apps and similar technologies that are not
covered by HIPAA, and therefore, not subject to the HIPAA Breach
Notification Rule.\16\ The FTC's Health Breach Notification Rule sets
forth steps entities covered by that rule must follow when there has
been a breach of unsecured personal health information. Any violation
of the FTC's Health Breach Notification Rule is treated as an unfair or
deceptive act or practice under section 18 of the FTC Act and subject
to civil penalties of up to $46,517 per violation per day.
---------------------------------------------------------------------------
\16\ Federal Trade Commission (January 2022). Complying with
FTC's Health Breach Notification Rule. Retrieved from <a href="https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule">https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule</a>. See also Federal Trade Commission
(2021, September 15). Statement of the Commission on Breaches by
Health Apps and Other Connected Devices. Retrieved from <a href="https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf">https://www.ftc.gov/system/files/documents/public_statements/1596364/statement_of_the_commission_on_breaches_by_health_apps_and_other_connected_devices.pdf</a>.
---------------------------------------------------------------------------
c. Privacy Policy
As we discussed earlier in this proposed rule and in detail
throughout the CMS Interoperability and Patient Access final rule (85
FR 25550), one of the most important aspects of making health data
accessible to patients is to protect the privacy and security of
patient health information, especially because once a patient's data
are received by a health app, their data may no longer be protected by
the HIPAA Rules.\17\ Also as discussed earlier, we do not have the
authority to directly regulate health apps. Yet, we take the privacy
and security of PHI seriously and understand that patients may not know
the implications of giving a health app access to their health
information. We are continually working to find ways to further protect
patient data.
---------------------------------------------------------------------------
\17\ Office for Civil Rights (OCR) (2021, January 6). The access
right, health apps & APIs. Retrieved from <a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access-right-health-apps-apis/index.html">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access-right-health-apps-apis/index.html</a>.
---------------------------------------------------------------------------
In the CMS Interoperability and Patient Access final rule, we
required that impacted payers make educational resources available to
their current and former patients with information to help protect the
privacy and security of their health information. That includes factors
to consider in selecting an app, including potential secondary uses of
data, and the importance of understanding the security and privacy
practices of any app to which they will entrust their health
information. Furthermore, impacted payers must provide an overview of
which types of organizations or individuals are and are not likely to
be HIPAA-covered entities, and the oversight responsibilities of the
Office for Civil Rights (OCR) and the FTC, and how to submit a
complaint to those entities. See 42 CFR 422.119(g) for MA
organizations, 42 CFR 431.60(f) for Medicaid FFS programs, through
existing cross-reference at 42 CFR 438.242(b)(5) for Medicaid managed
care plans, 42 CFR 457.730(f) for CHIP FFS programs, through existing
cross reference at 42 CFR 457.1233(d) for CHIP managed care entities,
and at 45 CFR 156.221(g) for QHP issuers on the FFEs. We continue to
believe these resources are important to provide to patients, but seek
comments on how we can improve this policy so patients can make
educated decisions about sharing their personal health information.
In the 21st Century Cures Act: Interoperability, Information
Blocking, and the ONC Health IT Certification Program final rule (21st
Century Cures Act final rule) (85 FR 25642, 25814 through 25815), ONC
noted that providing information that is factually accurate, objective,
unbiased, not unfair or deceptive, and provided in a non-discriminatory
manner to inform a patient about the advantages, disadvantages and any
risks of sharing their health information with a health app, would be
unlikely to interfere (as defined in that rule) with the access,
exchange, or use of electronic health information (EHI) for purposes of
the information blocking regulations at 45 CFR part 171.\18\
---------------------------------------------------------------------------
\18\ See 45 CFR 171.102: Electronic health information (EHI) is
electronic protected health information as defined in 45 CFR 160.103
to the extent that it would be included in a designated record set
as defined in 45 CFR 164.501, regardless of whether the group of
records are used or maintained by or for a covered entity as defined
in 45 CFR 160.103. EHI shall not include: (1) Psychotherapy notes as
defined in 45 CFR 164.501; or (2) Information compiled in reasonable
anticipation of, or for use in, a civil, criminal, or administrative
action or proceeding.
---------------------------------------------------------------------------
In response to comments on the CMS Interoperability and Patient
Access proposed rule (84 FR 7610), we noted in the final rule (85 FR
25549-25550) commenters' observations that many patients were unlikely
to understand the potential risk of disclosure when their data are
transmitted to a health app and are thus no longer protected by the
HIPAA Rules. Commenters were specifically concerned about secondary
uses of data, such as whether developers would sell their data to third
parties for marketing or other purposes. In the CMS Interoperability
and Patient Access final rule (85 FR 25549), we noted that a clear,
plain language privacy policy is the best vehicle to inform patients
about how their information will be protected and how it will be used
once shared with the health app.
In the December 2020 CMS Interoperability proposed rule (85 FR
82592 through 82594), we proposed to require impacted payers to request
a privacy policy attestation from health app developers when their app
requests to connect to the payer's Patient Access API. We proposed that
the attestation would include, at a minimum, statements that the app
has a plain language privacy policy that is always publicly available
and accessible, and has been affirmatively shared with the patient
prior to the patient authorizing the app to access their health
information. In addition, the attestation we proposed included yes/no
elements as to whether the privacy policy specifically communicates how
the patient's health information could be accessed, exchanged, or used.
While we still believe that certain aspects of our previously
proposed attestation policy could support enhanced patient education
about health apps' privacy policies, based on public comments and
feedback, we are concerned that this type of attestation would not
serve to benefit patients in ways that would outweigh the burden on
impacted payers. We are also concerned that such a policy could have
unintended consequences for patients. Under the proposal in the
December 2020 CMS Interoperability proposed rule, a health app
developer would only be attesting to the format and inclusion of
certain information. There would be no attestation that the substance
of the privacy policy meets specific minimum requirements or best
practices. We believe that having payers inform patients that an app
developer has attested to the form and format of a privacy policy could
easily be misinterpreted as assurance that the substance of the privacy
policy has been reviewed and found acceptable by the payer (or CMS). We
believe this is especially true in the case of patients with low health
or technology literacy, who are least likely to be able to find and
interpret an app's privacy policy to make well-informed decisions about
their health data. We are concerned that requiring such an attestation
would only give the appearance of privacy and
[[Page 76248]]
security for patients' health data, without providing additional
benefit.
Because CMS does not have the statutory authority to regulate
health apps, we cannot require developers to respond to that
attestation. Furthermore, as discussed, even if a health app developer
does not respond to the attestation (or responds in the negative), a
payer would be required to allow that app to connect (unless it would
create a security risk to the payer's own system) and provide a
patient's health information through the app selected by the patient.
Commenters also responded that the proposed process would put an
undue burden on payers to manage an attestation process for app
developers with whom they may have no legal or contractual
relationship. Furthermore, commenters expressed concerns about payers'
lack of adherence mechanisms and payer liability due to the HIPAA right
of access requirements discussed previously.
We still believe it is important for patients to have a clear
understanding of how their health information may be used by a person
or entity not covered by the HIPAA Rules, such as a health app, whether
their data would be sold or marketed, and how to stop sharing their
health information with such entities if they so choose. In particular,
explaining certain privacy and security practices in a patient-
friendly, easy-to-read privacy policy would help patients understand
those elements and how they can be an active participant in the
protection of their information. We also encourage app developers to
follow industry best practices, including the CARIN Alliance's Code of
Conduct and the ONC Model Privacy Notice (MPN).<SUP>19 20</SUP> We note
that the developer attestation discussed in the December 2020 CMS
Interoperability proposed rule (85 FR 82593) included some of the
elements of the 2018 ONC MPN, such as explaining how a patient's health
information may be accessed, exchanged, or used by any person or other
entity, including whether the patient's health information may be
shared or sold at any time.\21\ As discussed, if an app has a written
privacy policy and the app or developer operates contrary to that
policy, the FTC has authority to act.
---------------------------------------------------------------------------
\19\ CARIN. The CARIN Alliance Code of Conduct (May 2020).
Retrieved from <a href="https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/">https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/</a>.
\20\ Office of the National Coordinator. Model Privacy Notice
(MPN). Retrieved from <a href="https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn">https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn</a>.
\21\ Office of the National Coordinator. Model Privacy Notice
(MPN). Retrieved from <a href="https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn">https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn</a>.
---------------------------------------------------------------------------
We request comments on how we can help give patients the tools they
need to understand the privacy and security implications of using a
health app within the scope of our regulatory authority. We seek ideas
on how we can balance our desire to both educate patients and respect
their rights under the HIPAA Privacy Rule. For example, should there be
a process at the time a developer registers an app with a payer for
access to the API to submit information about its privacy policy?
Should payers be required to provide that information in an easy-to-
understand format the first time a patient requests access via an app?
We encourage comments about how we can leverage the MPN (most recent
version from 2018). While we cannot require health app developers to
utilize the MPN, should payers notify patients, the first time the
patients request data through an app, whether the app utilizes the MPN
or not? To encourage visibility for apps that use the MPN versus those
that do not, should payers be required to list apps that have
established access to their API on their websites that comply with the
MPN's transparency requirements? We note that payers would have to
treat apps identically based on the substance of their privacy policies
and could not favor certain apps over others, such as for competitive
advantage. Again, we (and payers) cannot prohibit patients from using
health apps that do not comply with best privacy and security practices
unless it presents an unacceptable security risk to the payer's
systems.
We also request comment on whether we can leverage and build on
other HHS health information exchange initiatives, such as TEFCA, to
address these issues. For more background on TEFCA, see the related
Request for Information in section III.E. of this proposed rule. The
Common Agreement and Framework Agreement include privacy and security
requirements for Qualified Health Information Networks (QHINs),
Participants, and Subparticipants that elect to exchange information
pursuant to it, including entities not covered by the HIPAA Rules.\22\
Within the Common Agreement, any QHIN, Participant, or Subparticipant
that offers Individual Access Services (IAS) \23\ by which an
individual can access, inspect, or obtain a copy of that individual's
information is an IAS Provider. If a health app developer becomes a
signatory to a Framework Agreement and offers IAS Services, that
developer would be an IAS Provider. That developer would be providing
services utilizing the TEFCA Connectivity Services to an Individual
with whom the QHIN, Participant, or Subparticipant has a Direct
Relationship to satisfy that Individual's ability to access, inspect,
or obtain a copy of that Individual's Required Information that is then
maintained by or for any QHIN, Participant, or Subparticipant.
---------------------------------------------------------------------------
\22\ For the Common Agreement definitions of the terms used in
this section (QHIN, Participant, Subparticipant, IAS Provider,
Framework Agreement, Connectivity Services, Individual, Required
Information, Direct Relationship, Use, Disclosure), see page 3-14
in, Office of the National Coordinator (January 2022). Common
Agreement for Nationwide Health Information Interoperability Version
1. Retrieved from <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf">https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf</a>.
\23\ The Common Agreement defines Individual Access Services
(IAS) as follows: ``with respect to the Exchange Purposes
definition, the services provided utilizing the Connectivity
Services, to the extent consistent with Applicable Law, to an
Individual with whom the QHIN, Participant, or Subparticipant has a
Direct Relationship to satisfy that Individual's ability to access,
inspect, or obtain a copy of that Individual's Required Information
that is then maintained by or for any QHIN, Participant, or
Subparticipant.'' See page 7 in, Office of the National Coordinator
(January 2022). Common Agreement for Nationwide Health Information
Interoperability Version 1. Retrieved from <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf">https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf</a>.
---------------------------------------------------------------------------
IAS Providers must, among other requirements, have a written
privacy and security notice; obtain express written consent from
individuals regarding the way their information will be accessed,
exchanged, used (as defined in the Common Agreement), or disclosed (as
defined in the Common Agreement), including the sale of their health
information; provide individuals with the right to delete their
individually identifiable information as well as the right to revoke
their consent, with certain exceptions, in addition to a disclosure of
any applicable fees or costs related to IAS; and provide individuals
with the right to obtain an export of their individually identifiable
information in a computable format.\24\ Additionally, IAS Providers are
required to protect all individually identifiable information
(including health information) they hold in accordance with security
requirements specified in the Common Agreement and applicable Standard
Operating Procedures, such as the draft IAS Provider Privacy and
[[Page 76249]]
Security Notice and Practices Standard Operating Procedure (SOP) \25\
and the IAS Exchange Purpose Implementation SOP.<SUP>26 27</SUP>
---------------------------------------------------------------------------
\24\ See pages 33-38 in, Office of the National Coordinator
(January 2022). Common Agreement for Nationwide Health Information
Interoperability Version 1. Retrieved from <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf">https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf</a>.
\25\ The Sequoia Project (2022, June 21). Standard Operating
Procedure (SOP): Individual Access Service (IAS) Provider Privacy
and Security Notice and Practices. DRAFT FOR PUBLIC FEEDBACK.
Retrieved from <a href="https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf</a>.
\26\ The Sequoia Project (2022). Standard Operating Procedure
(SOP): Individual Access Services (IAS) Exchange Purpose
Implementation. Retrieved from <a href="https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP_IAS_Exchange_Purpose_Implementation.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP_IAS_Exchange_Purpose_Implementation.pdf</a>.
\27\ See pages 35-37 in, Office of the National Coordinator
(January 2022). Common Agreement for Nationwide Health Information
Interoperability Version 1. Retrieved from <a href="https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf">https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf</a>.
---------------------------------------------------------------------------
Given the Common Agreement's privacy and security requirements, and
particularly those that will apply when patients access their health
information through a participating IAS Provider, we request comment on
whether CMS should explore requirements or ways to encourage exchange
under TEFCA as a way to ensure that more patients are informed about
the privacy and security implications of using health apps to access
their health information, consistent with the requirements for IAS
Providers described previously. For instance, how could CMS encourage
health apps that are not subject to the HIPAA Rules to connect to
entities that exchange information under TEFCA? If so, what should be
the contours of, and levers for, such encouragement? What other
approaches can CMS take to encourage app developers to enable exchange
under TEFCA and therefore leverage the Common Agreement's privacy and
security requirements?
In addition, we request comments on the availability of apps that
are accessible to individuals with disabilities, availability of apps
in a multitude of languages to ensure that individuals with limited
English proficiency can understand the information provided, and
availability of apps at an appropriate literacy level and in plain
language. We note that the draft IAS Provider Privacy and Security
Notice and Practices SOP includes guidance regarding plain language and
literacy requirements.\28\ We believe apps with these features are
important to ensure that all patients can benefit from the proposals in
this rule. We request comment on any actions that we can take to ensure
patients' equitable access to their health information.
---------------------------------------------------------------------------
\28\ See pages 5-6 in, The Sequoia Project (2022, June 21).
Standard Operating Procedure (SOP): Individual Access Service (IAS)
Provider Privacy and Security Notice and Practices. DRAFT FOR PUBLIC
FEEDBACK. Retrieved from <a href="https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf">https://rce.sequoiaproject.org/wp-content/uploads/2022/06/SOP-IAS-Privacy-and-Security-Notice-1.pdf</a>.
---------------------------------------------------------------------------
d. Patient Access API Metrics
We are proposing to require impacted payers to report metrics in
the form of aggregated, de-identified data to CMS on an annual basis
about how patients use the Patient Access API. This reporting would
help CMS better understand whether the Patient Access API requirement
is efficiently and effectively ensuring that patients have access to
their health information and whether payers are providing that required
information in a transparent and timely way. Aggregated usage data from
every impacted payer would help us evaluate whether the Patient Access
API policies are achieving the desired goals. Gathering this
information would also help us to provide targeted support or guidance
to impacted payers, if needed, to help ensure that patients have access
to their data and can use their data consistently across the impacted
payer types. We propose to require MA organizations to report these
data to CMS at the organization level, state Medicaid and CHIP FFS
programs to report at the state level, Medicaid managed care plans to
report at the state level, CHIP managed care entities to report at the
state level, and QHP issuers on the FFEs to report at the issuer level.
We are considering, and therefore seek comment on, whether we should
require payers that administer multiple plans under a single contract
to report these data to CMS at the contract level. We also seek comment
on the benefits or drawbacks of an alternative final policy that would
permit MA organizations, entities offering Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs to report
aggregate data for the same plan type at higher levels (such as the
parent organization level or all plans of the same type in a program).
We note that in the December 2020 CMS Interoperability proposed rule
(85 FR 82594), we proposed that these data be reported quarterly, and
received comments from a broad variety of stakeholders strongly in
favor of annual reporting. Based on that feedback, we are now proposing
annual reporting.
Specifically, we propose that these payers annually report:
<bullet> The total number of unique patients whose data are
transferred via the Patient Access API to a health app designated by
the patient; and
<bullet> The total number of unique patients whose data are
transferred more than once via the Patient Access API to a health app
designated by the patient.
Tracking multiple data transfers would indicate repeat access,
showing that patients are either using multiple apps or are allowing
apps to update their information over the course of the year. While we
are not certain whether such data transfers would indicate to what
extent patients are using the apps to manage their healthcare, it would
be a preliminary indicator of interest in the technology to access
their data.
We are proposing that payers must report data from the previous
calendar year to CMS by March 31 of each year. The first year the
requirement would be applicable, payers would report calendar year 2025
data by March 31, 2026. A new MA organization, Medicaid managed care
plan, CHIP managed care entity, or QHP issuer on the FFEs would
naturally have no data to report in its first year of existence and
would be required to report data following its first full calendar year
subject to the Patient Access API requirement.
In summary, we propose that beginning in 2026, MA organizations at
the organization level, state Medicaid and CHIP FFS programs at the
state level, Medicaid managed care plans at the state level, CHIP
managed care entities at the state level, and QHP issuers on the FFEs
at the issuer level must annually report the following metrics to CMS
in the form of aggregated, de-identified data: (1) the total number of
unique patients whose data are transferred via the Patient Access API
to a health app designated by the patient; and (2) the total number of
unique patients whose data are transferred more than once via the
Patient Access API to a health app designated by the patient.
Collecting this information would facilitate CMS' oversight and
evaluation of the MA, Medicaid, and CHIP programs and of QHP issuers on
the FFEs. We propose that impacted payers report the previous calendar
year's metrics, in the form of aggregated, de-identified data, to CMS
by March 31 of each year. MA organizations, Medicaid managed care
plans, and CHIP managed care entities would report metrics to CMS
following any year that they operated, and QHP issuers would report
metrics to CMS following any year that they offered a QHP on the FFEs.
We are making this proposal at the CFR sections identified in Table 1.
If we finalize this proposal, we do not plan to publicly report
these metrics at the state, plan, or issuer level, but may reference or
publish aggregated and de-identified data that does not include names
of specific state agencies, plans, or issuers. We solicit comment on
this aspect of our proposal.
[[Page 76250]]
In addition, we request comment on what other Patient Access API
metrics we should consider requiring payers to report to CMS and/or
make available to the public on their own websites, for consideration
in possible future rulemaking. For instance, we are seeking comments on
whether payers could report aggregated demographic information, such as
sex, race, age, ethnicity, and geographical (for instance, by zip code)
data that they may already have to help identify disparities in patient
access to health data or underserved populations and, if so, what
policies should be considered to minimize those disparities. We are
also seeking comment on the potential benefits and burden of requiring
payers to report the names of all apps that patients have used to
access the payers' API each year. We are considering either collecting
this information, or requiring payers to make it public, not to
recommend or endorse specific apps, but to maintain a view of the apps
that patients use to access their health information, which could help
us review for best practices and to evaluate patient ease of use.
e. Patient Access API Amendments
To accommodate the proposed requirements regarding the use of the
Patient Access API, we are proposing two minor terminology changes to
the requirements finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25558, 25547). We note that unlike most of our
proposals, we are proposing that these amendments would go into effect
on the effective date of the final rule. We are proposing these changes
to clarify terms, but do not expect them to substantively change any
current regulatory obligation.
First, we are proposing to revise the description of the clinical
data to be made available via the Patient Access API by MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 1. These provisions currently
require payers to make available ``clinical data, including laboratory
results.'' We are proposing to revise these paragraphs to specify that
the data that payers must make available are ``all data classes and
data elements included in a content standard at 45 CFR 170.213.'' The
standard currently referenced at 45 CFR 170.213 is the USCDI version 1.
Laboratory Values/Results is a USCDI version 1 data element, and USCDI
version 1 includes data classes for other aspects of clinical
information such as Immunizations, Procedures, and Assessment and Plan
of Treatment. Referring explicitly to the data set in a standard at 45
CFR 170.213 in the rule text would help avoid unnecessary confusion, as
this reference would more clearly identify exactly what data must be
available through the Patient Access API.
In the future, as versions of the USCDI evolve, there may be
multiple versions of the standard referenced at 45 CFR 170.213 at one
time. For the ONC Health IT Certification Program, this allows for a
transition period between standards as health IT developers incorporate
updated standards versions within their systems and complete required
certification. Through this proposal, we are seeking to ensure that the
same flexibility would apply for payers as they transition between the
versions of the USCDI. During such a period, when 45 CFR 170.213
includes more than one version of the USCDI standard, payers would be
allowed to use any of the then-available standards at 45 CFR 170.213
for the data classes and elements that they make available through the
API.
Second, we are proposing to revise the language previously
finalized for denial or discontinuation of a health app's access to the
API. Currently, the rules require that the payer make a determination
to deny or discontinue access to the Patient Access API using
objective, verifiable criteria that are applied fairly and consistently
across all apps and developers through which ``enrollees'' or
``beneficiaries'' seek to access EHI. We are proposing to change the
terms ``enrollees'' and ``beneficiaries'' to ``parties'' for
consistency with our proposal to apply this provision to the Provider
Access API, Payer-to-Payer API, and the PARDD API discussed further in
sections II.B., II.C., and II.D. of this proposed rule. Because other
parties would be accessing these APIs, such as providers and payers, it
would be more accurate to use the term ``parties'' rather than
``enrollees'' or ``beneficiaries.''
In summary, we propose that we will replace ``clinical data,
including laboratory results'' with ``all data classes and data
elements included in a content standard at 45 CFR 170.213'' for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 1. We also propose that we will
change the terms ``enrollees'' and ``beneficiaries'' to ``parties'' for
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs at the CFR sections identified in Table 1.
We request comment on these proposals. We also direct readers to
section II.F. of this proposed rule for a discussion of proposed
changes to the interoperability standards for APIs that affect the
Patient Access API.
f. Specific CHIP-Related Regulatory Framework
Specifically, for CHIP, the proposed amendments to 42 CFR
457.1233(d) would align separate CHIP managed care API requirements
with the Medicaid managed care API requirements, rather than with the
CHIP FFS API requirements. In the CMS Interoperability and Patient
Access final rule (85 FR 25559), we finalized requirements for separate
CHIP managed care entities at 42 CFR 457.1233(d). API requirements for
CHIP managed care entities were codified at 42 CFR 457.1233(d)(2) and
(3) through cross-references to CHIP FFS program requirements at 42 CFR
457.730 and 457.760, respectively. On November 13, 2020, we published a
final rule titled ``Medicaid Program; Medicaid and Children's Health
Insurance Program (CHIP) Managed Care'' (85 FR 72754). In that rule, we
removed 42 CFR 457.1233(d)(1) through (3), and, at 42 CFR 457.1233(d),
cross-referenced to Medicaid managed care regulatory requirements at 42
CFR 438.242. Therefore, the policies in the CMS Interoperability and
Patient Access final rule (85 FR 25559) are applicable to separate CHIP
managed care entities per 42 CFR 457.1233(d) through a cross reference
to Medicaid managed care at 42 CFR 438.242. We propose to apply the API
requirements in this proposed rule to separate CHIP managed care
entities through the existing cross reference at 42 CFR 457.1233(d) to
Medicaid managed care at 42 CFR 438.242, and have noted this throughout
the proposals in this proposed rule.
Most states have Medicaid Expansion CHIP programs, in which a state
receives Federal funding to expand Medicaid eligibility to optional
targeted low-income children that meet the requirements of section 2103
of the Social Security Act (the Act). We are proposing at 42 CFR
457.700(c) that for states with Medicaid Expansion CHIP programs, the
proposals in this rule for Medicaid would apply to those programs
rather than our proposals for separate CHIP programs. Functionally, our
proposals are the same, however, for clarity, we are making explicit
that the Medicaid requirements at 42 CFR 431.60, 431.61, and 431.80
would apply to those programs rather than the
[[Page 76251]]
separate CHIP requirements at 42 CFR 457.730, 457.731, and 457.732.
BILLING CODE 4120-01-P
[GRAPHIC] [TIFF OMITTED] TP13DE22.000
BILLING CODE 4120-01-C
3. Statutory Authorities for the Patient Access API Proposals
a. MA Organizations
[[Page 76252]]
For MA organizations, we are proposing these new requirements and
the revisions to current requirements under our authority at sections
1856(b)(1) (to promulgate regulations implementing MA standards,
including the requirements in section 1852(h) of the Act), and
1857(e)(1) of the Act (to add contract terms determined by the
Secretary to be ``necessary and appropriate''). Section 1856(b)(1) of
the Act requires the Secretary to establish regulatory standards for MA
organizations that are consistent with and carry out Part C of the
Medicare statute, Title XVIII of the Act. Section 1852(h) of the Act
requires that MA organizations have procedures in place to maintain
accurate and timely medical records and health information regarding MA
enrollees and to assure enrollees have timely access to such records
and information. Our proposal for the Patient Access API is to require
access for enrollees to specified medical records and health
information through a specific mechanism from the MA organization. The
Secretary is authorized under section 1857(e)(1) of the Act to add new
contract terms, including additional standards and requirements, for MA
organizations that the Secretary finds necessary and appropriate and
that are not inconsistent with Part C of the Medicare statute. The
proposals here meet this standard by addressing and facilitating access
to enrollees' medical records and health information for the reasons
identified in our discussions for each proposal.
The proposal in section II.A.2.a. of this proposed rule that would
require MA organizations to make an enrollee's prior authorization
requests and related clinical documentation available through the
Patient Access API would, if finalized as proposed, allow these
enrollees to have access to that information in a convenient, timely,
secure, and portable way, which is in enrollees' best interests. This
proposed requirement is consistent with section 1852(h) of the Act,
which requires MA organizations to assure enrollees timely access to
their records and data that is maintained by MA organizations. To
ensure that MA organizations meet modern-day patient expectations of
transparency, efficiency, and timeliness when providing prior
authorization data to enrollees, it is essential for CMS to ensure that
each MA organization has a standardized system in place that offers
enrollees access to their own data, including data that pertain to
their prior authorizations, using existing and emerging technologies of
their choice, specifically in this case, health apps. Therefore, making
these data available through the Patient Access API is consistent with
our programmatic authority to establish standards to implement section
1852(h) of the Act, and could help patients be more informed about and
active in their own care, which could potentially lead to better health
outcomes.
Making this information available via the Patient Access API could
help enrollees support the prior authorization process, as well.
Enrollees could see what information is needed and what information has
been provided on their behalf to facilitate a prior authorization
request. Enrollees could provide missing information needed by the
payer to reach a decision. This could allow MA organizations to address
prior authorization requests more promptly, streamlining this process,
and thus simplifying prior authorization for the MA organizations. This
could also improve an enrollee's experience with the process, by
facilitating timelier and potentially more successful initial prior
authorization requests. This, again, supports efficient operation and
timely provision of information and services.
In addition, to ensure the requirements proposed here and finalized
in the CMS Interoperability and Patient Access final rule (85 FR 25558
through 25559) would be most effective, CMS proposes in this rule that
MA organizations report specific metrics to CMS on enrollee use of the
Patient Access API. Section 1857(e)(1) of the Act explicitly authorizes
the adoption of additional reporting to CMS by MA organizations where
necessary and appropriate. Here, these proposed metrics would
facilitate CMS's oversight, evaluation, and administration of patient
health data access in the Part C program and therefore, this data
collection is necessary and appropriate to adopt.
In alignment with HHS's priorities and goals, CMS is focused on
putting patients at the center of their own healthcare and ensuring
patients have secure access to their health information. We believe
these proposals are critical and appropriate to ensure that MA
organizations stay abreast of industry standards and continue to offer
enrollees not only quality coverage but also a quality customer
experience.
b. Medicaid and CHIP
Our proposed requirements in this section for Medicaid managed care
plans and Medicaid state agencies fall generally under our authority in
sections 1902(a)(4), 1902(a)(7), 1902(a)(8), and 1902(a)(19) of the
Act. Section 1902(a)(4) of the Act requires that a state Medicaid plan
provide such methods of administration as are found by the Secretary to
be necessary for the proper and efficient operation of the state
Medicaid plan. Section 1902(a)(8) of the Act requires states to ensure
that Medicaid services are furnished with reasonable promptness to all
eligible individuals. Section 1902(a)(19) of the Act requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
In addition, section 1902(a)(7) of the Act requires that states
must provide safeguards that restrict the use or disclosure of
information concerning Medicaid applicants and beneficiaries to uses or
disclosures of information that are directly connected with the
administration of the Medicaid state plan. The implementing regulations
for this section of the Act list purposes that CMS has determined are
directly connected to Medicaid state plan administration at 42 CFR
431.302 and provide safeguards states must apply to uses and
disclosures of beneficiary data at 42 CFR 431.306. CHIP programs are
subject to the same requirements through a cross reference at 42 CFR
457.1110(b). Our proposal to require that the data described in this
section be shared via the Patient Access API would be consistent with
the requirement that states may share these data only for purposes
directly connected to the administration of the Medicaid state plan,
since this data sharing would be related to providing services for
beneficiaries, a purpose listed in Sec. 431.302(c). As mentioned
previously, giving a patient access to their own health information can
make them a more active participant in ensuring they receive timely and
appropriate care (for example, allowing them to monitor medications or
access treatment history). Additionally, states must apply the
safeguards described at 42 CFR 431.306 when sharing beneficiary data
via the Patient Access API. We remind states that in order to meet the
requirements of that regulation, states must have consistent criteria
for release and use of information (which should comply with the
proposed Patient Access API requirements, if finalized), in accordance
with 42 CFR 431.306(a). Access to information concerning beneficiaries
must be restricted to persons who are subject to standards of
confidentiality that are comparable to that of the Medicaid agency, in
accordance with 42 CFR 431.306(b). The
[[Page 76253]]
permission requirement at Sec. 431.306(d), which requires that the
State agency obtain permission from a family or individual, whenever
possible, before responding to a request for information from an
outside source, is not relevant to this proposal, because any request
for beneficiary information would be from Medicaid beneficiaries
themselves and the apps that they are authorizing to receive their
information. Beneficiaries are not ``outside sources,'' and, while apps
might be outside sources, information is shared with an app through
this API only if the beneficiary has verified their identity (through
authentication protocols) and authorized the app to receive
information. We do not believe that any of the other requirements at
section 431.306 are relevant because they cover data release and use in
contexts outside of our proposals in this section. However, we welcome
comments from state Medicaid agencies and other members of the public
on this topic.
The proposed requirement to make information about prior
authorization requests and associated documentation available through
the Patient Access API is expected to allow beneficiaries to more
easily obtain information about the status of prior authorization
requests submitted on their behalf. Beneficiaries could potentially use
that information to make more informed decisions about their
healthcare, improve the efficiency of accessing and scheduling
services, and, if needed, provide missing information that the state
(or Medicaid managed care plan, if applicable) needs to reach a
decision. Receiving missing information more quickly could enable more
prompt responses from Medicaid FFS programs and managed care plans to
prior authorization requests, thus facilitating more timely and
successful prior authorizations, which would help states fulfill their
obligations to provide care and services in a manner consistent with
simplicity of administration and the best interests of the recipients,
and to furnish services with reasonable promptness to all eligible
individuals. Improving the prior authorization process could also help
improve the efficient operation of the state plan by potentially
improving the speed and consistency of prior authorizations, which
could, in turn, facilitate faster access to care for beneficiaries. In
these ways, these proposals are authorized under section 1902(a)(4),
(8), and (19) of the Act.
In addition, this proposal would help implement section 1932(b)(4)
of the Act, which provides that each Medicaid managed care organization
must establish an internal grievance procedure under which a
beneficiary who is eligible for medical assistance may challenge the
denial of coverage or payment for such assistance. CMS has
traditionally extended requirements applicable to Medicaid managed care
organizations to other Medicaid managed care plan types as efficient
and proper methods of administration under section 1902(a)(4) of the
Act to ensure that Medicaid beneficiaries have the same protections,
benefits, and responsibilities regardless of the type of managed care
plan in which they are enrolled. Allowing beneficiaries to access the
status of their denied prior authorizations within 1 business day could
enable beneficiaries to file appeals timelier and receive faster
resolution. Enabling beneficiaries to monitor the status of prior
authorization requests submitted on their behalf is also consistent
with how section 1932(c)(2)(A) of the Act indicates that timely access
to care should be assured for beneficiaries. Knowing within 1 business
day that a prior authorization has been approved could enable a
beneficiary to more promptly schedule or obtain care.
We are also proposing to require state Medicaid agencies and
Medicaid managed care plans to report Patient Access API metrics to CMS
annually. We believe that having these metrics would support CMS'
oversight, evaluation, and administration of the Medicaid program, as
it would allow us to evaluate beneficiary access to the Patient Access
API. Use of the API could indicate that the policy is supporting
program efficiencies and ensuring access to information in a timely and
efficient way and in the best interest of beneficiaries, as intended,
and as is consistent with section 1902(a)(4) and (19) of the Act.
Additionally, section 1902(a)(6) of the Act requires Medicaid state
plans to provide that the state Medicaid agency will make such reports,
in such form and containing such information, as the Secretary may from
time to time require. These metrics would serve as a report to evaluate
the implementation and execution of the Patient Access API.
For CHIP, we propose these requirements under the authority in
section 2101(a) of the Act, which states that the purpose of Title XXI
of the Act is to provide funds to states to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage. This provision provides us with authority to adopt
these requirements for CHIP because the proposed requirements increase
patient access to their health information, which can improve the
efficacy of CHIP programs, allow for more efficient communication and
administration of services, and promote coordination across different
sources of health benefits coverage.
We believe that requiring CHIP agencies, as well CHIP managed care
entities, to make CHIP beneficiaries' prior authorization data and
other standardized data available through standards-based APIs would
ultimately lead to these beneficiaries accessing that information in a
convenient, timely, and portable way. This improved access would help
to ensure that services are effectively and efficiently administered in
the best interests of beneficiaries, consistent with the requirements
in section 2101(a) of the Act. We believe making patient data available
in this format would result in better health outcomes and patient
satisfaction and improve the cost effectiveness of the entire
healthcare system, including CHIP.
These proposals align with section 2101(a) of the Act in that they
also would improve the efficiency of CHIP programs. For example, adding
information about prior authorization requests to the Patient Access
API would allow beneficiaries to easily obtain the status of prior
authorization requests made on their behalf. This would in turn allow
patients to make scheduling decisions, and provide any missing
information needed by a payer to reach a decision, which makes the
prior authorization process more efficient, ultimately streamlining the
prior authorization process.
Additionally, the safeguards for applicant and beneficiary
information at subpart F of 42 CFR part 431 are also applicable to CHIP
through a cross-reference at 42 CFR 457.1110(b). As discussed above for
Medicaid, giving CHIP beneficiaries access to their prior authorization
statuses through the Patient Access API would be related to providing
services to beneficiaries, which is described at 42 CFR 431.302(c) as a
purpose directly related to state plan administration. Allowing
beneficiary access to prior authorization statuses also conforms with
provisions for beneficiary access to their records at 42 CFR
457.1110(e). We remind states that when they share beneficiary
information through the Patient Access API, they must comply with the
privacy protections at 42 CFR 457.1110 and the release of information
provisions at 42 CFR 431.306.
Finally, proposing to require state CHIP agencies and CHIP managed
care entities to report Patient Access API
[[Page 76254]]
metrics to CMS annually would help states and CMS understand how this
API can be used to continuously improve the effectiveness and
efficiency of state CHIP operations by providing information about its
use, which is an indication of the API's uptake among patients,
including how many only use it for a one-time setup consistent with
2107(b)(1) of the Act. The more we understand about the use of the
Patient Access API, the better we can assess that the API is leading to
improved operational efficiencies and providing information to
beneficiaries in a way that supports their best interests.
c. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we propose these new requirements
under our authority in section 1311(e)(1)(B) of the Affordable Care
Act, which affords the Exchanges the discretion to certify QHPs if the
Exchange determines that making available such health plans through the
Exchange is in the interests of qualified individuals in the state in
which the Exchange operates.
We believe generally that certifying only health plans that take
steps to make enrollees' prior authorization requests and related
clinical documentation available through interoperable technology would
ultimately lead to these enrollees having access to that information in
a convenient, timely, and portable way, which is in enrollees' best
interests. Having simple and easy access, without special effort, to
their health information also would facilitate enrollees' ability to
detect and report fraud, waste, and abuse--a critical component of an
effective program. Adding information about prior authorization
requests to the Patient Access API would allow enrollees to easily
obtain the status of prior authorization requests submitted on their
behalf and use that information effectively to make more informed
decisions about their healthcare, improve the efficiency of accessing
and scheduling services, and, if needed, provide missing information
needed by the issuer to reach a decision. This could allow QHP issuers
on the FFEs to more promptly address prior authorization requests. This
would also facilitate timelier and potentially more successful initial
prior authorization requests. We encourage SBEs (including SBE-FPs) to
consider whether a similar requirement should be applicable to QHP
issuers on SBEs.
Finally, proposing to require QHP issuers on the FFEs to report
Patient Access API metrics to CMS annually would help CMS assess the
effect this API is having on enrollees and would inform how CMS could
either enhance the policy or improve access or use through activities
such as additional patient education. These data could help CMS
understand how best to leverage this API, and patient access to it, to
ensure this requirement is being met efficiently and adding value to
CMS operations, including leading to the efficiencies intended.
B. Provider Access API
1. Background
In the CMS Interoperability and Patient Access final rule, we
implemented policies regarding the Patient Access API (85 FR 25558)
that would allow patients to access their health information through an
app. Patients who do so could then share their information with their
provider during an appointment. For example, during a visit with a
provider, a patient could share specific diagnoses, procedures, and
tests accessed through the Patient Access API and stored on their
mobile smart device, which could help inform a discussion with their
provider about their health status.
We also discussed the potential benefits of payers sharing patient
health information directly with providers in that final rule (85 FR
25555) and encouraged payers to consider an API solution that would
enable providers to access appropriate health information through the
payers' APIs to support the delivery of care. We sought comment on the
feasibility of implementing and maintaining a FHIR API for data
exchange between payers and providers and received comments strongly
supporting our concept to require data availability through a Provider
Access API. Some commenters stated that allowing providers to receive
data, including prior authorization information, directly from payers
would make FHIR-based data exchange significantly more valuable for
patients, providers, and payers. More data could be available to help
providers manage an individual's total care and providers could reduce
or eliminate duplicate tests, which might avoid diagnostic errors.
Payers might also see fewer duplicate requests for services, fewer
appeals and, possibly, lower costs. We specifically agreed with
commenters that making information about prior authorization decisions
available via an API would reduce burden on providers and their staff
(85 FR 25541).
While using the Patient Access API is a significant first step
toward sharing individual patient health information with providers, it
would also be beneficial for payers to make patient data directly
available to providers via a FHIR API. In the normal course of
business, many providers already maintain EHRs and share data for a
variety of purposes authorized by the patient and/or existing law.
Therefore, in this rule we propose to require that impacted payers
implement and maintain a FHIR API that makes patient data available to
providers who have a contractual relationship with the payer and a
treatment relationship with the patient. The proposed Provider Access
API has the potential to allow payers to build upon their existing
systems and processes to enhance access to patient data, while
continuing to protect patient privacy and data security.
In the December 2020 CMS Interoperability proposed rule, we
proposed to require payers to build a Provider Access API. As discussed
in section I.A. of this proposed rule, we are withdrawing the December
2020 CMS Interoperability proposed rule and issuing this new proposed
rule that incorporates the feedback we received from stakeholders on
that proposed rule. We understand that many readers may already be
familiar with that proposed rule. To distinguish between that proposed
rule and our proposals herein, we refer readers to section I.A. of this
proposed rule, which outlines the overarching differences between the
two proposed rules.
We are again proposing to require impacted payers to implement and
maintain a FHIR API to exchange data with providers, but with changes
from the December 2020 CMS Interoperability proposed rule. We are again
proposing a FHIR API, but we are now taking a different approach to the
standards required for the API, as further described in section II.F.
of this proposed rule. We are also proposing a patient opt out (rather
than an opt in) policy that would require payers to allow patients to
opt out of the Provider Access API proposed herein. Finally, we propose
to establish the Provider Access API compliance date as January 1,
2026.
As mentioned in section I.A. of this proposed rule, these proposals
do not pertain to Medicare FFS. We seek comment on how each of our
proposals discussed below on Provider Access API could be implemented
for the Medicare FFS program. We expect that a Medicare FFS
implementation would conform to the same proposed requirements that
apply to the impacted payers under this proposed rule, as applicable,
so Medicare FFS providers and patients enrolled in Medicare FFS could
also benefit from this type of data sharing. We seek comment on whether
this
[[Page 76255]]
could be implemented as proposed for the Medicare FFS program, how we
could apply each of these proposals below, and if there would be any
differences for implementing the Provider Access API in the Medicare
FFS program as a Federal payer. As noted later in this section of this
proposed rule, CMS's Data at the Point of Care (DPC) project is
currently piloting an API that makes Medicare FFS claims and Part D
data available to certain providers. We note that because Medicare FFS
provider remittances and enrollee cost-sharing information are not
proprietary, those data are shared in the DPC pilot; however, as
discussed in this section, impacted payers would not be required to
share that information under our proposals. The information gained from
the DPC pilot will be useful to implementers should the proposals in
this proposed rule be finalized.
2. Proposed Requirements for Payers: Provider Access API for Individual
Patient Information
In the CMS Interoperability and Patient Access final rule (85 FR
25558), we required impacted payers to make certain health information
available to health apps when requested by a patient, through a Patient
Access API. We believe it would be valuable for providers to have
access to the same patient data, except for provider remittances and
enrollee cost-sharing information, through a FHIR API that allows a
provider to request data for an individual patient, as needed, thereby
providing further insight into the patient's care activity. Research
shows that patients achieve better outcomes when their record is more
complete and there are more data available to the healthcare provider
at the point of care.\29\ Making more comprehensive information
available to providers could thus improve the care experience for
patients. Ensuring that providers have access to relevant patient data
at the point of care could also reduce the burden on patients to recall
and relay information during an appointment and/or provide confirmation
that the patient's recollection of prior care is accurate.
---------------------------------------------------------------------------
\29\ Office of the National Coordinator for Health Information
Technology (2019, June 4). Improved Diagnostics & Patient Outcomes.
Retrieved from <a href="https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes">https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes</a>.
---------------------------------------------------------------------------
Therefore, we are proposing to require that impacted payers
implement and maintain a Provider Access API to enable current
patients' information to be exchanged from payers to providers that are
in that payer's network, at the provider's request. A provider in the
payer's network, for purposes of this proposal, would be any provider
or healthcare facility that is part of a specific health plan's network
of providers with which it has a contract. In the case of Medicaid and
CHIP FFS programs, it would be any providers or healthcare facilities
that are enrolled with the state as Medicaid or CHIP providers. We note
that this requirement would only apply to current patients. Once a
patient is no longer enrolled with a payer, the payer would not need to
share data with providers under this proposal. However, see section
II.C. for the proposed Payer-to-Payer API requirements for transferring
a patient's data from a previous payer to a new payer.
The proposed Provider Access API would allow a provider to initiate
a request, for example, when the provider needs access to a patient's
data prior to or during a patient visit. Both this proposed Provider
Access API and the Patient Access API would facilitate the FHIR-based
exchange of claims and encounter data, as well as all data classes and
data elements included in a content standard adopted at 45 CFR 170.213,
such as Immunizations, Procedures, and Assessment and Plan of
Treatment, should the payer maintain such information. Both the Patient
Access and Provider Access APIs would require payers to share
information related to prior authorization requests and decisions
(including related administrative and clinical documentation) for items
and services (excluding drugs). As discussed in section II.A.2.a of
this proposed rule, we are proposing to require that information about
prior authorizations (and related administrative and clinical
documentation) be available via the Patient Access API for as long as
the authorization is active, and at least 1 year after the last status
change. We note that we are formulating our proposal for at least 1
year after any status change, but this provision would be particularly
relevant to denied and expired prior authorizations, to ensure that
they would be available for at least a year after expiring or being
denied. We do not propose to require payers to share a patient's full
prior authorization history, because that could comprise a significant
amount of information that may no longer be clinically relevant.
We believe that sharing claims and encounter information, without
provider remittances and enrollee cost-sharing information, would
complement the clinical data classes and data elements included in a
content standard at 45 CFR 170.213 by providing more information to
support treatment and care coordination. Claims and encounter data used
in conjunction with clinical data can offer a broader, more complete
picture of an individual's interactions with all their providers in the
healthcare system. With this proposal, we intend to help providers gain
efficient access to more comprehensive data on their patients. Thus, we
are proposing to require that impacted payers make available any of the
applicable patient data with a date of service on or after January 1,
2016. This proposed timeframe for data to be included is consistent
with the requirements of the Patient Access API, as finalized in the
CMS Interoperability and Patient Access final rule (85 FR 25567), so
payers should already be maintaining and making available data from
this timeframe via a FHIR API.
Such disclosures from payers to healthcare providers would be
permitted under the HIPAA Privacy Rule as disclosures for treatment
purposes,\30\ as well as disclosures required by law,\31\ which this
proposed rule would be establishing if finalized. Additionally,
Medicaid and CHIP agency disclosures of beneficiary data to in-network
providers under this proposal would be consistent with section
1902(a)(7) of the Act and implementing regulations at 42 CFR part 431,
subpart F, and 42 CFR 457.1110(b). Under these provisions, states must
restrict the use or disclosure of information concerning applicants and
beneficiaries to purposes directly connected with the administration of
the plan. The disclosures of patient data through the Provider Access
API would be directly related to the administration of the state plan
because they would support the provision of services for beneficiaries,
as described in 42 CFR 431.302(c). As mentioned, a provider could
better manage a patient's total care when they have access to more of
that patient's data because the data would provide a more in-depth
medical history, enable more informed decision making, and potentially
prevent the provision or ordering of duplicative services.
Additionally, states must apply the safeguards described in 42 CFR
431.306 when sharing beneficiary data via the Provider Access API. We
remind states that in order to meet the requirements of that
regulation, they must have consistent criteria for release and use of
information (which should comply with the proposed Provider Access API
requirements, if finalized), in accordance with 42 CFR 431.306(a).
Access to information concerning
[[Page 76256]]
beneficiaries must be restricted to persons or agency representatives
who are subject to standards of confidentiality that are comparable to
that of the Medicaid agency, in accordance with 42 CFR 431.306(b). The
permission requirement in Sec. 431.306(d), which requires that the
State agency obtain permission from a family or individual, whenever
possible, before responding to a request for information from an
outside source, is not relevant to this proposal, because any request
for beneficiary information would be from an enrolled Medicaid or CHIP
provider and thus would not be from an ``outside source.'' A Medicaid
or CHIP provider would have a provider agreement with the Medicaid or
CHIP agency in order to provide Medicaid or CHIP benefits and services
under its state plan. As such, Medicaid and CHIP providers are part of
the state's Medicaid and CHIP program assisting the state agency in
carrying out core functions of the state's Medicaid or CHIP State Plan,
providing benefits and services to beneficiaries. Therefore, no
additional consent from the beneficiary or personal representative
would need to be obtained by the Medicaid or CHIP agency prior to
sharing the individual's information with a Medicaid or CHIP provider.
We note that while patient permission is not required under Sec.
431.306(d) for the proposals we discuss here, state, or other laws may
require such permission. We do not believe that any of the other
requirements of 42 CFR 431.306 are relevant because they cover data
release and use in contexts outside of our proposals in this section.
However, we welcome comments from state Medicaid agencies and other
members of the public on this topic.
---------------------------------------------------------------------------
\30\ See 45 CFR 164.506(c)(2).
\31\ See 45 CFR 164.512(a).
---------------------------------------------------------------------------
There are a few notable differences between the requirements for a
Patient Access API and our proposals for a Provider Access API. The
biggest difference is how and why the end user would access the data.
For the Patient Access API, the patient is requesting access to their
own data through a health app for their own reference and use. For the
Provider Access API proposals, the provider would request and receive
access to the patient's information through their EHR, practice
management system, or other technology solution for treatment purposes,
including care coordination. Providers would securely access their
patients' data using at least one of these systems through a FHIR API.
Providers would not access patient data through their own health app;
rather, the data would flow from the payer to the provider's EHR or
practice management system, which would allow them to incorporate the
patient data into their records. For example, a provider who is
preparing for an upcoming appointment may need more information about
the patient than is contained in the patient's record. Under this
proposal, the provider would be able to request the additional data
from the patient's payer, provided the patient has not opted out (as
explained in section II.B.3.b. of this proposed rule). The payer would
then be required to share the requested data no later than 1 business
day after the provider initiates this request.
Finally, unlike the Patient Access API, we propose that the
Provider Access API would not include provider remittances and enrollee
cost-sharing information. Many payers consider cost-sharing information
proprietary, and we believe that information would have limited benefit
for treatment or care coordination. We note that our proposals in
section II.C. of this proposed rule would exclude provider remittances
and enrollee cost-sharing information from the payer to payer data
exchange, and we propose the same for the Provider Access API.
In the CMS Interoperability and Patient Access final rule CMS
required standards for the Patient Access API by cross reference to 45
CFR 170.215 (85 FR 25558). In this proposed rule, we are proposing to
amend these cross references, as discussed in section II.F. We also
propose, at the CFR citations listed in Table 2, that the Provider
Access API would require adherence to the same technical standards, API
documentation requirements, and standards for denial or discontinuation
of access to the API. Additionally, we note that unlike for the Patient
Access API, we are proposing to require the FHIR Bulk Data Access
Implementation Guide at 45 CFR 170.215(a)(4). For a complete discussion
of these requirements, we refer readers to the CMS Interoperability and
Patient Access final rule (85 FR 25526) and to section II.F. of this
proposed rule.
We acknowledge that it could be helpful for all providers to have
access to their patients' data regardless of contractual or enrollment
relationships with a patient's payer. However, if a provider does not
have a provider agreement or is not enrolled (in the case of Medicaid
and CHIP FFS programs) with a payer that holds their patient's data,
the payer would not be required to provide patient data to that
provider under this proposal, though it may be permissible or even
required by other law or regulation. We recognize that this could make
it more difficult for an out-of-network provider to create a
comprehensive care record for a patient. We considered requiring payers
to share the data with all providers, regardless of whether the
provider is under contract or enrolled with the payer. However, for
reasons we explain in this section of this proposed rule, we are not
proposing to do so, and are instead seeking comment on various issues
surrounding that possible requirement. Though we are not proposing to
require it at this time, we encourage payers to share information via
API with out-of-network or unenrolled providers who have a verified
treatment relationship with the patient, to the extent permitted by
law.
There could be privacy, security, and program integrity concerns
with requiring payers to share patient information with out-of-network
providers. For example, because MA organizations, Medicaid FFS
programs, CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities must ensure they do not enroll or contract with
providers that are on the HHS Office of the Inspector General List of
Excluded Individuals/Entities (LEIE), limiting data sharing through the
Provider Access API to in-network or enrolled providers can help ensure
these data are not shared with providers who have already been
determined by the Federal Government to present fraud or other program
integrity risks. Since these risks exist, if we were to require payers
to share patient information with out-of-network providers, we would
also have to require payers to establish safeguards to ensure that an
out-of-network provider would be a trustworthy recipient of patient
information. This could create significant burden for payers who may
need to expend resources towards vetting providers with whom they do
not have an existing relationship.
The LEIE does not apply to QHPs, but in order to offer coverage
through the FFEs, they must comply with certification rules per 45 CFR
part 156, which includes requirements to prevent QHP issuers from
contracting with providers known to submit fraudulent or wasteful
claims. For example, Sec. 156.810(a)(7) specifies that a QHP issuer
may be decertified if, based on credible evidence, they have committed
or participated in fraudulent or abusive activities, including
submission of false or fraudulent data. Section 156.340 provides that a
QHP issuer is responsible for its own compliance and the compliance of
any of its delegated or downstream entities with all applicable Federal
standards related to Exchanges. Per Sec. 156.20, ``delegated entity''
means any party that enters into an agreement with a QHP issuer to
[[Page 76257]]
provide administrative services or health care services (for example,
contracted providers). Section 156.20 also defines a ``downstream
entity'' as any party that enters into an agreement with a delegated
entity or with another downstream entity to provide administrative
services or health care services (for example, subcontracted
providers). Thus, in order to maintain certified status, QHP issuers
generally must have processes in place to avoid contracting with
providers that engage in fraudulent practices. QHP issuers that also
provide out-of-network coverage can make the determination of whether
or not to share data with out-of-network providers using their existing
processes.
As we consider imposing a requirement to share patient data with
out-of-network providers through future rulemaking, we request comment
on how payers do so today, the effectiveness of current processes to
validate the treatment relationships between patients and providers
when a contractual relationship does not exist between the provider and
the payer, and what additional program integrity safeguards might be
appropriate when other contractual mechanisms are not in place to
ensure that patient data are provided only to qualified, trustworthy
providers. We are particularly interested in the following questions:
How would out-of-network providers request access to their patients'
data and demonstrate that the provider has a treatment relationship
with the patient? What processes and verification requirements would we
need to require each payer to establish to verify the patient-provider
treatment relationship? Should payers consider certain provisions in
data use or data exchange agreements? If so, what could those
provisions address? What are current best practices for terms of
service? What other operational best practices for enabling safe data
exchange with out-of-network providers should CMS consider in
determining whether to propose a policy requiring this?
We emphasize that all data shared and received via this proposed
data exchange would still have to be handled in a way that is
consistent with all current and applicable laws and regulations, and
our proposals are not intended to modify those other laws. Payers and
healthcare providers that are covered entities under HIPAA are subject
to the HIPAA Rules. Adherence to the HIPAA Rules would ensure that the
provider disclosing patient data through the Provider Access API has
appropriate security protocols in place.\32\ These include, but are not
limited to, administrative and technical safeguards such as access
authorization and audit controls.\33\ Regardless of whether a provider
meets the definition of a covered entity under the HIPAA Rules at 45
CFR 160.103,\34\ there may also be state laws that require certain
privacy and security protections for health information exchange.
Additionally, other laws, such as the regulations that focus on
confidentiality of patient records associated with substance use
disorder at 42 CFR part 2 or state privacy laws, may require the payer
to obtain the enrolled individual's permission to disclose certain PHI.
We request comment on any other considerations regarding state privacy
or other laws that may be implicated by our proposals.
---------------------------------------------------------------------------
\32\ See 45 CFR part 164, subparts A and C.
\33\ Department of Health and Human Services (2022). Security
Rule Guidance Material. Retrieved from <a href="https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es">https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es</a>.
\34\ Under the HIPAA Rules at 45 CFR 160.103, a ``covered
entity'' includes a health care provider who transmits any health
information in electronic form in connection with a transaction
covered by the subchapter; see also definitions of health care
provider and transaction at <a href="https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103</a>.
---------------------------------------------------------------------------
We are proposing to require, at the CFR citations identified in
Table 2, that impacted payers share certain patient information with
in-network and enrolled providers who have a treatment relationship
with the payers' patients upon request by the provider. Thus, payers
would be required by regulation to make such disclosures if there is a
treatment relationship with the individual. The HIPAA Privacy Rule
permits a covered entity, such as a health plan, to disclose PHI of the
enrolled individual to a health care provider without individual
authorization for treatment purposes under 45 CFR 164.506(c)(2) or as
required by law per 45 CFR 164.512(a)(1).
Our proposal would not alter any obligation for HIPAA-covered
entities to follow the HIPAA Rules or other applicable law, including,
but not limited to, standards regarding the use and disclosure of PHI,
administrative, physical, and technical safeguards and other security
provisions, and breach notification. The security framework of the
proposed API, as required via reference to standards at 45 CFR 170.215,
would allow payers to verify the requesting provider's identity by
using the required authorization and authentication protocols.
Authorization refers to the process by which the payer would give the
provider permission to access data. The authentication protocols are
those that would allow the payer to ensure that the provider that is
requesting this access is who they say they are. In addition to using
these required protocols, the payer would be required to share the
specified data only if it can also attribute the patient to the
provider using an attribution process, as discussed in this section of
this proposed rule in detail. While FHIR itself does not define
security-related functions, used in combination with appropriate
security controls (such as authentication and access control), a FHIR
API can and should be implemented in compliance with the HIPAA Security
Rule for secure data exchange.\35\
---------------------------------------------------------------------------
\35\ Health Level Seven International (2022). FHIR Security.
Retrieved from <a href="http://www.hl7.org/Fhir/security.html">http://www.hl7.org/Fhir/security.html</a>.
---------------------------------------------------------------------------
HIPAA also requires the Secretary to adopt standards for specific
transactions and establish a process for updating those standards. A
HIPAA transaction is an electronic transmission of information from a
covered entity to carry out financial or administrative activities
related to health care (for example, when a health care provider sends
a claim to a health plan to request payment for medical services) for
which the Secretary has adopted a standard. Under HIPAA, HHS is
required to adopt standards for electronically transmitting certain
health care information, including:
<bullet> Health care claims or equivalent encounter information;
<bullet> Health care electronic funds transfers and remittance
advice;
<bullet> Health care claim status;
<bullet> Eligibility for a health plan;
<bullet> Enrollment and disenrollment in a health plan;
<bullet> Referrals certification and authorization;
<bullet> Coordination of benefits;
<bullet> Health plan premium payments; and
<bullet> Medicaid pharmacy subrogation (not mandated under HIPAA,
but, consistent with section 1173(a)(1)(B) of the Social Security Act,
a standard has been adopted for this purpose).
The Secretary has adopted a HIPAA transaction standard for
transmitting claims or equivalent encounter information. Although our
proposals would facilitate sharing claims data from payers to
providers, the transmission would not be subject to HIPAA transaction
standards because the purpose of the exchange would not be to request
or issue a payment.\36\ We are also not proposing a mechanism to
[[Page 76258]]
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.\37\ Therefore, a HIPAA
transaction standard is not required to be used for our proposals in
this section because the Secretary has not adopted a HIPAA standard
applicable to communicating claims or encounter information for a
purpose other than requesting or issuing payment.\38\
---------------------------------------------------------------------------
\36\ See 45 CFR 162.1101(a) and 162.1601(a).
\37\ See 45 CFR 162.1101(b)
\38\ See 45 CFR 162.923(a).
---------------------------------------------------------------------------
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
on or after January 1, 2026, and for QHP issuers on the FFEs, for plan
years beginning on or after January 1, 2026), impacted payers would be
required to implement and maintain a FHIR API to exchange data with
providers conformant to the standards discussed in section II.F and at
the CFR citations referenced in Table 9. Individual patient data
maintained by the payer with a date of service on or after January 1,
2016, must be made available via that API no later than 1 business day
after the payer receives a request for data by an in-network provider,
(or in the case of a Medicaid or CHIP FFS program, an enrolled Medicaid
or CHIP provider).
We are proposing these requirements for the Provider Access API for
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities (excluding Non-Emergency
Medical Transportation (NEMT) PAHPs, as explained in this section of
this proposed rule), and QHP issuers on the FFEs at the CFR sections
identified in Table 2.
For Medicaid and CHIP managed care, we propose that NEMT PAHPs, as
defined at 42 CFR 438.9(a) and 457.1206(a) respectively, would not be
subject to the requirement to establish a Provider Access API. MCOs,
PIHPs, and non-NEMT PAHPs would be subject to this proposed rule. We
believe that the unique nature and limited scope of the services
provided by NEMT PAHPs, in that they only cover transportation and not
medical care itself, justify their exclusion from the requirements of
the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we
do not believe that providers have routine need for NEMT data;
therefore, requiring NEMT PAHPs to implement and maintain a Provider
Access API would be an undue burden. However, we propose to include
NEMT PAHPs in the scope of most of the other requirements of this
proposed rule that apply to all other Medicaid managed care plans
listed in Table 2.
We request public comment on the proposal for impacted payers to
implement and maintain a Provider Access API to provide access to
specified patient information.
3. Additional Proposed Requirements for the Provider Access API
In general, the proposals discussed in this section regarding the
data that payers must make available through the API, as well as the
technical specifications, align with the requirements for the Patient
Access API finalized in the CMS Interoperability and Patient Access
final rule (85 FR 25558) and as proposed in section II.A.2. of this
rule. We anticipate that this alignment would provide consistency and
help payers build on the work done to comply with the requirements for
the Patient Access API, outlined previously. Additional proposed
requirements for the Provider Access API regarding attribution, patient
opt out process, patient resources, and provider resources are
discussed in the sections that follow.
a. Attribution
Patient attribution is a method of identifying a patient-provider
treatment relationship. Attribution is a critical component to ensure
that patient health data are shared only with appropriate providers.
For the Provider Access API, we are proposing to require that payers
develop an attribution process to associate patients with their
providers to help ensure that a payer only sends a patient's data to
providers who are requesting that data and who have a treatment
relationship with that patient.
We are aware that the process of attribution can have many
functions for payers, including managing contracts, payments, financial
reconciliation, reporting, and continuity of care. In addition, HL7 has
developed a member attribution process and workflow in the Da Vinci
Member Attribution List FHIR Implementation Guide (IG), which defines
various terms and describes a general process by which a payer and
provider can coordinate and reconcile their understanding of which
patients associated with a particular payer-provider contract.\39\ This
IG does not specify how the payer and provider identify these patients,
but it does specify the FHIR resources (that is, data elements) which
are created as an output of this process. We thus encourage payers to
use processes that they may already have to attribute patients to their
providers for these other purposes.
---------------------------------------------------------------------------
\39\ Health Level Seven International (2021, February 8). Da
Vinci Member Attribution (ATR) List. Retrieved from <a href="http://hl7.org/fhir/us/davinci-atr/">http://hl7.org/fhir/us/davinci-atr/</a>.
---------------------------------------------------------------------------
A payer may implement a process to generate a provider's current
patient roster using claims data, and only permit data exchange through
the Provider Access API to providers with whom those patients can be
attributed via claims data. For example, payers could accept proof of
an upcoming appointment to verify the provider-patient treatment
relationship. We know that many providers already verify coverage with
the payer before a new patient's first appointment. If an in-network
provider is seeing a patient for the first time, the provider's
practice can send proof of the upcoming appointment to the payer. Once
confirmed, this would then allow the provider to request the patient's
data in preparation for the appointment. We further note that the
Argonaut Project has developed an implementation guide specifying how
to use FHIR's Scheduling and Appointment resources to communicate this
information.\40\ We request comments on other examples of how patients
can be attributed to the providers from whom they are receiving care,
especially for a new patient-provider treatment relationship. We also
request comments on whether and how the payer could attribute the
patient to the provider at the same time as or through the same data
transaction.
---------------------------------------------------------------------------
\40\ Health Level Seven International (2022). Argonaut
Scheduling IG (Release 1.0.0). Retrieved from <a href="https://fhir.org/guides/argonaut/scheduling/">https://fhir.org/guides/argonaut/scheduling/</a>.
---------------------------------------------------------------------------
CMS has implemented an attribution process in our DPC pilot for
Medicare beneficiaries, which is the Medicare FFS version of the
Provider Access API. The pilot project requires HIPAA-covered entities
or their business associates to agree to certain terms of service \41\
before data can be sent to them. The current Medicare FFS terms of
service require each organization to maintain a list of patients which
represents the patient population currently being treated at their
facilities.\42\ To add a new patient, CMS requires providers to attest
that they have a treatment-related purpose for adding a patient to
their group. This is accomplished by submitting an attestation with
every request to add a
[[Page 76259]]
patient to their roster. This pilot will continue to test methodologies
to accurately attribute patients to their providers. The information
gained from this pilot may assist the industry to develop procedures to
identify providers under this proposed requirement.
---------------------------------------------------------------------------
\41\ Centers for Medicare & Medicaid Services. (n.d.) Terms of
Service. Data at the Point of Care. Retrieved from <a href="https://dpc.cms.gov/terms-of-service">https://dpc.cms.gov/terms-of-service</a>.
\42\ Centers for Medicare & Medicaid Services. (n.d.)
Attestation & Attribution. Data at the Point of Care. Retrieved from
<a href="https://dpc.cms.gov/docsV1#attestation--attribution">https://dpc.cms.gov/docsV1#attestation--attribution</a>.
---------------------------------------------------------------------------
Based on feedback from the industry, the HL7 Da Vinci attribution
work group has developed a published Member Attribution List IG.\43\
The Da Vinci Member Attribution List IG defines the mechanisms (that
is, protocols), data structures and value sets to be used for
exchanging the Member Attribution List. The Member Attribution List
supported by the Da Vinci Member Attribution List IG typically
contains: (1) plan/contract information which is the basis for the
Member Attribution List, (2) patient information, (3) attributed
individual provider information, (4) attributed organization
information, and (5) member and subscriber coverage information. DPC
has been working with the Da Vinci Member Attribution List team towards
compatibility with this IG.\44\ We also note that the list capability
of this IG is informing updates to the Da Vinci Payer Data Exchange
(PDex) IG.\45\ We encourage payers to review the information from the
workgroup.
---------------------------------------------------------------------------
\43\ Health Level Seven International. (2021, February 8). Da
Vinci Member Attribution (ATR) List. Retrieved from <a href="http://hl7.org/fhir/us/davinci-atr/">http://hl7.org/fhir/us/davinci-atr/</a>.
\44\ Centers for Medicare Medicaid Services. (n.d.) Groups. Data
at the Point of Care. Retrieved from <a href="https://dpc.cms.gov/docsV2#groups">https://dpc.cms.gov/docsV2#groups</a>.
\45\ Health Level Seven International (2020). Da Vinci Payer
Data Exchange. Retrieved from <a href="http://hl7.org/fhir/us/davinci-pdex/STU1/">http://hl7.org/fhir/us/davinci-pdex/STU1/</a>.
---------------------------------------------------------------------------
We do not wish to be overly prescriptive about how payers could
generate an attribution list for providers, but it would be necessary
for payers to establish a process to meet these proposed attribution
requirements for the Provider Access API. Because the standards for the
attribution process continue to evolve, we are not specifying how
payers should identify whether a specific patient can be attributed to
the requesting provider. Instead, we encourage the community to
continue to collaborate on viable approaches.
We also recognize that impacted payers may already have multiple
arrangements in place with providers to support data exchange, and may
even participate in community, local, state, or private health
information exchanges (HIEs). In many cases, these HIEs include patient
attribution capabilities for which payers may already have a process.
Once again, our goal is for payers to avoid having to develop multiple
approaches to address attribution, and we encourage collaboration on
potential solutions.
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs
for plan years beginning on or after January 1, 2026), impacted payers
would maintain a process to associate patients with their in-network or
enrolled providers to enable payer to provider data exchange via the
Provider Access API.
We are proposing these attribution requirements for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans other than NEMT PAHPs, CHIP managed care entities, and QHP
issuers on the FFEs at the CFR sections identified in Table 2.
We solicit comments on our proposal to require payers to develop
processes for verifying the patient-provider treatment relationship,
including any processes that may be in place today.
b. Opt Out
We are proposing that all impacted payers would be required to
establish and maintain a process to allow patients or their personal
representatives to opt out of having the patients' data available for
providers to access through the Provider Access API. We note that this
differs from our Payer-to-Payer API proposal in section II.C.3.c. of
this proposed rule, under which all impacted payers would have an opt
in process. Similar to the proposed attribution process, as previously
discussed, we do not intend to be prescriptive regarding how this opt
out process should be implemented, but payers would be required to make
this opt out process available, and give all currently enrolled
patients or their personal representatives a chance to opt out, before
the first date on which patient information is made available via the
Provider Access API. Specifically, we are proposing that impacted
payers must maintain a process to allow patients or their personal
representatives to opt out of data sharing, or if they have already
opted out, to opt back in. The process for opting out and opting back
in would have to be available before the first date on which patient
information is made available via the API and at any time while the
patient is enrolled with the payer. We are not proposing to require
specific methods for patients to opt out, but anticipate that payers
would make that process available by mobile smart device, website, and/
or apps. We also anticipate that mail, fax, or telephonic methods may
be necessary alternatives for some patients, which payers would have to
accommodate if this policy is finalized as proposed. We invite comments
on whether we should establish more explicit requirements regarding
patient opt out processes.
Our proposal would require payers to allow patients to opt out of
the Provider Access API data exchange for all providers in that payer's
network. However, we also encourage payers to implement processes that
allow more granular controls over the opt out process, so patients can
opt out of having data exchanged with individual providers or groups of
providers. We are not proposing implementation of such processes as a
requirement in this rulemaking, as we are concerned about the potential
administrative and technical burden this may place on some payers.
However, we request comments about the technical feasibility of
implementing an opt out process that would allow patients to make
provider-specific opt out decisions, and whether we should consider
proposing such a requirement in future rulemaking.
We are proposing an opt out approach because opt in models of data
sharing, as we discuss in this section of this rule, have been shown to
inhibit the utilization and usefulness of data sharing efforts between
patients and healthcare providers. We acknowledge that there are
positives and negatives to both opt in and opt out policies, and many
patients may prefer to control or direct their health information via
an opt in process because opt in policies require affirmative
permission from a patient before their data can be shared. However,
patients who are less technologically savvy or have lower health
literacy may be less likely to use the Patient Access API, so having an
opt out policy for the Provider Access API would facilitate sharing
data directly with the provider, without requiring intervention by the
patient. We believe this would promote the positive impacts of data
sharing between and among payers, providers, and patients to support
care coordination and improved health outcomes, which could lead to
greater health equity. In formulating our proposal, we carefully
weighed the issues related to both opt in and opt out policies,
especially as they relate to making data available to providers. We
believe that a proposal defaulting to share 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
propose in more
[[Page 76260]]
detail in this section of this rule, payers would be responsible for
providing patient resources to ensure that patients understand the
implications of the opt out option. We note that should patients choose
not to opt out of data sharing, then the data we propose be made
available via the Provider Access API would be available at any time to
providers that have been attributed to have a treatment relationship
with the patient. However, we believe our proposals, taken together,
would give patients ample opportunities to change their data sharing
preference as they see fit.
Opt in models can create greater administrative burden for smaller
healthcare organizations, depending on where the responsibility for
obtaining and updating the patient's data sharing preference is held.
We note that smaller hospitals in states with opt in patient permission
requirements for HIE are more likely to report regulatory barriers to
data exchange compared with those in states with opt out policies,
though more technologically advanced hospitals reported no
difference.\46\ A report produced for ONC found that states using an
opt out model were quantitatively associated with significantly higher
HIE utilization and maturation.\47\ A 2016 survey found that of the 24
states that give patients a choice regarding participation in the HIE,
16 states have laws describing an opt out procedure, and eight states
have enacted an opt in procedure.\48\ We note that for this report,
``HIE'' refers exclusively to organizations that facilitate information
exchange among healthcare providers, as opposed to the act of
exchanging data for other purposes.
---------------------------------------------------------------------------
\46\ Apathy, N.C., & Holmgren, A.J. (2020). Opt-In Consent
Policies: Potential Barriers to Hospital Health Information
Exchange. The American Journal of Managed Care. 26(1). Retrieved on
January 27, 2022, from <a href="https://doi.org/10.37765/ajmc.2020.42148">https://doi.org/10.37765/ajmc.2020.42148</a>.
\47\ NORC at the University of Chicago (2016, March). Evaluation
of the State HIE Cooperative Agreement Program: Final Report.
Retrieved on January 27, 2022, from <a href="https://www.healthit.gov/sites/default/files/reports/finalsummativereportmarch_2016.pdf">https://www.healthit.gov/sites/default/files/reports/finalsummativereportmarch_2016.pdf</a>.
\48\ Schmit et al. (2018). Falling short: how state laws can
address health information exchange barriers and enablers. Journal
of the American Medical Informatics Association. 25(6). Retrieved on
January 27, 2022, from <a href="https://academic.oup.com/jamia/article/25/6/635/4587931">https://academic.oup.com/jamia/article/25/6/635/4587931</a>.
---------------------------------------------------------------------------
Within the Department of Veterans Affairs (VA), the Veterans Health
Administration, Office of Health Informatics, Veterans Health
Information Exchange (VHIE) Program Office, leads interoperability and
HIE between VA facilities and private sector providers. Until April
2020, VA operated with an opt in model. Between 2013 and 2017, the VHIE
Program Office collected information on the opt in process, and in 2017
reported collecting patient permissions from only 4 percent of the
enrolled veterans.\49\ Consequently, an estimated 90 percent of
requests for patient information were rejected by the system for lack
of permission. One-third of these were collected online while the other
two-thirds were paper forms, which indicates a very high level of
manual work and administrative burden. Beginning in April 2020, as
authorized by section 132 of the John S. McCain III, Daniel K. Akaka,
and Samuel R. Johnson VA Maintaining Internal Systems and Strengthening
Integrated Outside Networks Act of 2018 (VA MISSION Act of 2018) (Pub.
L. 115-182), VA changed its procedures from an opt in to an opt out
model for obtaining patient permission to share data.\50\ \51\
---------------------------------------------------------------------------
\49\ Donahue et al. (2018). Veterans Health Information
Exchange: Successes and Challenges of Nationwide Interoperability.
AMIA Annu Symp Proc. Retrieved on January 27, 2022, from <a href="https://www.ncbi.nlm.nih.gov/labs/pmc/articles/PMC6371252/">https://www.ncbi.nlm.nih.gov/labs/pmc/articles/PMC6371252/</a>.
\50\ U.S. Department of Veteran Affairs (2019, September 30). VA
improves information sharing with community care providers. <a href="https://www.va.gov/opa/pressrel/pressrelease.cfm?id=5322">https://www.va.gov/opa/pressrel/pressrelease.cfm?id=5322</a>.
\51\ U.S. Department of Veteran Affairs (2020, April 20). VA,
DoD implement new capability for bidirectional sharing of health
records with community partners. <a href="https://www.va.gov/opa/pressrel/pressrelease.cfm?id=5425">https://www.va.gov/opa/pressrel/pressrelease.cfm?id=5425</a>.
---------------------------------------------------------------------------
In the December 2020 CMS Interoperability proposed rule, we
proposed an opt in patient permission model for the Provider Access API
and requested comments on opt in versus opt out approaches. In
response, commenters overwhelmingly supported an opt out model and
cited clinical and operational hurdles associated with an opt in
approach. Support for an opt out approach came from both provider
associations and payers, while patient commenters did not oppose such a
proposal. We also believe 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,\52\ 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
they are defined by the Healthy People 2030 report,\53\ while
protecting patients' choice to limit data sharing.
---------------------------------------------------------------------------
\52\ U.S. Department of Health and Human Services. Office of
Disease Prevention and Health Promotion (2010). National Action Plan
to Improve Health Literacy. Retrieved from <a href="https://health.gov/sites/default/files/2019-09/Health_Literacy_Action_Plan.pdf">https://health.gov/sites/default/files/2019-09/Health_Literacy_Action_Plan.pdf</a>.
\53\ Health Literacy in Healthy People 2030 (2020). History of
Health Literacy Definitions. Retrieved from <a href="https://health.gov/healthypeople/priority-areas/health-literacy-healthy-people-2030/history-health-literacy-definitions">https://health.gov/healthypeople/priority-areas/health-literacy-healthy-people-2030/history-health-literacy-definitions</a>.
---------------------------------------------------------------------------
This proposed opt out option is specific to the data we are
proposing payers be required to share via the Provider Access API. As
discussed previously, this proposed rule would not 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 payer's
obligation to disclose that information. However, if finalized, we
would encourage 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 proposals, provided such disclosure
is consistent with all other applicable requirements, such as the HIPAA
Rules. We also note that the HIPAA Rules permits health plans to
disclose PHI, without an individual's authorization, to providers via
the Provider Access API for certain permitted purposes under the HIPAA
Rules, such as, for example, treatment, payment, or health care
operations \54\
---------------------------------------------------------------------------
\54\ See 45 CFR 164.506(c)(2).
---------------------------------------------------------------------------
We value the importance of safeguarding the quality and integrity
of patient health information. We acknowledge that there may be
potential program integrity risks associated with sharing patient data
under both an opt in and opt out model. We believe that payers already
have program integrity protocols through which they determine if a data
exchange has resulted in potential fraud and coordinate investigations
of any potential fraud with the relevant programmatic authorities or
state laws. We expect that if payers identify any vulnerabilities, they
would work to make changes to their operations to address risks that
could lead to potential fraud and to limit the impact on patient
information.
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs
for plan years beginning on or after January 1, 2026), impacted payers
must maintain a process for patients or their personal representatives
to opt out of and subsequently opt into having the patient's health
information available
[[Page 76261]]
and shared via the Provider Access API. We propose 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 proposing this requirement for MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs at the CFR sections
identified in Table 2.
We request comments on our proposal for a patient opt out framework
for the Provider Access API. We additionally request comments on
whether patients should be able to exercise more granular controls over
which data they permit the payer to share, including permitting the
sharing of certain data from only specific timeframes.
c. Patient Resources Regarding the Provider Access API
To ensure that patients understand the implications of the opt out
option for the Provider Access API, we are proposing to require payers
to provide information to their patients about the benefits to the
patient of the Provider Access API requirements, their opt out rights,
and instructions both for opting out of the data exchange and for
opting in after previously opting out. Payers would have to provide
this information, in non-technical, simple, and easy-to-understand
language, at the time of enrollment and annually. Payers would also be
required to make this information available at all times, in an easily
accessible location on payers' public websites. We are not proposing
specific text or format of this information, but we request comments on
whether there are benefits or burdens to requiring that this
information be provided in a specific format or to include specified
content. In particular, we are interested in comments on language
regarding how patient data could be used and shared through the API. We
anticipate payers would include information about patients' ability to
opt out of (and opt back in to) this data sharing in their regular
communications, such as annual enrollment information, privacy notices,
member handbooks, or newsletters. However, we request comment on the
most appropriate and effective communication channel(s) for conveying
this information to patients. We also request comment on whether
providing this information at the time of enrollment and annually is
appropriate, or whether we should require that this information be
provided directly to the patient more frequently.
We believe it is important to honor patient privacy preferences,
and believe it is important for providers to have access to patient
information to be able to provide treatment and coordinate care
effectively. We also believe that more informed patients are more
empowered patients, which we believe leads to increased engagement with
their care and ultimately improved health outcomes. Offering patients
educational materials about their right to opt out of data sharing via
the proposed Provider Access API is thus fundamental to empowering
patients with their data.
In summary, we propose that beginning January 1, 2026 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2026, and for QHP issuers on the FFEs
for plan years beginning on or after January 1, 2026), impacted payers
must provide information in non-technical, simple, and easy-to-
understand language to their patients 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 opting in after previously
opting out. We are proposing that these payers must make this
information available to currently enrolled patients before the
Provider Access API is operational and shares any of their data. We are
proposing that thereafter, payers provide this information at
enrollment and at least annually. We are also proposing that this
information be available in an easily accessible location on payers'
public websites.
We are proposing this requirement for annual information for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs at
the CFR sections identified in Table 2.
d. Provider Resources Regarding the Provider Access API
We are proposing to require payers to develop non-technical and
easy-to-understand educational resources for providers about the
Provider Access API. These educational resources should explain how a
provider can request patient data using the payer's Provider Access
API. The resources would have to include information about the process
for requesting patient data from the payer using the API and how to use
the payer's attribution process to associate patients with the
provider. We are proposing that impacted payers provide these resources
to providers through the payer's website and other appropriate provider
communications, such as annual contract updates or handbooks. Non-
technical resources would help providers understand how they can use
the API to access patient data, thus realizing the expected benefit of
the proposed API.
Specifically, we propose that beginning January 1, 2026 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2026, and for QHP
issuers on the FFEs for plan years beginning on or after January 1,
2026), impacted payers would provide educational resources in non-
technical and easy-to-understand language on their websites and through
other appropriate mechanisms for communicating with providers,
explaining how a provider may make a request to the payer for patient
data using the FHIR API. We also propose that those resources must
include information about the mechanism for attributing patients to
providers.
We are proposing this requirement for provider resources for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP Issuers on the FFEs at
the CFR sections identified in Table 2.
We request comment on this proposal, including whether CMS should
develop guidance regarding, or address in future rulemaking the
specific content of these educational materials about the Provider
Access API.
4. Extensions, Exemptions, and Exceptions
a. Extensions and Exemptions for Medicaid and CHIP FFS Programs
Should our proposals regarding the Provider Access API be finalized
as proposed, we would strongly encourage state Medicaid and CHIP FFS
programs to implement the Provider Access API as soon as possible, due
to the many anticipated benefits of the API as discussed in this
section. However, we also recognize that state Medicaid and CHIP FFS
agencies may face certain circumstances that would not apply to other
impacted payers. To address these concerns, we are proposing a process
through which states may seek an extension of, and, in specific
circumstances, an exemption from, the Provider Access API requirements.
We propose the following:
(1) Extension
At the regulation citations identified in Table 2, we propose to
provide state Medicaid FFS and CHIP FFS programs the opportunity to
request a one-time
[[Page 76262]]
extension of up to 1 year to implement the Provider Access API
specified at 42 CFR 431.61(a) and 457.731(a). Some states may be unable
to meet the proposed compliance date due to challenges related to
securing needed funding for necessary contracting and staff resources
in time to develop and implement the API requirements, depending on
when the final rule is published in relation to a state's fiscal year,
legislative session, budget process, and related timeline. Some states
may need to initiate a public procurement process to secure contractors
with the necessary skills to support a state's implementation of these
proposed API policies. The timeline for an openly competed procurement
process, together with the time needed to onboard the contractor and
develop the API, can be lengthy for states. A state might need to hire
new staff with the necessary skillset to implement this policy. The
time needed to initiate the public employee hiring process, vet, hire,
and onboard the new staff may make meeting the proposed compliance
timeline difficult because, generally speaking, public employee hiring
processes include stricter guidelines and longer time-to-hire periods
than other sectors.\55\ Furthermore, states are currently responding to
the effects of the COVID-19 public health emergency, and their regular
operational resources are over-extended. Unwinding from the COVID-19
public health emergency is also expected to require significant IT
resources, which could have an impact on future IT work. In all such
situations, a state might need more time than other impacted payers to
implement the Provider Access API requirements. The 1-year extension
that we propose could help mitigate the challenges. We considered
delaying implementation of the provisions in this proposed rule an
additional year for states, but decided that it would be better to
propose to have only those states that needed an extension apply,
because states vary in their level of technical expertise and ability
to recruit staff and secure contracts.
---------------------------------------------------------------------------
\55\ State hiring processes are comparable with Federal hiring
processes. According to the Office of Management and Budget (OMB),
the average time-to-hire for Federal employees was 98.3 days in
2018, significantly higher than the private sector average of 23.8
days. See <a href="https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/">https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/</a>.
---------------------------------------------------------------------------
Should the proposal for this API be finalized as proposed, states
would be permitted to submit a written application for a one-time, one-
year extension as a part of their annual Advance Planning Document
(APD) for Medicaid Management Information System (MMIS) operations
expenditures. The state's request would have to include the following:
(1) a narrative justification describing the specific reasons why the
state cannot reasonably satisfy the requirement(s) by the compliance
date, and why those reasons result from circumstances that are unique
to the agency operating the Medicaid and/or CHIP FFS program (versus
other types of impacted payers); (2) a report on completed and ongoing
state implementation activities that evidence a good faith effort
towards compliance; and (3) a comprehensive plan to meet the Provider
Access API requirements no later than 1 year after the compliance date.
Under this proposal, CMS would approve an extension if, based on
the information provided in the APD, CMS determines that the request
adequately establishes a need to delay implementation, and that the
state has a comprehensive plan to implement the proposed requirements
no later than 1 year after the compliance date. We also solicit
comments on whether our proposal would adequately address the unique
circumstances that affect states and that might make timely compliance
with the proposed API requirement difficult for states.
(2) Exemption
At the CFR sections identified in Table 2, we propose to permit
state Medicaid FFS programs to request an exemption from the Provider
Access API requirements when at least 90 percent of the state's
Medicaid beneficiaries are enrolled in Medicaid managed care
organizations as defined at 42 CFR 438.2. Likewise, we propose that
separate CHIP FFS programs could request an exemption from the Provider
Access API requirements if at least 90 percent of the state's separate
CHIP beneficiaries are enrolled in CHIP managed care entities, as
defined at 42 CFR 457.10. In this circumstance, the time and resources
that the state would need to expend to implement the Provider Access
API requirements for a small FFS population may outweigh the benefits
of implementing and maintaining the API. Unlike other impacted payers,
state Medicaid and CHIP FFS programs do not have a diversity of plans
to balance implementation costs for those plans with low enrollment. If
there is low enrollment in a state Medicaid or CHIP FFS program, there
is no potential for the technology to be leveraged for additional
beneficiaries. States, unlike other payers, do not maintain additional
lines of business.
We acknowledge that the proposed exemption could mean that most
beneficiaries enrolled with exempted Medicaid or CHIP FFS programs
would not receive the full benefits of having this API available to
facilitate health information sharing with providers. To address this,
we propose that states that are granted an exemption would be expected
to implement an alternative plan to ensure that enrolled providers will
have efficient electronic access to the same information through other
means, to help ensure that Medicaid or CHIP services are provided with
reasonable promptness and in a manner consistent with simplicity of
administration and in the best interests of those beneficiaries who are
served under the FFS program.
We propose that a state could submit a written request for an
exemption from the requirements for the Provider Access API as part of
its annual APD for MMIS operations expenditures prior to the date by
which the state would otherwise need to comply with the requirements
(which may be extended by 1 year if the state receives an extension).
For Medicaid exemption requests, the state would be required to include
documentation that it meets the criteria for the exemption based on
enrollment data from the most recent CMS ``Medicaid Managed Care
Enrollment and Program Characteristics'' report. For a CHIP FFS
exemption, the state's request would have to include enrollment data
from Section 5 of the most recently accepted state submission to the
CHIP Annual Report Template System (CARTS). The state would also be
required to include in its request information about 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. CMS would grant the exemption if the state establishes to
CMS's satisfaction that it meets the criteria for the exemption and has
established such an alternative plan. We note that the same
considerations for beneficiary opt out, as previously explained, would
still be required.
Once an exemption has been approved, we propose that the exemption
would expire if either of the following two scenarios occurs: (1) based
on the 3 previous years of available, finalized Medicaid Transformed
Medicaid Statistical Information System (T-MSIS) and/or CHIP CARTS
managed care and FFS enrollment data, the State's managed care
enrollment for 2 of the previous 3 years is below 90 percent; or (2)
CMS has approved a State plan amendment,
[[Page 76263]]
waiver, or waiver amendment that would significantly reduce the share
of beneficiaries enrolled in managed care and the anticipated shift in
enrollment is confirmed by available, finalized Medicaid T-MSIS and/or
CHIP CARTS managed care and FFS enrollment data.
For the first scenario, CMS recognizes that there may be
circumstances where a state's managed care enrollment may fluctuate
slightly below the 90 percent threshold in 1 year, and yet return to
above 90 percent the next year. To help reduce the possible burden on
exempted states experiencing this type of temporary fluctuation in
managed care enrollment, CMS would consider data from the 3 previous
years of available, finalized Medicaid T-MSIS and/or CHIP CARTS managed
care and FFS enrollment data. We propose that if the state's managed
care enrollment for 2 of the previous 3 years is below 90 percent, the
state's exemption would expire.
We propose that a state would be required to provide written
notification to CMS that the state no longer qualifies for the Provider
Access API exemption when data confirm that there has been a shift from
managed care enrollment to FFS enrollment resulting in the State's
managed care enrollment falling below the 90 percent threshold for 2 of
the previous 3 years. We propose that the written notification be
submitted to CMS within 90 days of the finalization of the annual
Medicaid T-MSIS managed care enrollment data and/or the CARTS report
for CHIP confirming that there has been the requisite shift from
managed care enrollment to FFS enrollment in 2 of the 3 previous years.
For the second scenario, we recognize that there may be state plan
amendments, waivers, or waiver amendments that would result in a shift
from managed care enrollment to FFS enrollment. Additionally, there may
be instances where anticipated enrollment shifts may not be fully
realized due to other circumstances. We propose that a state would be
required to provide written notification to CMS that the state no
longer qualifies for the Provider Access API when data confirm that
there has been a shift from managed care enrollment to FFS enrollment
as anticipated in the state plan amendment or waiver approval. We
propose that the written notification 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 confirming that
there has been the requisite shift from managed care enrol
[…truncated; see source link]Indexed from Federal Register on December 13, 2022.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.