Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers, 25510-25640 [2020-05050]
Download as PDF
25510
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
DEPARTMENT OF HEALTH AND
HUMAN SERVICES
Centers for Medicare & Medicaid
Services
42 CFR Parts 406, 407, 422, 423, 431,
438, 457, 482, and 485
Office of the Secretary
45 CFR Part 156
[CMS–9115–F]
RIN 0938–AT79
Medicare and Medicaid Programs;
Patient Protection and Affordable Care
Act; Interoperability and Patient
Access for Medicare Advantage
Organization and Medicaid Managed
Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed
Care Entities, Issuers of Qualified
Health Plans on the FederallyFacilitated Exchanges, and Health Care
Providers
Centers for Medicare &
Medicaid Services (CMS), HHS.
ACTION: Final rule.
AGENCY:
This final rule is intended to
move the health care ecosystem in the
direction of interoperability, and to
signal our commitment to the vision set
out in the 21st Century Cures Act and
Executive Order 13813 to improve the
quality and accessibility of information
that Americans need to make informed
health care decisions, including data
about health care prices and outcomes,
while minimizing reporting burdens on
affected health care providers and
payers.
SUMMARY:
These regulations are effective
on June 30, 2020.
FOR FURTHER INFORMATION CONTACT:
Alexandra Mugge, (410) 786–4457, for
issues related to interoperability, CMS
health IT strategy, and technical
standards.
Denise St. Clair, (410) 786–4599, for
issues related API policies and related
standards.
Natalie Albright, (410) 786–1671, for
issues related to Medicare Advantage.
Laura Snyder, (410) 786–3198, for
issues related to Medicaid.
Rebecca Zimmermann, (301) 492–
4396, for issues related to Qualified
Health Plans.
Meg Barry, (410) 786–1536, for issues
related to CHIP.
Thomas Novak, (202) 322–7235, for
issues related to trust exchange
networks and payer to payer
coordination.
DATES:
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Sharon Donovan, (410) 786–9187, for
issues related to federal-state data
exchange.
Daniel Riner, (410) 786–0237, for
issues related to Physician Compare.
Ashley Hain, (410) 786–7603, for
issues related to hospital public
reporting.
Melissa Singer, (410) 786–0365, for
issues related to provider directories.
CAPT Scott Cooper, USPHS, (410)
786–9465, for issues related to hospital
and critical access hospital conditions
of participation.
Russell Hendel, (410) 786–0329, for
issues related to the Collection of
Information or the Regulation Impact
Analysis sections.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Background and Summary of Provisions
A. Purpose
B. Overview
C. Executive Order and MyHealthEData
D. Past Efforts
E. Challenges and Barriers to
Interoperability
F. Summary of Major Provisions
II. Technical Standards Related to
Interoperability Provisions, and Analysis
of and Responses to Public Comments
A. Technical Approach and Standards
B. Content and Vocabulary Standards
C. Application Programming Interface
(API) Standard
D. Updates to Standards
III. Provisions of Patient Access Through
APIs, and Analysis of and Responses to
Public Comments
A. Background on Medicare Blue Button
B. Expanding the Availability of Health
Information
C. Standards-based API Proposal for MA,
Medicaid, CHIP, and QHP Issuers on the
FFEs
IV. API Access to Published Provider
Directory Data Provisions, and Analysis
of and Responses to Public Comments
A. Interoperability Background and Use
Cases
B. Broad API Access to Provider Directory
Data
V. The Health Information Exchange and
Care Coordination Across Payers:
Establishing a Coordination of Care
Transaction To Communicate Between
Plans Provisions, and Analysis of and
Responses to Public Comments
VI. Care Coordination Through Trusted
Exchange Networks: Trust Exchange
Network Requirements for MA Plans,
Medicaid Managed Care Plans, CHIP
Managed Care Entities, and QHPs on the
FFEs Provisions, and Analysis of and
Responses to Public Comments
VII. Improving the Medicare-Medicaid Dually
Eligible Experience by Increasing the
Frequency of Federal-State Data
Exchanges Provisions, and Analysis of
and Responses to Public Comments
A. Increasing the Frequency of FederalState Data Exchanges for Dually Eligible
Individuals
PO 00000
Frm 00002
Fmt 4701
Sfmt 4700
B. Request for Stakeholder Input
VIII. Information Blocking Background and
Public Reporting Provisions, and
Analysis of and Responses to Public
Comments
A. Information Blocking Background
B. Public Reporting and Prevention of
Information Blocking on Physician
Compare
C. Public Reporting and Prevention of
Information Blocking for Eligible
Hospitals and Critical Access Hospitals
(CAHs)
IX. Provider Digital Contact Information
Provisions, and Analysis of and
Responses to Public Comments
A. Background
B. Public Reporting of Missing Digital
Contact Information
X. Conditions of Participation for Hospitals
and Critical Access Hospitals (CAHs)
Provisions, and Analysis of and
Responses to Public Comments
A. Background
B. Provisions for Hospitals (42 CFR
482.24(d))
C. Provisions for Psychiatric Hospitals (42
CFR 482.61(f))
D. Provisions for CAHs (42 CFR
485.638(d))
XI. Provisions of the Final Regulations
XII. Collection of Information Requirements
A. Background
B. Wage Estimates
C. Information Collection Requirements
(ICRs)
XIII. Regulatory Impact Analysis
A. Statement of Need
B. Overall Impact
C. Anticipated Effects
D. Alternatives Considered
E. Accounting Statement and Table
F. Regulatory Reform Analysis Under E.O.
13771
G. Conclusion
Regulation Text
I. Background and Summary of
Provisions
In the March 4, 2019 Federal Register,
we published the ‘‘Medicare and
Medicaid Programs; Patient Protection
and Affordable Care Act;
Interoperability and Patient Access for
Medicare Advantage Organization and
Medicaid Managed Care Plans, State
Medicaid Agencies, CHIP Agencies and
CHIP Managed Care Entities, Issuers of
Qualified Health Plans on the Federallyfacilitated Exchanges and Health Care
Providers’’ proposed rule (84 FR 7610)
(hereinafter referred to as the ‘‘CMS
Interoperability and Patient Access
proposed rule’’). The proposed rule
outlined our proposed policies that
were intended to move the health care
ecosystem in the direction of
interoperability, and to signal our
commitment to the vision set out in the
21st Century Cures Act and Executive
Order 13813 to improve quality and
accessibility of information that
Americans need to make informed
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
health care decisions, including data
about health care prices and outcomes,
while minimizing reporting burdens on
affected health care providers and
payers. We solicited public comments
on the CMS Interoperability and Patient
Access proposed rule. In this final rule,
we address those public comments and
outline our final policies in the
respective sections of this rule.
A. Purpose
This final rule is the first phase of
policies centrally focused on advancing
interoperability and patient access to
health information using the authority
available to the Centers for Medicare &
Medicaid Services (CMS). We believe
this is an important step in advancing
interoperability, putting patients at the
center of their health care, and ensuring
they have access to their health
information. We are committed to
working with stakeholders to solve the
issue of interoperability and getting
patients access to information about
their health care, and we are taking an
active approach to move participants in
the health care market toward
interoperability and the secure and
timely exchange of health information
by adopting policies for the Medicare
and Medicaid programs, the Children’s
Health Insurance Program (CHIP), and
qualified health plan (QHP) issuers on
the individual market Federallyfacilitated Exchanges (FFEs). For
purposes of this rule, references to QHP
issuers on the FFEs excludes issuers
offering only stand-alone dental plans
(SADPs), unless otherwise noted for a
specific proposed or finalized policy.
Likewise, we are also excluding QHP
issuers only offering QHPs in the
Federally-facilitated Small Business
Health Options Program Exchanges (FF–
SHOPs) from the provisions of this rule
and so, for purposes of this rule
references to QHP issuers on the FFEs
excludes issuers offering QHPs only on
the FF–SHOPs. We note that, in this
final 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 consumers in these
states enroll in coverage through
HealthCare.gov, and QHP issuers in
SBE–FPs are not subject to the
requirements in this rule.
B. Overview
We are dedicated to enhancing and
protecting the health and well-being of
all Americans. One critical issue in the
U.S. health care system is that people
cannot easily access their health
information in interoperable forms.
Patients and the health care providers
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
caring for them are often presented with
an incomplete picture of their health
and care as pieces of their information
are stored in various, unconnected
systems and do not accompany the
patient to every care setting. Although
more than 95 percent of hospitals 1 and
75 percent of office-based clinicians 2
are utilizing certified health IT,
challenges remain in creating a
comprehensive, longitudinal view of a
patient’s health history.3 4 5 This siloed
nature of health care data prevents
physicians, pharmaceutical companies,
manufacturers, and payers from
accessing and interpreting important
data sets, instead, encouraging each
group to make decisions based upon a
part of the information rather than the
whole. Without an enforced standard of
interoperability, data exchanges are
often complicated and time-consuming.
We believe patients should have the
ability to move from payer to payer,
provider to provider, and have both
their clinical and administrative
information travel with them
throughout their journey. When a
patient receives care from a new
provider, a record of their health
information should be readily available
to that care provider, regardless of
where or by whom care was previously
provided. When a patient is discharged
from a hospital to a post-acute care
(PAC) setting there should be no
question as to how, when, or where
their data will be exchanged. Likewise,
when an enrollee changes payers or ages
into Medicare, the enrollee should be
able to have their claims history and
encounter data follow so that
information is not lost. As discussed in
more detail in section III. of this final
rule, claims and encounter data can
offer a more holistic understanding of a
1 Office of the National Coordinator. (2019).
Hospitals’ Use of Electronic Health Records Data,
2015–2017. Retrieved from https://
www.healthit.gov/sites/default/files/page/2019-04/
AHAEHRUseDataBrief.pdf.
2 Office of the National Coordinator. (2019,
December 18). Health IT Playbook, Section 1:
Electronic Health Records. Retrieved from https://
www.healthit.gov/playbook/electronic-healthrecords/.
3 Powell, K. R. & Alexander, G. L. (2019).
Mitigating Barriers to Interoperability in Health
Care. Online Journal of Nursing Informatics, 23(2).
Retrieved from https://www.himss.org/library/
mitigating-barriers-interoperability-health-care.
4 Hochman, M., Garber, J., & Robinson, E. J. (2019,
August 14). Health Information Exchange After 10
Years: Time For A More Assertive, National
Approach. Retrieved from https://
www.healthaffairs.org/do/10.1377/hblog20190807.
475758/full/.
5 Payne, T. H., Lovis, C., Gutteridge, C., Pagliari,
C., Natarajan, S., Yong, C., & Zhao, L. (2019). Status
of health information exchange: A comparison of
six countries. Journal of Global Health, 9(2). doi:
10.7189/jogh.09.020427.
PO 00000
Frm 00003
Fmt 4701
Sfmt 4700
25511
patient’s health, providing insights into
everything from the frequency and types
of care provided and for what reason,
medication history and adherence, and
the evolution and adherence to a care
plan. This information can empower
patients to make better decisions and
inform providers to support better
health outcomes.
For providers in clinical and
community settings, health information
technology (health IT) should be a
resource, enabling providers to deliver
high quality care, creating efficiencies
and allowing them to access all payer
and provider data for their patients.
Therefore, health IT should not detract
from the clinician-patient relationship,
from the patient’s experience of care, or
from the quality of work life for
physicians, nurses, other health care
professionals, and social service
providers. Through standards-based
interoperability and information
exchange, health IT has the potential to
facilitate efficient, safe, high-quality
care for individuals and populations.
All payers should have the ability to
exchange data seamlessly with other
payers for timely benefits coordination
or transitions, and with health care and
social service providers to facilitate
more coordinated and efficient care.
Payers are in a unique position to
provide enrollees with a comprehensive
picture of their claims and encounter
data, allowing patients to piece together
their own information that might
otherwise be lost in disparate systems.
This information can contribute to
better informed decision making,
helping to inform the patient’s choice of
coverage options and care providers to
more effectively manage their own
health, care, and costs.
We are committed to working with
stakeholders to solve the issue of
interoperability and patient access in
the U.S. health care system while
reducing administrative burdens on
providers and are taking an active
approach using all available policy
levers and authorities to move
participants in the health care market
toward interoperability and the secure
and timely exchange of health care
information.
C. Executive Order and MyHealthEData
On October 12, 2017, President
Trump issued Executive Order 13813 to
Promote Healthcare Choice and
Competition Across the United States.
Section 1(c)(iii) of Executive Order
13813 states that the Administration
will improve access to, and the quality
of, information that Americans need to
make informed health care decisions,
including information about health care
E:\FR\FM\01MYR2.SGM
01MYR2
25512
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
prices and outcomes, while minimizing
reporting burdens on impacted
providers, and payers, meaning
providers and payers subject to this
rule.
In support of Executive Order 13813,
the Administration launched the
MyHealthEData initiative. This
government-wide initiative aims to
empower patients by ensuring that they
have access to their own health
information and the ability to decide
how their data will be used, while
keeping that information safe and
secure. MyHealthEData aims to break
down the barriers that prevent patients
from gaining electronic access to their
health information from the device or
application of their choice, empowering
patients and taking a critical step
toward interoperability and patient data
exchange.
In March 2018, the White House
Office of American Innovation and the
CMS Administrator announced the
launch of MyHealthEData, and CMS’s
direct, hands-on role in improving
patient access and advancing
interoperability. As part of the
MyHealthEData initiative, we are taking
a patient-centered approach to health
information access and moving to a
system in which patients have
immediate access to their computable
health information such that they can be
assured that their health information
will follow them as they move
throughout the health care system from
provider to provider, payer to payer. To
accomplish this, we have launched
several initiatives related to data sharing
and interoperability to empower
patients and encourage payer and
provider competition. We continue to
advance the policies and goals of the
MyHealthEData initiative through
various provisions included in this final
rule.
As finalized in this rule, our policies
are wide-reaching and will have an
impact on all facets of the health care
system. Several key touch points of the
policies in this rule include:
• Patients: Enabling patients to access
their health information electronically
without special effort by requiring the
payers subject to this final rule to make
data available through an application
programming interface (API) to which
third-party software applications
connect to make data available to
patients for their personal use. This
encourages patients to take charge of
and better manage their health care, and
thus these initiatives are imperative to
improving a patient’s long-term health
outcomes.
• Clinicians and Hospitals: Ensuring
that health care providers have ready
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
access to health information about their
patients, regardless of where the patient
may have previously received care. We
are also implementing policies to
prevent health care providers from
inappropriately restricting the flow of
information to other health care
providers and payers. Finally, we are
working to ensure that better
interoperability reduces the burden on
health care providers.
• Payers: Implementing requirements
to ensure that payers (that is, entities
and organizations that pay for health
care), such as payers in Medicare
Advantage, Medicaid, and CHIP, make
enrollee electronic health information
held by the payer available through an
API such that, with use of software
expected to be developed by payers and
third parties, the information becomes
easily accessible to the enrollee and data
flow seamlessly with the enrollee as
such enrollees change health care and
social service providers and payers.
Additionally, our policies ensure that
payers make it easy for current and
prospective enrollees to identify which
providers are within a given plan’s
network in a way that is simple and
easy for enrollees to access and
understand, and thus find the providers
that are right for them.
As a result of our efforts to
standardize data and technical
approaches to advance interoperability,
we believe health care providers and
their patients, as well as other key
participants within the health care
ecosystem such as payers, will have
appropriate access to the information
necessary to coordinate individual care;
analyze population health trends,
outcomes, and costs; and manage
benefits and the health of populations,
while tracking progress through quality
improvement initiatives. We are
working with other federal partners
including the Office of the National
Coordinator for Health Information
Technology (ONC) on this effort with
the clear objectives of improving patient
access and care, alleviating provider
burden, and reducing overall health care
costs, all while taking steps to protect
the privacy and security of patients’
personal health information. As
evidence of this partnership, ONC is
releasing the ONC 21st Century Cures
Act final rule (published elsewhere in
this issue of the Federal Register) in
tandem with this final rule. It is this
coordinated federal effort, in
conjunction with strong support and
innovation from our stakeholders, that
will help us move ever closer to true
interoperability.
PO 00000
Frm 00004
Fmt 4701
Sfmt 4700
D. Past Efforts
The Department of Health and Human
Services (HHS) has been working to
advance the interoperability of
electronic health information for over 15
years. For a detailed explanation of past
efforts, see the CMS Interoperability and
Patient Access proposed rule (84 FR
7612 through 7614).
E. Challenges and Barriers to
Interoperability
Through significant stakeholder
feedback, we understand that there are
many barriers to interoperability, which
have obstructed progress over the years.
We have conducted stakeholder
meetings and roundtables; solicited
comments via RFIs; and received
additional feedback through letters and
rulemaking. All of this input together
contributed to the policies in our
Interoperability and Patient Access
proposed rule, and when combined
with the comments we received on the
proposed rule, the content of this final
rule. Some of the main barriers shared
with us, specifically patient
identification, lack of standardization,
information blocking, the lack of
adoption and use of certified health IT
among post-acute care (PAC) providers,
privacy concerns, and uncertainty about
the requirements of the Health
Insurance Portability and
Accountability Act of 1996 (HIPAA)
Privacy, Security, and Breach
Notification Rules, were discussed in
the proposed rule (84 FR 7614 through
7617). While we have made efforts to
address some of these barriers in this
final rule and through prior rules and
actions, we believe there is still
considerable work to be done to
overcome some of these challenges
toward achieving interoperability, and
we will continue this work as we move
forward with our interoperability
efforts.
F. Summary of Major Provisions
This final rule empowers patients in
MA organizations, Medicaid and CHIP
FFS programs, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs, by finalizing
several initiatives that will break down
those barriers currently keeping patients
from easily accessing their electronic
health care information. Additionally,
the rule creates and implements new
mechanisms to enable patients to access
their own health care information
through third-party software
applications, thereby providing them
with the ability to decide how, when,
and with whom to share their
information.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
We are finalizing with modifications
our proposal to require MA
organizations, Medicaid and 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. This Patient Access API
must meet the technical standards
finalized by HHS in the ONC 21st
Century Cures Act final rule (published
elsewhere in this issue of the Federal
Register) at 45 CFR 170.215 (currently
including Health Level 7® (HL7) Fast
Healthcare Interoperability Resources®
(FHIR) Release 4.0.1) and the content
and vocabulary standards finalized by
HHS in the ONC 21st Century Cures Act
final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR
170.213, as well as content and
vocabulary standards at 45 CFR part 162
and the content and vocabulary
standards at 42 CFR 423.160. We are
finalizing that through the Patient
Access API, payers must permit thirdparty applications to retrieve, with the
approval and at the direction of a
current enrollee, data specified at 42
CFR 422.119, 431.60, 457.730, and 45
CFR 156.221. Specifically, we are
requiring that the Patient Access API
must, at a minimum, make available
adjudicated claims (including provider
remittances and enrollee cost-sharing);
encounters with capitated providers;
and clinical data, including laboratory
results (when maintained by the
impacted payer). Data must be made
available no later than one (1) business
day after a claim is adjudicated or
encounter data are received. We are
requiring that beginning January 1,
2021, impacted payers make available
through the Patient Access API the
specified data they maintain with a date
of service on or after January 1, 2016.
This is consistent with the requirements
for the payer-to-payer data exchange
detailed in section V. of this final rule.
Together these policies facilitate the
creation and maintenance of a patient’s
cumulative health record with their
current payer.
We are finalizing regulations to
require that MA organizations, Medicaid
and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed
care entities make standardized
information about their provider
networks available through a Provider
Directory API that is conformant with
the technical standards finalized by
HHS in the ONC 21st Century Cures Act
final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR
170.215, excluding the security
protocols related to user authentication
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
and authorization and any other
protocols that restrict availability of this
information to particular persons or
organizations. Authentication and
authorization protocols are not
necessary when making publicly
available data accessible via an API. We
are finalizing that the Provider Directory
API must be accessible via a publicfacing digital endpoint on the payer’s
website to ensure public discovery and
access. At a minimum, these payers
must make available via the Provider
Directory API provider names,
addresses, phone numbers, and
specialties. For MA organizations that
offer MA–PD plans, they must also
make available, at a minimum,
pharmacy directory data, including the
pharmacy name, address, phone
number, number of pharmacies in the
network, and mix (specifically the type
of pharmacy, such as ‘‘retail
pharmacy’’). All directory information
must be made available to current and
prospective enrollees and the public
through the Provider Directory API
within 30 calendar days of a payer
receiving provider directory information
or an update to the provider directory
information. The Provider Directory API
is being finalized at 42 CFR 422.120 for
MA organizations, at 42 CFR 431.70 for
Medicaid state agencies, at 42 CFR
438.242(b)(6) for Medicaid managed
care plans, at 42 CFR 457.760 for CHIP
state agencies, and at 42 CFR
457.1233(d)(3) for CHIP managed care
entities. Here we are finalizing that
access to the published Provider
Directory API must be fully
implemented by January 1, 2021. We do
strongly encourage payers to make their
Provider Directory API public as soon as
possible to make and show progress
toward meeting all the API requirements
being finalized in this rule.
We are finalizing our proposal, with
certain modifications as detailed in
section V. of this final rule, to require
MA organizations, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs to
coordinate care between payers by
exchanging, at a minimum, the data
elements specified in the current
content and vocabulary standard
finalized by HHS in the ONC 21st
Century Cures Act final rule (published
elsewhere in this issue of the Federal
Register) at 45 CFR 170.213 (currently
the ‘‘United States Core Data for
Interoperability’’ (USCDI) version 1 6).
This payer-to-payer data exchange
6 Office of the National Coordinator. (n.d.). U.S.
Core Data for Interoperability (USCDI). Retrieved
from https://www.healthit.gov/isa/us-core-datainteroperability-uscdi.
PO 00000
Frm 00005
Fmt 4701
Sfmt 4700
25513
requires these payers, as finalized at 42
CFR 422.119(f) for MA organizations, at
42 CFR 438.62(b)(1)(vi) for Medicaid
managed care plans (and by extension
under § 457.1216 CHIP managed care
entities), and at 45 CFR 156.221(f) for
QHP issuers on the FFEs, to send, at a
current or former enrollee’s request,
specific information they maintain with
a date of service on or after January 1,
2016 to any other payer identified by
the current enrollee or former enrollee.
This is consistent with the Patient
Access API detailed in section III. of this
final rule. We are also finalizing a
provision that a payer is only obligated
to share data received from another
payer under this regulation in the
electronic form and format it was
received. This is intended to reduce
burden on payers. We are finalizing that
this payer-to-payer data exchange must
be fully implemented by January 1,
2022.
In response to comments discussed
more fully below, we are not finalizing
our proposal to require MA
organizations, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs to participate
in a trusted exchange network given the
concerns commenters raised regarding
the need for a mature Trusted Exchange
Framework and Common Agreement
(TEFCA) to be in place first, and
appreciating that work on TEFCA is
ongoing at this time.
We are finalizing the requirements
that all states participate in daily
exchange of buy-in data, which includes
both sending data to CMS and receiving
responses from CMS daily, and that all
states submit the MMA file data to CMS
daily by April 1, 2022 in accordance
with 42 CFR 406.26, 407.40, and
423.910, respectively, as proposed.
These requirements will improve the
experience of dually eligible individuals
by improving the ability of providers
and payers to coordinate eligibility,
enrollment, benefits, and/or care for this
population.
We are finalizing our proposal to
include an indicator on Physician
Compare for the eligible clinicians and
groups that submit a ‘‘no’’ response to
any of the three prevention of
information blocking statements for
MIPS. In the event that these statements
are left blank, the attestations will be
considered incomplete, and we will not
include an indicator on Physician
Compare. The indicator will be posted
on Physician Compare, either on the
profile pages or in the downloadable
database, starting with the 2019
performance period data available for
public reporting starting in late 2020.
E:\FR\FM\01MYR2.SGM
01MYR2
25514
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
We are finalizing our proposal to
include information on a publicly
available CMS website indicating that
an eligible hospital or critical access
hospital (CAH) attesting under the
Medicare FFS Promoting
Interoperability Program had submitted
a ‘‘no’’ response to any of the three
attestation statements related to the
prevention of information blocking. In
the event that an eligible hospital or
CAH leaves a ‘‘blank’’ response, the
attestations will be considered
incomplete, and no information will be
posted related to these attestation
statements. We will post this
information starting with the
attestations for the EHR reporting period
in 2019 and expect this information will
be posted in late 2020.
Additionally, as detailed in section
IX. of this final rule, we are finalizing
our proposal to publicly report the
names and NPIs of those providers who
do not have digital contact information
included in the National Plan and
Provider Enumeration System (NPPES)
system beginning in the second half of
2020 as proposed. Additionally, we will
continue to ensure providers are aware
of the benefits of including digital
contact information in NPPES, and
when and where their names and NPIs
will be posted if they do not include
this information. We do strongly
encourage providers to include FHIR
endpoint information in NPPES if and
when they have the information, as
well.
To further advance electronic
exchange of information that supports
effective transitions of care we are
finalizing the requirement for a hospital,
psychiatric hospital, and CAH, which
utilizes an electronic medical records
system or other electronic
administrative system that is
conformant with the content exchange
standard at 45 CFR 170.205(d)(2) to
demonstrate that: (1) Its system’s
notification capacity is fully operational
and that it operates in accordance with
all state and federal statutes and
regulations regarding the exchange of
patient health information; (2) its
system sends notifications that must
include the minimum patient health
information specified in section X. of
this final rule; and (3) its system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, and at the time of a
patient’s registration in the emergency
department or admission to inpatient
services, and also prior to, or at the time
of, a patient’s discharge and/or transfer
from the emergency department or
inpatient services, to all applicable postacute care services providers and
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
suppliers, primary care practitioners
and groups, and other practitioners and
groups identified by the patient as
primarily responsible for his or her care,
and who or which need to receive
notification of the patient’s status for
treatment, care coordination, or quality
improvement purposes. We are
establishing that this policy will be
applicable 12 months after publication
of this rule for hospitals, including
psychiatric hospitals, and CAHs to
allow for adequate and additional time
for these institutions, especially small
and/or rural hospitals as well as CAHs,
to come into compliance with the new
requirements.
Finally, we note that we included two
RFIs in the proposed rule: one related to
interoperability and health IT adoption
in PAC settings and one related to the
role of patient matching in
interoperability and improved patient
care. We thank commenters for the
insights shared on these two topics. We
are reviewing these comments and will
take them into consideration for
potential future rulemaking.
Throughout this final rule, we refer to
terms such as ‘‘patient,’’ ‘‘consumer,’’
‘‘beneficiary,’’ ‘‘enrollee,’’ and
‘‘individual.’’ We note that every reader
of this final rule is a patient and has or
will receive medical care at some point
in their life. In this final rule, we use the
term ‘‘patient’’ as an inclusive term, but
because we have historically referred to
patients using the other terms noted
above in our regulations, we use specific
terms as applicable in sections of this
final rule to refer to individuals covered
under the health care programs that
CMS administers and regulates. We also
note that when we discuss patients, we
acknowledge a patient’s personal
representative. Per the HIPAA privacy
regulations at 45 CFR 164.502(g), a
personal representative is someone
authorized under state or other
applicable law to act on behalf of the
individual in making health care related
decisions (such as a parent, guardian, or
person with a medical power of
attorney).7 Policies in this final rule that
require a patient’s action could be
addressed by a patient’s personal
representative.
We also use terms such as ‘‘payer,’’
‘‘plan,’’ and ‘‘issuer’’ in this final rule.
Certain portions of this final rule are
applicable to the Medicare Fee-forService (FFS) Program, the Medicaid
FFS Program, the CHIP FFS program,
Medicare Advantage (MA)
7 See OCR guidance regarding personal
representatives at https://www.hhs.gov/hipaa/forprofessionals/faq/2069/under-hipaa-when-can-afamily-member/.
PO 00000
Frm 00006
Fmt 4701
Sfmt 4700
organizations, Medicaid Managed Care
plans (managed care organizations
(MCOs), prepaid inpatient health plans
(PIHPs), and prepaid ambulatory health
plans (PAHPs)), CHIP Managed Care
entities (MCOs, PIHPs, and PAHPs), and
QHP issuers on the FFEs. We use the
term ‘‘payer’’ in the preamble of this
final rule as an inclusive term for all
these programs (and plan types in the
case of plans), but we also use specific
terms as applicable in sections of this
final rule. Finally, we use the term
‘‘provider,’’ too, as an inclusive term
comprising individuals, organizations,
and institutions that provide health
services, such as clinicians, hospitals,
skilled nursing facilities, home health
agencies, hospice settings, laboratories,
suppliers of durable medical equipment,
community based organizations, etc., as
appropriate in the context used.
II. Technical Standards Related to
Interoperability Provisions, and
Analysis of and Responses to Public
Comments
A. Technical Approach and Standards
1. Use of Health Level 7® (HL7) Fast
Healthcare Interoperability Resources®
(FHIR) for APIs
Section 106(b)(1)(B)(ii) of the
Medicare Access and CHIP
Reauthorization Act of 2015 (MACRA)
defines health IT ‘‘interoperability’’ as
the ability of two or more health
information systems or components to
exchange clinical and other information
and to use the information that has been
exchanged using common standards to
provide access to longitudinal
information for health care providers in
order to facilitate coordinated care and
improved patient outcomes.
Interoperability is also defined in
section 3000 of the Public Health
Service Act (PHSA) (42 U.S.C. 300jj), as
amended by section 4003 of the 21st
Century Cures Act. Under that
definition, ‘‘interoperability,’’ with
respect to health IT, means such health
IT that enables the secure exchange of
electronic health information with, and
use of electronic health information
from, other health IT without special
effort on the part of the user; allows for
complete access, exchange, and use of
all electronically accessible health
information for authorized use under
applicable state or federal law; and does
not constitute information blocking as
defined in section 3022(a) of the PHSA,
which was added by section 4004 of the
Cures Act. We believe the PHSA
definition is consistent with the
MACRA definition of ‘‘interoperability’’.
Consistent with the CMS
Interoperability and Patient Access
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
proposed rule (84 FR 7619), we will use
the PHSA definition of
‘‘interoperability’’ for the purposes of
this final rule.
We believe the PHSA definition of
‘‘interoperability’’ is useful as a
foundational reference for our approach
to advancing the interoperability and
exchange of electronic health
information for individuals throughout
the United States, and across the entire
spectrum of provider types and care
settings with which health insurance
issuers and administrators need to
efficiently exchange multiple types of
relevant data. We noted the PHSA
definition of ‘‘interoperability’’ is not
limited to a specific program or
initiative, but rather can be applied to
all activities under the title of the PHSA
that establishes ONC’s responsibilities
to support and shape the health
information ecosystem, including the
exchange infrastructure for the U.S.
health care system as a whole. The
PHSA definition is also consistent with
HHS’s vision and strategy for achieving
a health information ecosystem within
which all individuals, their personal
representatives, their health care
providers, and their payers are able to
send, receive, find, and use electronic
health information in a manner that is
appropriate, secure, timely, and reliable
to support the health and wellness of
individuals through informed, shared
decision-making,8 as well as to support
consumer choice of payers and
providers.
We summarize the public comment
we received on use of the PHSA
definition of ‘‘interoperability’’ and
provide our response.
Comment: One commenter
specifically supported the use of the
PHSA definition of ‘‘interoperability’’.
Response: We appreciate the
commenter’s support.
A core policy principle we aim to
support across all policies in this rule is
that every American should be able,
without special effort or advanced
technical skills, to see, obtain, and use
all electronically available information
that is relevant to their health, care, and
choices—of plans, providers, and
specific treatment options. In the
proposed rule, we explained this
included two types of information:
personal health information that health
care providers and health plans, or
payers, must make available to an
8 See, for example, Office of the National
Coordinator. (2015). Connecting Health and Care for
the Nation: A Shared Nationwide Interoperability
Roadmap, Final Version 1.0. Retrieved from https://
www.healthit.gov/sites/default/files/hieinteroperability/nationwide-interoperabilityroadmap-final-version-1.0.pdf.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
individual, such as their current and
past medical conditions and care
received; and information that is of
general interest and should be widely
available, such as plan provider
networks, the plan’s formulary, and
coverage policies (84 FR 7619).
We also discussed that while many
consumers today can often access their
own electronic health information
through patient or enrollee portals and
proprietary applications made available
by various providers and health plans,
they must typically go through separate
processes to obtain access to each
system, and often need to manually
aggregate information that is delivered
in various, often non-standardized,
formats. The complex tasks of accessing
and piecing together this information
can be burdensome and frustrating to
consumers.
An API can be thought of as a set of
commands, functions, protocols, or
tools published by one software
developer (‘‘A’’) that enable 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, all while maintaining
consumer privacy data standards.9 This
is how API technology enables the
seamless user experiences associated
with applications familiar from other
aspects of many consumers’ daily lives,
such as travel and personal finance.
Standardized, transparent, and procompetitive API technology can enable
similar benefits to consumers of health
care services.10
While acknowledging the limits of our
authority to require use of APIs to
address our goals for interoperability
and data access, we proposed to use our
programmatic authority to require that a
variety of data be made accessible by
requiring that MA organizations,
Medicaid state agencies, Medicaid
managed care plans, CHIP agencies,
CHIP managed care entities, and QHP
issuers on the FFEs, adopt and
implement ‘‘openly published,’’ or
secure, standards-based APIs. In the
CMS Interoperability and Patient Access
proposed rule, we used the short form
terminology, ‘‘open API’’. We appreciate
that this term can be misunderstood to
mean ‘‘open’’ as in ‘‘not secure’’. In
9 See https://www.hl7.org/fhir/security.html for
information on how FHIR servers and resources
integrate privacy and security protocols into the
data exchange via an API.
10 ONC has made available a succinct, nontechnical overview of APIs in context of consumers’
access to their own medical information across
multiple providers’ EHR systems, which is available
at the HealthIT.gov website at https://
www.healthit.gov/api-education-module/story_
html5.html.
PO 00000
Frm 00007
Fmt 4701
Sfmt 4700
25515
actuality, an ‘‘open API’’ is a secure,
standards-based API that has certain
technical information openly published
to facilitate uniform use and data
sharing in a secure, standardized way.
To avoid this misinterpretation, we will
use the term ‘‘standards-based API’’ in
this final rule where we used ‘‘open
API’’ in the proposed rule. This is also
in better alignment with the terminology
used in the ONC 21st Century Cures Act
proposed rule (84 FR 7453) and final
rule (published elsewhere in this issue
of the Federal Register). We noted that
having certain data available through
standards-based APIs would allow
impacted enrollees to use the
application of their choice to access and
use their own electronic health
information and other related
information to manage their health. See
section III.C.2.a. of the CMS
Interoperability and Patient Access
proposed rule for further discussion (84
FR 7629).
Much like our efforts under Medicare
Blue Button 2.0, also part of the
MyHealthEData initiative, which made
Parts A, B, and D claims and encounter
data available via an API to Medicare
beneficiaries, the policies in this rule
extend these benefits to even more
patients. As of January 2020, over
53,000 Medicare beneficiaries have
taken advantage of Blue Button.
Currently, there are 55 production
applications and over 2,500 developers
working in the Blue Button sandbox.
For more information on Blue Button
2.0 see section III. of this final rule. As
we noted in the CMS Interoperability
and Patient Access proposed rule, we
believe that our Patient Access API, in
particular, will result in claims and
encounter information becoming easily
accessible for the vast majority of
patients enrolled with payers regulated
by CMS. As finalized, these policies will
apply to all MA organizations, all
Medicaid and CHIP FFS programs, all
types of Medicaid managed care plans
(MCOs, PIHPs, and PAHPs), as well as
CHIP managed care entities, and QHP
issuers on the FFEs. We hope that states
operating Exchanges might consider
adopting similar requirements for QHPs
on the State-Based Exchanges (SBEs),
and that other payers in the private
sector might consider voluntarily
offering data accessibility of the type
included in the policies being finalized
here so that even more patients across
the American health care system can
easily have and use such information to
advance their choice and participation
in their health care. In this way, we
hope that the example being set by CMS
will raise consumers’ expectations and
E:\FR\FM\01MYR2.SGM
01MYR2
25516
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
encourage other payers in the market to
take similar steps to advance patient
access and empowerment outside the
scope of the requirements being
finalized in this rule.
We explained in the CMS
Interoperability and Patient Access
proposed rule (84 FR 7620) that those
seeking further information regarding
what a standards-based API is are
encouraged to review the discussion of
the standardized API criterion and
associated policy principles and
technical standards included in ONC’s
21st Century Cures Act proposed rule
(84 FR 7424) and final rule (published
elsewhere in this issue of the Federal
Register). These rules provide more
detailed information on API
functionality and interoperability
standards relevant to electronic health
information. We noted that while that
discussion was specific to health IT,
including Electronic Health Records
(EHR) systems, certified under ONC’s
Health IT Certification Program rather
than the information systems generally
used by payers and plan issuers for
claims, encounters, or other
administrative or plan operational data,
it included information applicable to
interoperability standards, as well as
considerations relevant to establishing
reasonable and non-discriminatory
terms of service for applications seeking
to connect to the standards-based API
discussed in this rule. While we
reiterate that we did not propose to
require payers to use Health IT Modules
certified under ONC’s program to make
administrative data such as claims
history or provider directory
information available to enrollees, we
believe that the discussion of APIs and
related standards in the ONC 21st
Century Cures Act rules will be of use
to those seeking to better understand the
role of APIs in health care information
exchange.
We also discussed in our proposed
rule how other industries have
advanced the sort of standards-based
API-driven interoperability and
innovation that we seek in the health
system (84 FR 7620). We have sought to
collaborate and align with ONC’s
proposed and final policies specifically
related to APIs under the Cures Act as
we developed and finalized these
policies. In general, as we noted in our
proposed rule, we believe the following
three attributes of standards-based APIs
are particularly important to achieving
the goal of offering individuals
convenient access, through applications
they choose, to available and relevant
electronic health and health-related
information:
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
• The API technologies themselves,
not just the data accessible through
them, are standardized;
• The APIs are technically
transparent; and
• The APIs are implemented in a procompetitive manner.
In that section of the CMS
Interoperability and Patient Access
proposed rule, we discussed these
concepts generally and how they were
applicable in the health care context for
all payers, and explained how these
were relevant to our specific proposals,
which are discussed in detail in section
III. of this final rule. To revisit this full
discussion, see the proposed rule (84 FR
7620 through 7621). We did not receive
comments on this general discussion.
Any comments on specific proposals
that refer to these three attributes are
discussed in this final rule in the
context of the specific proposals.
2. Privacy and Security Concerns in the
Context of APIs
As we noted in the CMS
Interoperability and Patient Access
proposed rule, HHS has received a wide
range of stakeholder feedback on
privacy and security issues in response
to prior proposals 11 about policies
related to APIs that would allow
consumers to use an app of their
choosing to access protected health
information (PHI) held by or on behalf
of a HIPAA covered entity. Such
feedback included concerns about
potential security risks to PHI created by
an API connecting to third-party
applications and the implications of an
individual’s data being shared with
these third-party apps at the direction of
the individual.
As we discussed in our
Interoperability and Patient Access
proposed rule (84 FR 7621), deploying
API technology would offer consumers
the opportunity to access their
electronic health information held by
covered entities (including, but not
limited to MA organizations, the
Medicare Part A and B programs, the
Medicaid program, CHIP, QHP issuers
on the FFEs, and other health insurance
issuers in the private markets), and
would not lessen any such covered
entity’s duties under HIPAA and other
laws to protect the privacy and security
of information it creates, receives,
maintains, or transmits, including but
not limited to PHI. A covered entity
implementing an API to enable
individuals to access their health
information must take reasonable steps
11 For instance, see discussion of stakeholder
comments in the 2015 Edition final rule at 80 FR
62676.
PO 00000
Frm 00008
Fmt 4701
Sfmt 4700
to ensure an individual’s information is
only disclosed as permitted or required
by applicable law. The entity must take
greater care in configuring and
maintaining the security functionalities
of the API and the covered entities’
electronic information systems to which
it connects than would be needed if it
was implementing an API simply to
allow easier access to widely available
public information. In accordance with
the HIPAA Privacy and Security Rules,
the covered entity is required to
implement reasonable safeguards to
protect PHI while in transit. If an
individual requests their PHI in an EHR
be sent to the third party by
unencrypted email or in another
unsecure manner, which the individual
has a right to request, reasonable
safeguards could include, for example,
carefully checking the individual’s
email address for accuracy and warning
the individual of risks associated with
the unsecure transmission. We note that
the standards-based APIs discussed in
this final rule are secure methods of
data exchange.
HIPAA covered entities and their
business associates continue to be
responsible for compliance with the
HIPAA Rules, the Federal Trade
Commission Act (FTC Act), and all
other laws applicable to their business
activities including but not limited to
their handling of enrollees’ PHI and
other data. As we stated in the CMS
Interoperability and Patient Access
proposed rule (84 FR 7610), nothing
proposed in that rule was intended to
alter or should be construed as altering
existing responsibilities to protect PHI
under the HIPAA Rules or any other
laws that are currently applicable.
However, we acknowledged that a
number of industry stakeholders may
mistakenly believe that they are
responsible for determining whether an
application to which an individual
directs their PHI employs appropriate
safeguards regarding the information it
receives. In the proposed rule we
discussed Office for Civil Rights (OCR)
guidance that noted that covered
entities are not responsible under the
HIPAA Rules for the security of PHI
once it has been received by a thirdparty application chosen by an
individual (84 FR 7621 through 7622).
Further, we noted in the CMS
Interoperability and Patient Access
proposed rule that the HIPAA Privacy
Rule 12 established the individual’s right
of access, including a right to inspect
12 More information on the Privacy Rule,
including related rulemaking actions and additional
interpretive guidance, is available at https://
www.hhs.gov/hipaa/for-professionals/privacy/
index.html.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
and/or receive a copy of PHI held in
designated record sets by covered
entities and their business associates as
detailed at 45 CFR 164.524. We
specifically noted in the proposed rule
that OCR had indicated in regulations
and guidance, that an individual could
exercise their right of access by
requesting that their information be sent
to a third party.13
As we also noted in the proposed rule
(84 FR 7622), we are aware of
stakeholder concerns about which
protections apply to non-covered
entities, such as direct-to-consumer
applications. As we explained in the
proposed rule, when a non–covered
entity discloses an individual’s
confidential information in a manner or
for a purpose not consistent with the
privacy notice and terms of use to
which the individual agreed, the FTC
has authority under section 5 of the FTC
Act (15 U.S.C. Sec. 45(a)) to investigate
and take action against unfair or
deceptive trade practices. The FTC has
applied this authority to a wide variety
of entities.14 The FTC also enforces the
FTC Health Breach Notification Rule,
which applies to certain types of
entities, including vendors of personal
health records and third-party service
providers, that fall outside of the scope
of HIPAA, and therefore, are not subject
to the HIPAA Breach Notification
Rule.15 This FTC Health Breach
Notification Rule explains the process
and steps third parties must follow
when they discover a breach of
identifiable personal health record
information they maintain. Any
violation of this Rule is enforced by the
FTC as an unfair or deceptive act or
practice under the FTC Act.
We recognized that this is a complex
landscape for patients, who we
anticipate will want to exercise due
diligence on their own behalf in
reviewing the terms of service and other
information about the applications they
consider selecting. Therefore, we
proposed specific requirements on
payers to ensure enrollees have the
13 See 45 CFR 164.524(c)(2) and (3), and
164.308(a)(1), OCR HIPAA Guidance/FAQ–2036:
https://www.hhs.gov/hipaa/for-professionals/faq/
2036/can-an-individual-through-the-hipaa-right/
index.html, and OCR HIPAA Guidance/FAQ–2037:
https://www.hhs.gov/hipaa/for-professionals/faq/
2037/are-there-any-limits-or-exceptions-to-theindividuals-right/.
14 See also cases where this authority was used,
such as 2012 FTC action against Facebook (see
https://www.ftc.gov/enforcement/casesproceedings/092-3184/facebook-inc) and 2012 FTC
action against MySpace (see https://www.ftc.gov/
enforcement/cases-proceedings/102-3058/myspacellc-matter).
15 See 16 CFR part 318; see also https://
www.healthit.gov/sites/default/files/non-covered_
entities_report_june_17_2016.pdf.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
opportunity to become more informed
about how to protect their PHI,
important things to consider in selecting
an application, and where they can
submit a complaint if they believe a
HIPAA covered entity or business
associate may not be in compliance with
their duties under the HIPAA Rules, or
if they believe they have been subjected
to unfair or deceptive acts or practices
related to a direct-to-consumer
application’s privacy practices or terms
of use. A full discussion of the Enrollee
and Beneficiary Resources Regarding
Privacy and Security provision can be
found in section III.C.2.h. of this final
rule.
In some circumstances, we noted that
the information that we proposed to
require be made available through an
API per a patient’s request, under the
various program-specific authorities
authorizing this rulemaking, were also
consistent with the enrollee’s right of
access for their data held by a covered
entity or their business associate under
the HIPAA Privacy Rule. But we also
noted that some data to which an
individual is entitled to access under
HIPAA may not be required to be
transferred through the API. For
instance, when the covered entity does
not hold certain information
electronically. In those instances, we
noted that the inability to access data
via an API would in no way limit or
alter responsibilities and requirements
under other law (including though not
limited to the HIPAA Privacy, Security,
and Breach Notification Rules) that
apply to the organizations that would be
subject to this regulation. Even as these
requirements are finalized, the
organization may still be called upon to
respond to individuals’ request for
information not available through the
API, or for all of their information
through means other than the API. We
encouraged HIPAA covered entities and
business associates to review the OCR
website for resources on the individual
access standard at https://www.hhs.gov/
hipaa/for-professionals/privacy/
guidance/access/ to ensure
they understand their responsibilities.
We again encourage HIPAA covered
entities and business associates to
review their responsibilities under
HIPAA in light of the recent decision in
Ciox Health, LLC v. Azar, et al., No. 18cv-0040 (D.D.C. January 23, 2020).16 The
court order vacates a portion of the
HIPAA Privacy Rule related to the
individual right of access ‘‘insofar as it
expands the HITECH Act’s third-party
directive beyond requests for a copy of
16 See,
https://ecf.dcd.uscourts.gov/cgi-bin/show_
public_doc?2018cv0040-51.
PO 00000
Frm 00009
Fmt 4701
Sfmt 4700
25517
an electronic health record with respect
to [protected health information] of an
individual . . . in an electronic
format.’’ 17 Generally, the court order
vacates a portion of the HIPAA Privacy
Rule that provides an individual the
right to direct a covered entity to send
protected health information that is not
in an EHR to a third party identified by
the individual.
This decision does not affect CMS’
programmatic authorities, as discussed
in detail in section III. of the CMS
Interoperability and Patient Access
proposed rule (83 FR 7629 through
7630) and section III. of this final rule,
to propose and finalize the Patient
Access API for the programs specified.
Additionally, the court’s decision did
not alter individuals’ right under HIPAA
to request and obtain a copy of their
records. Because the goal of the Patient
Access API in our programs is to give
patients access to their own information
for their own personal use through a
third-party app, we believe these
policies as adopted in this rule remain
consistent with the spirit of access
rights under HIPAA.
As discussed in detail below, many
commenters discussed the issues of
privacy and security in regard to
information made available to thirdparty applications. Here, we summarize
the public comments we received on
general issues and concerns around
privacy and security of a standardsbased API, and provide our responses.
Comment: A few commenters
supported OCR’s efforts to more clearly
account for use cases, or specific
situations, in which apps are used to
exchange patients’ electronic health
information. Some commenters noted
support for OCR’s FAQ that specifies
that covered entities are not responsible
or liable for the privacy and security of
PHI once it is transmitted at the
individual’s direction to and received
by a third-party application. One
commenter expressed concern that CMS
and ONC proposed requirements would
make the safeguards of HIPAA moot if
HIPAA is not extended to third-party
applications that are able under this rule
to display patient data. Without
extending HIPAA, the commenter fears
payers and providers will be liable if the
third-party misuses patient data.
Response: We appreciate the
commenters’ support. We reiterate that
HIPAA covered entities and business
associates are responsible for meeting
their HIPAA privacy and security
obligations to protect patient data they
17 See, https://hds.sharecare.com/wp-content/
uploads/2020/01/CiOX-Health-v.-HHS-Court-Order3-24-2020.pdf.
E:\FR\FM\01MYR2.SGM
01MYR2
25518
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
maintain, and absent patient requests to
the contrary, are obligated to take
reasonable measures to protect these
data in transit. Once these data are
transmitted and no longer under the
control of the covered entity or business
associate, those entities no longer have
any obligations under HIPAA for the
privacy and security of the PHI, because
these data are no longer subject to
HIPAA. We stress, as discussed in the
CMS Interoperability and Patient Access
proposed rule, nothing in this rule alters
covered entities’ or business associates’
responsibilities to protect PHI under the
HIPAA Privacy and Security Rules.
The only instance per the policies
proposed in this rule that would allow
a payer to deny access to an app, as
discussed in the proposed rule and
underlying the rationale for finalizing
42 CFR 422.119(e), 431.60(e),
438.242(b)(6) (redesignated as
§ 438.242(b)(5) see section VI. in this
rule), 457.730(e), 457.1233(d)(2), and 45
CFR 156.221(e), would be if the covered
entity or its business associate’s own
systems would be endangered if it were
to engage with a specific third-party
application through an API, for instance
if allowing such access would result in
an unacceptable security risk. Therefore,
as we also noted, covered entities and
business associates are free to offer
advice to patients on the potential risks
involved with requesting data transfers
to an application or entity not covered
by HIPAA, but such efforts generally
must stop at education and awareness or
advice regarding concerns related to a
specific app. For instance, if a payer
notes that an app a patient requests
receive their data does not lay out in its
privacy policy specifically how the
patient’s personal data will be used, the
payer could choose to inform the patient
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 these 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
section III.C.2.g. of this final rule. The
requirements finalized in this rule do
not impact or change obligations under
the HIPAA Privacy and Security Rules
in any way.
Comment: A few commenters noted
discrepancies in the terminology used
in the OCR FAQ mentioned in the CMS
Interoperability and Patient Access
proposed rule compared to terminology
used throughout the CMS
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Interoperability and Patient Access
proposed rule and the ONC 21st
Century Cures Act proposed rule, and
suggested that any terminology
inconsistencies be addressed and
harmonized. These commenters noted
that the OCR FAQ pertains to
‘‘electronic protected health
information’’ (ePHI), and uses the term
‘‘electronic health record (EHR) system
developer’’, which differs from terms
used in the CMS Interoperability and
Patient Access and the ONC 21st
Century Cures Act proposed rules.
Response: We appreciate comments
regarding variance in the terminology
used in OCR guidance and the CMS
Interoperability and Patient Access
proposed rule. Regarding the
relationship between ePHI and
electronic health information (EHI), we
refer readers to the discussion in the
ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register). OCR guidance uses
the term ‘‘electronic health record
system developer’’ 18 to refer to a health
IT developer that develops and
maintains electronic health record
systems containing PHI for a covered
entity, and therefore is a business
associate of those covered entities. The
guidance also uses ‘‘app developer’’ to
describe the creator of the app that is
designated to receive an individual’s
PHI. ONC uses related terms that have
a specific meaning within the context of
ONC programs. For instance, ONC uses
the term ‘‘health IT developer’’ for the
purposes of the ONC Health IT
Certification Program to refer to a
vendor, self-developer, or other entity
that presents health IT for certification
or has health IT certified under the
program. In addition, the ONC 21st
Century Cures Act proposed rule
proposed to define the term ‘‘health IT
developer of certified health IT’’ for the
purposes of implementing provisions of
the Cures Act (84 FR 7510). We do not
use these ONC program-specific terms
in this CMS rule. We simply refer to any
developer of a third-party app, of which
an electronic record systems developer
may be one.
Comment: One commenter requested
clarification on a covered entity’s
liability under HIPAA if a patient
transfers their health information from a
covered entity’s mobile access portal or
application to a third-party application
not covered under HIPAA.
Response: As noted above, HIPAA
covered entities and business associates
18 See Office of the National Coordinator. (n.d.).
Health Information Technology. Retrieved from
https://www.hhs.gov/hipaa/for-professionals/faq/
health-information-technology/.
PO 00000
Frm 00010
Fmt 4701
Sfmt 4700
are responsible for meeting their HIPAA
privacy and security obligations to
protect patient data they maintain, and
absent patient requests to the contrary,
are obligated to take reasonable
measures to protect these data in transit.
Once these data are received by a thirdparty and no longer under the control of
the covered entity or its business
associate, the covered entity and
business associate are not liable for the
privacy and security of the PHI or any
electronic health information sent.
While HIPAA covered entities and their
business associates may notify patients
of their potential concerns regarding
exchanging data with a specific thirdparty not covered by HIPAA, they are
not required to do so, and they may not
substitute their own judgment for that of
the patient requesting the data be
transferred.
Comment: Several commenters
recommended that CMS include a safe
harbor provision in the regulatory text
of this final rule to indicate that plans
and providers are not responsible for the
downstream privacy and security of
PHI.
Response: Regarding commenters’
interest in a ‘‘safe harbor’’ provision for
covered entities when data is
transmitted to a third-party app, we do
not have the authority, nor do we
believe it is necessary, to incorporate
these principles in a safe harbor
provision under the HIPAA Privacy and
Security Rules. Covered entities and
business associates are not responsible
for the data after the data have been
received by the intended recipient. This
has been taken into account in
developing the requirements for the
Patient Access API.
Comment: Several commenters
expressed concerns that app developers
are not subject to many of the current
laws protecting the privacy and security
of electronic health information. Several
commenters requested that HHS specify
what requirements non-HIPAA covered
app developers will be subject to.
Response: We appreciate the
commenters’ concerns. As discussed in
the CMS Interoperability and Patient
Access proposed rule (84 FR 7622),
HIPAA protections do not extend to
third-party apps (that is, software
applications from entities that are not
covered entities or business associates).
However, the FTC has the authority to
investigate and take action against
unfair or deceptive trade practices
under the FTC Act and the FTC Health
Breach Notification Rule when a thirdparty app does not adhere to the stated
privacy policy. We have shared these
comments with the FTC. State laws may
provide additional protections as well.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Although CMS cannot regulate the
third-party apps directly, and thus
cannot establish specific requirements
for them, we are sharing best practices
and lessons learned from our experience
with Blue Button 2.0, as applicable,
with app developers to further support
strong privacy and security practices:
https://www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. Also, as previously noted, payers
will be required to share educational
resources with patients regarding how
to choose a third-party application
while protecting their health
information. Further, as discussed in
section III. of this final rule, we are
providing payers with a framework they
can use to request that third-party apps
attest to covering certain criteria in their
privacy policy, such as information
about secondary data use, which payers
can use to educate patients about their
options.
In addition, there are technical
requirements for APIs defined in the
ONC 21st Century Cures Act proposed
rule, and finalized by HHS in ONC’s
final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR
170.215, that enable and support
persistent user authentication and app
authorization processes. It is important
to clarify that any app accessing the
Patient Access API would be doing so
only with the approval and at the
direction of the specific patient. While
these technical standards at 45 CFR
170.215 establish the requirements for
the API itself, when implemented, these
technical standards in turn set
requirements on the app developer for
the app’s identity proofing and
authentication processes that must be
met in order to connect to the API and
access the specific patient’s data
through the API, as further discussed in
section III. of this final rule. These
technical requirements do not, however,
address concerns around data security
and use once data are with the thirdparty. This level of privacy and security
would be addressed in the app’s terms
and conditions or privacy notice.
Comment: Many commenters
expressed concern regarding the
secondary use of health information by
business partners of third-party
applications. A few commenters noted
that consumers may not always be
aware of the business partners of thirdparty apps, especially as this
information is typically part of a lengthy
privacy notice or dense or difficult to
understand terms and conditions.
Response: We appreciate the
commenters’ concerns. As noted, we do
not have the authority to directly
regulate third-party apps. As a result,
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
we cannot dictate how an app uses or
shares data. We have chosen to require
payers to educate patients about how to
choose a third-party app that best
mitigates potentially risks related to
secondary data uses. One way we will
address these concerns is to offer payers
and app developers best practices from
our own experiences using a patientcentered privacy policy, particularly
related to Blue Button 2.0. As we
discuss in section III.C.2.h. of this final
rule, we recognize that the payers that
will be subject to the API provisions of
this final rule are in the best position to
ensure that patients have the
information that they need to critically
assess the privacy and security of their
designated third-party options, and may
be best situated to identify for patients
the potential implications of sharing
data and to advise a patient if there is
a breach of their data. This is why we
proposed and are finalizing a
requirement at 42 CFR 422.119(g),
431.60(f), 457.730(f), 438.242(b)(5)
(proposed as § 438.242(b)(6) see section
VI. in this rule), and 457.1233(d)(2), and
45 CFR 156.221(g), detailing the
beneficiary and enrollee resources
regarding consumer-friendly, patient
facing privacy and security information
that must be made available on the
websites of the payers subject to this
final rule. As discussed in greater detail
in section III.C.2.h. of this final rule,
CMS will be providing payers with
suggested content they can consult and
tailor as they work to produce the
required patient resource document. We
are also sharing best practices and links
to model language of an easy-tounderstand, non-technical, consumerfriendly privacy policy, again building
off of our lessons learned with Blue
Button 2.0, to support payers and
developers in this effort: https://
www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. Also, as noted above, we discuss
in section III. of this final rule, a
framework payers can use to request
that third-party apps attest to covering
certain criteria in their privacy policy,
such as information about secondary
data use. It will be important to
encourage patients’ understanding of
app privacy policies, including
secondary use policies. The policies we
are finalizing in this rule help us
support payers and developers as they
work to make sure patients are informed
consumers through education and
awareness, and that patients understand
their rights.
Comment: Several commenters
expressed concerns over the complexity
of overlapping federal and state privacy
PO 00000
Frm 00011
Fmt 4701
Sfmt 4700
25519
laws, which they noted would be
perpetuated by uncertainty in privacy
and security requirements when apps
become more widely used in the health
care space. These commenters requested
work be done to harmonize state and
federal privacy laws. Another
commenter recommended that Congress
enact comprehensive consumer privacy
protections.
Response: We appreciate these
commenters’ concerns and
recommendations. However, these
comments are beyond the scope of this
regulation.
Comment: Several commenters
recommended that CMS work closely
with other HHS agencies and the FTC to
establish a transparent regulatory
framework for safeguarding the privacy
and security of patient electronic health
information shared with apps. A few
commenters recommended CMS
establish workgroups to share
experiences and technical assistance for
implementing privacy and security
approaches.
Response: We appreciate the
commenters’ suggestions. As noted
above, we have shared commenter’s
concerns with the FTC and relevant
HHS Operating Divisions, such as OCR.
3. Specific Technical Approach and
Standards
Achieving interoperability throughout
the health system is essential to
achieving an effective, value-conscious
health system within which consumers
are able to choose from an array of
health plans and providers. An
interoperable system should ensure that
consumers can both easily access their
electronic health information held by
plans and routinely expect that their
claims, encounter, and other relevant
health history information will follow
them smoothly from plan to plan and
provider to provider without
burdensome requirements for them or
their providers to reassemble or redocument the information. Ready
availability of health information can be
especially helpful when an individual
cannot access their usual source of care,
for instance if care is needed outside
their regular provider’s business hours,
while traveling, or in the wake of a
natural disaster.
The proposals described in section
III.C.2. of the CMS Interoperability and
Patient Access proposed rule (84 FR
7628 through 7639) would impose new
requirements on MA organizations,
Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs (excluding issuers offering
only SADPs or issuers in the FF–SHOP,
E:\FR\FM\01MYR2.SGM
01MYR2
25520
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
unless otherwise noted) to implement
standardized, transparent APIs. Using
the API, these entities would be
required to provide current enrollees
with specified claims and encounter
data and certain clinical information if
such information is maintained. We
proposed that these entities would also
be required to make available through
the API information already required to
be widely available, including provider
directory and plan coverage
information, such as formulary
information. In developing the proposal
delineating the information that would
be required to be made available
through an API, consistent with the
proposed technical requirements, we
were guided by an intent to have
available through the API all of the
individual’s electronic health
information held by the payer in
electronic format that is compatible
with the API or that can, through
automated means, be formatted to be
accurately rendered through the API.
We were also guided by an intent to
make available through standardized,
secure API technology all of the
provider directory and formulary
information maintained by the impacted
payers that can be made compatible
with the API.
Both the API technology itself and the
data it makes available must be
standardized to support true
interoperability. Therefore, as discussed
in detail in the proposed rule, we
proposed to require compliance with
both (1) ONC’s 21st Century Cures Act
rule proposed regulations regarding
content and vocabulary standards for
representing electronic health
information as finalized and (2)
technical standards for an API by which
the electronic health information would
be required to be made available as
finalized. For the proposals described in
section III.C.2.b. of the CMS
Interoperability and Patient Access
proposed rule (which addressed
transmissions for purposes other than
those covered by HIPAA transaction
standards, with which all the payers
subject to this final rule will continue to
be required to comply under 45 CFR
part 162), we proposed requiring
compliance with the interoperability
standards proposed for HHS adoption in
the ONC 21st Century Cures Act
proposed rule (84 FR 7424) as finalized.
In proposing to require that regulated
entities comply with ONC-proposed
regulations for non-HIPAA covered
transactions (84 FR 7424) and therefore,
requiring the use of specified standards,
we noted that we intended to preclude
regulated entities from implementing
API technology using alternative
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
technical standards to those ONC
proposed for HHS adoption at 45 CFR
170.215, which details the API technical
standards, including the use of FHIR.
Other technical standards that would be
precluded include, but are not limited
to, those not widely used to exchange
electronic health information in the U.S.
health system. We further noted that we
intended to preclude entities from using
earlier versions of the technical
standards adopted at 45 CFR 170.215 by
requiring compliance with only
specified provisions of 45 CFR part 170,
and deliberately excluding others. We
also discussed how by proposing to
require use of the proposed content and
vocabulary standards as finalized by
requiring compliance with 42 CFR
423.160 and 45 CFR part 162, and
proposed at 45 CFR 170.213, we
intended to prohibit use of alternative
standards that could potentially be used
for these same data classes and
elements, as well as earlier versions of
the adopted standards named in 42 CFR
423.160, 45 CFR part 162, and proposed
at 45 CFR 170.213.
While we generally intended to
preclude regulated entities from using
content and vocabulary standards other
than those described in 42 CFR 423.160,
45 CFR part 162, or proposed 45 CFR
170.213 (and technical standards at 45
CFR 170.215), we recognized there may
be circumstances that render the use of
other content and vocabulary
alternatives necessary. As discussed
below, we proposed to allow the use of
alternative content and vocabulary
standards in two circumstances. First,
where other content or vocabulary
standards are expressly mandated by
applicable law, we proposed to permit
use of those other mandated standards.
Second, where no appropriate content
or vocabulary standard exists within 45
CFR part 162, 42 CFR 423.160, or
proposed 45 CFR 170.213 and 170.215,
we proposed we would permit use of
any suitable gap-filling options, as may
be applicable to the specific situation.
We used two separate rulemakings
because the 21st Century Cures Act
proposed rule (84 FR 7424), which
included API interoperability standards
proposed for HHS adoption, would have
broader reach than the scope of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7610). At the same
time, we wished to assure stakeholders
that the API standards required of MA
organizations, state Medicaid agencies,
state CHIP agencies, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs under the
proposal would be consistent with the
API standards proposed by ONC for
HHS adoption because we would
PO 00000
Frm 00012
Fmt 4701
Sfmt 4700
require that the regulated entities follow
specified, applicable provisions of the
ONC-proposed requirements as
finalized.
Requiring that CMS-regulated entities
comply with the regulations regarding
standards finalized by HHS in ONC’s
21st Century Cures Act rule will support
greater interoperability across the health
care system, as health IT products and
applications that would be developed
for different settings and use cases
would be developed according to a
consistent base of standards that
supports more seamless exchange of
information. In the CMS Interoperability
and Patient Access proposed rule, we
welcomed public comment on our
proposal to require compliance with the
standards proposed for adoption by
HHS through ONC’s 21st Century Cures
Act proposed rule, as well as on the best
method to provide support in
identifying and implementing the
applicable content and vocabulary
standards for a given data element.
Finally, while noting that we believed
that the proposal to require compliance
with the standards proposed by ONC for
HHS adoption was the best approach,
we sought public comment on any
alternative by which CMS would
separately adopt the standards proposed
for adoption in the ONC 21st Century
Cures Act proposed rule and identified
throughout the CMS Interoperability
and Patient Access proposed rule, as
well as future interoperability, content,
and vocabulary standards. We stated
that we anticipated any alternative
would include incorporating by
reference the FHIR R2, R3, and/or R4
based on comments and OAuth 2.0
technical standards and the USCDI
version 1 content and vocabulary
standard (described in sections II.A.3.b.
and II.A.3.a. of the CMS Interoperability
and Patient Access proposed rule,
respectively) in CMS regulation to
replace the proposed references to ONC
regulations at 45 CFR 170.215, 170.213,
and 170.205, respectively. However, we
specifically sought comment on whether
this alternative would present an
unacceptable risk of creating multiple
regulations requiring standards or
versions of standards across HHS’
programs, and an assessment of the
benefits or burdens of separately
adopting new standards and
incorporating updated versions of
standards in CFR text on a program by
program basis. Furthermore, we sought
comment on: How such an option might
impact health IT development
timelines; how potentially creating
multiple regulations regarding standards
over time across HHS might impact
system implementation; and other
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
factors related to the technical aspect of
implementing these requirements.
We summarize the public comments
we received regarding separately
adopting standards in this CMS rule and
provide our responses.
Comment: Many commenters
supported CMS’ proposed alignment
with the standards proposed in ONC’s
21st Century Cures Act proposed rule to
be adopted by HHS to promote
interoperability, noting it was the most
effective and efficient approach.
Commenters explained that this
alignment was critical to ensure
interoperability across the health care
industry, and overwhelmingly preferred
‘‘one source of truth’’ for all standards
referenced in the CMS Interoperability
and Patient Access proposed rule. These
commenters explained having highly
technical standards, including content
and vocabulary standards, in different
CMS and ONC regulations would create
the potential for error and misalignment
of standards or versions of standards
across HHS programs. Commenters
supported alignment across agencies,
and indicated concern that if the
standards were adopted in different
regulations, it would complicate the
process of updating the standards when
necessary, and increase the cost and
burden of data capture, data
management, and data exchange.
Commenters did note opportunities for
even greater alignment across the CMS
and ONC rulemakings at the data
element level, indicating that the ONC
rule should include all data elements
required in the CMS rule, specifically
calling out data elements in an
Explanation of Benefits (EOB) not
specifically included in the USCDI
(proposed for codification at 45 CFR
170.213).
Response: We appreciate the
commenters’ support for alignment of
the regulations adopted in this final rule
with the standards as finalized by HHS
in the ONC 21st Century Cures Act final
rule (published elsewhere in this issue
of the Federal Register). We agree that
the best way to ensure continued
alignment is to have the regulations we
are adopting here—governing MA
organizations, state Medicaid FFS
programs, Medicaid managed care
plans, CHIP FFS programs, CHIP
managed care entities, and QHP issuers
on the FFEs—cross reference the
specific regulations codifying the
standards adopted by HHS in the ONC
21st Century Cures Act final rule. Our
intent is to ensure alignment and
consistent standards across the
regulated programs. We agree that this
will help support interoperability across
the health care industry and help set
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
clear and consistent goals for all payers,
providers, vendors, and developers.
CMS and ONC will continue to
coordinate closely on standards,
including content and vocabulary
standards and impacted data elements
and use cases, and we will continue to
work closely with all stakeholders to
ensure that this process is consensusbased. Regarding the recommendation
to add data elements from the EOB not
yet included in the USCDI, we have
shared these recommendations with
ONC, and we refer readers to the
discussion in ONC’s 21st Century Cures
Act final rule on the USCDI and the
Standards Version Advancement
Process (published elsewhere in this
issue of the Federal Register).
B. Content and Vocabulary Standards
The content and vocabulary standards
HHS ultimately adopts applicable to the
data provided through the standardsbased API will, by necessity, vary by use
case and within a use case. For instance,
content and vocabulary standards
supporting consumer access vary
according to what specific data elements
MA organizations, Medicaid and CHIP
FFS programs, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs have available
electronically. Where another law does
not require use of a specific standard,
we proposed to require use of, in effect,
a catalogue of content and vocabulary
standards from which the regulated
entities may choose in order to satisfy
the proposed requirements in 42 CFR
422.119, 431.60, 457.730, 438.252, and
457.1233, and 45 CFR 156.221. A
further discussion of these proposals
can be found in section II.B. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7623 through
7624). These proposals are detailed in
section III.C.2.b. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7626 through
7639), and comments received on these
proposals are summarized with our
responses in section III.C.2.b. of this
final rule. Specifically, we note that we
proposed to adopt the content and
vocabulary standards as finalized by
HHS in ONC’s 21st Century Cures Act
final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR
170.213. This standard is currently the
USCDI version 1.
C. Application Programming Interface
(API) Standard
In section III.C.2.b. of the CMS
Interoperability and Patient Access
proposed rule, we proposed to require
compliance with the API technical
standard proposed by ONC for HHS
PO 00000
Frm 00013
Fmt 4701
Sfmt 4700
25521
adoption at 45 CFR 170.215 as finalized
(84 FR 7589). By requiring compliance
with 45 CFR 170.215, we proposed to
require use of the foundational Health
Level 7® (HL7) 19 Fast Healthcare
Interoperability Resources® (FHIR)
standard,20 several implementation
specifications specific to FHIR, and
complementary security and app
registration protocols, specifically the
Substitutable Medical Applications,
Reusable Technologies (SMART)
Application Launch Implementation
Guide (IG) 1.0.0 (including mandatory
support for ‘‘refresh tokens,’’
‘‘Standalone Launch,’’ and ‘‘EHR
Launch’’ requirements), which is a
profile of the OAuth 2.0 specification, as
well as the OpenID Connect Core 1.0
standard, incorporating errata set 1. A
further discussion of these proposals
can be found in section II.C. (84 FR 7624
through 7625) and the proposals are
detailed in section III. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7626 through
7639). Comments received on these
proposals are summarized with our
responses in section III. of this final
rule.
We proposed to adopt the technical
standards as finalized by HHS in the
ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) at 45 CFR 170.215.
HHS is finalizing adoption of HL7 FHIR
Release 4.0.1 as the foundational
standard for APIs at 45 CFR
170.215(a)(1). Instead of the Argonaut IG
and server to support exchange of the
USCDI proposed at 45 CFR 170.215(a)(3)
and (a)(4) (84 FR 7424), HHS is
finalizing the HL7 FHIR US Core IG
STU 3.1.0 at 45 CFR 170.215(a)(2). The
HL7 SMART Application Launch
Framework IG Release 1.0.0 was
proposed at 45 CFR 170.215(a)(5) (84 FR
7424). HHS is finalizing the HL7
SMART Application Launch Framework
IG Release 1.0.0 (which is a profile of
the OAuth 2.0 specification), including
mandatory support for the ‘‘SMART on
FHIR Core Capabilities,’’ at 45 CFR
170.215(a)(3). HHS is finalizing as
proposed adoption of OpenID Connect
Core 1.0, incorporating errata set 1 at 45
CFR 170.215(b), as well as adoption of
version 1.0.0: STU 1 of the FHIR Bulk
Data Access specification at 45 CFR
19 Health Level Seven International® (HL7) is a
not-for-profit, ANSI-accredited standards
development organization (SDO) focused on
developing consensus standards for the exchange,
integration, sharing, and retrieval of electronic
health information that supports clinical practice
and the management, delivery and evaluation of
health services. Learn more at ‘‘About HL7’’ web
page, last accessed 06/27/2018.
20 FHIR Overview. (n.d.). Retrieved from https://
www.hl7.org/fhir/overview.html.
E:\FR\FM\01MYR2.SGM
01MYR2
25522
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
170.215(a)(4). HHS is not finalizing the
adoption of FHIR Release 2 or FHIR
Release 3, API Resource Collection in
Health (ARCH) Version 1, or the HL7
Consent2Share FHIR Consent Profile
Design that were proposed at 45 CFR
170.215(a)(1), (c)(1), (a)(2), or (c)(2),
respectively (84 FR 7424). For a full
discussion, see the ONC 21st Century
Cures Act final rule (published
elsewhere in this issue of the Federal
Register). The content and vocabulary
standards and technical standards
finalized by HHS in the ONC 21st
Century Cures Act final rule provide the
foundation needed to support
implementation of the policies as
proposed and now finalized in this rule.
D. Updates to Standards
In addition to efforts to align
standards across HHS, we recognized in
the proposed rule that while we must
codify in regulation a specific version of
each standard, the need for continually
evolving standards development has
historically outpaced our ability to
amend regulatory text. To address how
standards development can outpace our
rulemaking schedule, we proposed in
section III.C.2.b. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7630 through
7631) that regulated entities may use
updated versions of required standards
if use of the updated version is required
by other applicable law. In addition,
under certain circumstances, we
proposed to allow use of an updated
version of a standard if the standard is
not prohibited under other applicable
law.
For content and vocabulary standards
at 45 CFR part 162 or 42 CFR 423.160,
we proposed to allow the use of an
updated version of the content or
vocabulary standard adopted under
rulemaking, unless the use of the
updated version of the standard: Is
prohibited for entities regulated by that
part or the program under that section;
Is prohibited by the Secretary for
purposes of these policies or for use in
ONC’s Health IT Certification Program;
or is precluded by other applicable law.
We remind readers that other applicable
law includes statutes and regulations
that govern the specific entity. For the
content and vocabulary standards
proposed by ONC for HHS adoption at
45 CFR 170.213 (84 FR 7589) (currently,
USCDI version 1),21 as well as for API
technical standards proposed by ONC
for HHS adoption at 45 CFR 170.215 (84
FR 7589) (including HL7 FHIR and
other standards and implementation
21 For more information on the USCDI, see
https://www.healthit.gov/USCDI.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
As discussed in the CMS
Interoperability and Patient Access
proposed rule (84 FR 7626), we are
committed to advancing
interoperability, putting patients at the
center of their health care, and ensuring
they have simple and easy access,
without special effort, to their health
information. With the establishment of
the initial Medicare Blue Button®
service in 2010, Medicare beneficiaries
became able to download their Part A,
Part B, and Part D health care claims
and encounter data through
MyMedicare.gov in either PDF or text
format. While the original Blue Button
effort was a first step toward liberating
patient health information, we
recognized that significant opportunities
remain to modernize access to that
health information and the ability to
share health information across the
health ecosystem. We believe that
moving to a system in which patients
have access to and use of their health
information will empower them to make
better informed decisions about their
health care. Additionally,
interoperability, and the ability for
health information systems and software
applications to communicate, exchange,
and interpret health information in a
usable and readable format, is vital to
improving health care. Allowing access
to health information only through PDF
and text formats limit the utility of and
the ability to effectively share the health
information.
Medicare Blue Button 2.0 is a new,
modernized version of the original Blue
Button service. It enables beneficiaries
to access their Medicare Parts A, B, and
D claims and encounter data and share
that electronic health information
through an Application Programming
Interface (API) with applications,
services, and research programs they
select. As discussed in section II.A. of
the CMS Interoperability and Patient
Access proposed rule (see 84 FR 7618
through 7623), API technology allows
software from different developers to
connect with one another and exchange
electronic health information in
electronic formats that can be more
easily compiled and leveraged by
patients and their caregivers.
Beneficiaries may also select third-party
applications to compile and leverage
their electronic health information to
help them manage their health and
engage in a more fully informed way in
their health care.
Today, Blue Button 2.0 contains 4
years of Medicare Part A, B, and D data
for 53 million Medicare beneficiaries.
These data are available to patients to
help them make more informed
decisions. Beneficiaries dictate how
their data can be used and by whom,
with identity and authorization
controlled through MyMedicare.gov.
Medicare beneficiaries can authorize
sharing their information with an
application using their MyMedicare.gov
account information. Beneficiaries
authorize each application, service, or
research program they wish to share
their data with individually. A
beneficiary can go back to
MyMedicare.gov at any time and change
the way an application uses their
information. Using Blue Button 2.0,
beneficiaries can access their health
information; share it with doctors,
caregivers, or anyone they choose; and
get help managing and improving their
health through a wide range of apps and
other computer-based services. Blue
Button 2.0 is an optional service—
beneficiaries choose the apps and
services they want to use.
Today, Medicare beneficiaries using
Blue Button 2.0 can connect with apps
that keep track of tests and services they
need and receive reminders, track their
medical claims, make appointments and
send messages to their doctors, get
personalized information about their
symptoms and medical conditions, find
health and drug plans, keep track of
their medical notes and questions, and
connect to research projects.23 These are
22 For more information on FHIR, see https://
www.hl7.org/fhir/overview.html.
23 To review a list of apps currently available to
Blue Button 2.0 users, visit https://
guides (IGs) as discussed above),22 we
proposed to allow the use of an updated
version of a standard adopted by HHS,
provided such updated version has been
approved by the National Coordinator
through the Standards Version
Advancement Process described in the
ONC 21st Century Cures Act proposed
rule (84 FR 7424), as finalized. A further
discussion of these proposals can be
found in section II.D. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7625 through
7626). These proposals are also detailed
in section III. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7626 through
7639), and comments received on these
proposals are summarized with our
responses in section III. of this final
rule.
III. Provisions of Patient Access
Through APIs, and Analysis of and
Responses to Public Comments
A. Background on Medicare Blue Button
PO 00000
Frm 00014
Fmt 4701
Sfmt 4700
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
just some of the ways Blue Button 2.0
is using a standards-based, FHIRenabled API to lead the charge and
unleash the power of health data.
B. Expanding the Availability of Health
Information
1. Patient Benefits of Information Access
As discussed in the CMS
Interoperability and Patient Access
proposed rule, we believe there are
numerous benefits associated with
individuals having simple and easy
access to their health care data under a
standard that is widely used. Whereas
EHR data are frequently locked in
closed, disparate health systems, care
and treatment information in the form of
claims and encounter data is
comprehensively combined in a
patient’s claims and billing history.
Claims and encounter data, used in
conjunction with EHR data, can offer a
broader and more holistic
understanding of an individual’s
interactions with the health care system
than EHR data alone. As one 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
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.
Identifying and finding opportunities to
address the individual’s non-adherence
to a care plan are critical to keeping
people with chronic conditions healthy
and engaged so they can avoid
hospitalizations. While a health plan
can use claims and encounter data to
help it identify which enrollees could
benefit from an assessment of why they
are not filling their prescriptions or who
might be at risk for particular problems,
putting this information into the hands
of the individual’s chosen care
provider—such as the doctor or nurse
practitioner prescribing the medications
or the pharmacist who fills the
prescriptions—helps them to engage the
patient in shared decision making that
can help address some of the reasons
the individual might not be willing or
able to take medications as prescribed.
By authorizing their providers to access
the same information through a
standards-based API, individuals can
further facilitate communication with
their care teams. Enabling the provider
to integrate claims and encounter
information with EHR data gives the
www.medicare.gov/manage-your-health/medicaresblue-button-blue-button-20/blue-button-apps.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
provider the ability to use the combined
information, with relevant clinical
decision support tools, as part of normal
care delivery in a less burdensome way,
leading to improved care. This may be
particularly important during times of
system surge, an event that generates a
large and sudden demand for health
services, for example, when access to
such information may help to inform
patient triage, transfer, and care
decisions.
Further, we noted that we believe
patients who have immediate electronic
access to their health information are
empowered to make more informed
decisions when discussing their health
needs with providers, or when
considering changing to a different
health plan. We discussed that currently
not all beneficiaries enrolled in MA
plans have immediate electronic access
to their claims and encounter data and
those who do have it, cannot easily
share it with providers or others. The
same is true of Medicaid beneficiaries
and CHIP enrollees, whether enrolled in
FFS or managed care programs, and
enrollees in QHPs on the FFEs. As
industries outside of health care
continue to integrate multiple sources of
data to understand and predict their
consumers’ needs, we believe it is
important to position MA organizations,
Medicaid and CHIP FFS programs and
managed care entities, and QHP issuers
on the FFEs to do the same to encourage
competition, innovation, and value.
We noted that CMS has programmatic
authority over MA organizations,
Medicaid programs (both FFS and
managed care), CHIP (both FFS and
managed care), and QHP issuers on the
FFEs. We proposed to leverage CMS
authority to make claims and encounter
data available through APIs as a means
to further access for patients in these
programs along with other plan data
(such as provider directory data) as
detailed in sections III.C. and IV. of the
CMS Interoperability and Patient Access
proposed rule. For a complete
discussion of these proposals, see the
proposed rule (84 FR 7626 through
7640).
2. Alignment with the HIPAA Right of
Access
As discussed in section II. of this final
rule, the recent decision in Ciox Health,
LLC v. Azar, et al. vacates a portion of
the HIPAA Privacy Rule that provides
an individual the right to direct a
covered entity to send protected health
information that is not in an EHR to a
third party identified by the individual.
It does not alter a patient’s right to
request access to their records. In
addition, the decision does not affect
PO 00000
Frm 00015
Fmt 4701
Sfmt 4700
25523
CMS’ programmatic authorities, as
discussed in detail in section III. of the
CMS Interoperability and Patient Access
proposed rule (83 FR 7629 through
7630) and later in this section of this
final rule. Prior to this decision, in the
CMS Interoperability and Patient Access
proposed rule, we discussed that the
HIPAA Privacy Rule, at 45 CFR 164.524,
provides that an individual has a right
of access to inspect and obtain a copy
of their PHI 24 that is maintained by or
on behalf of a covered entity (a health
plan or covered health care provider 25)
in a designated record set.26 It was
noted that, at that time, a covered entity
was required to provide the access in
any readily producible form and format
requested by the individual, and that
the right of access also includes
individual’s right to direct a covered
entity to transmit PHI directly to a third
party the individual designates to
receive it.27
We explained that software
applications using the Patient Access
API proposed at 42 CFR 422.119,
431.60, 438.242(b)(6) (finalized as
438.242(b)(5) in this rule; see section
VI.), 457.730, and 457.1233(d)(2), and
45 CFR 156.221, and further discussed
below, would provide an additional
mechanism through which the
individuals who so choose could
exercise the HIPAA right of access to
their PHI, by giving them a simple and
easy electronic way to request, receive,
and share data they want and need,
including with a designated third party.
However, as discussed in section II. of
the CMS Interoperability and Patient
Access proposed rule (84 FR 7621
through 7622), due to limitations in the
current availability of interoperability
standards for some types of health
information, or data, we noted the API
requirement may not be sufficient to
support access to all of the PHI subject
to the HIPAA right of access because a
patient’s PHI may not all be transferable
through the API. For instance, we
proposed to require payers to make
claims and encounter data as well as a
specified set of clinical data (that is,
clinical data maintained by the
applicable payer in the form of the
USCDI version 1 data set) available
through the Patient Access API.
24 See 45 CFR 160.103, definition of protected
health information.
25 The third type of HIPAA covered entity, a
health care clearinghouse, is not subject to the same
requirements as other covered entities with respect
to the right of access. See 45 CFR 164.500(b).
26 See 45 CFR 164.501, definition of designated
record set.
27 For more information, see https://
www.hhs.gov/hipaa/for-professionals/privacy/
guidance/access/.
E:\FR\FM\01MYR2.SGM
01MYR2
25524
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
However, a patient may request access
to an X-ray image as well. Currently, the
X-ray image itself is not captured under
the USCDI version 1 data set, and
though the necessary FHIR resources to
share this information via an API like
the Patient Access API are available, use
is not required under this rulemaking
and so a payer may not be able to share
such information via the API. Therefore,
under our proposal, a HIPAA covered
entity would have to share this type of
information in a form and format other
than the Patient Access API in order to
comply with our program proposals and
in keeping with the HIPAA Privacy Rule
right of access.
C. Standards-Based API Proposal for
MA, Medicaid, CHIP, and QHP Issuers
on the FFEs
1. Introduction
We proposed to add new provisions at
42 CFR 422.119, 431.60, 438.242(b)(6)
(finalized as § 438.242(b)(5) in this rule;
see section VI.), 457.730, 457.1233(d),
and 45 CFR 156.221, that would,
respectively, require each MA
organization, Medicaid FFS program,
Medicaid managed care plan, CHIP FFS
program, CHIP managed care entity, and
QHP issuer on an FFE to implement,
test, and monitor a standards-based API
that is accessible to third-party
applications and developers. We noted
that states with CHIPs were not required
to operate FFS systems and that some
states’ CHIPs were exclusively operated
by managed care entities. We did not
intend to require CHIPs that do not
operate a FFS program to establish an
API; rather, we noted that these states
may rely on each of their contracted
plans, referred to throughout the CMS
Interoperability and Patient Access
proposed rule and this final rule as
CHIP managed care entities, to set up
such a system.
As discussed, the API would allow
enrollees and beneficiaries of MA
organizations, Medicaid and CHIP FFS
programs, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs to exercise
their HIPAA right of access to certain
health information specific to their plan
electronically, through the use of
common technologies and without
special effort. We explained how
‘‘common technologies,’’ for purposes of
the proposal, means those that are
widely used and readily available, such
as computers, smartphones, or tablets.
The proposals are detailed in section
III.C. of the CMS Interoperability and
Patient Access proposed rule (84 FR
7626 through 7639), and comments
received on these proposals and our
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
responses are noted below in this final
rule.
2. The Standards-Based API Proposal
In the proposed rule, we addressed
the following components of the
standards-based API. Specifically, we
discussed:
• Authority to require
implementation of a standards-based
API by MA organizations, Medicaid and
CHIP state agencies, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs;
• The API technical standard and
content and vocabulary standards;
• Data required to be available
through the standards-based API and
timeframes for data availability;
• Documentation requirements for
APIs;
• Routine testing and monitoring of
standards-based APIs;
• Compliance with existing privacy
and security requirements;
• Denial or discontinuation of access
to the API;
• Enrollee and beneficiary resources
regarding privacy and security;
• Exceptions or provisions specific to
certain programs or sub-programs; and
• Applicability and timing.
We also included an RFI on information
sharing between payers and providers
through APIs.
Specifically, we proposed nearly
identical language for the regulations
requiring standards-based APIs at 42
CFR 422.119; 431.60, and 457.730, and
45 CFR 156.221 for MA organizations,
Medicaid state agencies, state CHIP
agencies, and QHP issuers on the FFEs;
Medicaid managed care plans would be
required, at 42 CFR 438.242(b)(6)
(finalized as 438.242(b)(5) in this rule;
see section VI.), to comply with the
requirement at 42 CFR 431.60, and CHIP
managed care entities would be required
by 42 CFR 457.1233(d)(2) to comply
with the requirement at 42 CFR 457.730.
As discussed in detail in the CMS
Interoperability and Patient Access
proposed rule, we proposed similar if
not identical requirements for these
various entities to establish and
maintain a standards-based API, make
specified data available through that
API, disclose API documentation,
provide access to the API, and make
resources available to enrollees. We
noted that we believed that such nearly
identical text is appropriate as the
reasons and need for the proposal and
the associated requirements are the
same across these programs. We
intended to interpret and apply the
regulations proposed in section III.C. of
the CMS Interoperability and Patient
PO 00000
Frm 00016
Fmt 4701
Sfmt 4700
Access proposed rule similarly and
starting with similar text is an important
step to communicate that to the
applicable entities that would be
required to comply (except as noted
below with regard to specific proposals).
In paragraph (a) of each applicable
proposed regulation, we proposed that
the regulated entity (that is, the MA
organization, the state Medicaid or CHIP
agency, the Medicaid managed care
plan, the CHIP managed care entity, or
the QHP issuer on an FFE, as
applicable) would be required to
implement and maintain a standardsbased API that permits third-party
applications to retrieve, with the
approval and at the direction of the
individual patient, data specified in
paragraph (b) of each regulation through
the use of common technologies and
without special effort from the
beneficiary. By ‘‘common technologies
and without special effort’’ by the
enrollee, we explained that the
regulation means use of common
consumer technologies, like smart
phones, home computers, laptops, or
tablets, to request, receive, use, and
approve transfer of the data that would
be available through the standardsbased API technology. By ‘‘without
special effort,’’ we proposed to codify
our expectation that third-party
software, as well as proprietary
applications and web portals operated
by the payer could be used to connect
to the API and provide access to the
data to the enrollee. In the CMS
Interoperability and Patient Access
proposed rule (84 FR 7628 through
7638), we addressed the data that must
be made available through the API in
paragraph (b); the regulation regarding
the technical standards for the API and
the data it contains in paragraph (c); the
documentation requirements for the API
in paragraph (d); explicit authority for
the payer regulated under each
regulation to deny or discontinue access
to the API in paragraph (e); and,
requirements for posting information
about resources on security and privacy
for beneficiaries in paragraphs (f) or (g).
Additional requirements specific to
certain programs, discussed in sections
IV. and V. of the CMS Interoperability
and Patient Access proposed rule, were
also included in some of the regulations
that address the API. We address those
additional requirements in sections IV.
and V. of this final rule.
a. Authority To Require Implementation
of a Standards-Based API
As noted in the CMS Interoperability
and Patient Access proposed rule (84 FR
7629 through 7630), the proposal would
apply to MA organizations, Medicaid
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
state agencies and managed care plans,
state CHIP agencies and managed care
entities, and QHP issuers on the FFEs.
We noted that the proposal for Medicaid
managed care plans, at 42 CFR
438.242(b)(6) (finalized as 438.242(b)(5)
in this rule; see section VI.), would
require MCOs, PIHPs, and PAHPs to
comply with the regulation that we
proposed for Medicaid state agencies at
42 CFR 431.60 as if that regulation
applied to the Medicaid managed care
plan. Similarly, we intended for CHIP
managed care entities to comply with
the requirements we proposed at 42 CFR
457.730 via the regulations proposed at
42 CFR 457.1233(d)(2). We proposed to
structure the regulations this way to
avoid ambiguity and to ensure that the
API proposal would result in consistent
access to information for Medicaid
beneficiaries and CHIP enrollees,
regardless of whether they are in a FFS
delivery system administered by the
state or in a managed care delivery
system. We noted that CHIP currently
adopts the Medicaid requirements at 42
CFR 438.242 in whole. We proposed
revisions to 42 CFR 457.1233(d)(1) to
indicate CHIP’s continued adoption of
42 CFR 438.242(a), (b)(1) through (5),
(c), (d), and (e), while we proposed
specific text for CHIP managed care
entities to comply with the regulations
proposed at 42 CFR 457.1233(d)(2) in
lieu of the proposed Medicaid revision,
which we noted would add 42 CFR
438.242(b)(6) (finalized as
§ 438.242(b)(5) in this rule; see section
VI.). In our discussion of the specifics of
the proposal and how we proposed to
codify it at 42 CFR 422.119, 431.60,
457.730, and 45 CFR 156.221, we
referred in the CMS Interoperability and
Patient Access proposed rule and refer
in this final rule only generally to 42
CFR 438.242(b)(5) (proposed as
438.242(b)(6); see section VI.) and
457.1233(d)(2) for this reason.
(1) Medicare Advantage
Sections 1856(b) and 1857(e) of the
Social Security Act (the Act) provide
CMS with the authority to add
standards and requirements for MA
organizations that the Secretary finds
necessary and appropriate and not
inconsistent with Part C of the Medicare
statute. In addition, section 1852(c) of
the Act requires disclosure by MA
organizations of specific information
about the plan, covered benefits, and the
network of providers; section 1852(h) of
the Act requires MA organizations to
provide their enrollees with timely
access to medical records and health
information insofar as MA organizations
maintain such information. The
information required to be made
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
available under these authorities
through the APIs in this final rule is
within the scope of information that MA
organizations must make available
under section 1852(c) and (h) of the Act
and the implementing regulations at 42
CFR 422.111 and 422.118. As
technology evolves to allow for faster,
more efficient methods of information
transfer, so do expectations as to what
is generally considered ‘‘timely.’’ Thus,
we noted in the CMS Interoperability
and Patient Access proposed rule our
belief that to align the standards with
21st century demands, we must take
steps for MA enrollees to have
immediate, electronic access to their
health information and plan
information. We further noted that the
proposed requirements were intended to
achieve this goal by providing patients
access to their health information
through third-party apps retrieve data
via the required APIs.
The CMS Interoperability and Patient
Access proposed rule provisions for MA
organizations relied on our authority in
sections 1856(b) and 1857(e) of the Act
(which provide CMS with the authority
to add standards and requirements for
MA organizations), and explained how
the information to be provided is
consistent with the scope of disclosure
under section 1852(c) and (h) of the Act,
to propose that MA organizations make
specific types of information, at
minimum, accessible through a
standards-based API and require
timeframes for update cycles.
Requirements for the Patient Access API
further implement and adopt standards
for how MA organizations must ensure
enrollee access to medical records or
other health information as required by
section 1852(h) of the Act. Similarly, the
Provider Directory API is a means to
implement the disclosure requirements
in section 1852(c) regarding plan
providers. Throughout section III.C. of
the CMS Interoperability and Patient
Access proposed rule, we explained
how and why the standards-based API
proposal was necessary and appropriate
for MA organizations and the MA
program. We discussed how these
requirements would give patients
simple and easy access to their health
information through common
technologies, such as smartphones,
tablets, or laptop computers, without
special effort on the part of the user by
facilitating the ability of patients to get
their health information from their MA
organization through a user-friendly
third-party app. The goals and purposes
of achieving interoperability for the
health care system as a whole are
equally applicable to MA organizations
PO 00000
Frm 00017
Fmt 4701
Sfmt 4700
25525
and their enrollees. Thus, the discussion
in section II. of the CMS Interoperability
and Patient Access proposed rule served
to provide further explanation as to how
a standards-based API proposal is
necessary and appropriate in the MA
program. In addition, we noted that
having easy access to their claims,
encounter, and other health information
would also facilitate beneficiaries’
ability to detect and report fraud, waste,
and abuse—a critical component of an
effective programs.
To the extent necessary, we also
relied on section 1860D–12(b)(3) of the
Act to add provisions specific to the
Part D benefit offered by certain MA
organizations; that provision
incorporates the authority to add
program requirements to the contracts
from section 1857(e)(1) of the Act. For
MA organizations that offer MA
Prescription Drug plans, we proposed
requirements in 42 CFR 422.119(b)(2)
regarding electronic health information
for Part D coverage. We explained that
this proposal was supported by the
disclosure requirements imposed under
section 1860D–4(a) of the Act, requiring
Part D claims information, pharmacy
directory information, and formulary
information to be disclosed to enrollees.
Also, we note here that 42 CFR
423.136(d) requires Part D plans to
ensure timely access by enrollees to the
records and information that pertain to
them. The APIs in this rule further
implement and build on these
authorities for ensuring that Part D
enrollees have access to information.
(2) Medicaid and CHIP
We proposed new provisions at 42
CFR 431.60(a), 457.730, 438.242(b)(6)
(finalized as 42 CFR 438.242(b)(5) in
this rule; see section VI.), and
457.1233(d)(2) that would require states
administering Medicaid FFS or CHIP
FFS, Medicaid managed care plans, and
CHIP managed care entities to
implement a standards-based API that
permits third-party applications with
the approval and at the direction of the
beneficiary or enrollee to retrieve
certain standardized data. The proposed
requirement would provide Medicaid
beneficiaries’ and CHIP enrollees simple
and easy access to their information
through common technologies, such as
smartphones, tablets, or laptop
computers, and without special effort on
the part of the user.
For Medicaid, we proposed these new
requirements under our authority under
section 1902(a)(4) of the Act, which
requires that a state Medicaid plan
provide such methods of administration
as are found by the Secretary to be
necessary for the proper and efficient
E:\FR\FM\01MYR2.SGM
01MYR2
25526
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
operation of the plan, and section
1902(a)(19) of the Act, which requires
that care and services be provided in a
manner consistent with simplicity of
administration and the best interests of
the recipients. For CHIP, we proposed
these requirements under the authority
in section 2101(a) of the Act, which sets
forth that the purpose of title XXI is to
provide funds to states to provide child
health assistance to uninsured, lowincome children in an effective and
efficient manner that is coordinated
with other sources of health benefits
coverage. Together we noted that these
proposals would provide us with
authority (in conjunction with our
delegation of authority from the
Secretary) to adopt requirements for
Medicaid and CHIP that are necessary to
ensure the provision of quality care in
an efficient and cost-effective way,
consistent with simplicity of
administration and the best interest of
the beneficiary.
We noted that we believed that
requiring state Medicaid and CHIP
agencies and managed care plans/
entities to take steps to make Medicaid
beneficiaries’ and CHIP enrollees’
claims, encounters, and other health
information available through
interoperable technology would
ultimately lead to these enrollees
accessing that information in a
convenient, timely, and portable way,
which is essential for these programs to
be effectively and efficiently
administered in the best interests of
beneficiaries. Further, we noted that
there are independent statutory
provisions that require the disclosure
and delivery of information to Medicaid
beneficiaries and CHIP enrollees; the
proposal would result in additional
implementation of those requirements
in a way that is appropriate and
necessary in the 21st century. We also
noted that we believed making this
information available in APIs and
ultimately apps may result in better
health outcomes and patient satisfaction
and improve the cost effectiveness of
the entire health care system, including
Medicaid and CHIP. Having easy access
to their claims, encounter, and other
health information may also facilitate
beneficiaries’ ability to detect and report
fraud, waste, and abuse—a critical
component of an effective programs.
We discussed that as technology has
advanced, we have encouraged states,
health plans, and providers to adopt
various forms of technology to improve
the accurate and timely exchange of
standardized health care information.
We noted that the proposal would move
Medicaid and CHIP programs in the
direction of enabling better information
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
access by Medicaid beneficiaries and
CHIP enrollees, which would make
them active partners in their health care
by providing a way for them to easily
monitor and share their data. By
requiring that certain information be
available in and through standardized
formats and technologies, we noted that
the proposal moved these programs
toward interoperability, which is key for
data sharing and access, and ultimately,
improved health outcomes. We also
noted that states would be expected to
implement the CHIP provisions using
CHIP administrative funding, which is
limited under sections 2105(a)(1)(D)(v)
and 2105(c)(2)(A) of the Act to 10
percent of a state’s total annual CHIP
expenditures.
(3) Qualified Health Plan Issuers on the
Federally-Facilitated Exchanges
We proposed a new QHP minimum
certification standard at 45 CFR
156.221(a) that would require QHP
issuers on the FFEs to implement a
standards-based API that would permit
third-party applications, with the
approval and at the direction of the
individual enrollee, to retrieve
standardized data as specified in the
proposal. We also proposed to require
that the data be made available to QHP
enrollees through common technologies,
such as smartphones or tablets, and
without special effort from enrollees.
We proposed the new requirements
under our authority in section
1311(e)(1)(B) of the Patient Protection
and Affordable Care Act, as amended by
the Health Care and Education
Reconciliation Act of 2010 (Pub. L. 111–
148, enacted March 23, 2010, and Pub.
L. 111–152, enacted March 30, 2010,
respectively) (collectively referred to as
the Affordable Care Act), which
afforded the Exchanges the discretion to
certify QHPs that are in the best
interests of qualified individuals and
qualified employers. Specifically,
section 1311(e) of the Affordable Care
Act authorized Exchanges to certify
QHPs that meet the QHP certification
standards established by the Secretary,
and if the Exchange determined that
making available such health plan
through such Exchange is in the
interests of qualified individuals and
qualified employers in the state in
which such Exchange operates.
In the CMS Interoperability and
Patient Access proposed rule, we noted
specifically in our discussion on QHP
issuers on the FFEs, but applicable to all
payers impacted by this rule, that we
believe there are numerous benefits
associated with individuals having
access to their health plan data that is
built upon widely used standards. The
PO 00000
Frm 00018
Fmt 4701
Sfmt 4700
ability to easily obtain, use, and share
claims, encounter, and other health data
enables patients to more effectively and
easily use the health care system. For
example, by being able to easily access
a comprehensive list of their
adjudicated claims, patients can ensure
their providers know what services they
have already received, can avoid
receiving duplicate services, and can
help their providers verify when
prescriptions were filled. We noted that
we believe these types of activities
would result in better health outcomes
and patient satisfaction and improve the
cost effectiveness of the entire health
care system. Having simple and easy
access, without special effort, to their
health information, including cost and
payment information, also facilitates
patients’ ability to detect and report
fraud, waste, and abuse—a critical
component of an effective program. We
noted that existing and emerging
technologies provide a path to make
information and resources for health
and health care management universal,
integrated, equitable, accessible to all,
and personally relevant. Specifically, for
QHP issuers on the FFEs, we stated that
we believe generally certifying only
health plans that make enrollees’ health
information available to them in a
convenient, timely, and portable way is
in the interests of qualified individuals
and qualified employers in the state or
states in which an FFE operates. We
also noted we encouraged SBEs to
consider whether a similar requirement
should be applicable to QHP issuers
participating in their Exchange.
We did not receive comments on the
authorities discussed in this section to
implement the Patient Access API. We
are finalizing these provisions, with the
modifications discussed in section III.C.
of this rule, under this authority.
Additionally, we are making two
modifications to the regulation text to
more clearly identify issuers subject to
the regulation. First, we are modifying
the scope of the applicability of the
regulation to issuers on the individual
market FFEs, effectively excluding
issuers offered through the FF–SHOP,
and we are explicitly excluding QHP
issuers on the FFEs that only offer
SADPs.
b. API Technical Standard and Content
and Vocabulary Standards
We proposed to require compliance
with 45 CFR 170.215 as finalized at 42
CFR 422.119(a) and (c), § 431.60(a) and
(c), 457.730(a) and (c), 438.242(b)(6)
(finalized as 438.242(b)(5) in this rule;
see section VI.) and 457.1233(d)(2), and
45 CFR 156.221(a) and (c), so that MA
organizations, Medicaid and CHIP FFS
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
programs, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs implement
standards-based API technology
conformant with the API technical
standards finalized by HHS in the ONC
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register), as discussed in
section II.A.3. of the CMS
Interoperability and Patient Access
proposed rule and section II. of this
final rule. We further proposed to
require that the data available through
the API be in compliance with the
regulations regarding the following
content and vocabulary standards,
where applicable to the data type or
data element, unless an alternate
standard is required by other applicable
law: Standards adopted at 45 CFR part
162 and 42 CFR 423.160; and standards
finalized by HHS in the ONC 21st
Century Cures Act final rule at 45 CFR
170.213 (USCDI version 1). See section
II.A.3. of the CMS Interoperability and
Patient Access proposed rule for further
information about how entities subject
to this rule would be required to utilize
these standards. We proposed that both
the API technical standard and the
content and vocabulary standards
would be required across the MA
program, Medicaid program, and CHIP,
and by QHP issuers on the FFEs.
With the proposed requirements to
implement and maintain an API at 42
CFR 422.119(a), 431.60(a), and
457.730(a), we proposed corresponding
requirements at 42 CFR 422.119(c) for
MA plans, 431.60(c) for Medicaid FFS
programs, and 457.730(c) for CHIP FFS
programs implementing the proposed
API technology. At proposed 42 CFR
422.119(c), 431.60(c), and 457.730(c),
MA plans and the state Medicaid or
CHIP agency (for states that operate
CHIP FFS systems) would be required to
implement, maintain, and use API
technology conformant with the
standards finalized by HHS in the ONC
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) at 45 CFR 170.215; for
data available through the API, to use
content and vocabulary standards
adopted at 45 CFR part 162 and 42 CFR
423.160, and finalized at 45 CFR
170.213, unless alternate standards are
required by other applicable law; and to
ensure that technology functions in
compliance with applicable law
protecting the privacy and security of
the data, including but not limited to 45
CFR parts 162, 42 CFR part 2, and the
HIPAA Privacy and Security Rules.
We similarly proposed at 45 CFR
156.221(c) that QHP issuers on the FFEs
must implement, maintain, and use API
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
technology conformant with the API
technical standards finalized by HHS in
the ONC 21st Century Cures Act final
rule (published elsewhere in this issue
of the Federal Register) at 45 CFR
170.215; for data available through the
API, use content and vocabulary
standards adopted at 45 CFR part 162
and 42 CFR 423.160, and finalized at 45
CFR 170.213, unless alternate standards
are required by other applicable law;
and ensure that technology functions in
compliance with applicable law
protecting the privacy and security of
the data, including but not limited to 45
CFR part 162, 42 CFR part 2, and the
HIPAA Privacy and Security Rules.
We noted that we believed these
proposals would serve to create a health
care information ecosystem that allows
and encourages the health care market
to tailor products and services to better
serve and compete for patients, thereby
increasing quality, decreasing costs, and
empowering patients with information
that helps them live better, healthier
lives. Additionally, under our proposal,
clinicians would be able to review, with
the approval and at the direction of the
patient, information on the patient’s
current prescriptions and services
received by the patient; the patient
could also allow clinicians to access
such information by sharing data
received through the API with the
clinician’s EHR system—by forwarding
the information once the patient
receives it or by letting the clinician see
the information on the patient’s
smartphone using an app that received
the data through the API. Developers
and providers could also explore
approaches where patients can
authorize release of the data through the
API directly to the clinician’s EHR
system.
We also encouraged payers to
consider using the proposed API
infrastructure as a means to exchange
health information for other health care
purposes, such as to health care
providers for treatment purposes.
Sharing interoperable information
directly with the patient’s health care
provider in advance of a patient visit
would save time during appointments
and ultimately improve the quality of
care delivered to patients. Most
clinicians and patients have access to
the internet, providing many access
points for viewing health information
over secure connections. We noted that
we believed these proposed
requirements would significantly
improve patients’ experiences by
providing a mechanism through which
they can access their data in a
standardized, computable, and digital
format in alignment with other public
PO 00000
Frm 00019
Fmt 4701
Sfmt 4700
25527
and private health care entities. We
stated that we designed the proposals to
empower patients to have simple and
easy access to their data in a usable
digital format, and therefore, empower
them to decide how their health
information is going to be used.
However, we reminded payers, and
proposed to codify that the regulation
regarding the API would not lower or
change their obligations as HIPAA
covered entities to comply with
regulations regarding standard
transactions at 45 CFR part 162.
Finally, we also proposed to add a
new MA contract requirement at 42 CFR
422.504(a)(18) specifying that MA
organizations must comply with the
requirement for access to health data
and plan information under 42 CFR
422.119.
We summarize the public comments
we received on the Patient Access API
proposal, generally, and the technical
standards we proposed for the API and
its content, and provide our responses.
Comment: Many commenters
indicated support for the overall
proposal to require the specified payers
to provide patients access to their health
care information through a standardsbased API. These commenters
supported the goals to provide patients
near real-time, electronic access to their
claims, treatment, and quality
information. Many commenters were
also supportive of provider access to
patient data through APIs, if the patient
consented to (or authorized) access, in
order to support coordinated care. One
commenter was specifically in favor of
the patient access proposal noting it
supports patient access to their
historical claims information. Finally,
one commenter requested that CMS
explain whether ‘‘API technology’’ has
the same definition as in the ONC
proposed rule.
Response: We appreciate the
commenters’ support for the Patient
Access API proposal and are finalizing
this policy with modifications, as
discussed in detail below. We also note
that both the CMS and ONC rules use
the term ‘‘API’’ consistently as we work
together to align technology and
standards and forward interoperability
across the entire health care system. We
do note, however, that the Patient
Access API did not propose to include
quality information.
Comment: One commenter requested
CMS specify the historical look-back
period for API exchange. In addition,
one commenter requested that CMS not
require data older than from 2019 be
made available through APIs due to the
implementation costs of standardizing
older information.
E:\FR\FM\01MYR2.SGM
01MYR2
25528
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Response: We appreciate the
commenters’ suggestions. The proposed
rule did not specify a historical lookback period for the Patient Access API
or limit the timeframe of the data that
must be available through the API. To
ensure consistent implementation and
minimize the burden on payers, we are
finalizing additional text in the
applicable regulations to specify that
MA organizations at 42 CFR 422.119(h),
state Medicaid FFS programs at 42 CFR
431.60(g), Medicaid managed care plans
at 42 CFR 438.62(b)(1)(vii), CHIP FFS
programs at 42 CFR 457.730(g), CHIP
managed care entities at 42 CFR
457.1233(d), and QHP issuers on the
FFEs at 45 CFR 156.221(i), beginning
January 1, 2021 (or plan years beginning
on or after January 1, 2021 for QHPs on
the FFEs), must make available through
the Patient Access API data that they
maintain with a date of service on or
after January 1, 2016. This means that
no information with a date of service
earlier than January 1, 2016 will need to
be made available through the Patient
Access API. By ‘‘date of service,’’ we
mean the date the patient received the
item or service, regardless of when it
was paid for or ordered. This is
consistent with how we are finalizing
the payer-to-payer data exchange
requirement for MA organizations at 42
CFR 422.119(f), Medicaid managed care
plans at § 438.62(b)(1)(vi) (made
applicable to CHIP managed care
entities through incorporation in
§ 457.1216), and QHP issuers on the
FFEs at 45 CFR 156.221(f). Aligning the
years of data available through the
Patient Access API with the payer-topayer data exchange will minimize cost
and burden specific to this regulatory
requirement and will provide patients
with the same timeframe of information
as payers, furthering transparency.
Together these policies facilitate the
creation and maintenance of a patient’s
cumulative health record with their
current payer.
We do not believe limiting the Patient
Access API to data only from January 1,
2019 forward is sufficient to help
patients most benefit from this data
availability. However, we do appreciate
that making older data available for
electronic data exchange via the Patient
Access API is part of the cost of the API.
As a result, limiting this to data with a
date of service of January 1, 2016
forward minimizes cost and burden
while maximizing patient benefit.
Comment: A few commenters
expressed concerns and indicated that
they did not believe the Patient Access
API proposal would move the health
care industry toward the stated goal of
helping patients make more informed
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
care decisions. Several commenters
were concerned that certain patient
groups, such as those with low
technology access and/or health
literacy, would not make use of
electronic applications for making
health care decisions. A few
commenters recommended CMS not
limit patient access to health
information through apps alone,
especially for populations with low
technology access and/or literacy.
Response: We appreciate the
commenters’ concerns. However, more
and more Americans are using portable
technology like smart phones and
tablets to conduct a myriad of daily
activities. Approximately 81 percent of
U.S. adults reported owning a
smartphone and 52 percent reported
owning a tablet computer in 2019.28 An
American Community Survey Report
from the U.S. Census Bureau reported
that in 2016, 82 percent of households
reported an internet subscription and 83
percent reported a cellular data plan.29
People have a right to be able to
manage their health information in this
way should they choose. We appreciate
that not everyone is comfortable with,
has access to, or uses electronic
applications in making health care
decisions. Such patients will maintain
the same access that they have to their
personal health information today. This
regulation does not change any existing
patient information rights. This
regulation simply adds new options to
ensure patients have the information
they need, when, and how they need it.
Comment: Several commenters
indicated concerns over what they
believe would be a costly
implementation. A few commenters
questioned who would be required to
bear the costs of implementation and
maintenance of the APIs, with one
commenter requesting CMS explicitly
permit payers to charge patients and
other third-party partners for the costs
of API implementation and
maintenance. In contrast, a few
commenters recommended that payers
should not be allowed to charge patients
to access their information through
APIs. A few commenters requested CMS
provide federal grant funding to support
payers in implementing the proposed
APIs.
Response: We appreciate the
commenters’ concerns and
28 Pew Research Center. (2019, June 12).
Retrieved from https://www.pewinternet.org/factsheet/mobile.
29 Ryan, C. (2018). Computer and internet Use in
the United States: 2016 (American Community
Survey Reports, ACS–39). Retrieved from https://
www.census.gov/content/dam/Census/library/
publications/2018/acs/ACS-39.pdf.
PO 00000
Frm 00020
Fmt 4701
Sfmt 4700
recommendations. As discussed in
section XIII. of this final rule, we are
providing updated cost estimates for
implementing and maintaining the
Patient Access API, moving from a
single point estimate to a range—
including a low, primary, and high
estimate—to better take into account the
many factors that impact the cost of
implementation. We have revised our
original estimate of $788,414 per payer,
to a primary estimate of $1,576,829 per
payer, increasing our original estimate
by a factor of 2 to account for additional
information that was provided by
commenters, which we still believe is
relatively minimal in relation to the
overall budget of these impacted payers.
We have included a low estimate of
$718,414.40 per organization, and a
high estimate of $2,365,243 per
organization. We refer readers to
sections XII. and XIII. of this final rule
for a detailed discussion of our revised
cost estimates.
We acknowledge that payers may pass
these costs to patients via increased
premiums. In this way, patients could
absorb the cost of the API. However, we
note the costs of ‘‘premiums’’ for MA,
Medicaid, and CHIP enrollees are
primarily borne by the government, as
are some premium costs for enrollees of
QHP issuers on the FFEs who receive
premium tax credits. We believe that the
benefits created by the Patient Access
API outweigh the costs to patients if
payers choose to increase premiums as
a result.
At this time, we are not able to offer
support for the implementation of this
policy through federal grant funding.
Regarding costs for Medicaid managed
care plans—since the Patient Access
API requirements must be contractual
obligations under the Medicaid
managed care contract—the state must
include these costs in the development
of a plan’s capitation rates. These
capitation rates would be matched at the
state’s medical assistance match rate.
State Medicaid agency implementation
costs would be shared by the state and
federal government, based on the
relevant level of Federal Financial
Participation, which is 50 percent for
general administrative costs and 90
percent for system development costs.
Comment: A few commenters
described concerns with the maturity of
APIs for data exchange, as well as the
fact that implementation of FHIR-based
APIs is so new in health care, and
expressed that they believed there were
challenges with meeting the proposed
requirement given the newness of the
needed standards, particularly regarding
standardizing the required data
elements and vocabularies. Several
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
commenters were concerned that APIs
would not be implemented in a
standardized fashion, which could lead
to interoperability challenges, and noted
the need for testing for certain use cases,
such as exchanging data from plan to
patients and from plan-to-plan, as well
as the exchange of provider directory
and/or pharmacy/formulary
information. Several commenters
suggested CMS and/or HHS publish
implementation guides to support
consistent and standardized
implementation of FHIR-based APIs and
their associated data standards.
Response: We appreciate the
commenters’ concerns. As stated in
section II. of this final rule, the content
and vocabulary standards and technical
standards HHS is finalizing in the ONC
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) provide the
foundation needed to support
implementation of the policies as
proposed and now finalized in this rule.
That said, we have been working with
HL7 and other industry partners to
ensure the implementation guides
requested are freely available to payers
to use if they choose to use them. Use
of these implementation guides is not
mandatory; however, if a payer does
choose to use the publicly available
guidance, it will limit payer burden and
support consistent, interoperable API
development and implementation.
Therefore, use of this publicly available
guidance can help address the
consistency concerns raised. Part of the
development process of any
implementation guide is consensus
review, balloting, and testing. We are
providing a link to specific
implementations guides and reference
implementations for all interested
payers for both the Patient Access API
and the Provider Directory API
(discussed in section IV. of this final
rule) that provide valuable guidance to
further support sharing the needed data
using the required standards: https://
www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. The implementation guides
provide information payers can use to
meet the requirements of the policies
being finalized in this rule without
having to develop an approach
independently, saving time and
resources. In addition, the reference
implementations allow payers to see the
APIs in action and support testing and
development.
Comment: A few commenters
indicated concerns with an impending
proliferation of multiple health plan
APIs. Instead, commenters
recommended a centralized,
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
standardized approach where CMS
would require the use of Blue Button 2.0
as the platform for providing patient
access to their health data from all
impacted programs (Medicare
Advantage, Medicaid, CHIP, and QHPs
on the FFEs). Commenters suggested
this would also reduce the burden on
app developers to develop to one API
rather than multiple APIs for various
regulated entities.
One commenter requested CMS
implement a pilot program for the API
proposals, citing CMS’ Blue Button
pilot. One commenter suggested CMS
convene a group of 10–12 subject matter
experts from payers along with other
relevant stakeholders, such as
developers, to meet with CMS, ONC,
and the FTC to facilitate a smooth path
to the API compliance deadline and
ensure a successful implementation.
Response: We appreciate the
commenters’ concerns and
recommendations. However, we do not
wish to require use of the Blue Button
2.0 platform as a centralized solution.
We believe that industry will best have
the ability to take interoperability to the
next level by leading the development
of APIs that meet the requirements in
the regulations at 42 CFR 422.119,
431.60, 438.242, 457.730, and 457.1233,
as well as 45 CFR 156.221, and which
they maintain and control. Blue Button
is essentially the hub for the Medicare
data that CMS, as a payer, is making
available to our beneficiaries. We do not
wish to require the centralization of
other payer data under this rule. We are
requiring other payers to also unleash
their data and provide the same benefits
to their enrollees in a standardized way.
As noted above, we are providing a link
to specific implementation guides and
reference implementations to further
support implementation of the Patient
Access API, as well as the Provider
Directory API (discussed in section IV.
of this final rule), for all payers to use:
https://www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. Use of these freely available
materials is not required, but if used
will reduce development burden for
both payers and app developers and
facilitate industry-wide interoperability.
Although we appreciate the
recommendation to consider a pilot, we
believe it is important to move ahead
with APIs at this time to help the health
care sector as a whole—including
patients, providers and payers—start to
benefit from this technology as so many
other sectors have. Also, as previously
noted in this final rule, we will share
lessons learned and best practices from
our experience with Blue Button as
relevant and appropriate to aid the
PO 00000
Frm 00021
Fmt 4701
Sfmt 4700
25529
successful implementation of the API
requirements included in this final rule.
Regarding the request to convene
subject matter experts, we reiterate our
commitment to continuing our
collaboration with our federal partners
and a diversity of industry stakeholders
to ensure a successful and smooth
implementation of the requirements
included in this final rule. As this
collaboration is ongoing, we do not
believe it is necessary to convene a new,
dedicated group.
Comment: One commenter
recommended that CMS consider
standards to allow payers and providers
to upload patient data directly to a
patient portal that is owned and
managed by the patient. One commenter
suggested that Health Information
Exchanges (HIEs) and Health
Information Networks (HINs) can be a
central source for patients to obtain
aggregated data in a single location.
Response: We thank commenters for
these recommendations. We appreciate
that HIEs and HINs can provide patients
with valuable information, and we look
forward to innovative solutions from
this community. One option would be
to leverage APIs and support patient
access via this technology. We did not
propose to use a portal approach. One
of the advantages of an API approach is
that any system can make data available
and that data can be used by any other
system that is following the same
approach to mapping and transporting
data without a need to otherwise link
the systems or ensure any system-level
compatibility. Having APIs that can be
accessed by third-party apps permits the
patient to choose how they want to
access their data, and it promotes
innovation in industry to find ways to
best help patients interact with their
data in a way that is most meaningful
and helpful to them. This same
flexibility and interoperability is not
easily realized through a portal solution,
and thus we will not consider this
recommendation at this time.
Comment: A few commenters
requested CMS confirm the proposed
preclusion policy for versions of
standards and standards themselves at
42 CFR 422.119(c)(4) for MA
organizations, 42 CFR 431.60(c)(4) for
Medicaid FFS programs, 42 CFR
438.242(b)(5) for Medicaid managed
care plans, 42 CFR 457.730(c)(4) for
CHIP FFS programs, 42 CFR
457.1233(d)(1) for CHIP managed care
entities, and 45 CFR 156.221(c)(4) for
QHP issuers on the FFEs. These
commenters recommended CMS
indicate that the preclusion policy
would prohibit plans from using
standards not named by CMS for the
E:\FR\FM\01MYR2.SGM
01MYR2
25530
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
specified API functions, but would not
prohibit them from using those
standards for other use cases not
regulated by CMS.
Response: We confirm that the
requirements in this regulation will not
preclude a payer from using a standard
not finalized in this rule for use cases
that are not specifically discussed in
this final rule as required for use with
the Patient Access API requirement or
the Provider Directory API requirement
(discussed in section IV. of this final
rule). The content and vocabulary
standards being adopted are specifically
applicable to the data identified and
required to be made available through
the Patient Access API and Provider
Directory API; this means that if there
is a content standard identified in the
regulation text for the information
specified in the regulation text as
required to be made available through
the API, the payer subject to the
regulation must make available through
the API at least these data elements
using the named content standard. This
final rule indicates the minimum data
that must be made available via these
APIs. This does not prevent a payer
from including more information via
either API using other available
standards. We do strongly support the
continued use and adoption of FHIR
standards for additional use cases to
promote interoperability and efficient
and effective transfer of electronic
health information, generally.
Comment: A few commenters
expressed concerns that contracts
between health care providers and
payers need to be standardized in order
to support the requirements of the CMS
Interoperability and Patient Access
proposed rule. A few additional
commenters specifically noted that
timing requirements for making
information available through APIs
should be specified in these contracts.
One commenter requested CMS prohibit
payers from using the Patient Access
API requirements to place additional
contractual demands on health care
providers.
Response: We appreciate the
commenters’ concerns that there will be
downstream impacts from the Patient
Access API requirements on the
relationship between payers and their
contracted health care providers. It will
be up to each payer’s discretion to
address whether this information needs
to be included in contracts with
providers. We do not believe it is
necessary or appropriate for CMS to
adopt regulations to standardize all
contracts between payers and health
care providers to accomplish this and
are not convinced it would be wise to
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
try to do so as each payer is unique, as
are their relationships with their
contracted providers. We are finalizing
the implementation timeline with
modifications from the proposal, as
further discussed below, to provide
payers and providers more time to
address all implementation issues. We
do not anticipate this will create
significant additional provider burden.
Comment: Several commenters
supported the CMS proposal to adopt
FHIR as the technical standard for payer
APIs. Several commenters
recommended adopting FHIR Release 4
(R4), also referred to as ‘‘version 4,’’
noting it is more robust than Release 2
(R2), particularly regarding laboratory
information. A few other commenters
supported the use of FHIR R2 with the
eventual transition to R4. One
commenter indicated their
recommendation on the version of FHIR
to adopt (R2 vs R4) would depend on
the timeline CMS provides payers for
compliance. A few commenters also
suggested CMS align with the version of
FHIR that ONC adopts in its final rule.
Response: We thank commenters for
their recommendations, which we have
shared with ONC. We are adopting the
standards as finalized by HHS in ONC’s
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register). As a result, the
regulations we are finalizing will
require the use of the standards
identified at 45 CFR 170.215, which
specifically include the use of HL7 FHIR
Release 4.0.1. As previously stated, we
believe that requiring regulated entities
to comply with the specified standards
regulations finalized by HHS in ONC’s
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) will support greater
alignment and interoperability across
the health care system, as health IT
products and applications that will be
developed for different settings and use
cases will be developed according to a
consistent base of standards that
support a more seamless exchange of
information. Extending the
implementation date, as further
discussed below, should provide the
necessary time to build to and use FHIR
Release 4.0.1.
Comment: Although many
commenters were generally in support
of the proposal to use FHIR, several
commenters did raise specific
implementation concerns. Several
commenters expressed concerns about
the costs and burden for payers and
providers to update to the necessary
FHIR standard for content exchange,
especially for historical data that may
not currently be coded to support FHIR.
PO 00000
Frm 00022
Fmt 4701
Sfmt 4700
Many of these commenters cautioned
CMS from proceeding too quickly with
FHIR adoption and implementation.
One commenter noted that semantic
interoperability is needed for true
interoperability but that significant
mapping and implementation efforts
would be needed to achieve this goal.
One commenter requested CMS provide
federal funding to support adoption and
implementation of FHIR-based APIs.
Response: We appreciate the
commenters’ concerns. Regarding the
readiness of the FHIR standards and the
need for semantic interoperability, we
agree that semantic interoperability is
important. As noted in this section,
though not required for use, we are
providing a link to specific
implementation guides and reference
implementations that include
information about the FHIR resources to
use to code and map the required data
elements as to facilitate interoperable
data exchange via the Patient Access
API, as well as the Provider Directory
API (discussed in section IV. of this
final rule). This addresses the concern
raised regarding semantic
interoperability.
Regarding burden, as indicated in
section XIII. of this final rule, we do not
anticipate that upgrading to HL7 FHIR
Release 4.0.1 and preparing historical
data for electronic transfer via an API
using these standards will be more than
a relatively minimal expense. We are
also limiting the amount of historic
information that will need to be
included in the Patient Access API to
information with a date of service on or
after January 1, 2016. This should also
help address concerns around expense
and burden. In addition, we note the
discussion below regarding the
implementation date for this policy
appreciating the commenters’ concerns
about moving too quickly. Regarding
federal funding and costs, we note that
for several of the types of payers that
must comply with the Patient Access
API requirements, there is significant
federal participation in the costs.
For Medicaid FFS, the provision of
enhanced federal match rate is
addressed in section 1903(a)(3)(A) of the
Act and provides a 90 percent match
rate for the sums expended during such
quarter as are attributable to the design,
development, or installation of such
mechanized claims processing and
information retrieval systems as the
Secretary determines are likely to
provide more efficient, economical, and
effective administration of the plan.
For Medicaid managed care plans,
since the Patient Access API
requirements must be contractual
obligations under the Medicaid
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
managed care contract, the costs must
be included in the development of a
plan’s capitation rates. Approved
capitation rates would be matched at the
state’s medical assistance match rate.
As is discussed in section XIII. of this
final rule, MA organizations may
include in their bids the costs of
implementing provisions of this rule
that pertain to MA. The bid, as
compared to the benchmark, is a
significant component of what the
government pays MA organizations for
the provision of Part A and Part B
benefits: (1) For bids at or below the
benchmark, the government pays the
bid as the capitation amount, and (2) for
bids that are above the benchmark, the
government pays the benchmark and the
remainder of the bid amount is the
premium charged to enrollees of the
plan.
For CHIP, the federal government
pays an enhanced federal medical
assistance percentage (EFMAP) to states
for all costs associated with CHIP,
including systems costs. For federal FY
2020, the EFMAPS will range from
approximately 65 to 81.5 percent. We
note that states will be expected to
implement the CHIP provisions using
CHIP administrative funding, which is
limited under section 2105(a)(1)(D)(v)
and 2105(c)(2)(A) of the Act to 10
percent of a state’s total annual CHIP
expenditures.
For QHP issuers on the FFEs, we
would expect that issuers would raise
premiums in the short term in order to
cover the costs associated with
developing and implementing these
new standards. To the extent that
premiums are raised for all QHP issuers
on the FFEs, federal contributions for
the subsidized population in the form of
advanced premium tax credits will
increase proportionally in those initial
years. Non-subsidized consumers will
be expected to pay for the increase in
premiums themselves and any increases
may impact the ability of some
consumers to afford coverage. Some
consumers may instead select other
options or opt out of coverage if they
find QHPs unaffordable.
Comment: A few commenters
indicated they did not support CMS’
proposal to use one standard adopted by
HHS (FHIR, which ONC had proposed
for adoption at 45 CFR 170.215) as the
foundational standard for standardsbased APIs. A few commenters
suggested CMS permit the use of other
standards for exchanging the proposed
patient data during a transition period
or until the FHIR standards are more
mature. One commenter recommended
the use of HIPAA Administrative
Simplification transaction standards
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
such as those maintained by X12. One
commenter noted that these HIPAA
transaction standards were more
accessible to payers to represent clinical
and case management data. This
commenter suggested CMS should
precisely identify the specific claims
data layout of the HIPAA
Administrative Simplification
transaction standards that payers would
be required to generate and receive
because the HIPAA Administrative
Simplification transaction standards
layout varies by payer type. However,
one commenter noted that patients may
not find information available through
HIPAA standards useful.
A few commenters suggested CMS
should assist affected payers with
meeting the technical implementation
requirements by explaining the intent of
the required use of the HIPAA
Administrative Simplification
transaction content and vocabulary
standards with the HL7 FHIR standards.
Commenters recommended that CMS
review and reconcile differences
between existing standards that are
required for Medicaid programs, in
particular. For example, commenters
suggested identifying situations in
which CMS has required the use of X12
Electronic Data Interchange standards
and reconciling these requirements with
the adoption of the HL7 FHIR standards.
Response: We appreciate the
commenters’ concerns and
recommendations. The policies
included in this final rule are not
intended to alter HIPAA requirements
in any way, and these electronic data
exchanges are not defined transactions
under HIPAA regulations, therefore
there is no need to reconcile use of X12
and the HL7 FHIR standards required in
this rule. We appreciate that the HIPAA
standards are more known to many
payers at this time; however, we believe
the use of FHIR standards is important
for advancing the policies finalized in
this rule, which require the
transmission of information beyond
what is available using X12 standards
alone. At the same time, as discussed in
the proposed rule, we are requiring
entities subject to this rule to use
HIPAA content and vocabulary
standards at 45 CFR part 162 where
required by other applicable law, or
where such standards are the only
available standards for the data type or
element (84 FR 7623). The use of the
FHIR standard supports making this
information available through an API.
This is not in conflict with the use of
other standards to represent the data
being transmitted through the API.
Instead, the FHIR standard can be
thought of as defining an envelope,
PO 00000
Frm 00023
Fmt 4701
Sfmt 4700
25531
while the contents of the envelope can
be represented by different content and
vocabulary standards used in
conjunction with FHIR to make data
interoperable and accessible. For
additional information on FHIR
standards, we direct commenters to the
ONC’s 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register). To support
implementation of the policies included
in this final rule, we are providing a link
to specific implementation guides and
reference implementations that provide
valuable guidance to further support
sharing the needed data using the
required standards: https://
www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index.
As discussed in section II.A.3. of the
CMS Interoperability and Patient Access
proposed rule (84 FR 7622 through
7623), we recognized that while we
must codify in regulation a specific
version of each standard, the need for
continually evolving standards
development has historically outpaced
our ability to amend regulations. To
address how standards development can
outpace our rulemaking schedule, we
offered several proposals. We proposed
that regulated entities may use an
updated version of a standard where
required by other applicable law. We
also proposed that regulated entities
may use an updated version of the
standard where not prohibited by other
applicable law, under certain
circumstances.
We summarize the public comments
we received on our approach to
allowing voluntary adoption of updated
standards and provide our responses.
Comment: A few commenters
expressed support for the proposal to
allow plans to upgrade to newer
versions of standards supporting data
classes in the USCDI as standards
evolve. A few commenters specifically
supported the proposal to align with
ONC’s proposed Standards Version
Advancement Process and allow payers
to adopt newer versions of FHIR once
approved for use by HHS. A few
commenters were concerned with
backwards compatibility if
implementers—payers and developers—
are permitted to move to new versions
of standards, while a few commenters
supported the proposed requirement to
maintain compatibility with adopted
standards while upgrading to newer
standards. One commenter expressed
concerns with difficulty tracking
compliance with standards as they
move through different versions,
generally, and requested CMS establish
E:\FR\FM\01MYR2.SGM
01MYR2
25532
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
a versioning system or identifier for
consistency and transparency.
A few commenters specifically
discussed the NCPDP SCRIPT standard;
however, these comments are out of
scope for this rulemaking because this
rulemaking does not apply to
ePrescribing transactions.
Response: We appreciate the
commenters’ input. We are adopting the
ability to use updated standards. As
proposed, implementers will need to
ensure that use of the updated (or
newer) standard (instead of the standard
specified in the applicable regulation)
does not disrupt an end user’s ability to
access the data available through the
API, which should address concerns
raised around backward compatibility.
Specifically, we are finalizing at 42 CFR
422.119(c)(4) for MA organizations, 42
CFR 431.60(c)(4) for Medicaid FFS
programs, 42 CFR 438.242(b)(5) for
Medicaid managed care plans, 42 CFR
457.730(c)(4) for CHIP FFS programs, 42
CFR 457.1233(d)(1) for CHIP managed
care entities, and 45 CFR 156.221(c)(4)
for QHP issuers on the FFEs permission
to use an updated version of standards
adopted at 45 CFR 170.215, 45 CFR
170.213, 45 CFR part 162, or 42 CFR
423.160, subject to the conditions
proposed. As long as use of the updated
version of a standard is not otherwise
prohibited, permitted in accordance
with the conditions described, and, does
not disrupt an end user’s ability to
access the data per the requirements of
the API, it may be used.
Regarding the recommendation for
CMS to establish a versioning system or
identifier, we appreciate this
recommendation and will review the
suggestion for future consideration.
c. Data Required To Be Available
Through the Standards-Based API &
Timeframes for Data Availability
We proposed the content that must be
accessible for each enrollee of an entity
subject to the standards-based API
proposal as set out at proposed
paragraph (b) of 42 CFR 422.119, 431.60,
and 457.730, and 45 CFR 156.221; as
noted previously, the regulations for
Medicaid managed care plans and CHIP
managed care entities cross-reference
and incorporate the regulations we
proposed for Medicaid and CHIP FFS
programs. We noted that the types of
content proposed would represent the
minimum threshold for compliance; at
their discretion, MA organizations, state
Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs would have the option to
use the API required by the proposed
rule to make additional types of health
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
information or plan information
available, exceeding these minimum
requirements.
We requested comment on the data
proposed to be made available as
detailed in the subsections below. We
proposed that MA organizations,
Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs permit third-party
applications to retrieve, with the
approval and at the direction of an
enrollee, certain specific data:
Adjudicated claims data, including
provider remittances and beneficiary or
enrollee cost-sharing data; encounter
data from capitated providers; and
clinical data, including laboratory
results (but only if maintained by the
payer).
(1) Patient Claims and Encounter Data
We proposed that the adjudicated
claims data required to be provided
include approved and denied claims.
Under the proposal, adjudicated claims
data includes that for which the plan
has made an initial payment decision
even when the period during which an
enrollee can file an appeal is still in
effect, or when the enrollee has filed an
appeal and is awaiting a decision on
that appeal. Such appeal decisions
might be called reconsiderations,
reconsidered decisions, organization
determinations, or use other terms, but
the term is not relevant. We specifically
requested comments from plans
regarding the feasibility of including
such claims data, including any possible
timing issues.
The proposal included timeframe
requirements for making these various
categories of data available through the
standards-based API. For MA
organizations, proposed 42 CFR
422.119(b)(1)(i), (ii), and (b)(2)(i) would
require standards-based API access to
all claims activity pertaining to
standardized adjudicated claims
(including cost, specifically provider
remittances and enrollee cost-sharing)
and standardized encounter data for
benefits covered by the plan (that is,
Medicare Part A and Part B items and
services, Part D prescription drugs if
covered by the MA plan, and any
supplemental benefits) no later than one
(1) business day after a claim is
processed or the encounter data are
received by the MA organization. We
used the terms ‘‘adjudicated’’ and
‘‘processed’’ interchangeably in this
context.
For Medicaid state agencies and
managed care plans, we proposed that
standardized claims data and encounter
data would be required (specifically at
PO 00000
Frm 00024
Fmt 4701
Sfmt 4700
42 CFR 431.60(b)(1) and (2)) through the
API no later than one (1) business day
after the claim is processed or the data
are received. For State Medicaid
agencies in connection with the FFS
program, we explained that the API
would have to include all claims data
concerning adjudicated claims and
encounter data from providers (other
than MCOs, PIHPs or PAHPs) that are
paid using capitated payments. The
requirement for Medicaid managed care
plans to provide encounter data is
specified, in conjunction with the
incorporation of the Medicaid FFS
requirement into the Medicaid managed
care regulations, at 42 CFR
438.242(b)(6)(i) (finalized as
§ 438.242(b)(5)(i) in this rule; see section
VI.). Similarly, we proposed that
encounter data that Medicaid managed
care plans must make available through
the API would include any data from
subcontractors and providers
compensated by the managed care plan
on the basis of capitation payments,
such as behavioral health organizations,
dental management organizations, and
pharmacy benefit managers. The API for
Medicaid managed care plans would
have to include all claims and,
therefore, encounter data that would be
included regardless if it is adjudicated
or generated by the managed care plan
itself, a subcontractor, or a provider
compensated on the basis of capitation
payments. All data would need to be
obtained in a timely manner to comply
with these proposed requirements that
these types of data be available through
the API no later than one (1) business
data after a claim is processed or the
encounter data are received.
For CHIP agencies and managed care
entities, access to standardized claims
data and encounter data would be
required (specifically at 42 CFR
457.730(b)(1) and (2)) through the API
no later than one (1) business day after
the claim is processed or the encounter
data are received. The proposal for CHIP
state agencies (regarding FFS programs)
and CHIP managed care entities is
identical to the proposal for Medicaid
state agencies (regarding FFS programs)
and Medicaid managed care plans. For
QHP issuers on the FFEs, the proposed
regulation at 45 CFR 156.221(b) would
require claims and encounter data to be
available through the Patient Access API
no later than one (1) business day after
adjudication or receipt, respectively.
Specifically regarding QHP issuers on
the FFEs, at 45 CFR 156.221(b)(1)(i) and
(ii), we proposed to require that QHP
issuers participating on the FFEs make
available through the API standardized
data concerning adjudicated claims
(including cost) and standardized
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
encounter data. Under proposed
paragraph (b)(1)(i), we proposed that
QHP issuers on the FFEs would be
required to make available standardized
data concerning adjudicated claim,
provider remittance, and enrollee costsharing data through the API within one
(1) business day after the claim is
processed. Under proposed paragraph
(b)(1)(ii), we proposed that QHP issuers
on the FFEs would be required to
provide standardized encounter data
through the API no later than one (1)
business day after the data are received
by the issuer.
As discussed in the CMS
Interoperability and Patient Access
proposed rule (84 FR 7632 through
7633), the proposed timeframe—making
the data available to the third-party app
with the approval and at the direction
of the patient through the API no later
than one (1) business day after
processing a claim or receiving
encounter data—would ensure that data
provided to the third-party app, and
ultimately the patient, through the API
would be the most current data
available. Providing the most current
data may be critical if the data are
provided by an enrollee to his or her
health care provider to use in making
clinical decisions. As proposed, the
claims and encounter data to be
disclosed would include information
such as enrollee identifiers, dates of
service, payment information (provider
remittance if applicable and available),
and enrollee cost-sharing. Our proposal
did not exclude any elements from the
claims and encounter—or the clinical
data—required to be made available
through the Patient Access API. The
ability for enrollees—created and
facilitated by the API required under the
proposal—to access this information
electronically would make it easier for
them to take it with them as they move
from payer to payer or among providers
across the care continuum.
Regarding the provision of encounter
data through the API no later than one
(1) business day after receiving the data,
we noted that the proposal would mean
that a payer must rely on capitated
providers submitting their encounter
data in a timely manner to ensure that
patients receive a timely and complete
set of data. To the extent providers do
not submit in a timely manner, there
would be a delay in patients having
access to their data. We recommended
that MA organizations, Medicaid
managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs
that would need this information in
order to meet the proposed API
requirements in a timely manner should
consider whether their contracts with
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
network providers should include
timing requirements for the submission
of encounter data and claims so that the
payer can comply with the API
requirements more timely. For Medicaid
and CHIP FFS programs, we encouraged
states to consider other means to ensure
that necessary encounter data from
providers is also provided on a timely
basis.
We summarize the public comments
we received on making claims and
encounter data available via the Patient
Access API and provide our responses.
Comment: A few commenters
expressed concern that there are no
named or mature industry FHIR-based
standards available for representing and
exchanging claims information. One
commenter requested CMS only require
a specific subset of claims information
that would be most useful to patients,
suggesting patient name, diagnoses
codes, procedure codes, drug codes,
service date(s), provider of service, and
out-of-pocket costs.
Response: We appreciate the
commenters’ concerns and
recommendations. We have been
working with industry partners to
ensure the necessary FHIR standard and
implementation guides as specified at
45 CFR 170.215 are now available to
ensure that payers can fully implement
sharing claims data via a FHIR-based
API, as we are finalizing our proposal to
have payers impacted by this rule make
claims and encounter data available via
the standards-based Patient Access API
no later than one (1) business day after
claims processing or encounter data
receipt. To further support payers as
they work to build the Patient Access
API and map claims and encounter data
for exchange via a FHIR-based API, in
partnership with industry, we have
worked to ensure relevant
implementation guides and reference
implementations are available. A link to
specific implementation guides and
reference implementations for claims
and encounter data have been produced
and tested and can be found at https://
www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. Though not mandatory, using
these publicly available resources will
reduce payer burden as they work to
prepare their data for exchange via a
FHIR-based API.
We also appreciate the
recommendation to only include a
subset of claims information. However,
we believe it is important for patients to
have all of their claims information in
order to facilitate informed decision
making. Patients have a right to their
claims data. While that information
currently can be obtained through
PO 00000
Frm 00025
Fmt 4701
Sfmt 4700
25533
various means, we decline to require
that only a subset of the available claims
information be available through the
Patient Access API.
Comment: One commenter noted that
health plans cannot verify the accuracy
of all information contained in a claim.
This commenter requested CMS should
state that these policies do not mandate
that payers audit and correct all
information furnished by health care
providers beyond what is currently
necessary for existing rules, regulations,
and internal business purposes.
Response: We appreciate the
commenter’s concern. We agree that our
regulations, as proposed and as
finalized, for this Patient Access API do
not require that payers do any
additional audit or review of the claims
they receive beyond current practices.
To the extent that payers wish to, they
may include a disclaimer or other notice
to enrollees as part of the API to
indicate this. Such a disclaimer would
be permissible under these regulations.
Comment: A few commenters
recommended that further
standardization work be done to
improve the accuracy of the claims data
field that identifies the attributed health
care provider administering services. If
this data element is accurate,
commenters note it will help ensure
patients are reaching out to the right
clinician. Commenters believe this
could reduce confusion when patients
seek clarification or request
amendments to their health information.
Response: We appreciate the
commenters’ recommendation and will
evaluate potential future options to
address this concern through our work
with HL7 and other industry partners.
We do note, however, this seems to be
a data accuracy issue and not a
standardization issue. That said, we do
strongly encourage all payers and
providers to work together to ensure the
accuracy of these and all data.
Comment: A few commenters were
concerned that claims data were not
accurate representations of clinical
findings and therefore not valuable in
assisting patients in making health care
decisions. These commenters expressed
fears that patients may misinterpret
claims information for health care
decision-making when claims data serve
a payment use case.
Response: We appreciate the
commenters’ concerns. We do note,
however, that there is valuable
information on the claim relevant to a
patient’s care and care history that can
inform health care decision-making. For
instance, this information provides
patients with the names of the providers
they have visited, when they visited
E:\FR\FM\01MYR2.SGM
01MYR2
25534
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
certain providers for certain medical
needs, when tests or procedures were
conducted, and more information about
these tests and procedures. This
information alone is very useful to
patients as they plan and discuss future
care with their providers. Also, in the
absence of clinical data (which is
required to be provided through the
Patient Access API under this rule only
if the payer maintains such data), claims
and encounter data provide a basis of
information for patients to work with
and get value from.
Comment: One commenter sought
clarification on the scope of Medicaidcovered services to which the
requirement to make claims and
encounter data available through an API
applies. This commenter recommended
that CMS specify that this requirement
to make claims and encounter data
available does not apply to long-term
care waiver services, such as in-home
care, meal preparation or delivery, and
transportation. The commenter stated
that providing claims and encounter
data for these services through the API
would be cumbersome for a variety of
reasons including the fact that long-term
care waiver services tend to have
frequent (daily or weekly) utilization by
each participant, which would result in
an unwieldly number of claims or
encounters being provided through the
API for each individual.
Response: We confirm that under 42
CFR 431.60(b)(1) and (2), 42 CFR
457.730(b)(1) and (2), 42 CFR
438.242(b)(5) (proposed as
§ 438.242(b)(6); see section VI.), and 42
CFR 457.1233(d), states and managed
care plans must make adjudicated
claims and encounter data available
through the API for all Medicaid- or
CHIP-covered services, including longterm services and supports (LTSS). This
requirement extends to in-home care,
transportation services, and all other
Medicaid- or CHIP-covered services for
which a claim or encounter is generated
and adjudicated. We do not believe the
number of claims generated by LTSS
will make the data unwieldy or
unusable by the beneficiary. We believe
that the benefits of providing claims and
encounter data to beneficiaries so they
can make better health care decisions
and know which providers have been
paid for providing services to them is no
less important simply because it is a
frequently provided service. Some
beneficiaries may find having such data
on frequently rendered services more
important since billing with such
frequency may make it more prone to
errors, fraud, waste, and abuse.
Comment: Several commenters were
concerned with the appropriateness of
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
sharing certain claims information,
particularly specific costs such as
negotiated rates that commenters
believed could reveal trade secrets or be
considered proprietary information.
These commenters requested CMS
ensure that confidential, proprietary
cost information is excluded from the
proposed requirements. One commenter
believed that disclosure of information
such as negotiated rates would lead to
higher health prices in the industry and
other anticompetitive behavior.
Specifically, this commenter gave the
example where dominant payers in a
geographic or other market use this
price information to deter competitors
from entering into value-based payment
arrangements. One commenter also
requested that third-party apps be
prohibited from aggregating or using any
cost information for purposes other than
transfer of the data to the patient.
Response: We note that we take our
obligations seriously to protect from
disclosure information that is protected
under current law. We also affirm our
commitment to safeguarding data
protected by law from inappropriate use
and disclosure. We understand the
concerns raised around sharing cost
data. We appreciate the commenters’
concerns, however we reiterate that we
are committed to giving patients access
to their health information, and we
believe the benefits of making this
information available to patients
through third-party apps outweigh these
concerns. It is critical for patients to
better understand health care costs and
be able to plan and budget as well as
possible. Having cost information,
which is already accessible to patients,
available to them in a more easy-tounderstand presentation would allow
patients to get the maximum benefit
from this information. If a patient uses
an app to view their health information
that does not clearly indicate it will not
use this cost data for any other purpose,
there is a chance the app could
aggregate or otherwise analyze the data,
assuming the single app has access to
enough patient data in a given market or
patients who use a particular payer or
plan, to make such an analysis possible.
Appreciating patients already have
access to this information and
understanding the possibility for
secondary uses of such data, we are
finalizing the policy as proposed to
require plans to share adjudicated
claims, including provider remittances
and enrollee cost-sharing information,
via the FHIR-based Patient Access API
so patients can continue to access this
information in ways that will be most
useful to them. We reiterate, however,
PO 00000
Frm 00026
Fmt 4701
Sfmt 4700
that we do not have the authority to
directly regulate third-party apps.
Comment: A few commenters also
indicated that even if patients had
access to price information, they would
not have the ability to negotiate or
impact health care costs. One
commenter noted that patients would
find prospective cost information more
valuable than retrospective payment
information.
Response: We appreciate the
commenters’ input. With access to price
information, patients who would have
cost sharing that is tied to such prices
can be more informed consumers of
their health care. Even patients who
have no direct financial responsibility
tied to these prices can benefit from
knowing the information in the event
their insurance coverage changes in the
future or so they can appreciate the
relationship between the services they
receive and their cost to the health care
system. It is important for patients to
understand as much as they can about
their care. For instance, understanding
the costs of past services can help them
plan for future services. As a result, this
information has great value to patients
even if it does not directly impact their
ability to specifically influence what
they pay for their care, or tell them
exactly how much their next service
will cost out of pocket.
Comment: Many comments were
received regarding price transparency,
generally, and were beyond the scope of
the discussion in this rule. Overall,
these were out of scope for this final
rule as they referenced other rulemaking
activities within HHS.
Response: We appreciate the
commenters’ strong interest in greater
price transparency in health care. We
strongly support the Administration’s
and Department’s efforts to continue to
move toward greater transparency to
help health care consumers make the
most informed decisions. We point to
the recent release of the CY 2020
Hospital Outpatient Prospective
Payment System Policy Changes and
Payment Rates and Ambulatory Surgical
Center Payment System Policy Changes
and Payment Rates. Price Transparency
Requirements for Hospitals To Make
Standard Charges Public final rule (84
FR 65524). This final rule establishes
requirements for all hospitals operating
in the United States to make their
standard charges available to the public
under section 2718(e) of the PHSA, as
well as an enforcement scheme under
section 2718(b)(3) to enforce those
requirements. Specifically, sections
2718(b)(3) and 2718(e) of the PHSA
require that for each year each hospital
operating within the United States
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
establish (and update) and make public
a list of the hospital’s standard charges
for items and services provided by the
hospital, including for diagnosis-related
groups established under section
1886(d)(4) of the Act. This final rule
requires hospitals (as defined at 45 CFR
180.20) to establish, update, and make
public a list of their gross charges,
payer-specific negotiated charges
(including the de-identified minimum
and maximum negotiated charges), and
discounted cash prices for all items and
services online in a single digital file
that is in a machine-readable format, as
well as their payer-specific negotiated
charges (including the de-identified
minimum and maximum negotiated
charges) and discounted cash prices (or
gross charges, if a discounted cash price
is not offered by the hospital) for a more
limited set of shoppable services online
in a consumer-friendly format.
We also direct commenters to the triagency Transparency in Coverage
proposed rule (84 FR 65464) for
additional proposals to further price
transparency.
Comment: Some commenters
generally opposed the proposal to make
claims and encounter data available
through a standards-based API no later
than one (1) business day after receiving
it. Some commenters suggested the
proposed data availability timeframe is
challenging due to the timeline for
sharing adjudicated claims, in
particular, noting the different
timeframes for payment discharge,
benefit determination, and settlement of
the patient account. One commenter
noted the reliance on third-party
contractors to adjudicate claims and the
time required to migrate data from one
system to another and that validation
could take longer than one (1) business
day. Several commenters expressed
concern about the timeframe based on
revised determinations or revised
decisions triggered by data that arrives
after the initial determination. One
commenter specifically questioned the
value of third-party application use of
claims data when an enrollee has filed
an appeal and is awaiting a
reconsideration decision. One
commenter recommended CMS only
permit finalized claims where a
determination has been made be
available to be shared via the Patient
Access API.
Some commenters specifically
referenced the reliance of MA plans on
pharmacy benefit management
organizations for the administration of
Part D benefits as a factor in the ability
to make these claims data available
within one (1) business day after
receiving them. Other commenters
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
referenced the Explanation of Benefit
requirements that provide a timeframe
for information adjustment, which
means that the final information may
not be available in one (1) business day.
Several commenters suggested an
alternative timeframe of 3 or 5 days for
vendor-adjudicated claims, citing time
and costs. Some commenters
recommended a grace period for plans
when there is a delay due to delayed
provider encounter data submission. In
addition, some requested an exception
for specific conditions attributable to
certain claims and encounter data.
Other commenters recommended that
CMS work with stakeholders to
determine an appropriate timeframe for
making claims and encounter data
available via the Patient Access API.
Response: We appreciate the
commenters’ concerns and
recommendations, including comments
regarding claims that may be under
appeal. We are finalizing this policy as
proposed that payers make available
through the Patient Access API, no later
than one (1) business day after the
information is received: (1) Adjudicated
claims, including claims data for
payment decisions that may be
appealed, were appealed, or are in the
process of appeal, and (2) encounter
data. We reiterate that this is one (1)
business day after the claim is
adjudicated or encounter data are
received. This allows for potential
delays in adjudication or delays in
providers submitting their encounter
data. It does not require payers and
providers to change their contractual
relationships or current processes for
receipt, though we strongly encourage
payers and providers to work together to
make patient data available in as timely
a manner as possible.
We believe it is valuable to patients to
be able to have their data in as timely
a manner as possible. Having access to
this information within one (1) business
day could empower patients to have the
information they need when they need
it to inform care coordination and
improve patient outcomes. If a patient
needs to get follow-up care, having the
information relevant to their previous
visit is important and valuable. API
technology allows this exchange to
happen more quickly and efficiently,
and we believe it is important to
leverage this technological opportunity
to ensure patients have the most current
information about their care.
It is also important for patients to get
this information timely even if there is
the possibility of a change in
determination due to appeal or other
factors. We conducted research to
evaluate the maturity of claims to
PO 00000
Frm 00027
Fmt 4701
Sfmt 4700
25535
inform researchers using the Chronic
Conditions Data Warehouse (CCW)
data.30 This research indicates that
nearly half of all Medicare FFS or
carrier claims are submitted once and
unchanged, and nearly 85 percent of
inpatient claims are never adjusted. For
carrier claims, 99 percent are fully
mature at 10 months; and of noninpatient claims that were adjusted, 0.13
percent or less had the diagnosis code
changed. What this research shows is
that many claims remain unchanged,
and those that do take more that 3 or 5
days after adjudication to begin to
mature. This wait would not provide
patients more accurate or complete data;
it would only delay their ability to
benefit from access to their information.
Patients have a right to see the full
lifecycle of their claims and encounter
information, and we believe they should
be able to have access to their
information as soon as it is available.
Even if the payment amounts may
change due to appeal, for instance, the
services received and the providers who
rendered them are less likely to change.
This is very useful information and
could impact care decisions and
facilitate better care coordination if
available as soon as possible. We do
appreciate that there are many factors
that could influence when some data are
available. Again, we encourage payers to
work with health care providers and
third-party contractors to ensure timely
data processing.
Comment: Several commenters
expressed concern that the proposed
timeframe for payers to share claims and
encounter data with patients could
require providers to accelerate their
submissions to payers triggering
additional requirements in existing
contracts for the submission of claims
and encounter data. Some commenters
cautioned there could be potential
downstream consequences such as
narrowing a payer’s provider network.
One commenter recommended removal
of proposed rule preamble language
suggesting that MA plans, Medicaid
managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs
could consider adding time
requirements for submission of claims
and encounter data in their contracts
with providers. One commenter
recommended CMS provide sample
contract language or dedicate resources
30 Chronic Conditions Data Warehouse. (2017,
October). CCW White Paper: Medicare Claims
Maturity (Version 2.0). Retrieved from https://
protect2.fireeye.com/url?k=7bd1837b-2785aa507bd1b244-0cc47a6d17cc590a0fb580f6d595&u=https://www2.ccwdata.org/
documents/10280/19002256/medicare-claimsmaturity.pdf.
E:\FR\FM\01MYR2.SGM
01MYR2
25536
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
to educating providers about the intent
of these possible contract revisions.
Response: We appreciate the
commenters’ concerns and
recommendations. As discussed in the
CMS Interoperability and Patient Access
proposed rule, we do appreciate that
some payers may consider adding
timeframes to contracts with providers
to help ensure patients get timely access
to their claims and encounter data.
Again, we strongly encourage providers
to make this information available in as
timely a fashion as possible to best
assist patients in having access to their
health information. Adding language to
contracts is one way for payers and
providers to work together to ensure
patients get this valuable information in
as timely a manner as possible. We
believe providers can benefit as well if
this information is available sooner; it
could be shared with them for the
purposes of care coordination in a more
timely manner, too. It may take some
time for providers to improve internal
efficiencies to meet potential new
timeline requirements, but we believe
the long-term benefit outweighs
potential short term implementation
burden. We do note, however, that the
policy being finalized in this rule is
specific to payers making adjudicated
claims and encounter information
available to patients via the Patient
Access API within one (1) business day
after the payer receives the information.
Any additional timeframes are between
the payers and their providers.
(2) Provider Directory Data
We proposed at 42 CFR
422.119(b)(1)(iii), 431.60(b)(3),
438.242(b)(6)(ii), 457.730(b)(3), and
457.1233(d)(2)(ii) that the required
Patient Access API make available
provider directory data, including
updates to such data. The proposal at 45
CFR 156.221 would not require QHP
issuers to permit third-party retrieval of
provider directory (and preferred drug
list information) because such
information is already required to be
provided by QHP issuers on the FFEs.
For MA organizations, at proposed 42
CFR 422.119(b)(1)(iii), we proposed to
specify that MA organizations make
specific provider directory information
for their network of contracted
providers accessible through their
Patient Access APIs: The names of
providers; addresses; phone numbers;
and specialty. This information is the
same information MA organizations are
already required to disclose to their
enrollees under 42 CFR 422.111(b)(3)
and make available online under 42 CFR
422.111(h)(2)(ii). As proposed, MA
organizations would be required to
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
ensure the availability of this
information through the Patient Access
API for all MA plans. We noted that
including this information in a
standards-based API allows non-MA
third-party applications to consume,
aggregate, and display this data in
different contexts, allowing patients to
understand and compare plan
information in a way that can best serve
their individual needs. As proposed,
MA plans would be required to update
provider directory information available
through the API no later than 30
business days after changes to the
provider directory are made.
Under proposed 42 CFR 431.60(b)(3)
and 457.730(b)(3), state Medicaid and
CHIP agencies respectively would be
required to make provider directory
information available through the
Patient Access API, including updated
provider information no later than 30
calendar days after the state receives
this provider directory information or
updates to provider directory
information. The proposed regulation
for Medicaid managed care plans at 42
CFR 438.242(b)(6) (finalized as
§ 438.242(b)(6) in this final rule; see
section IV. of this final rule) and for
CHIP managed care entities at 42 CFR
457.1233(d)(2) would require MCOs,
PIHPs, and PAHPs to comply with the
same timeframe, with the addition of
specific provider directory information
as noted in 42 CFR 438.242(b)(6)(ii) and
457.1233(d)(2)(ii). For Medicaid
managed care plans and CHIP managed
care entities, we proposed the provider
directory information available through
the API must include all information
that is specified in 42 CFR 438.10(h)(1)
about provider directories for disclosure
to managed care enrollees. We proposed
that the Patient Access API be updated
with new provider directory
information within 30 calendar days
from when the updated information is
received by the state (or the managed
care plan under 42 CFR 438.242(b)(6)
(finalized as § 438.242(b)(6) in this final
rule; see section IV. of this final rule)
and § 457.1233(d)(2)) to be consistent
with existing Medicaid managed care
rules at 42 CFR 438.10(h)(3). We
proposed that the API implemented by
the state Medicaid agency would
include the data elements specified for
disclosure by Medicaid state agencies in
section 1902(a)(83) of the Act; we
proposed at 42 CFR 438.242(b)(6)(ii)
that the Patient Access API
implemented by Medicaid managed care
plans would have the data elements
specified for disclosure at 42 CFR
438.10(h)(1). For CHIP agencies that
operate FFS systems and CHIP managed
PO 00000
Frm 00028
Fmt 4701
Sfmt 4700
care entities at 42 CFR 457.730(b)(3) and
457.1233(d)(2)(ii), respectively, we also
proposed that provider directory data be
available through the API no later than
30 calendar days after receipt of
updated information.
We did not propose a similar
requirement for QHP issuers on the
FFEs. As discussed in the CMS
Interoperability and Patient Access
proposed rule (84 FR 7633), these
issuers are already required, under 45
CFR 156.230(c) and implementing
guidance, to make provider directory
information accessible in a machinereadable format. Because this
information is already highly accessible
in this format, we noted that we did not
believe the benefits of making it also
available through a standards-based API
outweigh the burden for QHP issuers on
the FFEs. However, we sought comment
as to whether this same requirement
should apply to QHP issuers, or if such
a requirement would be overly
burdensome for them.
To avoid unnecessary duplication of
effort and potential confusion, we are
not finalizing the proposal to include
provider directory information in the
Patient Access API. Instead, we are
finalizing the inclusion of this
information (consistent in scope as
proposed for the Patient Access API) in
the public facing Provider Directory API
discussed in section IV. of this final
rule, which requires MA organizations,
Medicaid FFS programs, Medicaid
managed care plans, CHIP FFS
programs, and CHIP managed care
entities to provide public access to
complete and accurate provider
directory information at 42 CFR
422.120, 431.70, 438.242(b)(6), 457.760,
and 457.1233(d)(3). Appreciating that
the comments we received on provider
directory information and APIs
addressed issues relevant to both
including these data in the Patient
Access API discussed in this section of
the final rule, but more so making this
information more widely available
through the Provider Directory API as
discussed in section IV. of this final
rule, all comments and our responses
related to provider directory
information via APIs can be found in
section IV. of this final rule.
(3) Clinical Data Including Laboratory
Results
Regarding the provision of clinical
data, including laboratory results, we
proposed at 42 CFR 422.119(b)(1)(iv)
that MA organizations make clinical
data, such as laboratory test results,
available through the API if the MA
organization maintains such data. We
also proposed in paragraph (c)(3)(i) that
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the USCDI standard, proposed by ONC
for HHS adoption at 45 CFR 170.213, be
used as the content and vocabulary
standard for the clinical data made
available through the API. We intended
the proposal to mean that the data
required under paragraph (b)(1)(iv) be
the same as the data that is specified in
that content and vocabulary standard
defined at 45 CFR 170.213. In effect, we
proposed that at a minimum any
clinical data included in the USCDI
standard, proposed by ONC for HHS
adoption at 45 CFR 170.213, be
available through the Patient Access API
if such data are maintained by the MA
organization. We recognized that some
MA organizations receive this
information regularly, or as a part of
their contracted arrangements for health
services, but that not all MA
organizations do. Therefore, we
proposed that this requirement would
apply to MA organizations, regardless of
the type of MA plan offered by the MA
organization, but only under
circumstances when the MA
organization receives and maintains this
clinical data as a part of its normal
operations. The proposed requirement
aligned with existing regulations at 42
CFR 422.118, which required MA
organizations to disclose to individual
enrollees any medical records or other
health or enrollment information the
MA organizations maintain with respect
to their enrollees. We proposed that this
data be available through the API no
later than one (1) business day from its
receipt by the MA organization.
Similarly, the proposed regulations
for Medicaid and CHIP FFS programs
and managed care plans (proposed 42
CFR 431.60(b)(4) and § 457.730(b)(4)),
required provision through the Patient
Access API of standardized clinical
data, including laboratory results, if
available, no later than one (1) business
day after the data are received (by the
state or the managed care plan or
entity). We noted that this would ensure
that data provided through the API
would be the most current data
available, which may be critical if the
data are being shared by an enrollee
with a health care provider who is
basing clinical decisions on these data.
As noted, like proposed 42 CFR
422.119(c), the Medicaid and CHIP
regulations proposed compliance with
the regulations regarding the USCDI
standard, proposed by ONC for HHS
adoption at 45 CFR 170.213, as the
content and vocabulary standard for the
clinical data available through the
Patient Access API; therefore, we
proposed that at a minimum any
clinical data included in that USCDI
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
standard be made available through the
Patient Access API within one (1)
business day of receipt. For state
agencies managing Medicaid or CHIP
FFS programs, we proposed that such
data be made available through the API
under the proposal if the state maintains
clinical data. The proposed regulation
for Medicaid managed care plans at 42
CFR 438.242(b)(6) (finalized as
§ 438.242(b)(5) in this rule; see section
VI.) and CHIP managed care entities at
42 CFR 457.1233(d)(2) would require
MCOs, PIHPs, and PAHPs to comply
with the same standard in terms of the
scope of information and the timing of
its availability through the Patient
Access API; the limitation that the
clinical data be maintained by the entity
for it to be required to be sent via the
Patient Access API would carry through
to managed care plans and entities
under the proposal.
Proposed 45 CFR 156.221(b)(1)(iii)
would require QHP issuers on the FFEs
to also make these clinical data,
including laboratory results, available
via the Patient Access API, with the
approval and at the direction of the
enrollee, if the QHP maintains such
data.
We recognized not all of the entities
subject to this requirement have
uniform access to this type of data and
sought comment on what barriers exist
that would discourage them from
obtaining, maintaining, and making
these data available through the Patient
Access API.
We summarize the public comments
we received on the inclusions of clinical
data, specifically the data included in
the USCDI standard, via the Patient
Access API and provide our responses
below.
Comment: Several commenters
expressed concerns that payers are
typically not the original source of
clinical information, including data
elements that are part of the USCDI, and
would not be the best source of the most
accurate clinical data for patients. These
commenters noted concerns with data
accuracy provided by payers who are
typically secondary sources of this
clinical information and explained that
payers do not verify this information.
One commenter believed the originator
should be providing the data, or that
payers should be allowed to indicate the
provenance of the data and where to
direct questions regarding data
accuracy. There was concern that the
administrative burden on providers
could increase due to patient inquiries
and requests to correct or clarify their
data.
Response: We appreciate the
commenters’ concerns and
PO 00000
Frm 00029
Fmt 4701
Sfmt 4700
25537
recommendations. We understand that
payers are not the source of this clinical
information; however, payers do
maintain clinical data that can be of
great value to patients. We note that
provenance is one data class within the
USCDI. As such, this information would
be available to patients. We also note,
that as discussed above, we intend to
provide suggested content for
educational information that payers will
be able to tailor and use to communicate
with their patients about the Patient
Access API. Payers can choose to
indicate the part of a data exchange that
was received from an outside source so
the receiving party understands where
to direct questions. This will also help
patients understand how to address
incorrect information as it can be made
clear where questions should be
directed. Payers are under no obligation
under this Patient Access API
requirement to validate or correct
clinical data received from another
source; and, providers are under no
obligation to submit updated data to
payers should patients suggest there is
an error in their data. We do encourage
payers and providers to continually
work to ensure the accuracy of the
patient data they maintain and share to
the extent possible. The Patient Access
API must include all of the specified
clinical information for the enrollee
maintained by the payer with a date of
service on or after January 1, 2016.
Comment: A few commenters were
concerned that payers could use clinical
data to discriminate against providers,
such as through discriminatory
reimbursement models, for instance
offering lower reimbursement rates for
certain types of care that a physician
deems necessary or in the best interest
of the patient based on the data viewed
about the doctor and the care they
provide.
Response: We appreciate the
commenters’ concerns; however, we
note the fact that some payers are
already automatically accessing a
physician’s EHR for other purposes,
either as an elective offering or through
contractual requirements. As a result,
additional data than is required to meet
the requirements of this final rule are
already being shared between providers
and payers. We reiterate that payers are
not entitled to receive information from
a health care provider if such
information is protected by applicable
federal, state, or local law from
disclosure to the payer. This final rule
does not change any such existing legal
obligations.
Comment: A few commenters
expressed concerns over provider
liability for the quality or accuracy of
E:\FR\FM\01MYR2.SGM
01MYR2
25538
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
clinical data and for being given certain
sensitive patient diagnosis and
problems information, particularly if the
provider is a downstream recipient of
such data.
Response: We appreciate the
commenters’ concerns, but reiterate that
the policies finalized in this regulation
do not change any payer or provider’s
obligations to abide by existing federal
and state regulations and law, including
42 CFR part 2, which governs certain
substance use disorder records, which
are some of the most sensitive health
information. We note, however, that the
patient can direct the entity to transfer
this sensitive data upon their
designation of a recipient, or may
provide consent or authorization for the
transfer, as applicable. As a provider,
and likely as a covered entity under
HIPAA, providers are experienced in
handling sensitive data. Access through
an API will provide a new route to
receiving sensitive data, not add to the
burden of protecting such information,
given the continued need to maintain
compliance with all applicable rules
and regulations. These policies just
allow this information to be transmitted
via an API with the approval and at the
direction of the patient.
Comment: Some commenters
expressed concern that patients may not
understand, or may be confused by, the
health information that will be
available, and questioned if this
information will all be relevant to
patients. A few commenters
recommended that educational
materials and resources be developed to
ensure that the data are useful and do
not cause alarm.
Response: We appreciate the
commenters’ concerns and
recommendations. We appreciate that
every patient may not understand every
piece of information in their medical
record. We intend to provide suggested
content for educational materials or
other patient resources that payers can
tailor and use to ensure that patients
have information about how to
accurately and productively navigate
their health care information, as further
discussed below in this section. It is
important for patients to have access to
their records, review them, and have an
opportunity to raise questions and seek
clarification about the information
maintained in them.
Comment: One commenter requested
CMS explain the requirement that MA
organizations make clinical data
available through the Patient Access API
if the entity ‘‘manages such data,’’
particularly what is meant by ‘‘manages
such data.’’ This commenter noted that
providers manage clinical data and
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
requested clarification of whether the
requirement applies to MA
organizations. Another commenter
expressed similar concerns and inquired
whether ‘‘managed by the payer’’ would
include only lab results or all clinical
data. Commenters questioned if
‘‘manage’’ meant ‘‘electronically stored
in a database under the payer’s
control’’?
Response: We appreciate the
commenters’ request for additional
information. As noted in the CMS
Interoperability and Patient Access
proposed rule, payers, including MA
organizations, need to make these data
available through the API when the
payer receives and maintains these data
as a part of its normal operations (84 FR
7633). We used the verb ‘‘manages’’ to
communicate that this proposed
requirement would apply when the
payer has access to the data, control
over the data, and the authority to make
the data available through the API. In
order to more closely align with how the
relevant HIPAA Privacy Rule
requirement refers to such activity, we
are finalizing the regulation text at 42
CFR 422.119(b)(1)(iii), 431.60(b)(3), and
457.730(b)(3), as well as 45 CFR
156.221(b)(1)(iii) with the verb
‘‘maintains’’ in place of the verb
‘‘manages’’. As such, we define
‘‘maintain’’ to mean the payer has
access to the data, control over the data,
and authority to make the data available
through the API.
Comment: One commenter questioned
if Medicaid agencies will be required to
provide clinical data regardless of the
type of transaction by which the agency
received the data.
Response: We confirm that Medicaid
and CHIP agencies, and their respective
managed care plans, will be required
under 42 CFR 431.60(b)(3),
457.730(b)(3), 438.242(b)(5), and
457.1233(d) to provide clinical data
through the API if the state or managed
care plan maintains such clinical data.
Clinical data subject to this requirement
includes laboratory results and other
clinical data, and must be made
available through the Patient Access API
regardless of the type of transaction by
which the state or managed care plan
received the data originally. However, if
the data were received under the payerto-payer data exchange requirement
finalized in section V. of this final rule
at 42 CFR 422.119(f), 438.62(b)(1)(vi),
and 457.1216, and 45 CFR 156.221(f),
then the payer would only need to share
the clinical data received via the payerto-payer data exchange via the Patient
Access API if the data were received
from another payer via a standardsbased API. As required at 42 CFR
PO 00000
Frm 00030
Fmt 4701
Sfmt 4700
422.119(f)(1)(iii), 438.62(b)(1)(vi)(C),
and 457.1216 and 45 CFR
156.221(f)(1)(iii), data received via the
payer-to-payer data exchange only need
to be made available to share in the
electronic form and format they were
received from another payer. If a payer
receives data specifically for the payerto-payer data exchange via an API, they
can then make these data available via
the Patient Access API without
additional burden—the payer will not
be required per this final rule to take
data from another payer received as a
direct result of the payer-to-payer data
exchange policy and prepare it to be
shared via the Patient Access FHIRbased API; the payer will only be
required to incorporate that data into
the enrollee’s record so that it can be
shared with a new payer, if requested by
the patient, in the electronic form and
format received. Appreciating concerns
raised around the burden of preparing
data for exchange via an API, we have
provided this guidance to minimize this
burden. We note that Medicaid and
CHIP state agencies are not subject to
the payer-to-payer data exchange
requirement in this rulemaking, as we
did not propose this policy for these
entities.
Comment: A few commenters
recommended that patients have access
to detailed and accurate lab test and
results information through the Patient
Access API. A few commenters were not
supportive of CMS’ proposal that
laboratory information be made
available only where available. One
commenter recommended that these
same API requirements apply to
laboratories providing service to
Medicare and Medicaid patients as any
provider receiving reimbursement for
medical services. One commenter
expressed concern that lab information
is not standardized and may be difficult
to exchange.
Response: We appreciate the
commenters’ concerns and
recommendations. These regulations
requiring the Patient Access API and
detailing the data available through the
Patient Access API, as proposed and as
finalized, do not apply to laboratories or
to any providers—these requirements
are specific to payers as detailed above,
but we will review the
recommendations made for potential
future consideration.
Regarding concerns about
standardized data exchange of
laboratory information, the regulations
finalized in this rule provide the content
and vocabulary standards at 45 CFR
170.213 needed to address sharing
laboratory data through the API.
Implementation guidance, now
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
available at https://www.cms.gov/
Regulations-and-Guidance/Guidance/
Interoperability/index, though not
mandatory, can be used to further
support sharing these data utilizing the
content and vocabulary standards
adopted in this rule. These
implementation guides and reference
implementations provide additional
support to help payers implement this
policy in a standardized way that
facilitates interoperability.
Comment: Some commenters were
concerned about the proposed timeline
and challenges specifically because of
the nature of laboratory data,
specifically laboratory results. Final
results can replace preliminary results,
and laboratory data coming from third
parties can take time to receive.
Additionally, there may be conflicting
disclosure requirements that permit up
to 30 days to pass before laboratory data
are available to a payer.
Response: We appreciate the
commenters’ concerns. We do
understand that there are many factors
that could influence when some data are
available. However, we reiterate that
this Patient Access API policy requires
the information to be shared no later
than one (1) business day after it is
received by the regulated payer. If it
takes additional time for laboratory
information to be provided to a payer,
that does not impact the payer’s
obligation to make the data available via
the Patient Access API no later than one
(1) business day after the receipt of the
information by the payer. Therefore, we
strongly encourage all payers and
providers to work to make data available
in as timely a fashion as possible to
ensure an optimally informed health
care ecosystem.
Comment: Many commenters
supported the proposal to require
providing the information in the USCDI
via the Patient Access API. Commenters
supported alignment with ONC on this
and encouraged additional alignment
across government data sets.
Commenters also supported the data
classes and associated standards in the
proposed ONC USCDI. One commenter
specifically noted support for the
pediatric vital signs proposed as part of
the USCDI. A few commenters
recommended the addition of data
classes that are already proposed as part
of the USCDI, such as clinical notes,
provenance, and unique device
identifiers. A few commenters strongly
supported the inclusion of notes in the
USCDI, citing several studies of the
benefits of patients having this
information including, but not limited
to, patient literacy, empowerment,
health care coordination, medication
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
adherence, and safety. One commenter
recommended only final notes be
considered applicable to the USCDI and
that the imaging note be removed from
the types of required notes. This
commenter also indicated that notes
that contain sensitive information were
likely subject to a variety of state
privacy laws. A few commenters noted
further standardization work was
needed for provenance data fields.
Response: We appreciate the
commenters’ support and
recommendations; we have shared these
comments about the USCDI with ONC
for future consideration. We agree that
aligning with ONC and finalizing
exchange of the USCDI as defined at 45
CFR 170.213 in ONC’s 21st Century
Cures Act final rule (published
elsewhere in this issue of the Federal
Register) has many benefits and will
help us reach our interoperability goals.
We refer readers to ONC’s final rule for
the specifics of exactly how the USCDI
standard is being finalized by HHS. As
finalized here, the clinical data required
to be made available through the Patient
Access API at 42 CFR 422.119(b)(1)(iii),
431.60(b)(3), and 457.730(b)(3), and 45
CFR 156.221(b)(1)(iii) at a minimum are
the USCDI version 1 as defined at 45
CFR 170.213 and specified in this rule
at 42 CFR 422.119(c)(3)(i),
431.60(c)(3)(i), and 457.730(c)(3)(i), and
45 CFR 156.221(c)(3)(i). We do note the
policies finalized in this regulation do
not alter obligations under existing
federal and state laws. We reiterate that
we are working closely with HL7 and
other partners leading the effort to
develop standards to ensure helpful
guidance is available for payers to
consult as they work to implement the
policies being finalized in this rule.
Again, we note that, though not
mandatory, we are providing a link to
specific implementation guides and
reference implementations that provide
valuable guidance to support payers as
they work to implement the Patient
Access API: https://www.cms.gov/
Regulations-and-Guidance/Guidance/
Interoperability/index.
Comment: One commenter requested
that all the data elements in the USCDI
be specifically enumerated in the
regulation text of this final rule for
clarity. A few commenters
recommended CMS and ONC limit the
definition of electronic health
information to solely the data classes
included in the USCDI. Another
commenter did not believe this
definition should be limited to
identifiable information. One
commenter suggested that the definition
of electronic health information should
include real price information.
PO 00000
Frm 00031
Fmt 4701
Sfmt 4700
25539
Response: We appreciate the
commenters’ recommendations. We are
finalizing our regulation text that
requires use of the standard specified at
45 CFR 170.213 in ONC’s separate
rulemaking to ensure alignment and
consistency across the two regulations.
That specific standard is currently the
USCDI version 1 and therefore the
USCDI will be the initial standard
applicable under this final rule.
Additional information about the data
classes and data elements included in
USCDI can be found at https://
www.healthit.gov/USCDI. We continue
to use ‘‘electronic health information’’
as defined by ONC at 45 CFR 171.102.
With regard to specifically listing the
data elements in the USCDI, we believe
cross referencing ONC’s regulation
better supports our goal of aligning with
ONC’s policy regarding this
information.
Comment: One commenter did not
support the proposed requirement to
provide patients with the USCDI data
because the commenter believed it was
not feasible for payers. The commenter
indicated that payers do not typically
collect clinical data. One commenter
recommended that CMS use FHIR
bundles, or a collection of relevant FHIR
resources, rather than the USCDI. One
commenter was concerned with how
free text fields would be addressed in
the USCDI. One commenter expressed
concern that CMS would require the use
of non-HIPAA standards in the USCDI
for providing data to patients.
Response: We appreciate the
commenters’ concerns and
recommendations. We acknowledge that
payers do not maintain all clinical data
for all patients and our regulation text
at 42 CFR 422.119(b)(1)(iii),
431.60(b)(3), and 457.730(b)(3), and 45
CFR 156.221(b)(1)(iii), as finalized,
specifically limits the obligation to
make clinical data available through the
Patient Access API to those payers that
maintain any such data. If a payer
subject to these regulations (including
the Medicaid and CHIP managed care
plans that are subject to regulations that
incorporate these requirements)
maintain the data elements specified in
this final rule, these data elements must
be shared as noted in this final rule
using the standards indicated. If payers
do maintain valuable clinical data about
patients, patients have a right to these
data. This is a first step in providing
patients with information from their
medical record in an efficient electronic
format.
We appreciate the recommendation to
look at alternatives to the USCDI, but we
believe it is critical for interoperability
to align with ONC and see great value
E:\FR\FM\01MYR2.SGM
01MYR2
25540
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
in the continued coordination between
CMS, ONC, and partners such as HL7 to
ensure helpful guidance is available for
payers to consult as they work to
successfully implement these final rule
policies. To this end, we again note that
we have provided a link to specific
implementation guides and reference
implementations that, though not
mandatory, can be used to support
consistent implementation. We refer
readers to additional information on the
USCDI at https://www.healthit.gov/
USCDI and available guidance at
https://www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index to best understand how to
implement all data classes and elements
included in the USCDI including text
fields. Regarding the use of non-HIPAA
versus HIPAA standards, we do not
believe there is a conflict, and we refer
readers to the discussion of
Administrative Simplification
transaction standards in section
III.C.2.b. of this final rule for more
information.
Comment: One commenter suggested
that standards development
organizations such as HL7 would be
better positioned to support data
standardization rather than the
proposed USCDI approach. A few
commenters noted there are different
use cases for various data types and that
coordination is required to expand the
data in the USCDI. One commenter
recommended CMS allow voluntary
extensions to data sets outside of the
USCDI to support the growth of new
standards and data types from a payer
perspective.
Response: We appreciate the
commenters’ recommendations. In
addition, we appreciate the valuable
role of standards development
organizations, like HL7, and reiterate
our commitment to working with such
partners as industry develops the
necessary standards and associated
guidance to implement the policies
being finalized in this rule. We will
continue to refer to the USCDI as
finalized by HHS in ONC’s 21st Century
Cures Act final rule (published
elsewhere in this issue of the Federal
Register) at 45 CFR 170.213 to ensure
alignment and consistency across the
two regulations. We further refer readers
to additional information about the
USCDI and the expansion process as
defined by ONC at https://
www.healthit.gov/USCDI. We note that
this expansion process is a consensus
process that allows for public input and
comment and strongly recommend
stakeholders continue to engage in this
valuable process. This coordination and
consensus is a cornerstone of our
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
interoperability efforts. We also note
that the data elements required in this
final rule represent the minimum data
that must be shared under our finalized
policy through a payer’s Patient Access
API. We strongly encourage payers to
share more data as the more data that
patients have access to, the more they
will benefit from this access. We agree
that continuing to push these limits will
spur innovation and growth.
Comment: A few commenters
requested additional information
regarding the definitions of terminology
used when discussing the USCDI in the
CMS Interoperability and Patient Access
proposed rule. One commenter
requested more information on the
meaning of ‘‘state agencies,’’ in
reference to ‘‘any clinical data included
in the USCDI standard . . . be available
through the API,’’ and if this meant that
if the state agency managed an
immunization registry it would be
required to make the data available
through an API. Another commenter
requested CMS to provide more
information about the use of ‘‘forward’’
(in the preamble) versus ‘‘send’’ (in the
regulatory text) regarding the USCDI,
including whether the information
needs to be available to the receiving
payer and whether use of a trusted
exchange network is required.
Response: We appreciate the
commenters’ requests for additional
information. We note that the term
‘‘state agencies’’ in this instance in the
proposed rule (84 FR 7634) refers to
those state agencies that manage
Medicaid and CHIP programs. If a
Medicaid or CHIP state agency has
immunization data in connection with
its Medicaid program or CHIP as
defined in the USCDI, these data would
be required to be available via the
Patient Access API per our proposal as
finalized. We note that in section V. of
this final rule, we require the exchange
of the USCDI between payers subject to
this regulation; this payer-to-payer data
exchange does not require the use of an
API. As finalized, our policies do not
require the use of a trusted exchange
network. Regarding the use of terms
‘‘forward’’ and ‘‘send,’’ we note this
means that the data must be exchanged
with the patient as specified here in
section III. of this final rule or between
payers as discussed in section V. of this
final rule.
(4) Drug Benefit Data, Including
Pharmacy Directory, and Formulary
Data
We proposed that drug benefit data,
including pharmacy directory
information and formulary or preferred
drug list data, also be available through
PO 00000
Frm 00032
Fmt 4701
Sfmt 4700
the Patient Access API at proposed 42
CFR 422.119(b)(2)(ii) and (iii),
431.60(b)(5), and 457.730(b)(5). (Our
proposal for providing prescription drug
claims through this API is discussed in
section III.C.2.c.(1) of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7632).) As
previously discussed, Medicaid
managed care plans would be required
by 42 CFR 438.242(b)(6) (finalized as
§ 438.242(b)(5) in this rule; see section
VI.) to comply with the requirement at
42 CFR 431.60(b)(5), and CHIP managed
care entities would be required by 42
CFR 457.1233(d)(2) to comply with the
requirement at 42 CFR 457.730(b)(5).
We proposed at 42 CFR
422.119(b)(2)(ii) and (iii) that MA
organizations offering MA–PD plans
must make available through the API
the following pharmacy benefit data: (1)
Pharmacy directory data, including the
number, mix (specifically the type of
pharmacy, such as ‘‘retail pharmacy’’),
and addresses of pharmacies in the plan
network; and (2) formulary data
including covered Part D drugs and any
tiered formulary structure or utilization
management procedure which pertains
to those drugs. The pharmacy directory
information is the same information that
MA–PD plans—like all Part D plans—
must provide on their websites under 42
CFR 423.128(b)(5) and (d)(2). While
prescription drug claims would have to
be made available through the Patient
Access API no later than one (1)
business day after the MA–PD plan’s
receipt of that information, we did not
propose a specific timeframe for
pharmacy directory or formulary
information to be available (or updated)
through the API. We noted that we
intended that the requirements in 42
CFR part 423 requiring when and how
information related to pharmacy
directories be updated would apply to
the provision of this information
through the API; we solicited comment
whether we should address this in the
regulation text or otherwise impose a
timeframe for this information to be
made available through the API.
At 42 CFR 431.60(b)(5), for Medicaid
FFS programs, and at 42 CFR
457.730(b)(5) for CHIP FFS programs,
we proposed that states would be
required to include and update
information about covered outpatient
drugs and updates to such information,
including, where applicable, preferred
drug list information, no later than one
(1) business day after the effective date
of any such information or updates to
such information.
We did not propose a similar
requirement for QHP issuers on the
FFEs because, like the provider
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
directory information, QHP issuers are
required to make drug formulary data
accessible in a machine-readable format.
As discussed above for the provider
directory information, to avoid
unnecessary duplication of effort and
potential confusion, we are also not
finalizing the proposal to include
pharmacy directory information in the
Patient Access API. Instead, we are only
finalizing the inclusion of this
information as proposed and explained
above be included in the public facing
Provider Directory API discussed in
section IV. of this final rule, which
requires MA organizations that offer
MA–PD plans to provide public access
to pharmacy directory information at 42
CFR 422.120(b). Relevant comments are
also discussed in section IV. of this final
rule.
We summarize the public comments
received on our proposal that
information about drug coverage and
pharmacy benefit coverage be available
through the Patient Access API and
provide our responses.
Comment: One commenter
recommended CMS require that MA
plans make information about patients’
step therapy available for sharing
electronically. This commenter opposes
step therapy and recommended that it
not be used in MA or Part D.
Response: The use of step therapy is
beyond the scope of this rule. However,
because step therapy is a utilization
management procedure, it is included
among the types of information MA–
PDs must make available about Part D
drugs through the API. In regard to
information about utilization
management that pertains to basic
benefits, which was not addressed in
this rule, we appreciate the commenter’s
recommendations and will evaluate
them for potential future consideration.
Comment: One commenter strongly
recommended the inclusion and
standardization of prescription drug
monitoring program data (PDMP) for
exchange through APIs, although this
commenter referred more to exchange
between providers for downstream
clinical decision support and analytics
rather than for patient access. A few
commenters were not in favor of sharing
PDMP data through APIs. A few
commenters were not supportive of
PDMP data being available to other
providers and payers.
Response: We appreciate the
commenters’ recommendations and
concerns. However, we note that this
information is not required to be
available through the Patient Access API
as it is not within the scope of
422.119(b)(2).
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Comment: Several commenters
expressed concern that the proposals in
42 CFR 431.60(b)(5), 457.730(b)(5),
438.242(b)(6) (finalized as 42 CFR
431.60(b)(4), 457.730(b)(4), and
438.242(b)(5) in this rule), and 45 CFR
457.1233(d) to provide information on
covered outpatient drugs and preferred
drug lists through an API within one (1)
business day after the effective date of
the information or updates to the
information may be a challenge for state
Medicaid and CHIP agencies and
Medicaid and CHIP managed care
entities. One commenter recommended
to first require state Medicaid pharmacy
programs to focus on developing
interoperable standards for API
development and only require managed
care entities to adopt the standards once
the API has been tested and scaled at
the state level.
Response: We appreciate the
commenters’ concerns. We understand
that our proposed timeframe of one (1)
business day may be operationally
challenging for states and managed care
plans but continue to believe that this
timeframe is critical in order for
beneficiaries and prescribers to have
this information as soon as the
information is applicable to coverage or
in near real time since this information
could improve care and health
outcomes. We believe that timely data
are particularly important during urgent
or emergency situations. We note that
having access to this information as
soon as, or even before, it is effective is
necessary for patients and their
providers to make important decisions
about which medications should be
included in a patient’s care plan. This
is particularly important for patients
who may not be able to cover a
medication out of pocket if it is not
covered by their plan. Therefore, we are
finalizing the timeframe. We decline to
only apply these requirements to state
Medicaid programs (and decline to
postpone application of the timeframe
to managed care plans until a future
time as recommended by the
commenter) because this approach
would not be consistent with our goal
of ensuring that the patients covered by
the payers impacted by this requirement
have access to the specified data. We
also note that we are providing a link to
specific implementation guidance and
reference implementations for all payers
to further support sharing the needed
data using the required standards:
https://www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. We are finalizing these
requirements for the API to include
formulary information for MA
PO 00000
Frm 00033
Fmt 4701
Sfmt 4700
25541
organizations offering MA–PD plans,
state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP
managed care entities.
In addition to comments about the
specific types of information we
proposed be made available through the
Patient Access API, we also received
comments on additional types of
information stakeholders would like to
see included. We summarize the public
comments we received on this topic and
provide our responses.
Comment: Commenters made a
number of suggestions for additional
data to be made available to patients via
the Patient Access API. Some of the data
requested is already included in the
proposal and being finalized for
inclusion as proposed. In addition to
these requests, a few commenters
recommended CMS also require the
inclusion of information regarding prior
authorization decisions, drug pricing,
and a direct phone number for patients
to call providers and their staff about
prior authorization issues. A few
commenters specifically requested prior
authorization decision information,
including active prior authorizations, be
made accessible to patients; a few other
commenters suggested this prior
authorization information be available
to providers.
Commenters recommended future
versions of the USCDI include
additional data so that these data would
be available via the Patient Access API.
A few commenters recommended the
USCDI include social determinants of
health data. One commenter
recommended CMS and ONC include
additional immunization data elements
from the CDC endorsed data elements
for immunization and the American
Immunization Registry Association’s
Functional Guide. One commenter
recommended Care Team Data Class as
well as Data Class Provenance ‘‘Author
Health Profession’’ be added. One
commenter recommended including
coverage and explanation of benefit data
to the USCDI per the CARIN Alliance’s
Implementation Guide. Another
commenter recommended CMS include
data elements related to administrative
transactions. One commenter
recommended the USCDI include
Digital Imaging and Communications in
Medicine (DICOM) images in addition
to the already included imaging notes.
A few commenters requested CMS
specifically require the use of
Systematized Nomenclature of Dentistry
(SNODENT) for dentistry findings,
disorders, and diagnoses, versus making
SNODENT optional as part of the
proposed USCDI.
E:\FR\FM\01MYR2.SGM
01MYR2
25542
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
A few commenters recommended that
additional care settings or provider
types are considered for additional
USCDI data classes in the future. These
included anesthesiology, registered
dietitian nutritionists, and post-acute
care settings (including hospice). One
commenter recommended that the
USCDI include additional FHIR-based
pharmacy benefit standard-based
formulary and drug benefit data.
Another commenter requested that
Admission, Discharge, and Transfer
(ADT) data classes and data elements be
included in the USCDI. One commenter
recommended CMS work with the
industry to standardize unstructured
encounter data. One commenter was
concerned that the USCDI includes data
traditionally collected in EHRs and that
data/standards for non-health care
transactions are not included (for
example, home modifications). One
commenter expressed concerns that the
USCDI does not include the entire
designated record set, such as images
and genomic test reports and
recommends this be included.
Response: We appreciate the
commenters’ recommendations and will
work with ONC to evaluate these
recommendations for possible future
consideration, as appropriate and
feasible.
We also received comments detailing
concerns with the volume of data being
proposed to be made available through
the Patient Access API. We summarize
the public comments we received on
this topic and provide our responses.
Comment: A few commenters were
concerned with the potential volume of
data that will be made available to
patients through the Patient Access API.
A few commenters requested CMS
provide more information regarding the
minimum information required to be
shared under our policies. One
commenter suggested that an advisory
panel determine the volume and types
of information that patients should
receive.
Response: We appreciate the
commenters’ concerns and
recommendations. Regarding the data to
be made available to patients, as noted
in section III.C.2.b. of this final rule, to
ensure consistent implementation and
minimize the burden on payers, we are
finalizing in the applicable regulations
additional text to specify that MA
organizations at 42 CFR 422.119(h),
state Medicaid FFS programs at 42 CFR
431.60(g), Medicaid managed care plans
at 42 CFR 438.62(b)(1)(vii), CHIP FFS
programs at 42 CFR 457.730(g), CHIP
managed care entities at 42 CFR
457.1233(d), and QHP issuers on the
FFEs at 45 CFR 156.221(i), beginning
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
January 1, 2021 (or beginning with plan
years beginning on or after January 1,
2021 for QHPs on the FFEs), must make
available through the Patient Access API
data they maintain with a date of service
on or after January 1, 2016. We are also
finalizing the same years of data be
available through the Patient Access API
and for the payer-to-payer data
exchange requirement discussed in
section V. of this final rule. These
policies support the ultimate goal to
provide patients access to their
cumulative health information.
We are finalizing as proposed the
minimum content required to be
accessible through the Patient Access
API in the regulation text at 42 CFR
422.119(b), 431.60(b), 438.242(b)(5), and
457.730(b), and 45 CFR 156.221(b). This
specifically includes adjudicated claims
(including cost); encounters with
capitated providers; provider
remittances; enrollee cost-sharing; and
clinical data (including laboratory
results) (where maintained by the
applicable payer), as well as formularies
or preferred drug lists for all impacted
payers except QHP issuers on the FFEs.
As discussed above, these data must be
shared using the content and vocabulary
standards at 45 CFR 170.213, finalized
by HHS in ONC’s 21st Century Cures
Act final rule (published elsewhere in
this issue of the Federal Register), and
in 45 CFR part 162 and 42 CFR 423.160.
We believe that patients have a right to
their health care information so they can
use and share this information to best
inform their health care decisions. We
appreciate the recommendation to
create an advisory panel, and will
evaluate it for potential future
consideration.
d. Documentation Requirements for
APIs
We proposed that the specific
business and technical documentation
necessary to interact with the proposed
APIs be made freely and publicly
accessible. As discussed in section
II.A.1 of the CMS Interoperability and
Patient Access proposed rule (84 FR
7620), we believed transparency about
API technology is needed to ensure that
any interested third-party application
developer can easily obtain the
information needed to develop
applications technically compatible
with the organization’s API.
Transparency is also needed so that
third-parties can understand how to
successfully interact with an
organization’s API. This includes how
to satisfy any requirements the
organization may establish for verifying
a developer’s identity and their
applications’ authenticity, consistent
PO 00000
Frm 00034
Fmt 4701
Sfmt 4700
with the payer’s security risk analysis
and related organizational policies and
procedures. In this way payers can
ensure they maintain an appropriate
level of privacy and security protection
for data on their systems.
Specifically, at 42 CFR 422.119(d),
431.60(d), 457.730(d), and 45 CFR
156.221(d), we proposed virtually
identical text to require the regulated
entities to make complete
accompanying documentation regarding
the API publicly accessible by posting
this documentation directly on the
applicable entity’s website or via a
publicly accessible hyperlink. As
previously discussed, Medicaid
managed care plans would be required
by 42 CFR 438.242(b)(6) (finalized as
§ 438.242(b)(5) in this rule; see section
VI.) to comply with the requirement at
42 CFR 431.60(d), and CHIP managed
care entities would be required by 42
CFR 457.1233(d)(2) to comply with the
requirement at 42 CFR 457.730(d). In
requiring that this documentation be
made ‘‘publicly accessible,’’ we noted
that we expected that any person using
commonly available technology to
browse the internet could access the
information without any preconditions
or additional steps beyond downloading
and using a third-party application to
access data through the API. We also
noted that this was not intended to
preclude use of links the user would
click to review the full text of lengthy
documents or access sources of
additional information, such as if the
technology’s supplier prefers to host
technical documentation at a
centralized location. Rather, we meant
‘‘additional steps’’ to include actions
such as: Collecting a fee for access to the
documentation; requiring the reader to
receive a copy of the material via email;
or requiring the user to read
promotional material or agree to receive
future communications from the
organization making the documentation
available.
We summarize the public comments
received on our proposal regarding API
documentation and provide our
responses.
Comment: Some commenters opposed
the API documentation proposal
indicating payers and providers will be
required to provide data without a
charge, but the freely and publicly
accessible documentation would enable
applications to collect data and possibly
sell the data back to payers and
providers if needed for secondary uses
such as provider directories.
Some commenters supported fees for
documentation noting the funds
required to create and maintain data for
sharing between payers and enrollees.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Commenters believed third parties
should be charged a fee to maintain the
API. One commenter expressed concern
that the business model of the thirdparty applications hinges on their
ability to sell the data they collect for
secondary uses while payers and
providers would be required to provide
information to vendors absent a fee.
This commenter argued that charging
third-party vendors a fee for
documentation could be one way for
vendors to absorb some of the cost of
maintaining the API in exchange for the
data they could potentially use to make
a profit.
Response: We also appreciate the
concerns raised around the secondary
uses of data shared with third-parties.
We note that under section 5 of the FTC
Act (15 U.S.C. Sec. 45(a)), it is
considered a deceptive act to use a
person’s sensitive information without
disclosing in product documentation
how this information will be shared.31
In addition, we do not believe that
charging a fee to access API
documentation is appropriate to offset
secondary data use concerns. We refer
readers to the additional discussion
below regarding informing patients
about potential secondary uses of data.
The data that must be shared via the
API under this policy are data that the
payers have and must currently share
with patients under existing law. The
public directory data is already public
information. We do not believe it is
appropriate to charge a fee for
documentation required to access such
available data. Taking the example of
provider directory data raised by
commenters, currently there are vendors
that collect the publicly available
directory data, clean these data,
supplement these data, and offer this
enhanced data product back to payers
and providers. It is not the data the
vendors are charging for as much as it
is the service of cleaning and enhancing
these data. Vendors may generate
revenue from their third-party apps, but
a major component of this is the service
they are providing—building the app,
making the data the patient directs to
them most usable and valuable—that
generates the revenue. Payers must
already make these data available to
patients. These data alone may also
drive revenue, but it is the patient’s
31 See also cases where this authority was used,
such as 2012 FTC action against Facebook (see
https://www.ftc.gov/enforcement/casesproceedings/092-3184/facebook-inc), the 2012 FTC
action against MySpace (see https://www.ftc.gov/
enforcement/cases-proceedings/102-3058/myspacellc-matter), and the 2017 FTC action against VIZIO
(see https://www.ftc.gov/enforcement/casesproceedings/162-3024/vizio-inc-vizio-inscapeservices-llc).
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
prerogative to provide their data to a
third-party in order to get a service in
exchange. Being sure patients are as
informed as possible about secondary
uses of data and how this may impact
them is important. As a result, we
discuss this issue more below.
Comment: Some commenters
indicated support for permitting access
to documentation without access fees,
citing concern that the fees would be
extended to consumers as well as
logistical concerns for how they would
be paid. A few commenters specifically
recommended alignment with the ONC
21st Century Cures Act proposed rule
API documentation requirement by
using the language included in the
discussion of the proposed requirement
at 45 CFR 170.315(g)(10) stating that the
documentation should be ‘‘accessible to
the public via a hyperlink without
additional access requirements,
including, without limitation, any form
of registration, account creation, ‘clickthrough’ agreements, or requirement to
provide contact details or other
information prior to accessing the
documentation’’ (84 FR 7484).
Response: We do appreciate the
requests to explicitly state what we
mean by ‘‘public access’’ and ensure it
is clear this does not permit any
additional restrictions or fees. As a
result, to further align with the
discussion in the ONC 21st Century
Cures Act proposed rule (84 FR 7477),
and the CMS Interoperability and
Patient Access proposed rule (84 FR
7620), we are finalizing regulation text
stating that ‘‘publicly accessible’’ means
we expect that any person using
commonly available technology to
browse the internet could access the
information without any preconditions
or additional steps, such as a fee for
access to the documentation; a
requirement to receive a copy of the
material via email; a requirement to
register or create an account to receive
the documentation; or a requirement to
read promotional material or agree to
receive future communications from the
organization making the documentation
available. We are finalizing this
requirement at 42 CFR 422.119(d),
431.60(d), 438.242(b)(5) (through crossreference to Medicaid FFS), 457.730(d),
457.1233(d)(2) (through cross-reference
to CHIP FFS), and 45 CFR 156.221(d).
Comment: One commenter did not
support this documentation proposal for
security reasons as the commenter
believed that if the documentation was
public, any third-party or organization
could potentially call, or connect to, a
payer’s API. This commenter preferred
an alternate approach where CMS
stipulates in order to call an API, there
PO 00000
Frm 00035
Fmt 4701
Sfmt 4700
25543
would need to be appropriate security
tokens in place between the two parties
engaged in the data exchange.
Response: We appreciate the
commenters’ concerns. We note,
however, that making the
documentation available publicly does
not impact the security of the standardsbased API itself. This level of
transparency is common in other
industries and across standards, and has
been shown to lead to innovation and
competition. HL7 is built on free and
open documentation to ensure that all
developers can equally access
information. Reviewing the
documentation available for FHIR is one
way of appreciating the value of this
information and how having it freely
accessible can allow innovators to
engage with health care data in the most
meaningful ways.32 Having access to the
documentation is not the same as access
to the actual API for the purposes of
data exchange.
Appreciating the comments received
and the need to have documentation
available to ensure successful
implementation and use of the Patient
Access API, we are finalizing our
proposal to make publicly accessible
documentation that includes, at a
minimum: (1) API syntax, function
names, required and optional
parameters supported and their data
types, return variables and their types/
structures, exceptions and exception
handling methods and their returns; (2)
The software components and
configurations an application must use
in order to successfully interact with the
API and process its response(s); and (3)
All applicable technical requirements
and attributes necessary for an
application to be registered with any
authorization server(s) deployed in
conjunction with the API. As noted, we
have made one modification by adding
the definition of ‘‘publicly accessible’’
to the relevant regulation text.
e. Routine Testing and Monitoring of
Standards-Based APIs
At 42 CFR 422.119(c)(2), 431.60(c)(2),
457.730(c)(2), and 45 CFR 156.221(c)(2)
for MA organizations, state Medicaid
and CHIP FFS programs, and QHP
issuers on the FFEs, respectively, we
proposed that the API must be routinely
tested and monitored to ensure it is
functioning properly, including
assessments to verify that the API is
fully and successfully implementing
privacy and security features such as
but not limited to those required to
32 HL7 International. (n.d.). FHIR Overview.
Retrieved from https://www.hl7.org/fhir/
overview.html.
E:\FR\FM\01MYR2.SGM
01MYR2
25544
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
comply with the HIPAA Privacy and
Security Rules, 42 CFR parts 2 and 3,
and other applicable law protecting
privacy and security of individually
identifiable health information. As
proposed, Medicaid managed care plans
would be required by 42 CFR
438.242(b)(6) (redesignated as
438.242(b)(5) in this final rule; see
section VI. of this final rule) to comply
with the requirement at 42 CFR
431.60(c), and CHIP managed care
entities would be required by 42 CFR
457.1233(d)(2) to comply with the
requirement at 42 CFR 457.730(c).
Additionally, we noted that while
federal laws that regulate MA
organizations and MA plans supersede
any state law except where noted under
section 1856(b)(3) of the Act, some state,
local, or tribal laws that pertain to
privacy and security of individually
identifiable information generally, and
that are not specific to health insurance,
may also apply to MA organizations and
MA plans in the context of the proposal.
For the other entities regulated under
the proposals in these various programs,
we noted that we also intended the
phrase ‘‘other applicable law’’ to
include federal, state, tribal or local
laws that apply to the entity.
We proposed this requirement to
establish and maintain processes to
routinely test and monitor the
standards-based APIs to ensure they are
functioning properly, especially with
respect to their privacy and security
features. We explained in the preamble
of the proposed rule that under the
proposal, MA organizations, Medicaid
and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs
would have to implement, properly
maintain, update (as appropriate), and
routinely test authentication features
that will be used to verify the identity
of individual enrollees who seek to
access their claims and encounter data
and other PHI through the API.
Similarly, as discussed, compliance
with the proposed requirements would
mean that these entities must
implement, maintain, update (as
appropriate), and routinely test
authorization features to ensure an
individual enrollee or their personal
representative can only access claims
and encounter data or other PHI that
belongs to that enrollee. As is the case
under existing HIPAA Privacy Rule
requirements, where an individual is
also a properly designated personal
representative of another enrollee, the
HIPAA covered entity must provide the
personal representative appropriate
access to the information about the
enrollee that has designated them as
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
their personal representative, just as
they would if the personal
representative were the enrollee.
We summarize the public comments
we received on routine testing and
monitoring and provide our responses.
Comment: Several commenters
supported the proposal to require that
payers routinely test and monitor the
standards-based API needed to meet the
requirements of this proposal. One
commenter recommended that this be
self-regulated rather than mandated,
however. A few commenters expressed
concern with the requirement to test
and monitor the API. A few additional
commenters expressed concern that
there is no consensus on a common
testing environment. One commenter
believed that testing and monitoring
will be costly.
Several commenters urged CMS to
provide additional information and
guidance on any requirements for
testing and monitoring APIs, including
the expected frequency of testing. A few
commenters requested additional
information on whether payers will be
required to demonstrate compliance by
submitting or reporting on testing plans.
One commenter requested clarification
on the process if an issue is found
during testing or monitoring. One
commenter requested that CMS specify
what ‘‘routine’’ means.
Response: We appreciate the
commenters’ concerns and
recommendations. We did not specify
exactly at what intervals or frequency
testing should be done, and thus did not
quantify ‘‘routine,’’ as we believe it is
important that payers put a process in
place that works best for them to
conduct testing and monitoring at
regular intervals to ensure the required
API remains in compliance and is
working as expected. We will provide
best practice information, including
information on available API testing
tools to support payers with this
required activity. In our review of the
proposed regulation text, we realized
that the regulation text at 42 CFR
422.119(c)(2), 431.60(c)(2),
457.730(c)(2), and 45 CFR 156.221(c)(2)
did not specify the requirement to also
update (as appropriate) the API to
ensure it functions properly and
includes assessments to verify an
individual enrollee or their personal
representative can only access claims
and encounter data or other PHI that
belongs to that enrollee. We are
finalizing additional text to this effect.
We are also removing the word
‘‘minimally’’ from this regulation text in
order to ensure it is clear that privacy
and security features must be reasonable
and appropriate, consistent with the
PO 00000
Frm 00036
Fmt 4701
Sfmt 4700
requirements of the HIPAA Security
Rule. We note that this testing
requirement is accounted for in sections
XII. and XIII. of this final rule as one of
the expected steps of implementing and
maintaining an API. This is part of the
cost factored into implementation of the
API and is a necessary part of using an
API. It is also part of current software
development best practices. Payers
implementing APIs can incorporate
testing tools into a comprehensive
testing plan and continuous integration
(CI) system, which can automatically
validate adherence to the
implementation guide when changes are
made to further mitigate this cost.
f. Compliance With Existing Privacy and
Security Requirements
In the hands of a HIPAA covered
entity or its business associate,
individually identifiable health
information, including information in
patient claims and encounter data, is
PHI and protected by the HIPAA Rules.
Ensuring the privacy and security of the
claims, encounter, and other health
information when it is transmitted
through the API is important. Therefore,
in the CMS Interoperability and Patient
Access proposed rule (84 FR 7635), we
reminded MA organizations, state
Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs that mechanisms and
practices to release PHI, including but
not limited to authorization and
authentication protocols and practices,
must provide protection sufficient to
comply with the HIPAA Rules and other
privacy and security law (whether
federal, state, tribal, or local) that may
apply based on the specific
circumstances. As proposed, the entities
subject to these requirements would
need to continuously ensure that all
authorization and authentication
mechanisms provide sufficient
protections to enrollee PHI and that they
function as intended. We specifically
requested public comment on whether
existing privacy and security standards,
including but not limited to those in 45
CFR part 164, are sufficient with respect
to these proposals, or whether
additional privacy and security
standards should be required by CMS as
part of the proposal.
We note that comments and our
responses related to privacy and
security issues, generally, can be found
in section II.A.2. of this final rule. Here,
we summarize the public comments we
received on privacy and security as it
relates to consent, authentication, and
identity verification and provide our
responses.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Comment: A few commenters
expressed concerns with using the
proposed FHIR standards for obtaining
patient consent, with some noting the
lack of mature consent mechanisms
supported through FHIR. A few
commenters expressed concerns that
there are no mature or widely accepted
standards for documenting patient
consent electronically, generally. One
commenter suggested that the patient be
able to see their consent preferences and
the types of data that have been
authorized for sharing from a central
location.
One commenter recommended that
CMS or OCR develop a standardized
data sharing patient consent form that
payers, providers, and health IT vendors
can use to ensure appropriate consent.
A few commenters recommended that
CMS require payers and/or apps to use
ONC’s Model Privacy Notice. One
commenter recommended that CMS and
FTC should develop plain language
consumer notifications that could be
used by app developers. One
commenter recommended that CMS
require payers to include in their
enrollment process an efficient ‘‘check
off’’ authorization for an enrollee to
release their information to their
providers. A few commenters noted that
it should be the responsibility of the app
to verify the patient’s ability to provide
consent.
Response: We appreciate the
commenters concerns and
recommendations, and we have shared
these with ONC for consideration.
Regarding FHIR standards for consent,
we refer readers to discussion in the
ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register), which considers the
status of current development efforts
around consent resources. We will
continue to work with ONC and
industry partners to monitor the
development of FHIR resources to
support consent management. We
believe that the security protocols at 45
CFR 170.215 are sufficient to
authenticate users and authorize
individuals to access their data
maintained by payers in accordance
with the requirements described in this
rule and, therefore, provide the
necessary consent mechanisms for
payers to implement the policies in this
rule.
We appreciate the additional
recommendations made regarding
developing consent materials for all
payers to use, as well as
recommendations around the use of the
ONC Model Privacy Notice. More
information on available consent
options can be found at https://
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
gforge.hl7.org/gf/project/cbcc/frs/, and
ONC’s Model Privacy Notice is available
at https://www.healthit.gov/topic/
privacy-security-and-hipaa/modelprivacy-notice-mpn, which interested
payers or app vendors can use. We will
evaluate recommendations made that
would add requirements on payers that
we had not proposed, including any
centralized solution, for possible future
rulemaking.
Comment: Several commenters
supported efforts to verify if an entity is
authorized to access the data they are
seeking. One commenter supported the
proposed use of the OAuth standard.
One commenter believes that the use of
OAuth 2.0 for client application
authorization and OpenID Connect for
client application authentication should
include authenticity, integrity, and nonrepudiation standards. Another
commenter suggested CMS permit
flexibility in the implementation of
security standards. A few commenters
expressed concerns with using the
proposed FHIR standards for identity
proofing alone and supported additional
measures, such as biometrics, be
employed as well. A few commenters
expressed concern about open-ended
token access once initially authenticated
and instead recommended CMS
implement a 90-day timeframe for the
authentication token to remain open.
One commenter suggested that
encryption of authentication credentials
is not sufficient.
One commenter believed that the only
true means by which an individual can
assert their identity is through a
government-issued ID, and if this cannot
be produced, the commenter noted
several limitations that should be put in
place to prohibit data sharing until
further authentication can be done.
Another commenter suggested CMS
look into biometrics as a means for
improving identity proofing. A few
commenters recommended the use of
multi-factor authentication to verify the
identification of an individual.
A few commenters recommended
requiring payers give their members an
online way to self-enroll for the
necessary credentials to access their
health information via an API. One
commenter stated that this will reduce
the time it takes for an organization to
verify a request. One commenter
recommended that this should apply to
any of a payer’s patients who have been
a member in the past 5 years. One
commenter expressed concern that
without clear guidelines for how
patients can access their data, patients
may face barriers such as trying to get
authentication credentials, and trying to
get an app authorized.
PO 00000
Frm 00037
Fmt 4701
Sfmt 4700
25545
A few commenters recommended
CMS develop a common method to
validate the identity and authority of the
requesting party. One commenter
recommended CMS issue guidance on
authenticating the requestor that offers a
simple, secure method to obtain
authentication across all entities. A few
commenters supported efforts to
develop methods to verify a caregiver
for a patient and allow that caregiver to
access all health information systems.
Response: We appreciate the
commenters’ concerns and
recommendations. We are finalizing as
proposed to require compliance with 45
CFR 170.215 as finalized by HHS in the
ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register). This requires use of
HL7 FHIR Release 4.0.1, and
complementary security and app
registration protocols, specifically the
SMART Application Launch
Implementation Guide (SMART IG)
1.0.0 (including mandatory support for
the ‘‘SMART on FHIR Core
Capabilities’’), which is a profile of the
OAuth 2.0 specification, and the
OpenID Connect Core 1.0 standard,
incorporating errata set 1). Additional
information and implementation
guidance can be found at https://hl7.org/
fhir/smart-app-launch/. The goal of
using these resources is to make
authorization electronic, efficient, and
secure so that patients can access their
health information as effortlessly as
possible.
We agree that multifactor
authentication represents a best practice
for privacy and security in health care
settings, and we note that an important
benefit of the OAuth 2.0 standard HHS
is finalizing is that it provides robust
support for multifactor authentication.
By requiring that payers subject to our
Patient Access API requirement use an
API that is conformant with 45 CFR
170.215, where HHS has finalized the
SMART IG, we are supporting the use
of multifactor authentication. We also
note that as part of ONC’s 21st Century
Cures Act final rule (published
elsewhere in this issue of the Federal
Register), HHS is finalizing a new
provision in the ONC certification
program that would require health IT
developers to attest as to whether they
support multifactor authentication,
further encouraging adoption of such
security practices. We also strongly
encourage payers subject to the
requirements in this final rule to employ
robust privacy and security protocols,
and use multifactor authentication,
where appropriate. Multifactor
authentication is industry accepted,
routinely used across many sectors,
E:\FR\FM\01MYR2.SGM
01MYR2
25546
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
known to patients, and a low burden
option that could significantly increase
security.
Though we appreciate commenters’
requests to leave flexibility here, we do
believe adopting the standards as
finalized by HHS in ONC’s 21st Century
Cures Act final rule regarding the use of
the SMART IG (using the OAuth 2.0
standard) and OpenID Connect Core 1.0
is an important starting point. In
addition, we note that the technical
standards at 45 CFR 170.215 address the
comments regarding tokens, as HHS is
finalizing use of tokens at 45 CFR
170.215 as part of the SMART IG. We
note that ONC is requiring that a token
be valid for at least 3 months for
certified health IT; we encourage payers
subject to this final rule to align with
this best practice. We appreciate
recommendations for a centralized
solution to patient authentication and
identity proofing, and caregiver access,
and will take these under consideration
as appropriate.
Comment: Many commenters
expressed that patients should have
ultimate authority and the ability to
consent to what type of information can
be shared as well as who can access
their health information. One
commenter recommended CMS require
that patients have the ability to filter or
request only the specific data that they
want to be shared. One commenter
requested that payers be able to access
the specific types of data a patient
authorized the app to access. One
commenter added patients should also
have an accounting of disclosures or
access to their data.
A few commenters expressed
concerns over the sharing of patient
electronic health information with
health care providers that the patient
has not consented to share with. A few
commenters expressed specific concerns
with sharing electronic health
information beyond the immediate
health care provider, such as with
providers with which a patient may be
seeking a second opinion or additional
care. One commenter was concerned
with the sharing of family health history
data particularly for family members
who have not consented.
A few commenters recommended that
providers be able to pre-filter or select
which data can be made available to the
patient, citing concerns with the
sensitivity of some provider notes or
patient confusion in interpreting certain
information. A few commenters also
suggested that providers be able to
select which information can be made
available to the payer.
Response: We appreciate the
commenters’ concerns and suggestions.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Collectively, HHS has been working to
evaluate various technical specifications
for data segmentation to enhance
privacy protections and comply with
applicable law (such as laws regarding
privacy for minors or 42 CFR part 2).
Both HHS and the industry as a whole
are currently evaluating future use cases
related to segmenting data at the patient
request. At this time, however, the
policies as they are being finalized
under this rule require that the payers,
with the approval and at the direction
of the patient, provide all of the data as
specified in the applicable regulation
text. Beyond this, payers, providers, and
patients cannot direct specific segments
of data be made available via this
Patient Access API. The necessary
technical specifications to allow a
patient to request some data elements be
shared but not others are not widely
adopted.33 If the patient requests their
data via the Patient Access API from a
payer, the payer must make available all
of the data allowed per current law,
such as 42 CFR part 2 and relevant state
laws, including the data as specified in
this final rule. We reiterate, however,
that the data that are available to be
shared are only to be shared at the
patient’s request. If there are data
elements the patient does not want to be
shared, they can choose not to make the
request. In addition, we note that this
policy allows data to be exchanged from
the payer to a third-party app of the
patient’s choice for their personal use.
This rule does not require any data
exchange directly between or with
providers.
Specifically regarding the comment
on sharing family history, we note that
the health information required to be
shared under this policy includes
claims and encounter data as well as the
data included in the USCDI version 1.
At this time, ‘‘family history’’ is not a
specific data class within the USCDI. As
a result, we do not believe this should
be an issue under this current policy.
We will, however, take this into
consideration as we consider future
policy options.
We appreciate the recommendation
for patients to have a full record of
disclosures or access to their health
information via the API. At present, the
HIPAA Privacy Rule requires
accountings of certain disclosures.
Consistent with the spirit of this
accounting of disclosures, we encourage
payers to consider setting up
functionality to allow patients to view a
33 For information on adoption levels for
technical specifications related to data
segmentation, see the Interoperability Standards
Advisory at https://www.healthit.gov/isa/datasegmentation-sensitive-information.
PO 00000
Frm 00038
Fmt 4701
Sfmt 4700
record of when and with whom their
data have been shared via the API.
Comment: Many commenters
expressed concerns over the complexity
with parsing or segmenting electronic
health information that is considered
sensitive and/or is subject to 42 CFR
part 2 rules. Commenters requested
CMS take into account these situations
with these API proposals and cited use
cases such as women’s health, sexual
health, young adult health, mental
health, and substance abuse treatment.
A few commenters noted concerns that
some health care providers may
discriminate or treat a patient
differently if they were able to access
certain patient’s health information. A
few commenters recommended that
HHS align part 2 and HIPAA
regulations. One commenter
recommended the use of the
Consent2Share (C2S) FHIR Consent
Profile developed by SAMHSA. Another
commenter suggested CMS defer
adoption of the Data Segmentation for
Privacy standards until an API FHIR
standard version is finalized and the
Consent2Share guide is revised to
conform to that version.
Response: We appreciate the
commenters concerns and
recommendations. We are currently
evaluating future options around
parsing or segmenting data, generally,
using the API. As noted above, HHS is
collectively working to explore
standards and technical supports for
data segmentation for privacy and
consent management and point
commenters to the ONC 21st Century
Cures Act final rule for additional
discussion on this. We also note that
using the appropriate FHIR profiles,
such as those being finalized by HHS in
the ONC 21st Century Cures Act final
rule (published elsewhere in this issue
of the Federal Register) for API
technical standards, including the
SMART IG (using the OAuth 2.0
standard) and OpenID Connect as
finalized at 45 CFR 170.215, can be
leveraged to support this. Again, we
note that additional information and
implementation guidance can be found
at https://hl7.org/fhir/smart-app-launch/.
However, we reiterate that payers’
privacy and security obligations under
the HIPAA Rules and 42 CFR part 2 are
not impacted by this final rule.
Comment: A few commenters
expressed particular concern for
appropriate authorization of parent/
guardian proxies for minor patients.
One commenter recommended CMS
align the CMS Interoperability and
Patient Access proposed rule with the
Children’s Online Privacy Protection
Act (COPPA), which was created to
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
protect the privacy of children under 13
and has been in effect since 2000.
Response: We appreciate the
commenters concerns and
recommendations, which we are
reviewing for future possible
consideration in regulation. We note
that this current regulation does not
change any existing privacy
relationships between minors and
parents. If, for instance, a teenage minor
has asserted their protections to not
have their guardians see their
Explanation of Benefits, the payer
would be obligated to maintain these
protections when sharing data via the
API. For non-minor dependents, again
the existing policies hold true.
Regarding privacy in an enrollment
group, at this time, a policyholder can
see the claims for all members of their
enrollment group unless there is an
agreed upon privacy provision available
and in place. The HIPAA Privacy Rule
states at 45 CFR 164.522 that
individuals have a right to request
restrictions on how a covered entity will
use and disclose protected health
information about them for treatment,
payment, and health care operations.
However, a covered entity is not
generally required to agree to an
individual’s request for a restriction
unless certain limited exceptions are
met 34, but is bound by any restrictions
to which it does agree. After the
Affordable Care Act extended the age
that group health plans and issuers of
health insurance coverage in the group
or individual market that offer
dependent coverage of children must
continue to make such coverage
available to adult children until age 26,
some states, including California,
Colorado, Washington, Oregon, and
Maryland, have enacted stricter
protections regarding privacy rights, and
although all of these states operate their
own SBEs and issuers on these
Exchanges are not implicated in this
rule, to the extent issuers are operating
in both these and FFE states and have
applied their privacy policies across
markets, consumers in FFE states may
also benefit from these stricter
protections. This final rule does not
alter obligations under any existing
federal, state, local, or tribal law. Again,
we note that this data sharing is
currently ongoing; the API just provides
an additional way to facilitate this
exchange.
34 See 45 CFR 154.522(a)(1)(vi) for a discussion of
the limited exceptions.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
g. Issues Related to Denial or
Discontinuation of Access to the API
We believe patients have a right to
their health information. However, a
covered entity is not expected to tolerate
unacceptable levels of risk to the PHI
held by the covered entity in its
systems, as determined by its own risk
analysis. Accordingly, it may be
appropriate for an organization to deny
or terminate specific applications’
connection to its API under certain
circumstances in which the application
poses an unacceptable risk to the PHI on
its systems.
At 42 CFR 422.119(e), § 431.60(e),
438.242(b)(6) (redesignated as
§ 438.242(b)(5) in this rule; see section
VI.), 457.730(e), 457.1233(d)(2) and 45
CFR 156.221(e) for MA organizations,
state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs, respectively, we proposed
to specify the circumstances under
which these regulated entities, which
are all HIPAA covered entities subject to
HIPAA privacy and security
requirements, may decline to establish
or may terminate a third-party
application’s connection to the covered
entity’s API while remaining in
compliance with the proposed
requirement to offer patients access
through standards-based APIs. We noted
in the CMS Interoperability and Patient
Access proposed rule that we intended
for the proposal to be consistent with
the HIPAA Rules, and we noted that
these circumstances apply to specific
applications, rather than the third party
itself (84 FR 7635 through 7636).
Specifically, we proposed that a payer
subject to our API proposal could deny
access to the API if the payer reasonably
determined that allowing that
application to connect or remain
connected to the API would present an
unacceptable level of risk to the security
of PHI on the payer’s systems. We
further proposed that this determination
would be made consistent with the
payer’s HIPAA Security Rule obligations
and based on objective, verifiable
criteria that would be applied fairly and
consistently across all applications
through which enrollees seek to access
their electronic health information as
defined at 45 CFR 171.102, including
but not limited to criteria that may rely
on automated monitoring and risk
mitigation tools.
Where we proposed to require access
through standards-based APIs to
otherwise publicly available
information, such as provider
directories, the entities subject to the
proposal may also deny or terminate an
PO 00000
Frm 00039
Fmt 4701
Sfmt 4700
25547
application’s connection to the API
when it makes a similar determination
about risk to its systems. However,
depending on how the organization’s
systems are designed and configured,
we recognize that the criteria and
tolerable risk levels appropriate to
assessing an application for connection
to an API for access to publicly available
information may differ from those
required for API access to nonpublished personally identifiable
information (PII).
We also anticipated that, where an
application’s connection has been
terminated under these circumstances,
it might be feasible in some instances
for the organization to allow the
application to reconnect to the API if
and when the flaw or compromise of the
application has been addressed
sufficiently that the organization can no
longer fairly say the application’s API
connection continues to pose an
unacceptable risk.
We summarize the public comments
we received on denial or
discontinuation of service and provide
our responses.
Comment: Several commenters
supported the proposal to allow payers
to deny or discontinue access to apps
that pose security risks. One commenter
specifically supported that the proposal
does not allow payers to deny requests
based on concerns about the worthiness
of the third-party as a recipient of PHI,
because patients have the right to share
their health information with the app
they choose.
Several commenters encouraged CMS
to develop and/or further define
guidelines for identifying ‘‘unacceptable
risk’’ and establish a clearer standard for
acceptable circumstances when API
access can be restricted or denied. A few
commenters expressed concerns that the
proposed requirements may be
interpreted differently among payers,
apps, users, and providers. One
commenter expressed concern because
payers are liable for breaches that occur
during data exchange and the
commenter does not believe the
proposal provides clear authority to
deny access based on such security
concerns. A few commenters requested
that CMS provide more information
regarding whether payers may delay
and/or deny certain apps that are
suspected, or proven to be bad actors.
One commenter requested that CMS
make the distinction between the risk
posed by providing PHI and providing
other widely available payer data. A few
commenters requested CMS define a
time period for how long the ban on
access may remain in place. One
commenter sought additional
E:\FR\FM\01MYR2.SGM
01MYR2
25548
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
information on whether payers will be
able to deny third-party access across
the board for all patient queries and
plans. A few commenters suggested that
CMS should develop a clear process for
app developers to follow in the event
that a covered entity denies access to an
API. A few commenters recommended
that CMS include in the final rule a
reference to ONC’s information blocking
definition and clarify that unacceptable
levels of risk could be an exception to
information blocking.
Response: We appreciate the
commenters’ concerns. As discussed in
the CMS Interoperability and Patient
Access proposed rule, the criteria and
process for assessing unacceptable risk
to a payer’s system are part of the
payer’s responsibilities under the
HIPAA Security Rule (84 FR 7635). The
HIPAA Security Rule requires a covered
entity to perform risk analysis as part of
its security management processes.35
HHS makes a number of tools available
to assess risk.36 Additional tools are
available through the National Institute
of Standards and Technology (NIST).37
We note that this policy regarding
denial or discontinuation of service
refers to a payer’s determination that
allowing access to their API by a third
party would result in risk to their
system. As also noted previously,
covered entities, in accordance with
HIPAA privacy and security obligations,
should take reasonable measures to
protect data in transit, unless an
individual expressly asks that the
information be conveyed in an unsecure
form or format (assuming the individual
was warned of and accepted the risks
associated with the unsecure
transmission). As explained in this
section above, it is the responsibility of
payers to assess the risk to their system
and act accordingly regardless of
whether the data being accessed via the
API is PHI or not. If the concern is the
security of the payer’s system, the type
of data being transferred is not at issue.
Absent an individual’s instruction to
disregard in-transit security, if while
assessing the security of the app’s
connection to the API, the covered
entity determines the data could be
compromised in transit, the payer could
discontinue or deny access in order to
project the ePHI on its system. Again,
35 45
CFR 164.308(a)1)(ii)(A).
more information, see https://
www.hhs.gov/hipaa/for-professionals/security/
index.html.
37 Brooks, S., Garcia, M., Lefkovitz, Ligthman, S.,
& Nadeau, E. (2017, January). NISTIR 8062
An Introduction to Privacy Engineering and Risk
Management in Federal Systems. Retrieved from
https://nvlpubs.nist.gov/nistpubs/ir/2017/
NIST.IR.8062.pdf.
36 For
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
this assessment must be based on
objective, verifiable criteria in
accordance with obligations under the
HIPAA Security Rule. Having
considered comments, we are finalizing
that payers may deny or discontinue
any third-party application’s connection
to their API if the payer reasonably
determines, consistent with its security
analysis under 45 CFR part 164 subpart
C, that allowing an application to
connect or remain connected to the API
would present an unacceptable level of
risk to the security of protected health
information on the payer’s systems or in
transit in instances in which the
individual did not tell the payer to
disregard in-transit risk. For example,
where an individual requests that their
unencrypted ePHI be transmitted to an
app, the payer would not be responsible
for unauthorized access to the
individual’s ePHI while in transmission
to the app. When access has been
denied or discontinued due to security
concerns, we encourage payers and
third parties to work together to address
the concerns if and as possible to best
serve patients. We are not able to set a
specific time period or process for this
as it is beyond our authority, however,
we do note that the HIPAA Privacy Rule
requires access to be provided to the
individual in a timely manner.
Regarding information blocking, we
refer readers to the ONC 21st Century
Cures Act final rule (published
elsewhere in this issue of the Federal
Register).
Comment: One commenter requested
that CMS indicate whether third-party
applications will be subject to HIPAA or
FTC regulations. One commenter
requested information about whether
patients will be able to terminate thirdparty access to their health data.
Response: We appreciate the
commenters’ request for more
information. We refer commenters to
OCR and FTC for additional information
about jurisdiction over third-party apps.
We do note, as discussed earlier, that
under section 5 of the FTC Act (15
U.S.C. Sec. 45(a)), the FTC does regulate
such third-party apps. Regarding a
patient’s ability to terminate third-party
access, this would be something
determined in the terms and conditions
of each app.
Comment: A few commenters
recommended that covered payers
should have the flexibility to establish
additional terms and conditions when
denying third-party applications access
to their systems. One commenter stated
that payers should be able to develop
their own validation process for
enrollees and have the right to not
release the data where the full scope
PO 00000
Frm 00040
Fmt 4701
Sfmt 4700
cannot be validated. One commenter
stated the payers should be able to
refuse to connect to non-vetted apps.
Another commenter stated that payers
should be able to restrict access if the
information exchanged is not permitted
under the HIPAA Privacy Rule or if the
exchange or use would compromise the
confidentiality, integrity, and
availability of the information. One
commenter recommended that CMS
allow covered entities to remove an app
from their system if the app does not
follow the approved privacy policy. One
commenter recommended that
providers should be allowed to require
a business associate agreement (BAA)
with third-party app developers that
connect to the API required under this
final rule. One commenter suggested
allowing restrictions on data mining.
However, one commenter expressed
concern that payers may place
unnecessary barriers and burdens on
third-party app developers. The
commenter encouraged CMS to ensure
that payers cannot place additional
constraints on apps, such as requiring a
BAA, additional security audits, or
requiring that apps make commitments
about how it will or will not use the
information patients store on it.
Response: We appreciate the
commenters’ recommendations.
Specifically, regarding the ability to
deny access to a third-party app, we are
finalizing this policy as proposed with
one modification to add additional
clarity around what it means to
reasonably determine risk. As such, and
as noted above, we are finalizing that
payers may deny or discontinue any
third-party application’s connection to
their API if the payer reasonably
determines, consistent with its security
analysis under 45 CFR part 164 subpart
C, that allowing an application to
connect or remain connected to the API
would present an unacceptable level of
risk to the security of protected health
information on the payer’s systems and
the payer makes this determination
using objective, verifiable criteria that
are applied fairly and consistently
across all applications and developers.
As patients have a right to their data and
this proposal provides the payers the
ability to appropriately protect their
systems and the data they hold on it, we
do not believe any additional
restrictions are needed at this time. We
also note it would not be appropriate to
require a patient-designated third party
to enter into a BAA with a payer as the
API-facilitated exchange is taking place
per the request of the patient and not by,
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
on behalf of, or in service to the payer.38
In addition, we reiterate that it is
beyond our authority to regulate third
parties directly. We do note that under
section 5 of the FTC Act (15 U.S.C. Sec.
45(a)), it is considered a deceptive act to
use a person’s sensitive information
without disclosing in product
documentation how this information
will be shared. We do, however, believe
patient privacy and security are vitally
important. As a result, we lay out an
option for payers to ask a third-party
app to attest to certain privacy
provisions, to help make patients aware
of the privacy risks associated with their
choices, as detailed in the next section.
Comment: Several commenters had
suggestions on how to further this
proposal. A few commenters
recommended that CMS could require
apps to attest to certain privacy and
security provisions, and if they did not,
payers could deny access to the API.
One commenter recommended that
payers be required to vet third-party
applications centrally, rather than
requiring vetting for every payer and
plan. A few commenters expressed
concern that it will be significantly
burdensome for payers and providers to
vet every app that patients may choose
to use in support of more central
vetting. One commenter suggested that
app developers should be able to
proactively request to be vetted by a
payer, even if the app developer has not
received a request from a member.
Many commenters recommended
CMS and/or HHS establish a
certification, independent verification,
or vetting process for third-party
applications and vendors that would vet
or test apps for certain functions,
including privacy and security
assurances. As an alternative, one
commenter recommended CMS require
apps generate an accounting of
disclosures or join a trusted exchange
network.
A few commenters requested CMS
share its best practices with app
authorization and access under the Blue
Button 2.0 initiative. A few commenters
recommended CMS, or the payers preapprove and/or maintain a list of
approved apps in order for them to
access data. Several commenters
supported CMS’ proposal to allow
patients to select any app of their
choice. One commenter recommended
that providers and payers be required to
authenticate the apps their patients
choose to use to gain access.
One commenter recommended that
third-party application should be clear
38 See 45 CFR 164.103 Definitions, regarding
functions of business associate.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
in their terms and conditions when a
consumer downloads an app, and if
they are not, a payer should not be
required to interface with the app. One
commenter recommended that the
proposal for payers to deny or terminate
specific applications from connecting to
its API if the risk posed to its systems
is unacceptable should be extended to
hospitals, health systems, and other
health care providers. One commenter
suggested that payers should be
required to consider the security risks
related to provider EHR systems when
determining whether to deny or
terminate a third-party application. One
commenter recommended that CMS
develop three options for denial of an
application: denial at each API
endpoint, centralized application
denial, or no denial. One commenter
suggested that CMS could consider
allowing providers to voluntarily seek
assurances or certifications that thirdparties are abiding by the API’s terms.
Response: We appreciate the
commenters’ recommendations, and we
appreciate the concerns raised around
privacy and security and the discussion
regarding additional steps we can take
to protect patient health information.
We note that hospitals, health systems,
and other health care providers are
considered covered entities under
HIPAA, and the HIPAA Privacy and
Security Rules apply.
We do appreciate that app vetting, in
particular, is an issue of great interest to
payers and providers. We note that we
strongly value the role that industry can
play in this capacity, and we support
efforts within industry to facilitate
efficient and effective, publicly
accessible information on vetted apps
and vendors. We believe industry is in
the best position to collectively find the
best ways to identify those apps with
strong privacy and security practices.
We also appreciate the commenters’
request for best practices learned
through our experience with Blue
Button 2.0. You can find this
information at https://www.cms.gov/
Regulations-and-Guidance/Guidance/
Interoperability/index.
We are not going to pursue the
recommendation to develop a CMS or
HHS app certification program. Under
our current authorities, we do not
believe we have the ability to require a
third-party app to take part in such a
certification program.
We do appreciate that, above all else,
stakeholders commented on privacy and
security and the need to do more to
protect patient health information.
Throughout this rule we have noted the
limitations to our authority to directly
regulate third-party applications. We
PO 00000
Frm 00041
Fmt 4701
Sfmt 4700
25549
have also explained that we are
finalizing that payers can deny API
access to a third-party app that a patient
wishes to use only if the payer assesses
that such access would pose a risk to the
PHI on their system. We appreciate,
however, that more needs to be done.
In the ONC 21st Century Cures Act
final rule (published elsewhere in this
Federal Register), ONC notes that it is
not information blocking to inform a
patient about the advantages and
disadvantages and any associated risks
with sharing their health information
with a third party. In this rule, we are
finalizing that impacted payers must
share educational resources with
patients to help them be informed
stewards of their health information and
understand the possible risk of sharing
their data with third-party apps. As
discussed above, commenters believe it
is a risk when patients do not
understand what happens after their
data leaves the protection of HIPAA and
are transmitted to a third-party app.
Commenters were specifically
concerned about secondary uses of data.
A clear, plain language privacy policy is
the primary way a patient can be
informed about how their information
will be protected and how it will be
used once shared with a third-party app.
Taking into consideration comments
indicating strong public support for
additional privacy and security
measures, we are further building off of
the privacy and security policies we are
finalizing in this rule by asserting that
MA organizations, Medicaid FFS
programs, Medicaid managed care
plans, CHIP FFS programs, CHIP
managed care entities, and QHP issuers
on the FFEs are encouraged, but are not
required, to request third-party apps
attest to having certain privacy and
security provisions included in their
privacy policy prior to providing the
app access to the payer’s API. If a payer
chooses, they can ask that the apps
requesting access to their API with the
approval and at the direction of the
patient to attest that important
provisions that can help keep a patient’s
data private and secure are in place.
Explaining certain practices around
privacy and security in a patientfriendly, easy-to-read privacy policy
helps inform patients about an app’s
practices for handling their data. It
helps patients understand if and how
the app will protect their health
information and how they can be an
active participant in the protection of
their information. Also, as explained
earlier in this final rule, if an app has
a written privacy policy and does not
follow the policies as written, the FTC
has authority to intervene. As a result,
E:\FR\FM\01MYR2.SGM
01MYR2
25550
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
we assert that impacted payers can, but
are not required to, ask a third-party app
to attest that:
• The app has a publicly available
privacy policy, written in plain
language,39 that has been affirmatively
shared with the patient prior to the
patient authorizing app access to their
health information. To ‘‘affirmatively
share’’ means that the patient had to
take an action to indicate they saw the
privacy policy, such as click or check a
box or boxes.
• The app’s privacy policy includes,
at a minimum, the following important
information:
++ How a patient’s health information
may be accessed, exchanged, or used by
any person or other entity, including
whether the patient’s health information
may be shared or sold at any time
(including in the future);
++ A requirement for express consent
from a patient before the patient’s health
information is accessed, exchanged, or
used, including receiving express
consent before a patient’s health
information is shared or sold (other than
disclosures required by law or
disclosures necessary in connection
with the sale of the application or a
similar transaction);
++ If an app will access any other
information from a patient’s device; or
++ How a patient can discontinue app
access to their data and what the app’s
policy and process is for disposing of a
patient’s data once the patient has
withdrawn consent.
Payers can look to industry best
practices, including the CARIN
Alliance’s Code of Conduct 40 and the
ONC Model Privacy Notice41 for other
provisions to include in their attestation
request that best meet the needs of their
patient population. If a payer chooses to
request third-party apps provide this
attestation, the payer must not
discriminate in its implementation,
including for the purposes of
competitive advantage. Specifically, if a
payer requests this attestation of one
app, it must request it of all apps that
seek to obtain data. If the third-party
app does not attest that their privacy
policy meets the provisions indicated by
the payer, the payer may inform patients
that the app did not attest and advise
them to reconsider using this third-party
app. The notification to the patient
39 Plain Language Action and Information
Network. (2011, May). Federal Plain Language
Guidelines. Retrieved from https://
www.plainlanguage.gov/media/FederalPL
Guidelines.pdf.
40 See https://www.carinalliance.com/our-work/
trust-framework-and-code-of-conduct/.
41 See https://www.healthit.gov/topic/privacysecurity-and-hipaa/model-privacy-notice-mpn.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
should make it clear that the app has
not attested to having the basic privacy
and security protections and indicate
what those are, and that the patient
should exercise caution before opting to
disclose their information to the app. If
the patient still requests the payer make
their data available to the third-party
app, the payer must provide API access
to the app unless doing so would
endanger the security of PHI on the
payer’s systems. This process should
not overly delay the patient’s access. If
the app does not attest positively or at
all, the payer must work to quickly
inform the patient and provide a short
window for the patient to cancel their
request the data be shared. If the patient
does not actively respond, the payer
must move forward as the patient has
already directed their data be shared
and this initial request must be honored.
We believe it is important for patients
to have a clear understanding of how
their health information may be used by
a third-party, as well as how to stop
sharing their health information with a
third-party, if they so choose. We
believe the use of this attestation, in
combination with patient education,
will help patients be as informed as
possible while providing payers with a
lower burden vetting option. We believe
this will better help protect patient
privacy and security and mitigate many
of the concerns raised. Together, this
framework and the requirement for
payers to provide patients with
educational resources will help
continue to move us toward a safer data
exchange environment. This is a critical
focus for CMS, and we look forward to
continuing to work with stakeholders to
keep patient privacy and data security a
top priority.
h. Enrollee and Beneficiary Resources
Regarding Privacy and Security
As discussed in section II.A. of the
CMS Interoperability and Patient Access
proposed rule (84 FR 7618 through
7623), we are committed to maximizing
enrollees’ access to and control over
their health information. We noted that
we believed this calls for providing
enrollees that would access data under
the proposal with essential information
about the privacy and security of their
information, and what to do if they
believe they have been misled or
deceived about an application’s terms of
use or privacy policy.
At 42 CFR 422.119(g), 431.60(f), and
457.730(f), and 45 CFR 156.221(g), we
proposed to require MA organizations,
state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs, to make available to their
PO 00000
Frm 00042
Fmt 4701
Sfmt 4700
current and former enrollees certain
information about: factors to consider in
selecting a health information
management application, practical
strategies to help them safeguard the
privacy and security of their data, and
how to submit complaints to OCR or
FTC. The proposed obligations would
apply to Medicaid managed care plans
and CHIP managed care entities through
cross-references proposed in 42 CFR
438.242(b)(6) (finalized as
§ 438.242(b)(5) in this final rule; see
section VI. of this final rule) and
§ 457.1233(d)(2).
The general information about the
steps individuals can take to help
protect the privacy and security of their
health information should not be
limited to, but should specifically
include and emphasize the importance
of understanding the privacy and
security practices of any application to
which they entrust their data.
Information about submitting
complaints should include both specific
contact information for the OCR and
FTC complaints processes and a brief
overview, in simple and easy-tounderstand language, of: What
organizations are HIPAA covered
entities, OCR’s responsibility to oversee
compliance with HIPAA, and FTC’s
complementary responsibility to take
action against unfair or deceptive
practices, including by non-covered
entities that may offer direct-toconsumer health information
management applications.
We proposed that this information
must be made available on the website
of the payers subject to the proposed
requirement, and through other
appropriate mechanisms through which
the payer ordinarily communicates with
enrollees that are seeking to access their
health information held by the payer.
This could include customer portals,
online customer service help desks, and
other locations, such as any portals
through which enrollees and former
enrollees might request disclosure of
their data to a third-party application
through the payer’s API. We also
proposed that the payer must make this
information available in non-technical,
simple, and easy to understand
language.
We explained in the proposed rule
how we anticipate that payers could
meet the requirement to provide
information to current and former
enrollees in whole or in part using
materials designed for consumer
audiences that are available on the HHS
website. However, we noted that
whether the organization chooses to
draft its own resource materials to
provide the required information or to
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
rely on governmental or other sources
for such materials, the organization will
be responsible for ensuring that the
content of the materials is adequate to
inform the patient regarding the privacy
and security risks, and that it remains
current as relevant law and policy may
evolve over time. We sought comment
on the proposal, and we invited
additional comments on what specific
information resources in addition to
those already available on the websites
noted above would be most useful to
entities in meeting this requirement. We
anticipated using this feedback to help
inform HHS planning and prioritization
of informational resource development
work in addition to making a decision
on the final rule regarding the proposal.
We summarize the public comments
we received on enrollee resources and
provide our responses.
Comment: Several commenters
supported the enrollee resources
proposal that would require payers to
make information available to
consumers about selecting an app,
safeguarding data, and submitting
complaints. Several commenters
supported the recommendation that the
resources be available in consumerfriendly language and be presented in a
way that is easy for consumers to
understand. One commenter requested
more information about whether payers
may make the educational information
available through electronic disclosures,
such as emailing the information to
enrollees, in addition to making the
information available online.
Response: We appreciate the
commenters’ support. We do note that
payers may share the information
through other appropriate mechanisms
usually used to communicate with
patients, such as secure email, as well
as include the information on a payer
website.
Comment: A few commenters
recommended that CMS provide patient
education resources to help patients
understand the information available to
them through the payers’ APIs. These
commenters expressed concerns that
patients may not fully understand the
context of the data, such as detailed
claims information that may not be
intuitive to understand. Several
commenters expressed concern with
consumers’ lack of knowledge about the
privacy and security of their health
information as it relates to third-party
applications. Several commenters
expressed concern that consumers may
not understand that their health
information is not protected by HIPAA
once the information is sent to a noncovered third-party app or how an app
may use their health information.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Many commenters recommended that
CMS develop and/or support education
for consumers. Several commenters
stated that CMS should have the
responsibility to develop educational
materials, rather than the payers or
providers. Many commenters
recommended that CMS collaborate
with other regulatory agencies,
including OCR and the FTC, to provide
consumer education and notification
materials. Several commenters
recommended that CMS and other HHS
agencies develop a campaign to educate
patients about the privacy and security
of health information, including the
risks and challenges when connecting to
third-party apps as well as differences
between HIPAA and non-HIPAA
covered entities and how the differences
may affect how their data are used,
stored, and shared.
Specifically, a few commenters
recommended that CMS and FTC
should require that third-party app
developers inform consumers that
HIPAA privacy rules will not apply
when they agree to share their data with
apps and describe how they will use the
consumer’s data. One commenter
recommended that educational
materials include information on the
differences between HIPAA and FTC
protections. One commenter
recommended that CMS, OCR, or FTC
publish the resources on their website
and maintain a complaint portal. A few
commenters stated that it is the
responsibility of all stakeholders to
inform consumers of their rights and use
of PHI. One commenter recommended
that the responsibility of providing
educational materials to the consumer
should fall on an organization where the
patient may have a longer-term, nontransactional relationship, such as an
HIE.
Several commenters expressed
concern that educational resources will
not be enough to promote privacy and
security. Several commenters
recommended that CMS and ONC
should require third-party apps to
provide notifications on how they may
use, share, or sell their health
information. One commenter expressed
concern that there will not be enough
oversight over third-party apps. The
commenter recommended that CMS use
HIPAA as a framework for developing a
privacy structure for third-party apps.
Response: We appreciate the
commenters’ concerns and
recommendations. We agree it is
important to help ensure patients fully
understand their health information,
their rights, and the implications of
sharing their information. It is also
important patients know what to do if
PO 00000
Frm 00043
Fmt 4701
Sfmt 4700
25551
there is a breach of their health
information. We appreciate that it
would eliminate some burden from
payers and providers if we assist with
the production of the educational
materials needed for the purposes of the
requirements in this final rule. As a
result, CMS is providing suggested
content for educational materials that
payers can use to tailor to their patient
population and share with patients. We
are finalizing the requirement with
modification that payers must publish
on their websites the necessary
educational information, but we will
help supply the content needed to meet
this requirement. The suggested content
we are providing for the educational
materials will be shared through our
normal communication channels
including via listservs and is available
via our website: https://www.cms.gov/
Regulations-and-Guidance/Guidance/
Interoperability/index. The modification
we are making is to refine the language
in the regulation text to expressly state
that payers must include a discussion
about a third-party app’s secondary uses
of data when providing factors to
consider in selecting an application at
42 CFR 422.119(g)(1), 431.60(f)(1), and
457.730(f)(1), and 45 CFR 156.221(g)(1).
In addition, at 42 CFR 422.119(g),
431.60(f), and 457.730(f), and 45 CFR
156.221(g), we are modifying the
regulation text to state the payer must
make these materials available in an
easily accessible location on its public
website.
We note, however, that our authority
is limited to helping payers educate
patients about their privacy and security
rights and where they can go for
additional information. We have shared
commenter feedback with our federal
partners and will continue to work with
all stakeholders to ensure patients,
providers, and payers have the
information they need to address
privacy and security issues relevant to
the regulations finalized in this rule. We
will also continue coordinating with
ONC and all of our federal partners
through the Federal Health IT
Coordinating Council and other federal
partnering opportunities to ensure we
are tracking the impact of this final rule
together, as appropriate. Privacy and
security, however, is a much larger
issue, and we remind commenters that
CMS does not have authority to regulate
third-party apps or their developers or
develop privacy frameworks that exceed
the scope of our authority or this final
rule.
Comment: Several commenters
provided additional recommendations
related to patient resources. One
commenter recommended requiring
E:\FR\FM\01MYR2.SGM
01MYR2
25552
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
payers to include information on how
the consumer can contact the payer
directly to report a privacy or security
breach. One commenter recommended
that CMS develop an easy-to-understand
questionnaire for third-party
applications to fill out that included
information about how the app plans to
use the data. This questionnaire could
be available to patients. One commenter
recommended that educational
information about tools be available to
family members and clinicians and not
just the patient. One commenter
suggested including educational content
for specific conditions or patient
populations, such as for pediatric care.
Several commenters recommended
that CMS include a requirement that the
educational materials developed for
consumers should also include
materials for consumers who may be
limited English proficient or have low
health literacy. A few commenters
recommended that educational
materials should be developed with
special considerations for vulnerable
populations. One commenter
recommended that consistent
information be available across multiple
settings to accommodate varying levels
of technology literacy.
Response: We appreciate the
commenters’ recommendations. As
indicated above, we will be providing
suggested content for educational
materials to assist payers in meeting
their educational obligations under this
final rule as detailed at 42 CFR
422.119(g), 431.60(f), and 457.730(f),
and 45 CFR 156.221(g). We note that
this would also be available to
caregivers and family members as we
are requiring this material to be posted
on the payer’s website. Payers can tailor
these materials to best meet the needs of
their patient populations, including
literacy levels, languages spoken,
conditions, etc. Regarding
recommendations to have patients
contact the payer directly in the event
of a breach, that is the patient’s
prerogative; a payer is required by the
HIPAA Privacy Rule to have procedures
for individuals to submit complaints,
and to provide directions for doing so in
its Notice of Privacy Practices.
Individuals may also submit complaints
to the OCR and FTC, in the appropriate
situations, to address these concerns.
Finally, we reiterate that we do not have
the authority to regulate apps, so we
cannot ask apps to fill out a
questionnaire or facilitate sharing that
information with patients. We do note
that we are making available a
document containing best practices for
app developers to follow, with a special
emphasis on ways to protect the privacy
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
and security of patient data: https://
www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index.
i. Exceptions or Provisions Specific to
Certain Programs or Sub-Programs
We proposed certain exceptions or
specific additional provisions as part of
the CMS Interoperability and Patient
Access proposed rule (84 FR 7637) for
certain QHP issuers on the FFEs. We
also proposed specifics about how MA
organizations subject to the regulations
finalized here would have to include
certain information about the Part D
benefit if the MA organization also
offered Part D benefits; those aspects of
the proposals are addressed in section
III.C.2.c(1) of this final rule.
Related to QHP issuers, we
specifically proposed two exceptions.
First, we proposed that the requirements
proposed in 45 CFR 156.221(a) not
apply to issuers offering only SADPs on
the FFEs. In contrast to QHP issuers of
medical plans, issuers offering only
SADPs offer enrollees access to a unique
and specialized form of medical care.
We believed the proposed standards and
health IT investment would be overly
burdensome for SADP issuers as related
to their current enrollment and
premium intake and could result in
SADP issuers no longer participating in
FFEs, which would not be in the best
interest of enrollees. Additionally, we
believed much of the benefit to
enrollees from requiring issuers of QHPs
to make patient data more easily
available through a standard format
depends upon deployment of standardsbased API technology that conforms to
standards proposed by ONC for HHS
adoption at 45 CFR 170.215 (84 FR
7589) and a corresponding energetic
response by the developer community
in developing innovative, useful, usable,
and affordable consumer-facing
applications through which plan
enrollees can conveniently access, use,
and share their information as they
choose. Based on the proposals to
require implementation of standardsbased API technology in the Medicare,
Medicaid and CHIP programs, as well as
by QHP issuers on the FFEs, we would
anticipate significantly expanding the
implementation of standards-based APIs
by medical plans. However, we noted
that we did not anticipate similar
widespread usage with respect to
SADPs. Therefore, we believed that the
utility of access to issuers’ data is less
applicable to dental coverage, and did
not believe it would be in the interest
of qualified individuals and qualified
employers in the states in which an FFE
operates to not certify SADPs because
PO 00000
Frm 00044
Fmt 4701
Sfmt 4700
they do not provide patient access to
their data through a standards-based
API. We sought comment on whether
we should apply this policy to SADP
issuers in the future.
We also proposed to provide an
exceptions process through which the
FFEs may certify health plans that do
not provide patient access through a
standards-based API, but otherwise
meet the requirements for QHP
certification. We proposed in 45 CFR
156.221(h)(1) that if a plan applying for
QHP certification that is to be offered
through an FFE does not provide patient
access to their data through a standardsbased API, the issuer must include as
part of its QHP application a narrative
justification outlining the reasons why
the plan cannot reasonably satisfy the
requirements in proposed 45 CFR
156.221(a), (b), or (c), the impact of noncompliance upon enrollees, the current
or proposed means of providing health
information to enrollees, and proposed
solutions and timeline to achieve API
compliance. In 45 CFR 156.221(h)(2),
we proposed that the FFE may grant an
exception to the requirement to provide
enrollees access to data through
standards-based API technology, if the
FFE determines that making available
such health plan is in the interest of
qualified individuals and qualified
employers in a particular FFE state. We
anticipated that this exception would be
provided in limited situations. For
example, we would consider providing
an exception for small issuers, issuers
who are only in the individual or small
group market, financially vulnerable
issuers, or new entrants to the FFEs who
demonstrate that deploying standardsbased API technology consistent with
the required interoperability standards
would pose a significant barrier to the
issuer’s ability to provide coverage to
consumers, and not certifying the
issuer’s QHP or QHPs would result in
consumers having few or no plan
options in certain areas. We sought
comment on other circumstances in
which the FFE should consider
providing an exception.
We summarize the public comments
we received on QHP exemptions and
provide our responses.
Comment: Several commenters
supported CMS’ proposal to exempt
SADPs from the requirements to provide
a patient API. These commenters agreed
with the justification offered that dental
information may not be as useful to
patients, as well as the resource burden
concern for SADPs. A few commenters
did not support the proposal to exempt
SADPs from the patient API proposed
requirements, suggesting it may help
dentists and their patients make more
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
informed decisions and that dental
information may help other health care
providers for patient treatment.
Response: We appreciate the
commenters support, as well as the
concerns raised. We believe the
financial impact on SADP issuers may
result in fewer SADPs available in the
FFEs. We may consider the application
of this policy to SADP issuers in future
rulemaking. We are finalizing this
policy as proposed and exempting
SADPs from the Patient Access API at
this time.
Comment: A few commenters
expressed support for the proposal to
allow CMS to review a QHP issuer’s
justification for an exception to the
Patient Access API proposal. One
commenter recommended CMS require
QHPs that are granted an exception to
notify potential enrollees that they will
not be compliant with the requirement
to provide enrollees access to data
through standards-based API
technology. A few commenters did not
support or expressed concern with
CMS’ proposal to grant QHPs an
exception process, fearing an impact to
patient care and uneven patient access
to health data. One commenter did not
want plans and entities to function
solely as data consumers or aggregators.
One commenter suggested that
exceptions should be rare, limited, and
for a defined duration.
A few commenters recommended
CMS establish or work with plans to
make clear the evaluation criteria for
reviewing exception requests to ensure
parity. One commenter recommended
CMS define a standard for expected
alternative API implementation
timeline. This commenter also
recommended CMS establish a timeline
for evaluating exception requests. One
commenter requested CMS specify how
justifications will be submitted as well
as guidance in its annual Letter to
Issuers in the FFEs to assist providers in
understanding the requirements of the
exception application process.
Response: We appreciate the
commenters’ concerns and
recommendations. Regarding concerns
that this exception would impact care
and access to health data, we believe it
is more important to ensure patients
have access to QHPs, and if an
exception can provide consumers
continued coverage, the exception is the
preferable approach. We are evaluating
the additional recommendations
provided for future consideration.
Further, in order to better clarify the
applicability of the API-related
requirements, we are revising 45 CFR
156.221(h) to expand the exceptions
process to encompass all requirements
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
in paragraphs (a) through (g), rather than
(a) through (c) in the proposed rule.
This will ensure that QHP issuers on the
FFEs that are not able to meet any of the
standards will be subject to the
exceptions process. Again, we believe
that ensuring patients have access to
QHPs is paramount. We also note that
additional guidance will be provided to
QHP issuers in the future in order to
specify how issuers will demonstrate
compliance with these standards.
Comment: Several commenters
recommended that CMS expand the
proposal to provide exemptions to the
Patient Access API proposal to other
types of plans for similar reasons
including implementation burden and
potential unintended consequences,
such as driving plans out of the market.
The types of payers that the commenters
recommended be provided exemptions
include MA, Medicaid (including
MCOs, Medicare-Medicaid Plans, Fully
Integrated Dual-Eligible Special Needs
Plan, Long-Term Services and
Supports), CHIP, public health agencies,
smaller QHPs and small plans, and new
and current QHP issuers. A few
commenters recommended CMS
include ‘‘local plans’’ in the definition
of ‘‘small issuer.’’ One commenter
recommended that tribes also be exempt
from this policy.
Response: We appreciate the
commenters’ recommendations, and we
appreciate the concerns that certain
payers may have unique circumstances
making new requirements potentially
more challenging. We note that these
policies only apply to Medicare
Advantage organizations, Medicaid and
CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs. We are
only finalizing one exemption, the
exception noted below, not identified in
the proposed rule, however. We do not
believe the burden or potential
unintended consequences outweigh the
immense benefit to patients and the
potential for improved health outcomes
these policies can facilitate.
As noted earlier in this final rule, we
are modifying the scope of the
applicability of the regulations to QHP
issuers on an individual market FFE. In
considering the application to issuers
offering plans through the FF–SHOPs,
we believe that, like the exception for
issuers of SADPs discussed above, the
financial burden to implement these
policies may result in fewer issuers
offering plans through the FF–SHOPs
and could result in small employers and
consumers having fewer or no FF–SHOP
plan options. Further, we believe that
most FF–SHOP issuers likely would
qualify for exclusion via the exceptions
PO 00000
Frm 00045
Fmt 4701
Sfmt 4700
25553
process we are finalizing. We have
modified 45 CFR 156.221(h)(2) to
remove the reference to ‘‘qualified
employers’’ and paragraph (i) to include
applicability to individual market FFEs.
j. Applicability and Timing
At 42 CFR 422.119(h) and 45 CFR
156.221(i), we proposed specific
provisions regarding applicability and
timing for MA organizations and QHP
issuers on the FFEs that would be
subject to the proposal. We did not
propose specific regulation text for 42
CFR 431.60 or 438.242 because we
intended to make the regulation text
effective on the applicable date, as
discussed below. We noted that we
expected that state Medicaid and CHIP
agencies would be aware of upcoming
new regulations and planning for
compliance with them when they are
applicable, even if the new regulation is
not yet codified in the CFR; we similarly
expected that such agencies will ensure
that their managed care plans/entities
will be prepared for compliance. Unlike
Medicaid state agencies and managed
care plans and state CHIP agencies and
managed care entities, MA organizations
and QHP issuers on the FFEs generally
are subject to rules regarding bid and
application submissions to CMS in
advance of the coverage period; for
example, MA organizations must submit
bids to CMS by the first Monday in June
of the year before coverage starts in
order to be awarded an MA contract. In
an abundance of caution and to ensure
that these requirements for MA
organizations and QHP issuers on the
FFEs are enforceable and reflected in
the bids and applications these entities
submit to us in advance of when the
actual requirements must be met, we
proposed to codify the actual
compliance and applicability dates of
these requirements. We solicited
comment on this approach.
For MA organizations, under 42 CFR
422.119(h), we proposed that the
requirements would be applicable
beginning January 1, 2020. Under the
proposal, the requirements at 42 CFR
422.119 would be applicable for all MA
organizations with contracts to offer any
MA plan on that date and thereafter. We
requested feedback about the proposed
timing from the industry. In particular,
we solicited information and requested
comment from MA organizations about
their current capability to implement an
API consistent with the proposal and
the costs associated with compliance by
January 1, 2020, versus compliance by
a future date.
For Medicaid FFS at 42 CFR 431.60,
CHIP agencies that operate FFS systems
at 42 CFR 457.730, Medicaid managed
E:\FR\FM\01MYR2.SGM
01MYR2
25554
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
care plans at 42 CFR 438.242(b)(6)
(finalized as § 438.242(b)(5) in this rule;
see section VI.), and CHIP managed care
entities at 42 CFR 457.1233(d)(2), we
proposed that the API requirements
would be applicable beginning July 1,
2020, regardless of when the managed
care contract started. We noted that
given the expected date of publication
of the final rule, we believed July 1,
2020, would provide state Medicaid
agencies and CHIP agencies that operate
FFS systems, Medicaid managed care
plans, and CHIP managed care entities
sufficient time to implement. We
solicited comment on the proposal and
whether additional flexibility would be
necessary to take into account the
contract terms that states use for their
Medicaid managed care plans.
For CHIP, we noted that we are aware
that some states do not provide any
benefits on a FFS basis, and we did not
intend for those states to implement an
API outside their managed care plans.
Therefore, we proposed in 42 CFR
457.700(c) that separate CHIP agencies
that provide benefits exclusively
through managed care entities may meet
the requirements of 42 CFR 457.730 by
requiring the managed care entities to
meet the requirements of 42 CFR
457.1233(d)(2) beginning July 1, 2020.
For QHP issuers on the FFEs, we
proposed in 45 CFR 156.221(i) that
these requirements would be applicable
for plan years beginning on or after
January 1, 2020. We sought comment on
the timing of these requirements, and on
how long issuers, particularly smaller
issuers, anticipate it would take to come
into compliance with these
requirements.
We explained in the CMS
Interoperability and Patient Access
proposed rule our belief that these
proposals would help to create a health
care information ecosystem that allows
and encourages the health care market
to tailor products and services to
compete for patients, thereby increasing
quality, decreasing costs, and helping
them live better, healthier lives.
Additionally, under these proposals,
physicians would be able to access
information on their patient’s current
prescriptions and services by reviewing
the information with the patient on the
patient’s personal device or by the
patient sharing data with the provider’s
EHR system, which would save time
during appointments and ultimately
improve the quality of care delivered to
beneficiaries. Most health care
professionals and consumers have
widespread access to the internet,
providing many access points for
viewing health care data over secure
connections. These proposed
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
requirements would significantly
improve beneficiaries’ experiences by
providing a secure mechanism through
which they can access their data in a
standardized, computable format.
We noted that these proposals were
designed to empower patients by
making sure that they have access to
health information about themselves in
a usable digital format and can make
decisions about how, with whom, and
for what uses they will share it. By
making claims data readily available
and portable to the enrollee, these
initiatives supported efforts to move our
health care system away from a FFS
payment system that pays for volume
and toward a payment system that pays
for value and quality by reducing
duplication of services, adding
efficiency to patient visits to providers;
and, facilitating identification of fraud,
waste, and abuse. Data interoperability
is critical to the success of new payment
models and approaches that incentivize
high quality, efficient care. All of the
health care providers for a patient need
to coordinate their care for a valuebased system to work, and that requires
information to be securely shareable in
standardized, computable formats.
Moreover, we noted that patients
needed to understand and be actively
involved in their care under a valuebased framework. We committed to
supporting requirements that focus on
these goals, and we noted we believe
that the specific proposals supported
these efforts.
We summarize the public comments
we received on applicability and timing
of the Patient Access API and provide
our responses.
Comment: A few commenters
supported the proposed timeline for
implementing APIs. One commenter
believes that payers have sufficient time
to prepare APIs and recommended that
CMS maintain the proposed timeline.
One commenter suggested that to
address payer concerns CMS could
reward plans, such as through higher
HEDIS scores, who are able to meet the
January 1, 2020 date.
Many commenters expressed concern
with the proposed implementation
timelines. Many commenters believed
that payers and developers will need
more time to implement the
requirements and encouraged CMS to
delay the implementation date. A few
commenters were concerned that
without sufficient time and resources to
implement security protocols, payers
will be unable to meet the proposed
requirements. Many commenters
believed that additional time will allow
health IT vendors and payers to
develop, test, and implement the
PO 00000
Frm 00046
Fmt 4701
Sfmt 4700
necessary systems. Several commenters
expressed concern with the costs
needed to implement the proposals
under the proposed timelines.
Several commenters recommended an
implementation deadline no earlier than
2021, while several other commenters
recommended a proposed
implementation date of January 1, 2022.
One commenter each suggested January
1, 2023 and January 1, 2024, while
another recommended 12 months after
the publication of the rule. Many
commenters recommended a timeline of
at least 18 to 24 months after
publication of the final rule. Several
commenters recommended aligning the
CMS timelines with the ONC timelines,
therefore recommending CMS
implement policies in this final rule 2
years after the publication of this final
rule. A few commenters recommended
a 36-month timeline for all proposed
policy implementation dates included
in this rulemaking.
A few commenters did not support
proposing a timeline yet. The
commenters noted that the standards
and the infrastructure should be more
mature before implementation dates are
set. One commenter suggested that CMS
and ONC convene a planning group to
establish a more appropriate timeline.
Several commenters encouraged CMS
take a phased approach, which some
explained as creating a ‘‘glide path’’
from ‘‘proof of concept’’ to more
advanced use cases and a more
expansive set of data. Commenters had
a few different recommendations for
which data elements could be included
in which phase of the implementation
in such a scenario. A few commenters
suggested an approach where smaller
plans meet fewer requirements initially
and phase-in to full adoption. One
commenter requested that CMS exempt
small issuers from the requirements of
the rule.
A few commenters recommended
delaying any disincentives and/or
penalties until 2 years after
implementation. One commenter
expressed concern that the different
implementation dates for different
payers may create confusion,
particularly for dual eligible
beneficiaries.
Response: We appreciate the
commenters’ concerns and
recommendations. We understand that
payers need time to be able to develop,
test, and implement the APIs being
finalized in this rule. We appreciate that
it will take time to map and prepare
historic data for sharing via the
standards-based FHIR API. We want to
be sure that payers have the time and
guidance needed to fully and accurately
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
implement the policies being finalized
in this rulemaking. We do not agree,
however, that it is necessary to convene
a planning group to develop a timeline
for implementation. The public has had
the opportunity to provide feedback on
this issue as part of this rulemaking. As
a result, we are finalizing the
implementation date of the Patient
Access API as January 1, 2021 for all
payers impacted by this rulemaking,
except for QHP issuers on the FFEs, for
which the rule will be applicable
beginning with plan years beginning on
or after January 1, 2021. We strongly
encourage payers to implement these
policies as soon as they are capable, but
the Patient Access API will not be
required until January 1, 2021. For
Medicaid managed care, we remind
states that should they determine that
obligations in this rule warrant a
retroactive adjustment to capitation
rates, those adjustments must be
certified by an actuary in a revised rate
certification and submitted to CMS as a
contract amendment, pursuant to 42
CFR 438.7(c).
We do appreciate the commenters’
suggestion to evaluate a phased
implementation approach. As a result,
you will see in section IV. of this final
rule how we are using the Provider
Directory API proposal as a way for
payers to show they are making progress
toward API development and access.
k. Request for Information on
Information Sharing Between Payers
and Providers Through APIs
We proposed the implementation of
standards-based APIs for making
accessible data that a third party could
use to create applications for patients to
access data in order to coordinate and
better participate in their medical
treatment. While in some instances,
direct provider to health plan
transmission of health information may
be more appropriate than sharing data
through a standards-based API, in other
instances a patient may wish to send a
provider a copy of their health
information via another health care
provider’s API. In such cases, patients
could direct the payer to transmit the
health information to an application (for
example, an application offered by a
health care provider to obtain patient
claims and encounter data, as well as
lab test results (if applicable)) on a oneoff and as-needed basis. To the extent a
HIPAA covered entity offers patients
access to their records via a standardsbased application, another HIPAA
covered entity may be able to obtain an
individual’s health information from the
app for treatment, payment, or certain
health care operations purposes,
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
without need of an individual’s
authorization, consistent with the
HIPAA Rules (see 45 CFR 164.506).
Under other laws, providers may need
to obtain specific individual consent to
obtain health information related to care
provided by a behavioral health
provider, treatment received at a
substance use disorder treatment
facility, certain 42 CFR part 2-covered
diagnoses or other claims-related
information, or labs that suggest a part
2 diagnosis. We explained in the CMS
Interoperability and Patient Access
proposed rule how we did not intend to
expand any scope of authority to access
patient data nor to contravene existing
requirements related to disclosure of
PHI under the HIPAA Rules and other
legal standards, but instead specified a
new and additional mechanism by
which to share health information as
directed by the individual, through the
use of API technology in compliance
with all existing federal, state, local, and
tribal privacy and security laws.
We explained how, in the future, we
anticipate payers and providers may
seek to coordinate care and share
information in such a way as to request
data on providers’ or a payer’s patient/
insured overlapping population(s) in
one transaction. We sought comment for
possible consideration in future
rulemaking on the feasibility of
providers being able to request a
download on a shared patient
population using a standards-based API.
We thank commenters for their insights
and are reviewing the comments
received for inclusion in potential
future rulemaking.
In addition to the comments we
received about the specific sections of
this Patient Access API proposal, we
also received a number of comments
that were specific to the types of payers
impacted by the proposal, generally. We
summarize these public comments by
payer type and provide our responses.
We received these public comments
related to Medicare Advantage.
Comment: One commenter suggested
CMS require that MA organizations
make patient data maintained in
connection with the organizations’
various individual and small group
market plans available for access and
exchange through the Patient Access
API.
Response: We appreciate the
commenter’s suggestion. However, in
light of the limits on CMS’s authority
over MA organizations, commercial
insurance, and group health plans, we
are not adopting requirements to apply
as broadly as the commenter suggested.
We note that QHP issuers on the
individual market FFEs are required
PO 00000
Frm 00047
Fmt 4701
Sfmt 4700
25555
under this final rule to implement the
Patient Access API, and we encourage
other individual markets, as well as
small group market plans and group
health plans to do so, as well.
Comment: One commenter
recommended CMS specify the
expectations of MA organizations
regarding supplemental benefits in
relation to the Patient Access API. One
commenter recommended CMS evaluate
whether the standards proposed for this
API are appropriate for the dental care
space.
Response: We appreciate the
commenter’s request for additional
information. We note that MA claims
data, encounter data, and clinical data
related to supplemental benefits,
including dental services, are subject to
the API requirement, even if issuers
only offering SADPs on FFEs are not
subject to the requirement.
Comment: One commenter requested
additional information on whether
Medicare Advantage D–SNPs would be
required to provide patients an API.
Response: We appreciate the
commenter’s request for additional
information. We note D–SNPs are MA
plans offered by MA organizations and
therefore subject to the API requirement
adopted at 42 CFR 422.119.
Comment: One commenter requested
additional information of whether data
shared via an API would be subject to
member communication rules, such as
Medicare Communications and
Marketing Guidelines.
Response: We appreciate the
commenter’s request for additional
information. Whether or not data shared
via the Patient Access API being
finalized at 42 CFR 422.119(b) falls
under the purview of CMS’s
communication and marketing rules
would be dependent on factors such as
the relationship of the developer and
the MA plan(s), the content
accompanying the API data, and the
intended outcome of the application
using the API data. MA plans must
continue to follow the provisions of 42
CFR part 422 (such as but not limited
to 42 CFR 422.118(d), 422.2260 through
422.2268), including in circumstances
when their communications and
marketing materials include data that is
retrieved through an API. For example,
if a field marketing organization (FMO)
uses API data to create a software
application that compares the provider
networks for the plans the FMO is
contracted to sell, the application would
fall under the MA marketing and
communications regulations and CMS’s
oversight. Conversely, if a developer
uses API data to create an independent
application that provides an alternative
E:\FR\FM\01MYR2.SGM
01MYR2
25556
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
means of scheduling provider
appointments, the application would
fall outside of CMS’s purview.
We received these public comments
related to Medicaid and CHIP.
Comment: Several commenters
requested additional information on
which Medicaid programs would be
required to implement and maintain a
standards-based API. One commenter
wanted additional information as to
whether all state’s Medicaid
Management Information Systems
(MMIS) would be required to develop
APIs. This commenter stated that while
it seemed clear that the rule does not
require health plans to use Health IT
modules to make administrative data
available, the role of a payer’s claims
adjudication system (including MMIS)
is unclear.
Response: We appreciate the
commenters’ request for information. In
proposed 42 CFR 431.60 and 457.730,
we specified that states would have to
implement and maintain an API for FFS
Medicaid programs and CHIP; we also
proposed in 42 CFR 438.242(b)(6)
(finalized as 42 CFR 438.242(b)(5) in
this rule; see section VI.) and
457.1233(d) that states would have to
require each MCO, PIHP, and PAHP to
comply with 42 CFR 431.60 (under
Medicaid managed care contracts) and
457.730 (under CHIP managed care
contracts) as if such requirements
applied directly to them. We are
finalizing these policies as proposed.
Sections 431.60 and 457.730 do not
require a specific system to be used for
the implementation and maintenance of
the API, thus we defer to each state and
Medicaid managed care plan to
determine which of their systems would
be the most appropriate.
Comment: One commenter requested
that CMS clarify if an arrangement in
which a state provided beneficiaries
access to their FFS data by delegating
the API function to a managed care plan
would be sufficient to satisfy the rule,
or if each entity in the chain is required
to implement their own systems,
portals, and/or API interfaces. This
commenter questioned if CMS
envisioned the creation of a national
network to exchange Medicare/
Medicaid records that would satisfy
these requirements in a centralized
fashion.
Response: We appreciate the
commenter’s request for information.
We are, however, somewhat unclear
what the commenter meant by
‘‘delegating the API function to a
managed care plan.’’ We believe the
commenter may be questioning if a state
could utilize a managed care plan to
implement the API required for the
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
state’s FFS beneficiaries in lieu of the
state implementing the API required in
42 CFR 431.60. If so, the proposed rule
did not anticipate nor prohibit that type
of an arrangement. As such, this final
rule could permit such an arrangement,
but we remind a state contemplating
using such an arrangement that it must
meet the all of the requirements in this
final rule, including the timelines and
scope specified for data accessibility in
§ 431.60(b). There is no plan for a
national network to exchange Medicare/
Medicaid records in lieu of the APIs
being finalized in this rule at this time.
Comment: One commenter suggested
that CMS establish a stakeholder
workgroup to identify best practices in
data-sharing with Medicaid
beneficiaries.
Response: We appreciate this
suggestion and encourage states and
Medicaid managed care plans to work
with their stakeholders to identify best
practices for data-sharing with Medicaid
beneficiaries in their states.
Comment: A commenter expressed
concern that reimbursing states for
modification of their IT systems at an
enhanced match rate while reimbursing
managed care plans for their system
modifications at the state’s standard
match rate creates an uneven playing
field for Medicaid managed care plans
and a disparity of funding. This
commenter noted that in states that
make extensive use of managed care, the
bulk of system modifications needed to
carry out and maintain the proposed
interoperability capabilities for
Medicaid enrollees will be borne by
Medicaid managed care plans and
requested that CMS revise its proposal
to reflect that all costs attributable to
design, development, installation,
enhancement, or ongoing operation of
both state and Medicaid managed care
plan systems will receive the
appropriate enhanced federal match.
Finally, this commenter requested that
CMS take a more rigorous approach and
update its methodology for review of
state MCO capitation rates to ensure that
proposed rates include reasonable
allowances for costs of IT systems work
performed by the state’s Medicaid
managed care plans in furtherance of
the proposals in this regulation.
Response: We appreciate the
commenter’s concern. However, we do
not agree that the difference in the
federal match rate creates an uneven
playing field. Capitation rates must be
actuarially sound independent of the
federal matching rate that applies to the
payment of those rates. The provision of
enhanced federal match rate is
addressed in section 1903(a)(3)(A) of the
Act and provides a 90 percent match
PO 00000
Frm 00048
Fmt 4701
Sfmt 4700
rate for ‘‘. . . the sums expended during
such quarter as are attributable to the
design, development, or installation of
such mechanized claims processing and
information retrieval systems as the
Secretary determines are likely to
provide more efficient, economical, and
effective administration of the plan
. . .’’ It does not specifically provide an
enhanced match rate for the portion of
a capitation rate that may be included
for information technology
expenditures, and we do not have the
authority to extend the enhanced match
rate beyond the conditions specified in
statute. We already have a very rigorous
capitation rate review process and will
review any changes noted by the states
in those rates, including any specifically
noted for IT system enhancements
specific to the requirements finalized in
this rule.
Comment: One commenter requested
that the new requirement to implement
and maintain an API must be uniform
across the system and non-negotiable to
Medicaid managed care plans, state
government, and providers. One
commenter noted that CMS should
address situations where states may
choose to adopt additional or conflicting
data sharing requirements in Medicaid
or CHIP managed care contracts. This
commenter further stated that it is
critical that covered health plans be
subject to uniform standards for data
accessed through an API and that CMS
should work with state Medicaid and
CHIP programs to ensure that any state
mandated requirements for data
accessed through an API are
harmonized with the new federal
standards. This commenter suggested
that submission of the encounters in a
timely manner by all involved with the
new rule must be a non-negotiable
condition for the receipt of Medicare or
Medicaid reimbursement. In addition,
the commenter noted that enforcement
cannot be left to plans based on variable
contract terms but must be provided by
federal agencies.
Response: We agree with the
commenter that implementation of
standards-based APIs should be
consistent across states and Medicaid
and CHIP managed care plans and have
codified the requirements for APIs in 42
CFR 431.60(b), 457.730(b), 438.242(b)(6)
(finalized as 438.242(b)(5) in this rule;
see section VI.), and 457.1233(d) to
ensure an appropriate level of
uniformity and consistency while still
providing states with an adequate level
of flexibility to go beyond the minimum
standards included in this final rule
when they believe doing so benefits
their beneficiaries. While we do not
have a specific provisions that
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
conditions payment on the timely
receipt of encounters, states and
managed care plans may find that a
useful provision to include in their
contracts. States must have a monitoring
system in effect for their Medicaid
managed care programs under
§ 438.66(b)(6), which also specifies
‘‘information systems, including
encounter data reporting’’ as a required
element. Similarly, we have certain
program oversight responsibilities, such
as the review of certain Medicaid and
CHIP managed care contracts and all
capitation rates, and will incorporate
oversight of requirements in this final
rule to the extent appropriate.
Comment: One commenter noted that
CMS encourages the Medicaid and CHIP
FFS programs to use the API as a means
to exchange PHI with providers for
treatment purposes, suggesting the data
would be shared in advance of a
patient’s visit. But CMS also states that
this proposal can empower the patient
to decide how their health information
is going to be used. This commenter
requested additional information of the
role CMS intends for the patient and the
provider to have in the use of APIs.
Response: While we believe that a
beneficiary’s use of an API to obtain
their health care data will play an
important role in their health care, as
proposed and finalized, this rule does
not set standards for health care
provider use of apps to obtain
information from payers. As proposed
and finalized in 42 CFR 431.60(a) and
457.730(a), the API permits third-party
applications to retrieve a patient’s data
at the patient’s request. A beneficiary
may make the decision to obtain their
health care data through such an app
and share it with a provider in advance
of a visit or otherwise.
Comment: One commenter requested
clarity on whether the proposed rule
requires all states’ MMIS [Medicaid
Management Information System] to
make information available to patients
within one (1) business day of receipt or
adjudication of administrative data
(adjudicated claims, encounters,
provider remittance, etc.). This
commenter expressed concern that these
data could appear to conflict with data
obtained by a patient directly from a
managed care plan, causing confusion
and increasing administrative overhead.
Response: We appreciate the
commenter’s request for additional
information. Medicaid beneficiaries
should not be receiving the information
from both the state and managed care
plan for the same service. If the
beneficiary is receiving a service under
the state’s Medicaid FFS program, the
requirements in § 431.60 apply; that is,
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
the state is responsible for providing the
specified data elements in § 431.60(b)
through the API. If the beneficiary is
enrolled in a managed care plan
(receiving the service under the
managed care plan’s contract), the
requirements in § 438.242(b)(5)
(proposed as § 438.242(b)(6); see section
VI.) apply; that is, the managed care
plan is responsible for providing the
specified data elements in § 431.60(b)
through the API. The beneficiary should
not receive data that is in conflict with
other data that is made available
through the API. The same is true for
CHIP. If the beneficiary is in CHIP FFS,
the requirements in § 457.730 apply;
that is, the state is responsible for
providing the specified data elements in
§ 457.730(b) through an API. If the
beneficiary is enrolled in a managed
care plan, the requirements in
§ 457.1233(d) apply; that is, the
managed care plan is responsible for
providing the specified data elements in
§ 457.730(b) through the API.
Comment: One commenter expressed
concerns regarding the ongoing burden
for state Medicaid and CHIP agencies to
monitor the API, privacy and security
features, and potential security risks
posed by the numerous applications
that may connect to the API. This
commenter recommended that states be
required to monitor the compliance of
each of their managed care plans
regarding the API requirements.
Response: We understand the
commenter’s concerns about burden
related to the API, as well as the need
for states to monitor the API for privacy
and security. These requirements are
specified at 42 CFR 431.60(c)(1) and (2)
and 457.730(c)(1) and (2). While we
understand that there is some burden
for states and managed care plans
related to the development and
implementation of the API, we continue
to believe that the benefits and potential
for improved health outcomes outweigh
the burden associated with these
requirements. We also confirm for
commenters that states are required to
monitor compliance for their contracted
managed care plans in regard to the API
requirements under 42 CFR
438.242(b)(5) (proposed as 42 CFR
438.242(b)(6); see section VI.) and
457.1233(d). Since these requirements
apply to managed care plans, states are
required to include the requirements
under their managed care contracts and
must ensure that plans comply with the
standards specified in 42 CFR 431.60
and 457.730 as if those requirements
applied directly to the managed care
plan.
Comment: Several commenters stated
that the Patient Access API proposal
PO 00000
Frm 00049
Fmt 4701
Sfmt 4700
25557
places a significant burden on Medicaid
and CHIP beneficiaries to monitor the
privacy and security of their own health
information while it is being accessed
by non-HIPAA covered entities. One
commenter recommended that CMS
consider how educational efforts could
be uniquely tailored to specific
populations, such as Medicaid
beneficiaries, particularly given the
need for special considerations when
attempting to engage with vulnerable
populations. This commenter
recommended that CMS amend or
revise the current language in its
proposed rule to explicitly require that
API vendors be responsible for the
education of consumers. Another
commenter noted that many Medicaid
and CHIP beneficiaries are children and
that app developers, states, and
managed care plans will also need to
develop resources for minor access and
control over health information and
educate members accordingly.
Response: We appreciate the
commenters’ concerns, and we
acknowledge that some Medicaid
beneficiaries may find negotiating the
privacy and security app landscape
burdensome. Any patient, including one
who is not comfortable with technology,
may choose not to use this method of
data exchange. However, we would like
all beneficiaries to be able to benefit
from these apps. One way we are
looking to mitigate this burden is
through education. We believe that it is
important for beneficiaries to have the
educational resources to be able to best
evaluate their third-party options. States
and managed care plans must comply
with the requirements 42 CFR 431.60(f)
and 457.730(f) that require states and
managed care plans to develop and
provide on a public website beneficiary
resources regarding privacy and
security, including information on how
beneficiaries can protect the privacy and
security of their health information in
non-technical, simple and easy-tounderstand language. We note in section
III.C.2.h. of this final rule, that CMS will
provide suggested content for
educational material payers can use to
meet this requirement. States, Medicaid
managed care plans, and CHIP managed
care entities have vast experience with
techniques for creating effective
communications for their beneficiaries
and we encourage states and managed
care plans to tailor these resources for
their Medicaid and CHIP populations.
We also agree that states and managed
care plans will need to develop or refine
resources to address patient access for
minor populations and for populations
based on health literacy levels. We do
E:\FR\FM\01MYR2.SGM
01MYR2
25558
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
note that we do not have the authority
to regulate vendors. While we agree that
API vendors should have a role in
educating consumers, states and
managed care plans are the entities
responsible for developing and
implementing the API; therefore, we
believe it is more appropriate for states
and managed care plans to develop and
provide the educational resources for
beneficiaries.
Comment: A few commenters
requested that CMS modify the rule to
exempt Medicaid managed care plans.
Commenters noted that Medicaid
managed care plans are already
operating with razor thin margins and
the proposed rule will substantially
increase the costs for Medicaid managed
care plans. Further, commenters noted
that due to the substantial increase in
costs, plans may not be able to meet the
MLR requirements in 42 CFR 438.8.
Another commenter suggested that CMS
explicitly exclude from the
requirements of the rule long-term
services and supports (LTSS) plans.
Some commenters also recommended
that CMS exclude dental plans from the
requirements in the proposed rule.
Response: We appreciate the
commenters’ concerns, however we are
not exempting Medicaid or CHIP
managed care plans, including LTSS or
dental plans, from the requirements in
this rule, as such an approach would
not be consistent with our goal of
ensuring that all beneficiaries across the
health care market, including Medicaid
FFS and managed care, have access to
and can exchange specified health care
data. We are finalizing the Patient
Access API requirements for state
Medicaid and CHIP agencies and
managed care plans, including LTSS
and dental plans. States and managed
care plans must make adjudicated
claims and encounter data available
through the API for all Medicaidcovered services, including LTSS and
dental. This requirement extends to all
Medicaid-covered services for which a
claim, or encounter claim, is generated
and adjudicated. Regarding costs for
managed care plans—since the Patient
Access API requirements must be
contractual obligations under the
managed care contract—the state must
include these costs in the development
of a plan’s capitation rates.
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments and in the CMS
Interoperability and Patient Access
proposed rule, we are finalizing with
modifications our proposal to require
MA organizations, Medicaid and CHIP
FFS programs, Medicaid managed care
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
plans, CHIP managed care entities, and
QHP issuers on the FFEs to implement
and maintain a standards-based Patient
Access API that meets the technical
standards as finalized by HHS in the
ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) at 45 CFR 170.215,
content and vocabulary standards
adopted at 45 CFR part 162 and 42 CFR
423.160, and finalized by HHS at 45
CFR 170.213 (USCDI version 1), unless
alternate standards are required by other
applicable law; includes the data
elements specified in this final rule, and
permits third-party applications to
retrieve, with the approval and at the
direction of the enrollee, data specified
at 42 CFR 422.119, 431.60, 457.730, and
45 CFR 156.221. Specifically, we are
finalizing that the Patient Access API
must, at a minimum, make available
adjudicated claims; encounters with
capitated providers; provider
remittances; enrollee cost-sharing; and
clinical data, including laboratory
results (where maintained by the
impacted payer). Data must be made
available no later than one (1) business
day after a claim is adjudicated or
encounter data are received by the
impacted payer. We are not finalizing a
requirement for the Patient Access API
to make provider directory and
pharmacy directory information
available. Instead, to limit burden, we
are only requiring provider and, in the
case of MA–PD plans, pharmacy
directory information be included in the
Provider Directory API discussed in
section IV. of this final rule.
We are finalizing the proposed
documentation requirements noting
business and technical documentation
necessary to interact with the API must
be made freely and publicly accessible.
We note that the APIs need to comply
with all existing federal and state
privacy and security laws. We are
finalizing, consistent with the HIPAA
Rules that a payer may deny access to
the Patient Access API if the payer
reasonably determines that allowing a
specific third-party application to
connect or remain connected to the API
would present an unacceptable level of
risk to the security of PHI on the payer’s
systems based on objective and
verifiable criteria. We are also finalizing
that payers need to make available to
enrollees resources explaining factors to
consider in selecting an app for their
health information, practical strategies
to safeguard their privacy and security,
and how to submit complaints to OCR
or FTC. We do note that we are
providing payers with suggested content
they can use and tailor to meet this
PO 00000
Frm 00050
Fmt 4701
Sfmt 4700
requirement, available here: https://
www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/
index. We also note that impacted
payers are allowed to request that thirdparty apps attest to having certain
information included in their privacy
policy, and inform patients about this
attestation, to help ensure patients are
aware of the privacy risks associated
with their choices.
We are finalizing this policy with the
following technical corrections and
additional information. At 42 CFR
422.119(a) and (b)(1); 42 CFR 431.60(a)
and (b); 42 CFR 457.730(a) and (b); and,
45 CFR 156.221(a) and (b) we specify
these policies apply to current patients
and their personal representatives. At 42
CFR 422.119(b)(1)(i), (1)(ii), and (2)(i);
42 CFR 431.60(b)(1) and (2); 42 CFR
457.730(b)(1) and (2); and, 45 CFR
156.221(b)(1)(i) and (ii) we are removing
the word ‘‘standardized’’ to avoid
confusion as the standards are specified
elsewhere. We are finalizing the
regulation text at 42 CFR
422.119(b)(1)(iii), 431.60(b)(3), and
457.730(b)(3), with the verb ‘‘maintains’’
in place of the verb ‘‘manages’’ in order
to more closely align with the relevant
HIPAA Privacy Rule requirement. We
are finalizing a technical correction at
42 CFR 431.60(b)(2) and 42 CFR
457.730(b)(2) to replace ‘‘within one (1)
business day’’ with ‘‘no later than 1
business day after’’ to be consistent
across payers. We have added text to
specifically indicate that the technical
requirements at 42 CFR 422.119(c),
431.60(c), and 457.730(c), and 45 CFR
156.221(c) apply to the API under
paragraph (a) of the respective sections.
We are finalizing at 42 CFR
422.119(c)(2), 431.60(c)(2),
457.730(c)(2), and 45 CFR 156.221(c)(2),
to include additional text to explicitly
require, as described in the CMS
Interoperability and Patient Access
proposed rule (84 FR 7635) the
requirement to also update (as
appropriate) the API to ensure it
functions properly and includes
assessments to verify an individual
enrollee or their personal representative
can only access claims and encounter
data or other PHI that belongs to that
enrollee. In addition, we are removing
the word ‘‘minimally’’ from this
regulation text in order to ensure it is
clear that privacy and security features
must be reasonable and appropriate,
consistent with the requirements of
HIPAA Privacy and Security Rules, 42
CFR parts 2 and 3, and other applicable
law protecting privacy and security of
individually identifiable health
information. We are making a technical
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
change for readability only at 42 CFR
422.119(c)(3) and (4)(ii)(C), 431.60(c)(3)
and (4)(ii)(C), 438.242(b)(5),
457.730(c)(3) and (4)(ii)(C),
457.1233(d)(1), and 45 CFR
156.221(c)(3) and (4)(ii)(C). In addition,
we have refined the language at 42 CFR
422.119(g), 431.60(f), and 457.730(f),
and 45 CFR 156.221(g) to state the payer
must make education materials
available ‘‘in an easily accessible
location on its public website,’’ and at
42 CFR 422.119(g)(1), 431.60(f)(1), and
457.730(f)(1), and 45 CFR 156.221(g)(1)
to include a reference to ‘‘secondary
uses of data.’’
At 42 CFR 422.119(d), 431.60(d),
457.730(d), and 45 CFR 156.221(d), we
are finalizing additional text to specify
that ‘‘publicly accessible’’ means that
any person using commonly available
technology to browse the internet could
access the information without any
preconditions or additional steps, such
as a fee for access to the documentation;
a requirement to receive a copy of the
material via email; a requirement to
register or create an account to receive
the documentation; or a requirement to
read promotional material or agree to
receive future communications from the
organization making the documentation
available.
In the CMS Interoperability and
Patient Access proposed rule, the
criteria and process for assessing
unacceptable risk to a payers system
was explained as part of the payer’s
responsibilities under the HIPAA
Security Rule (84 FR 7635). At 42 CFR
422.119(e)(1), 431.60(e)(1),
438.242(b)(5), 457.730(e)(1), and
457.1233(d), as well as 45 CFR
156.221(e)(1) we are finalizing
additional text to note that payers
should determine risk consistent with
its security risk analysis under 45 CFR
part 164 subpart C to indicate the
specific section of the HIPAA Security
Rule implicated here. We are modifying
45 CFR 156.221(h)(2) to remove the
reference to ‘‘qualified employers’’ and
45 CFR 156.221(i) to include
applicability to ‘‘individual market’’
FFEs to exclude issuers offering plans
through the FF–SHOPs. Finally, we are
finalizing for MA organizations at 42
CFR 422.119(h), Medicaid FFS programs
at 42 CFR 431.60(g), Medicaid managed
care plans at 42 CFR 438.62(b)(1)(vii),
CHIP FFS programs at 42 CFR
457.730(g), CHIP managed care entities
at 42 CFR 457.1233(d), that beginning
January 1, 2021, and for QHP issuers on
the FFEs at 45 CFR 156.221(i) beginning
with plan years beginning on or after
January 1, 2021, these payers must make
available through the Patient Access API
data they maintain with a date of service
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
on or after January 1, 2016, consistent
with the payer-to-payer data exchange
requirement discussed in section V. of
this final rule.
IV. API Access to Published Provider
Directory Data Provisions, and Analysis
of and Responses to Public Comments
A. Interoperability Background and Use
Cases
In section III. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7626 through
7639), we focused on patient access to
their own data through a standardized,
transparent API—the Patient Access
API. As part of this proposal, we
discussed and sought comment on
requiring payers at 42 CFR
422.119(b)(1)(iii) and (b)(2)(ii) for MA
organizations, 42 CFR 431.60(b)(3) for
Medicaid FFS programs, 42 CFR
438.242(b)(6)(ii) for Medicaid managed
care plans, 42 CFR 457.730(b)(3) for
CHIP FFS programs, and 42 CFR
457.1233(d)(2)(ii) for CHIP managed
care entities to provide their provider
directory information through that same
Patient Access API. In addition, the
proposed rule sought comment on
making the provider directory
information available through a publicfacing standards-based API. As we
discussed in the CMS Interoperability
and Patient Access proposed rule (84 FR
7639), making provider directory
information available through a publicfacing API raised different issues than
API access proposals related to patient
data. Based on our consideration of
public comments summarized and
responded to below, and in an effort to
avoid duplicative effort and additional
burden resulting from having the
provider directory information included
in both the Patient Access API and the
Provider Directory API, we are
finalizing the requirement for a publicfacing Provider Directory API at 42 CFR
422.120 for MA organizations, 42 CFR
431.70 for Medicaid FFS programs, 42
CFR 438.242(b)(6) for Medicaid
managed care plans, 42 CFR 457.760 for
CHIP FFS programs, and 42 CFR
457.1233(d)(3) for CHIP managed care
entities, but we will not finalize our
proposal to also provide access to this
provider directory information through
the Patient Access API at 422.119, 42
CFR 431.60, 42 CFR 438.242(b)(6), 42
CFR 457.730, and 42 CFR
457.1233(d)(2), respectively.
Provider directories make key
information about health care
professionals and organizations
available to help consumers identify a
provider when they enroll in an
insurance plan or as new health needs
PO 00000
Frm 00051
Fmt 4701
Sfmt 4700
25559
arise. For example, such information
might include hours of operation,
languages spoken, specialty/services,
and availability for new patients.
Provider directories also function as a
resource used by the provider
community to discover contact
information of other providers to
facilitate referrals, transitions of care,
and care coordination for enrollees.
As discussed in the CMS
Interoperability and Patient Access
proposed rule, the current applicable
regulations for MA plans (42 CFR
422.111) and Medicaid and CHIP
managed care plans (42 CFR
438.10(e)(2)(vi) and (h) and 457.1207,
respectively) already require that
provider directories be made available
to enrollees and potential enrollees in
hard copy and on the plan’s website.
Section 1902(a)(83) of the Act requires
state Medicaid agencies to publish a
directory of certain physicians on the
public website of the State agency. A
regulation for QHP issuers (45 CFR
156.230(b)) requires public access to the
QHP’s provider directory in addition to
distribution and access for enrollees. In
addition to mandating that this
information be accessible, the current
regulations also address the content of
such directories and the format and
manner in which MA plans, Medicaid
managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs
must make the information available.
Making this required provider
directory information available to
enrollees and prospective enrollees
through an API could support
development of third-party software
applications, or apps, (whether
standalone or integrated with providers’
EHR technology) that would pull in
current information about available
providers to meet enrollees’ current
needs. Broad availability of provider
directory data through interoperable API
technology would also allow for
innovation in applications or other
services that help enrollees and
prospective enrollees to more easily
compare provider networks while they
are considering their options for
changing health plans. Finally, we
noted in our proposal that a consistent,
FHIR-based API-driven approach to
making provider directory data
accessible could reduce provider burden
by enabling payers to more widely share
basic information about the providers in
their networks, such as provider type,
specialty, contact information, and
whether or not they are accepting new
patients.
E:\FR\FM\01MYR2.SGM
01MYR2
25560
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
B. Broad API Access to Provider
Directory Data
In sections III.C. and IV. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7633, 7639
through 7642), we proposed to require
at 42 CFR 422.119(b)(1)(iii) for MA
organizations, 42 CFR 431.60(b)(3) for
Medicaid FFS programs, 42 CFR
438.242(b)(6)(ii) for Medicaid managed
care plans, 42 CFR 457.730(b)(3) for
CHIP FFS programs, and 42 CFR
457.1233(d)(2)(ii) for CHIP managed
care entities that payers subject to the
proposed rule make standardized
information about their provider
networks available through API
technology, so that the public, including
third-party app developers and patients,
could access and use that information,
including republishing the information
or information derived from that
information in a user-friendly way. As
discussed in the preamble of the CMS
Interoperability and Patient Access
proposed rule, we sought comment on
making provider directory information
more generally available (84 FR 7639
through 7642). We discussed requiring
that the API technology conform to the
API standards proposed by ONC for
HHS adoption at 45 CFR 170.215 (84 FR
7589). Currently, because QHP issuers
on the FFEs are already required to
make provider directory information
available in a specified, machinereadable format,42 we did not propose
that QHP issuers would have to make
provider directory information available
through an API. However, we requested
information regarding whether this
same requirement should apply to QHP
issuers, or if such a requirement would
be overly burdensome for them. We
thank commenters for their insights on
this request for information and are
reviewing the comments received for
inclusion in potential future
rulemaking.
We noted in the preamble of the
proposed rule that, since this provider
directory information is already
available and accessible to enrollees
without cost to them under existing law,
this information should be as accessible
through the API as it is required to be
when posted on the organization’s
websites. Therefore, we proposed that
the technical standards proposed (now
finalized) by HHS in the ONC 21st
Century Cures Act final rule (published
elsewhere in this issue of the Federal
Register) at 45 CFR 170.215 (specifically
at paragraphs (a)(3) and (b)) that are
specific to authenticating users and
42 Available at https://cmsgov.github.io/QHPprovider-formulary-APIs/developer/.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
confirming individuals’ authorization or
request to disclose their personal
information to a specific application
through an API, namely the SMART IG
(using the OAuth 2.0 standard) and
OpenID Connect Core 1.0, should not
apply to our proposed public access to
provider directory information through
APIs (84 FR 7639). We noted that while
we were aware the organization will
nevertheless need to take appropriate
steps to mitigate the potential security
risks of allowing any application to
connect to the API through which it
offers provider directory access, we
emphasized that these steps should be
appropriate to the level of risk
associated with the specific use case of
accessing otherwise public information
through API technology. We also noted
that those wishing to access these data
should not be unduly burdened by
security protocols that are not necessary
to provide the appropriate degree of
protection for the organization’s systems
and data.
As referenced in sections II. and III. of
the CMS Interoperability and Patient
Access proposed rule (84 FR 7618
through 7639), we intended to develop
additional guidance, incorporating
feedback from industry that provides
implementation best practices relevant
to FHIR-conformant standards-based
APIs to help organizations subject to the
requirements proposed in this
rulemaking. To that end, we solicited
comment on what specific resources
would be most helpful to organizations
implementing APIs under requirements
proposed in the proposed rule.
We summarize all public comments
we received on making provider
directory information available through
an API—in terms of requiring a
dedicated, publicly accessible Provider
Directory API and more generally
sharing provider directory information
via an API, including as proposed under
the Patient Access API discussed in
section III. of this final rule and provide
our responses.
Comment: Many commenters
supported a requirement for MA
organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care
plans, and CHIP managed care entities
to make standardized information about
their provider networks available
through API technology to current
enrollees, prospective enrollees, and
possibly the general public.
Commenters stated that they believe
accurate provider directory data will
improve transparency and accessibility
of information regarding a provider’s
network status, which will help with
efforts to address surprise billing and
PO 00000
Frm 00052
Fmt 4701
Sfmt 4700
other coverage issues related to whether
providers are in or out-of-network.
Response: We thank commenters for
their support. Appreciating that
provider information is already publicly
available, and unlike the other
information included in the Patient
Access API discussed in section III. of
this final rule, is of a less sensitive
nature, to avoid potential confusion and
reduce burden resulting from having the
provider directory information included
in both the Patient Access API and the
Provider Directory API, we are only
requiring that one API—the Provider
Directory API—provide access to
provider directory information. As a
result, we are finalizing additional
regulation text to require the Provider
Directory API at 42 CFR 422.120 for MA
organizations; at 42 CFR 431.70 for
Medicaid state agencies; at 42 CFR
438.242(b)(6) for managed care plans; at
42 CFR 457.760 for CHIP state agencies;
and at 42 CFR 457.1233(d)(3) for CHIP
managed care entities. This Provider
Directory API must include the same
information about the provider directory
as originally proposed for the Patient
Access API. Specifically, the Provider
Directory API must include provider
directory data on a payer’s network of
contracted providers, including names,
addresses, phone numbers, and
specialties, updated no later than 30
calendar days after a payer receives
provider directory information or
updates to provider directory
information. We are finalizing the
applicable regulation text with the
phrase ‘‘complete and accurate’’ to
emphasize our intent that the directory
data meet this standard. For MA
organizations that offer MA–PD plans,
the Provider Directory API must also
make available pharmacy directory data,
we are specifying that the plans must
make available, at a minimum,
pharmacy name, address, phone
number, number of pharmacies in the
network, and mix (specifically the type
of pharmacy, such as ‘‘retail
pharmacy’’). As with the provider
directory information, we are finalizing
that pharmacy directory information
must be updated no later than 30
calendar days after the MA organization
that offers the MA–PD plan receives
pharmacy directory information or
updates to pharmacy directory
information.
Comment: Some commenters
disagreed with the proposal. They stated
that payers are already required to make
this information available and this
proposal could result in unnecessary
duplication of effort and additional
costs. One commenter suggested CMS
provide an exemption for payers that are
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
already providing this information in a
manner that aligns with the
requirements in the proposed rule.
Response: We appreciate the
commenters’ concern about potentially
duplicative effort. While we understand
that different payers are already
required to make this information
available in a machine readable format
or on a public website according to the
different rules associated with each
program, we believe that making this
information available through a
standardized API will bring additional
benefits to enrollees and prospective
enrollees by making it easier for
developers to incorporate this
information into consumer-facing
applications. We note that we did not
propose to extend the requirement
regarding provider directory
information to QHP issuers on the FFEs,
as these issuers are already required to
make provider directory information
available according to a specific
standard for the electronic transfer of
this information, as discussed in the
CMS Interoperability and Patient Access
proposed rule (84 FR 7633).
Comment: Many commenters raised
concerns about the accuracy of provider
directory information that would be
available through the API, and how
these inaccuracies can have a negative
impact on consumers. One commenter
stated that there is a high prevalence of
inaccurate provider directories issued
by MA organizations, in particular, and
for other public and private payers,
generally, and that this can bring into
question the adequacy and validity of a
network. Another noted that inaccurate
provider directories have also resulted
in patients receiving surprise bills as a
result of seeing an out-of-network
physician. Commenters expressed
concern that making provider directory
information more accessible through an
API could exacerbate the impact of
inaccuracies resulting in conflicting and
confusing information for consumers,
for instance, where an enrollee
participates in two plans and receives
different information about the same
provider from each.
Commenters discussed a variety of
steps that CMS should take in concert
with the proposal to ensure that
provider directory information made
available through the API is tested to
ensure it is current, correct, and
accurate. One commenter suggested
CMS require payers to provide API
vendors with accurate provider
directory information.
Response: We appreciate commenters’
concerns and thank the commenters for
their suggestions. We have taken a
number of steps to improve the accuracy
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
of provider directory information for
plans subject to direct regulation by
CMS, such as implementing a process to
audit directory information with MA
organizations to identify deficiencies in
an effort to increase data accuracy (for
more information see https://
www.cms.gov/Medicare/Health-Plans/
ManagedCareMarketing/Downloads/
Provider_Directory_Review_Industry_
Report_Round_3_11-28-2018.pdf). We
will take the suggestions provided into
consideration as we continue this effort.
We encourage all enrollees to check
with a new provider about network
participation to avoid surprises and
continue to explore ways to work with
the payers that we directly regulate (like
MA organizations) to improve the
accuracy of directories.
We are finalizing regulation text on
the Provider Directory API at 42 CFR
422.120(b), 431.70(b), 438.242(b)(6),
457.760(b), and 457.1233(d)(3) to
require that accurate and complete
provider directory information be made
available through the API. We believe
that this language will clarify our
expectation that payers take steps to
ensure provider directory information
made available through the API
accurately reflects the current providers
within the payer’s network.
Commenter: Several commenters
responded to our proposal that
impacted payers update provider
directory information made available
through the API to current and
prospective enrollees within 30 days of
receiving an update to their directory
information. The commenters suggested
that CMS should decrease the amount of
time allowed for updates; for instance,
one commenter suggested that CMS
should require that provider directory
information is updated within 48 hours
of a change, while another
recommended directory updates occur
in real time, or on a regular basis as
frequently as possible.
Some commenters who supported the
requirement that provider directories be
publicly available through API
technology specifically expressed
concerns with how frequently
directories must be updated in the case
of Medicaid and CHIP programs. One
commenter recommended that the clock
for the 30-day requirement begins from
the date the state provides the
information to the Medicaid or CHIP
managed care plan. Another commenter
recommended that entities should be
required to update provider directories
in real-time.
Response: We appreciate commenters’
suggestions, and agree that more
frequent updates of the provider
directory information made available
PO 00000
Frm 00053
Fmt 4701
Sfmt 4700
25561
through the API could help to increase
the accuracy of this information. Our
proposed 30-day time frame was not
intended to preclude payers from
updating the information available via
the API on a shorter timeframe, or from
making updates in real time. However,
we understand that payers may have
different operational processes for
making updates to their provider
directories and are seeking to set a
minimum floor for how frequently
information available through the API
must be updated. This is consistent with
timeframes for other updates some of
these payers are required to make. For
instance, Medicaid managed care plans
must update paper provider directories
monthly and electronic provider
directories no later than 30 days after
the plan receives the updated
information under § 438.10(h)(3).
The Provider Directory API
regulations finalized here require that
state Medicaid and CHIP agencies, and
managed care plans, make available
through the API provider directory
information no later than 30 calendar
days after the state or managed care plan
receives the provider directory
information or updates to the provider
directory information. We confirm that
the state or managed care plan must
make the provider directory information
available through the API within 30
calendar days of receiving the
information. This timeframe for
managed care plans is consistent with
the requirement in § 438.10(h)(3) for
Medicaid managed care plans, which
applies to CHIP managed care entities
under § 457.1207.
We decline to require updates to
provider directories in real-time as we
do not believe that such a timeframe is
operationally feasible for MA
organizations, states or Medicaid and
CHIP managed care plans at this time.
We are finalizing our proposal that MA
organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care
plans, and CHIP managed care entities
update provider directory information
made available through this API within
30 days of receiving a change as
proposed.
Comment: Several commenters
believe that, in order to increase the
accuracy of provider directory data,
CMS should take steps to hold providers
responsible for the accuracy of their
provider directory information. One
commenter suggested CMS require
health care providers to update their
information with a centralized entity,
for instance a trusted health information
exchange, rather than looking to
impacted payers to include these
mandates in their contracts with
E:\FR\FM\01MYR2.SGM
01MYR2
25562
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
providers. Another suggested that CMS
should require providers to submit
rosters to CMS each month indicating
which health plans they contract with,
enabling CMS to validate information
provided through the proposed API.
Another commenter suggested CMS
ensure that CMS-regulated payers are
provided with updated provider
information in a timely manner by
making such reporting requirements a
condition of participation in Medicare.
Response: We appreciate commenters’
suggestions, and agree that providers
have an important role to play in
ensuring that provider directory
information about them, provided to,
and used by the payers with which they
contract or participate, is up-to-date.
While we did not include any proposals
in this rulemaking specifically focused
on provider responsibility for updating
the information to be made available
through the proposed API, we will
continue to work with federal and
industry partners to identify
opportunities to improve the accuracy
of provider directory information across
the health care system.
Comment: Several commenters noted
that a centralized repository that can
serve as a ‘‘source of truth’’ for provider
directory information is needed to
ensure accuracy, and urged CMS to
support work across stakeholders for
such an approach. One commenter
noted that health information exchanges
(HIEs) could help payers to update their
information through access to the
directories that HIEs use for clinical
data exchange.
Response: We thank commenters for
their input. Our policy is focused
around payers making provider
directory information available through
APIs to provide greater access to
specific information on the providers in
their networks. However, we believe
entities focused on aggregating provider
directory information can serve an
important role, and we encourage
payers to work with partners that
maintain this information to improve
accuracy.
Comment: Several commenters
suggested additional information for
inclusion as part of the provider
directory information made available
through the API for current and
prospective enrollees (in addition to
provider names, addresses, phone
numbers, and specialties), such as NPIs
for individual and group providers,
practice group name, health system
name, as well as the specific plan(s) and
tiers a provider participates in. One
commenter also suggested including
minimum provider demographics to be
included in the clinical and
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
administrative transactions to ensure
accurate provider matching; whether the
provider is accepting new patients;
information about which providers are
in-network for a plan by geography and/
or specialty regardless of whether the
individual is a member of a particular
plan or is researching plan options; and
which clinicians are in-network for care
coordination and plan switching
purposes.
Response: We appreciate commenters’
suggestions and agree that this
additional information may be helpful
to consumers. However, at this time we
are seeking to minimize the burden for
the regulated payers that must comply
with this proposal, and have sought to
identify a minimum set of provider
directory information that aligns with
existing requirements applicable to MA
organizations (including MA
organizations that offer MA–PD plans),
state Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP
managed care entities regarding such
directories. We do encourage payers to
explore how they can make additional
provider directory data available
through the API to most benefit current
and prospective enrollees. Also, we note
that the requirements in this final rule
set out the minimum requirements;
payers are strongly encouraged to go
beyond that minimum, if and as
possible, to make useful information
available for their enrollees and
beneficiaries.
Comment: One commenter who
supported our proposal also urged CMS
to take additional steps to make
provider directories more accessible to
enrollees, for instance by integrating a
provider directory in future iterations of
Plan Finder for MA plans, and ensuring
the directory data is accurate and up to
date.
Response: We thank the commenter
for the suggestions. We will take these
suggestions into consideration.
Comment: Several commenters
addressed issues with technical
standards for provider directory
information, with several stating that
appropriate standards for making this
information available through an API
are still emerging. For instance, one
commenter noted that current provider
directory standards were written for
FHIR Release 3 and that the standard
has not been adopted by the field. The
commenter stated that before CMS
requires payers to make provider
directory information available via a
standards-based API, more work is
needed to build the provider directory
specification in FHIR Release 4.
Several commenters suggested that
CMS should delay implementing this
PO 00000
Frm 00054
Fmt 4701
Sfmt 4700
proposal, proposed to be applicable
starting January 1, 2020, until
stakeholders have been able to establish
consensus-based standards for the
creation and display of directory
information. One commenter
encouraged CMS to develop a voluntary,
multi-stakeholder partnership to
establish data content FHIR-based
standards related to provider directories
and then wait to establish the timeframe
for provider directory data updates until
the development of these FHIR-based
standards are completed.
Response: We appreciate commenters’
concerns, and agree that updated FHIRbased provider directory
implementation guidance is important
for implementation of this policy. We
confirm here that HL7 FHIR Release
4.0.1—the API standard adopted at 45
CFR 170.215 and which must be used
under our Provider Directory API
requirement—provides a base standard
for moving information through an API.
The basic information (name, phone
number, address, and specialty)
required for this Provider Directory API
can all be represented through FHIR
Release 4.0.1. Additional
implementation guidance will provide
additional information for how to use
the FHIR Release 4.0.1 base standard to
make provider directory information
available and ensure greater uniformity
in implementation and reduce
implementation burden for payers. As
noted in section III. of this final rule, we
have been working with HL7 and
partners to ensure the necessary
consensus-based standards and
associated guidance are available so that
impacted payers can consistently
implement all of the requirements
included in this final rule. We are
providing a link to a specific FHIR
Release 4.0.1 implementation guide and
reference implementation for all
interested payers for the Provider
Directory API that provide valuable
guidance to further support sharing the
needed data using the required
standards: https://www.cms.gov/
Regulations-and-Guidance/Guidance/
Interoperability/index. Though not
mandatory, using this guidance will
lower payer burden and support
consistent implementation of the FHIR
Release 4.0.1 APIs.
Appreciating the time needed for
payers to build, implement, and test
these APIs, we are providing additional
time for implementation, and are
finalizing January 1, 2021 as the
implementation date for the Provider
Directory API for all payers subject to
this requirement. Appreciating the value
of making this information publicly
accessible, we do encourage payers to
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
implement this Provider Directory API
as soon as they are able. We are
requiring at 42 CFR 422.120 for MA
organizations, at 42 CFR 431.70 for
Medicaid state agencies, at 42 CFR
438.242(b)(6) for Medicaid managed
care plans, at 42 CFR 457.760 for CHIP
state agencies, and at 42 CFR
457.1233(d)(3) for CHIP managed care
entities that these payers make the
Provider Directory API accessible via a
public-facing digital endpoint on their
website. We will check a random
sample of payer websites for links to
these publicly accessible APIs, starting
in January 2021 to evaluate compliance.
Comment: One commenter suggested
that, as CMS already requires provider
directory information to be made
available online by payers subject to this
rule, for interoperability transactions
CMS should require use of a standard
described as ‘‘the HIPAA 274
transaction.’’ The commenter stated that
the metadata defined within this
transaction can drive a consistent
payload for an API to support provider
directory information sharing.
Response: We appreciate the
commenter’s suggestion, but at this time
we are finalizing requirements for
provider directory information to be
available through an API using the
standards at 45 CFR 170.215, including,
FHIR Release 4.0.1 standards finalized
by HHS in the ONC 21st Century Cures
Act final rule (published elsewhere in
this issue of the Federal Register) to
consistently align all various API
formats throughout the rule with a
single modern standard capable of
meeting all requirements. CMS
understands that some information
within the X12 274 Transaction
(Healthcare Provider Information
Transaction Set for use within the
context of an Electronic Data
Interchange (EDI) environment) may
provide the basic provider information
to support an API. HHS, however, has
not adopted the X12 274 transaction
standard under HIPAA or for any other
use. Moreover, the required availability
of a plan’s entire provider directory via
an API is not a HIPAA transaction that
has been defined or associated with a
specific transaction under HIPAA. We
believe that using FHIR Release 4.0.1 for
the purpose of this Provider Directory
API will provide greater long term
flexibility for payers subject to this rule,
allowing them the ability to meet
minimum requirements, and extend
beyond these requirements based on the
industry’s diverse and evolving needs
surrounding provider directories, while
reducing impact on those who may not
be ready to receive additional
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
information beyond the minimum set of
data required by this final rule.
Comment: One commenter requested
that CMS ensure public health agencies
are also able to access provider directory
information made available through the
API, while another commenter
requested that approved agents and
brokers be granted access to this
information.
Response: Under this final rule, the
Provider Directory API must be publicly
accessible, so that any third party can
access an impacted payer’s provider
directory information. Our regulation
text reflects this by requiring that the
Provider Directory API be accessible via
a public-facing digital endpoint on the
applicable payer’s website. The value of
making this information available via an
API is that third-party developers will
be able to access it to make it available
in valuable and useful ways for all
interested stakeholders. We therefore
anticipate that public health agencies,
agents, and brokers, and any other
member of the public would be able to
access these data via third-party apps.
Comment: Several commenters
suggested CMS require payers to
include other types of non-physician
professionals within their provider
directories, such as nurse practitioners,
certified registered nurse anesthetists,
physical therapists, and post-acute care
providers. Commenters stated that
including additional qualified licensed
non-physician providers could help
increase patient access to care.
Response: We appreciate commenters’
suggestions. We did not propose to
change the parameters of the
information required to be included in
provider directories for the payers
subject to the Provider Directory API
requirement here. Existing requirements
for paper and on-line provider
directories, such as those in 42 CFR
422.111 and 438.10(h), are not changed
or limited by this final rule. Instead, our
API proposals and this final rule focus
on making certain payers (that is, MA
organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care
plans, and CHIP managed care entities)
share provider directory information
through an API. How ‘‘provider’’ is
defined in this context is outside the
scope of this regulation.
Comment: One commenter
recommended that CMS amend the API
requirement to also include FHIR
endpoint information for providers as
part of provider directory information,
to ensure access to regional/national
directories in addition to the current
partial ones.
Response: We agree with commenters
that FHIR endpoint information is
PO 00000
Frm 00055
Fmt 4701
Sfmt 4700
25563
important to improve interoperability
across providers. We discuss FHIR
endpoints in section IX. of this final
rule. For this Provider Directory API, we
have focused on a minimum set of
information of primary interest to
patients and typically found in provider
directories. However, we encourage
payers to consider including other data
elements that may add value to the
Provider Directory API. We may
consider expanding this minimum set of
information in potential future
rulemaking.
Comment: One commenter suggested
that CMS impose penalties on plans that
do not comply with the provider
directory requirement.
Response: We thank the commenter
for this suggestion. We did not propose
to establish additional penalties for
noncompliance with the requirement to
make provider directory information
available through an API; however, we
note that the requirement to make
provider directory information available
through an API will be a requirement for
MA organizations, Medicaid managed
care plans and CHIP managed care
entities to fulfill under their contracts in
their respective programs. Therefore,
existing enforcement authority for
ensuring compliance with those
contracts will apply. Further, the API
requirements, including the provider
directory components of the required
API(s) will be required for state
Medicaid and CHIP agencies operating
FFS Medicaid programs and CHIPs.
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments and in the CMS
Interoperability and Patient Access
proposed rule, we are finalizing
regulations to require that MA
organizations, Medicaid and CHIP FFS
programs, Medicaid managed care
plans, and CHIP managed care entities
make standardized information about
their provider networks available via a
FHIR-based API conformant with the
standards finalized by HHS in the ONC
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) at 45 CFR 170.215
(including FHIR Release 4.0.1),
excluding the security protocols related
to user authentication and authorization
and any other protocols that restrict the
availability of this information to
anyone wishing to access it. At a
minimum, these payers must make
available via the Provider Directory API
provider names, addresses, phone
numbers, and specialties. For MA
organizations that offer MA–PD plans,
we are specifying that they must make
available, at a minimum, pharmacy
E:\FR\FM\01MYR2.SGM
01MYR2
25564
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
directory data, including the pharmacy
name, address, phone number, number
of pharmacies in the network, and mix
(specifically the type of pharmacy, such
as ‘‘retail pharmacy’’), updating the
regulation text from the proposed rule,
which simply stated ‘‘number, mix, and
addresses of network pharmacies’’. All
directory information must be available
through the API within 30 calendar days
of a payer receiving the directory
information or an update to the
directory information. We note we have
also revised the proposed regulation text
for making directory information
available through an API to specify
consistently that the directory
information must be complete and
accurate and that updates must be made
in ‘‘calendar’’ days.
The Provider Directory API is being
finalized at 42 CFR 422.120 for MA
organizations, at 42 CFR 431.70 for
Medicaid state agencies, at 42 CFR
438.242(b)(6) for Medicaid managed
care plans, at 42 CFR 457.760 for CHIP
state agencies, and at 42 CFR
457.1233(d)(3) for CHIP managed care
entities. We are finalizing that access to
the published Provider Directory API
must be fully implemented by January
1, 2021 for all payers subject to this new
requirement. We encourage payers to
implement this Provider Directory API
as soon as they are able to make and
show progress toward the API
requirements in this final rule and to
signal their commitment to making the
information that will empower their
patients easily accessible and usable.
Under this final rule, MA organizations,
Medicaid and CHIP FFS programs,
Medicaid managed care plans, and CHIP
managed care entities must make the
Provider Directory API accessible via a
public-facing digital endpoint on their
website to ensure public discovery and
access.
V. The Health Information Exchange
and Care Coordination Across Payers:
Establishing a Coordination of Care
Transaction To Communicate Between
Plans Provisions, and Analysis of and
Responses To Public Comments
We proposed a new requirement for
MA organizations, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs to require
these payers to maintain a process to
coordinate care between payers by
exchanging, at a minimum, the USCDI
at the enrollee’s request as specified in
the proposed regulation text. Instead of
specifically proposing use of the USCDI,
we proposed use of a content standard
adopted by ONC at 45 CFR 170.213,
which was proposed in a companion
proposed rule, the ONC 21st Century
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Cures Act proposed rule as the USCDI
(version 1) (84 FR 7441 through 7444).
Understanding that enrollees’
information is already exchanged
between plans for use in carrying out
various plan functions,43 payers have
experience exchanging, receiving, and
incorporating data from other plans into
an enrollee’s record. We proposed
requiring the USCDI data set be
exchanged at the enrollee’s direction,
and when received by a payer,
incorporated into the recipient payer’s
data system. As proposed, upon request
from an enrollee, the USCDI data set
would have to be sent to another payer
that covers the enrollee or a payer
identified by the enrollee at any time
during coverage or up to 5 years after
coverage ends, and the payer would
have to receive the USCDI data set from
any payer that covered the enrollee
within the preceding 5 years. These
proposals were intended to support
patient directed coordination of care;
that is, each of the payers subject to the
requirement would be required to, upon
an enrollee’s request: (1) Receive the
data set from another payer that had
covered the enrollee within the previous
5 years; (2) send the data set at any time
during an enrollee’s enrollment and up
to 5 years later, to another payer that
currently covers the enrollee; and (3)
send the data set at any time during
enrollment or up to 5 years after
enrollment has ended to a recipient
identified by the enrollee.
We identified in the proposed rule
that this proposal is based on our
authority under sections 1856(b) and
1857(e) of the Act to adopt standards
and contract terms for MA plans;
section 1902(a)(4) of the Act to adopt
methods of administration for state
Medicaid plans, including requirements
for Medicaid managed care plans
(MCOs, PIHPs, and PAHPs); section
2101(a) of the Act for CHIP managed
care entities (MCOs, PIHPs, and
PAHPs); and section 1311(e)(1)(B) of the
Affordable Care Act for QHP issuers on
the FFEs. We explained in the CMS
Interoperability and Patient Access
proposed rule our belief that the
proposal will help to reduce provider
burden and improve patient access to
their health information through
coordination of care between payers (84
FR 7640 through 7642). We also noted
that the CHIP regulations incorporate
and apply, through an existing cross43 See Office for Civil Rights. (2016, August 16).
3014–HIPAA and Health Plans—Uses and
Disclosures for Care Coordination and Continuity of
Care. Retrieved from https://www.hhs.gov/hipaa/
for-professionals/faq/3014/uses-and-disclosuresfor-care-coordination-and-continuity-of-care/
index.html.
PO 00000
Frm 00056
Fmt 4701
Sfmt 4700
reference at 42 CFR 457.1216, the
Medicaid managed care plan
requirements codified at 42 CFR
438.62(b)(1)(vi). Therefore, the proposal
for Medicaid managed care plans
described also applied to CHIP managed
care entities even though we did not
propose new regulation text in part 457.
We proposed that this new requirement
would be applicable starting January 1,
2020 for MA organizations, Medicaid
managed care plans, CHIP managed care
entities, and beginning with plan years
beginning on or after January 1, 2020 for
QHP issuers on the FFEs. Among other
topics related to the proposal, we
solicited comments on the proposed
date these policies would be applicable.
We proposed to codify this new
requirement at 42 CFR 422.119(f) for
MA organizations; at 42 CFR
438.62(b)(1)(vi) for Medicaid managed
care plans (and by extension under
existing rules at 42 CFR 457.1216, to
CHIP managed care entities); and at 45
CFR 156.221(f) for QHP issuers on the
FFEs. The proposed new requirement
was virtually identical for MA
organizations, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs, with
modifications in the proposal necessary
for specific payer types to account for
the program needs of each. The
proposed regulation text references the
content standard adopted at 45 CFR
170.213, which ONC proposed as the
USCDI (version 1) data set (84 FR 7441
through 7444). We noted we believed
that exchanging this data set would help
both enrollees and health care providers
coordinate care and reduce
administrative burden to ensure that
payers provide coordinated high-quality
care in an efficient and cost-effective
way that protects program integrity. For
a full discussion of the benefits we
anticipate from this data exchange
requirement, see the discussion in the
CMS Interoperability and Patient Access
proposed rule (84 FR 7640).
In addition to the benefits for care
coordination at the payer level and
reduced provider burden, we noted that
once the requested information, as
specified by the USCDI standard, was
made available to the patient’s current
plan, the enrollee would have access to
multiple years of their health
information through the proposed
Patient Access API, discussed in section
III.C. of the CMS Interoperability and
Patient Access proposed rule and in this
final rule. This is the case because the
proposal required the receiving payer to
incorporate the received data into its
records about the patient, therefore
making these data the payer maintains,
and data available to share with the
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
patient via the Patient Access API. The
USCDI data set includes clinical data
points essential for care coordination.
Access to these data would provide the
patient with a more comprehensive
history of their medical care, helping
them to make better informed health
care decisions. We sought comment on
how plans might combine records and
address error reconciliation or other
factors in establishing a more
longitudinal record for each patient.
We proposed to allow multiple
methods for electronic exchange of the
information, including use of the APIs
proposed in section III. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7627 through
7639), to allow for patient-mediated
exchange of payer information or direct
payer-to-payer communication, subject
to HIPAA requirements, 42 CFR part 2,
and other applicable federal and state
laws. We noted that we considered
requiring the use of the FHIR-based API
discussed in section III. of the proposed
rule for this information exchange;
however, we understood that some
geographic areas might have a regional
health information exchange (HIE) that
could coordinate such data transfers for
any HIE-participating MA plans,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs that are subject to the
proposal. We sought comment on
whether it would be beneficial to
interoperability and patient care
coordination for us to require the use of
the FHIR-based API otherwise proposed,
and whether this should be the only
mechanism allowed for this exchange,
or whether multiple methods for
electronic exchange of the information
should be allowed under the proposed
policy and whether CMS might be able
to leverage its program authority to
facilitate the data exchanges
contemplated by the proposal. We
expected enrollees to have constant
access to requesting an exchange of data
as the proposal would require exchange
of the USCDI data set whenever an
enrollee makes such a request, which
may occur at times other than
enrollment or disenrollment. We
acknowledged that in some cases payers
subject to the proposed requirement
may be exchanging patient health
information with other payers that are
not similarly required to exchange
USCDI data sets for enrollees, for
example, if a consumer changes their
health coverage from a QHP on an FFE
to employer-sponsored coverage, and
we requested comment on how to
support patients and providers in those
situations.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
We also proposed that a patient
should be able to request his or her
information from their prior payer up to
5 years after dis-enrollment, which is
considerably less than existing data
retention policies for some of the
payers.44 Further, we proposed that the
health information received as part of
the USCDI (version 1) data set under our
proposal would have to be incorporated
into the IT and data systems of each
payer that receives the USCDI data set
under the proposed requirement, such
that the enrollee’s data would be
cumulative and move with the enrollee
as he or she changes enrollment. For
example, if a patient is enrolled in Plan
1 in 2020 and Plan 2 in 2021, then
requests the data from Plan 1 to be sent
to Plan 2, Plan 2 would have at least 2
years (2020 and 2021) of health
information for that patient. If the
patient moves to Plan 3 in 2022, Plan 3
should receive both 2020 and 2021 data
from Plan 2 at the patient’s request.
While the proposal would require
compliance (and thus exchange of these
data sets) only by MA plans, Medicaid
managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs,
we noted that we hoped that
compliance by these payers could be the
first step toward adoption and
implementation of these standards on a
voluntary basis by other payers
throughout the health care system.
Research indicates that the
completeness of a patient record and the
availability of up-to-date and relevant
health information at the point of care
can have a significant impact on patient
outcomes.45 We noted that we believe
the proposal for MA organizations,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs to exchange the USCDI data
set in particular scenarios would
support improvement in care
coordination by allowing for sharing of
key patient health information when an
enrollee requests it.
We proposed that the payers subject
to this new requirement would be
required to exchange, at a minimum, the
data classes and elements included in
the content standard proposed to be
adopted at 45 CFR 170.213 in the ONC
21st Century Cures Act proposed rule,
specifically, the USCDI (version 1) data
44 Under 42 CFR 422.504(d) and 438.3(u), MA
organizations and Medicaid managed care plans,
and CHIP plans must retain records for at least 10
years. Under 45 CFR 156.705; 45 CFR
155.1210(b)(2), (3) and (5), QHP issuers on the FFEs
must also retain records for 10 years.
45 Office of the National Coordinator. (2019, June
4). Improved Diagnostics & Patient Outcomes.
Retrieved from https://www.healthit.gov/topic/
health-it-and-health-information-exchange-basics/
improved-diagnostics-patient-outcomes.
PO 00000
Frm 00057
Fmt 4701
Sfmt 4700
25565
set. On behalf of HHS, ONC proposed to
adopt the USCDI as a standard (84 FR
7441 through 7444), to be codified at 45
CFR 170.213, and the proposed
regulation text cross-references this
regulation. These data exchanges would
provide the enrollee’s new payer with a
core set of data that could be used to
support better care coordination and
improved outcomes for the enrollee. We
considered requiring plans to exchange
all the data that we proposed be
available through an API (see section III.
of the CMS Interoperability and Patient
Access proposed rule (84 FR 7627
through 7639)) but we understood that
ingesting data and reconciling errors has
challenges and proposed this more
limited data set to address those
concerns. We sought comment on
whether the USCDI data set would be
comprehensive enough to facilitate the
type of care coordination and patient
access described in the proposal, or
whether additional data fields and data
elements that would be available under
the API proposal in section III. of the
CMS Interoperability and Patient Access
proposed rule (84 FR 7627 through
7639) should also be required. For a full
discussion of the benefits of the USCDI
for this data exchange, see the CMS
Interoperability and Patient Access
proposed rule (84 FR 7641).
We stated that we believed that the
proposed requirement would also
support dually eligible individuals who
are concurrently enrolled in MA plans
and Medicaid managed care plans.
Under the proposal, both of the dually
eligible individual’s payers would be
subject to the requirement to exchange
that individual’s data in the form of the
USCDI, which should improve the
ability of both payers to coordinate care
based on that data, as discussed in the
CMS Interoperability and Patient Access
proposed rule (84 FR 7642). We sought
comment on how payers should
coordinate care and exchange
information for dually eligible
individuals. We also sought comment
on the associated burden on plans to
exchange the USCDI data set under the
proposal. In addition, we noted that we
were interested in comments about
potential legal barriers to exchanging
the USCDI data set as would be required
under the proposal; for example,
whether there were federal, state, local,
and tribal laws governing privacy for
specific use cases (such as in the care of
minors or for certain behavioral health
treatments) that would raise additional
considerations that we should address
in this regulation or in guidance.
We stated that activities related to the
proposed requirement could qualify as a
quality improvement activity (QIA)
E:\FR\FM\01MYR2.SGM
01MYR2
25566
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
meeting the criteria described in section
2718(a)(2) of the PHSA for purposes of
the Medical Loss Ratio (MLR)
requirements for QHP issuers on an
FFE,46 and similar standards for
treatment of QIA standards applicable to
Medicaid managed care plans (MCOs,
PIHPs, and PAHPs) under 42 CFR 438.8,
CHIP managed care entities under 42
CFR 457.1203(f), and MA plans under
42 CFR 422.2400 through 422.2490. An
entity’s MLR is generally calculated as
the proportion of revenue spent on
clinical services and QIA. There are
several specific criteria an expense must
meet, such as being designed to improve
health quality and health outcomes
through activities such as care
coordination, in order to qualify as
QIA.47 We requested comments related
to this assumption and its implications.
We summarize the public comments
we received on the payer-to-payer data
exchange, as well as on whether these
new activities may qualify as QIA for
MLR purposes, and provide our
responses.
Comment: Many commenters were
very supportive of this proposal and
indicated their belief that these new
data exchange requirements could
improve care coordination by reducing
burden on both beneficiaries and
providers by limiting the need for
duplicative letters of medical necessity,
preventing inappropriate step therapy,
and reducing unnecessary utilization
reviews and prior authorizations.
Response: We appreciate the
commenters’ support for this payer-topayer data exchange proposal. We are
finalizing this proposal with some
modifications as detailed below. Under
this final rule, payers subject to this
requirement must maintain a process for
the electronic exchange of, at a
minimum, the data classes and elements
included in the content standard
finalized by HHS in the ONC 21st
Century Cures Act final rule (published
elsewhere in this issue of the Federal
Register) at 45 CFR 170.213, which is
currently version 1 of the USCDI. We
are also finalizing that payers must use
this process to exchange the USCDIdefined data set with the approval and
at the direction of a current or former
enrollee, or the enrollee’s personal
representative, to align with the
language used for the API requirements.
Furthermore, we are finalizing the
46 While this rulemaking is specific to QHP
issuers participating on the FFEs, we note that to
the extent other commercial market issuers incur
similar costs for coverage sold in the individual or
group markets, those expenses may similarly
qualify as QIA.
47 See, for example, 45 CFR 158.150 and 45 CFR
158.151.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
proposal that upon receipt, the receiving
payer must incorporate the data set into
the payer’s own records about the
enrollee with a clarification that this
obligation applies to records about
current enrollees. We clarify here that
incorporating the data into the payer’s
records under this specific regulation
would not require that the payer treat or
rely on these data as its own, but that
the payer must include these data in the
record it maintains for each enrollee.
While the obligation to incorporate data
received from other payers into the
receiving payer’s records applies only
for data about current enrollees, once
incorporated, these data must be
maintained even after a current enrollee
leaves the payer’s coverage. We do not
want to be overly prescriptive about
how these data are used by each payer
at this time. Initially, we are only
requiring that these data are
incorporated into the existing record to
facilitate the creation and maintenance
of a patient’s cumulative health record
with their current payer. In subsequent
rulemaking, however, we may be more
specific, depending on proposed use
cases, and propose more prescriptive
use of specific data.
Comment: Some commenters
expressed concern about each payer’s
increased access to clinical information
impacting coverage decision-making.
Commenters noted that while
historically physicians have controlled
the patient’s clinical data in
determining what to submit to obtain
reimbursement for care provided, payers
would now have access to information
outside of the scope of the specific
service being billed by a provider.
Commenters noted that a payer may
access the exchanged health data from
a prior payer and determine that a
patient has already received treatment
for a condition and deny, delay, and/or
require prior authorization for allegedly
duplicative treatment. Additionally, a
few commenters expressed concern that
payers may use prior information to
restrict coverage for medically necessary
care that a patient may have received
previously. A few commenters
recommended that CMS require that
payers must attest that the exchanged
data cannot be used to deny or delay
treatment, increase rates, or implement
step therapy.
Response: We appreciate the
commenters’ concerns. We note that this
regulation does not make any changes to
when payers can deny coverage. The
data received via this data exchange
must be used per all applicable law,
regulation, and in accordance with
payer contracts as it relates to coverage
decisions and, specifically, coverage
PO 00000
Frm 00058
Fmt 4701
Sfmt 4700
denial. Nothing in this regulation
changes any existing obligations or
policies related to coverage or services.
Further, as proposed and finalized, the
regulations regarding the exchange of
data among payers is triggered by an
enrollee’s request that the information
be sent or received and incorporated.
The individual enrollee retains control
in this situation and can refrain from
requesting information be sent to a new
or current payer. We do note, however,
that there are currently scenarios where
payers can exchange data without an
enrollee’s request, such as for payment
and health care operations.
Comment: Several commenters were
concerned about the responsibility of
MA plans, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs to forward
information from other payers or
information from outside their
organization where they did not control
data integrity. Also, commenters were
concerned there might be information
that is contradictory and were unsure of
each payer’s responsibilities in that
case.
Response: We appreciate the
commenters’ concerns. We do believe
that patients have a right to their data.
In addition, they have a right to request
that their health data follow them
throughout their health care journey. It
is only when patients are able to
facilitate the sharing of their data, and
even see it themselves, such as via the
Patient Access API, that they will be
able to understand where there may be
opportunities to work with their
previous and current providers and
payers to ensure they have an accurate
health record. Today, to the extent
permitted by law, payers may exchange
patient data without the patient’s
consent for various purposes including
payment and health care operations.
The policy we are finalizing here will
allow the patient to facilitate that
exchange of their health information. In
using this process, patients can ensure
their payers and providers have the
most accurate and up-to-date
information about them.
Payers can choose to indicate which
data being exchanged were received
from a previous payer so the receiving
payer, or even a patient, understands
where to direct questions and is aware
of the scope of control over data
integrity. This will also help receiving
payers and patients understand how to
reconcile contradictory information as it
can be made clear where questions
should be directed. Payers are under no
obligation under this regulation to
update, validate, or correct data
received from another payer.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Comment: Several commenters agreed
with the proposed suggestion that
activities related to this proposal may
qualify as QIA meeting the criteria
described in section 2718(a)(2) of the
PHSA for purposes of the MLR
requirements for QHP issuers on the
FFEs, and similar standards for
treatment of quality improvement
standards applicable to Medicaid
managed care plans (MCOs, PIHPs, and
PAHPs) under 42 CFR 438.8, CHIP
managed care entities under 42 CFR
457.1203(f), and MA plans under 42
CFR 422.2400 through 422.2490.
Response: We confirm that we
continue to believe that expenses for the
care coordination data exchanges
required by this final rule may qualify
as QIA for purposes of calculating the
MLR for payers that engage in such
exchanges. As noted above, while this
rulemaking is specific to QHP issuers
participating on the FFEs, to the extent
other commercial market issuers incur
similar costs for coverage sold in the
individual or group markets, those
expenses may similarly qualify as QIA.
We appreciate the commenters’ support
and will consider recognizing the
expenses related to this data exchange
as QIA in future rulemaking or
guidance, as may be necessary.
Comment: Many commenters were
concerned about the time frame to
implement this provision and were
concerned making this policy applicable
in 2020 would not provide enough time
to operationalize this policy.
Response: We appreciate the
commenters’ concerns and understand
that it will take time to fully and
properly implement this policy. We are
finalizing this payer-to-payer data
exchange requirement with an
applicability date of January 1, 2022
with respect to the exchange of the
USCDI data set.
Although we did not propose to
require payers to use an API to exchange
the USCDI under this payer-to-payer
data exchange proposal, we appreciate
and support that some payers would
like to leverage the Patient Access API
(discussed in section III. of this final
rule) to meet the requirements of this
payer-to-payer data exchange. The
Patient Access API requirement makes
USCDI data available to the patient or a
third party at the patient’s direction.
Because the Patient Access API is
facilitating the exchange of the USCDI,
some of the work to develop an API to
exchange these data and the work to
map the relevant USCDI data will be
completed by January 1, 2021, when the
Patient Access API must be made
available as finalized in section III. of
this rule. In addition, if a payer receives
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
data via an API, the payer could then
incorporate it into a patient’s record and
in turn share it with the patient via the
Patient Access API with little additional
work needed.
We appreciate the value of using an
API for this data exchange, and we
understand the efficiencies that it can
add to both this payer-to-payer data
exchange as well as the Patient Access
API policy. We also appreciate that
incorporating data from other payers
received via an API will be a new
experience for payers, however. For
instance, payers will need to develop a
process to incorporate data from other
payers into their systems, including
potentially processes for tagging these
data as originating with another payer
so they can efficiently share that
information with patients and future
payers. These are additional processing
steps that take time to implement.
In evaluating the comments on the
proposals in this rule, and appreciating
the value of sharing and exchanging
data via APIs, we see the benefit of
having all data exchanged via APIs.
Therefore, we may consider for future
rulemaking an API-based payer-to-payer
data exchange. At this time, we believe
that an applicability date of January 1,
2022 for compliance with this
requirement is appropriate. This
provides time for payers to get
experience with the Patient Access API,
and provides payers with additional
time to fully and successfully
implement this payer-to-payer data
exchange requirement.
To support a more seamless data
exchange and to further clarify this
payer-to-payer data exchange
requirement, we are finalizing some
modifications of the proposed
regulation text at 42 CFR
422.119(f)(1)(ii) and (iii) for MA
organizations; at 42 CFR
438.62(b)(1)(vi)(B) and (C) for Medicaid
managed care plans (and by crossreference from 42 CFR 457.1216, to
CHIP managed care entities); and at 45
CFR 156.221(f)(1)(ii) and (iii) for QHP
issuers on the FFEs to clearly indicate
payers are obligated under this proposal
to, with the approval and at the
direction of a current or former enrollee,
exchange data with any other payer
identified by the enrollee. The proposed
regulation text used both the term
‘‘recipient’’ and ‘‘any other health care
plan’’ to identify where these data
would be sent at an enrollee’s request;
the term ‘‘recipient’’ could have been
interpreted more broadly than we
intended. In the final regulation text, we
are using ‘‘payer’’ instead and
consolidating the proposed provisions
that would require the payer that is
PO 00000
Frm 00059
Fmt 4701
Sfmt 4700
25567
subject to these rules to send data at the
enrollee’s request at any time during
enrollment or up to 5 years after
enrollment ends. As discussed in
section III. of this final rule, we are also
specifying in the final regulations that a
payer is only required to send data
received under this payer-to-payer data
exchange requirement in the electronic
form and format it was received. In this
way, a payer would not be asked to
receive paper records from another
payer under this policy and then in turn
share those paper records with another
payer in the future at the patient’s
direction. If the payer received a
patient’s information via an API, the
payer must share it via an API if the
payer they are sending to has the
capacity to receive it. If a patient
requests that a former payer send their
information to their new payer and then
requests that their new payer make their
data accessible via that new payer’s
Patient Access API, the new payer
would only be required to include the
information received from the former
payer at the patient’s direction if this
newly acquired information was
received via a FHIR-based API.
Otherwise, the new payer is only
required to share data via the Patient
Access API that the payer already
maintains and has prepared to be shared
via a FHIR-based API.
We are also finalizing new regulation
text, at 42 CFR 422.119(h) for MA
organizations; at 42 CFR
438.62(b)(1)(vii) for Medicaid managed
care plans (and by cross-reference from
42 CFR 457.1216, to CHIP managed care
entities); and at 45 CFR 156.221(i) for
QHP issuers on the FFEs, that these
regulated payers will need to comply
with the payer-to-payer data exchange
requirements beginning January 1, 2022
(or beginning with plan years beginning
on or after January 1, 2022 for QHP
issuers on the FFEs). In addition, this
requirement, as finalized, provides that
payers are required to exchange data
they maintain with a date of service on
or after January 1, 2016. In this way,
payers only have to prepare a defined
initial historical set of data for sharing
via this payer-to-payer data exchange
policy, as also required under the
Patient Access API policy discussed in
section III. of this final rule. We believe
that delaying implementation to January
1, 2022 and specifying that only data
with a date of service on or after January
1, 2016 must be exchanged under the
new requirement addresses concerns
about the timing and level of burden
involved in meeting this requirement.
This also clarifies that if certain
information is not maintained by the
E:\FR\FM\01MYR2.SGM
01MYR2
25568
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
payer, the payer is not obligated to seek
out and obtain the data.
We also sought comment on how this
policy might impact dually eligible
individuals. We summarize the public
comments we received on this payer-topayer data exchange specifically
regarding our request for comment for
how this policy might impact dually
eligible individuals who are
concurrently enrolled in MA plans and
Medicaid managed care plans and
provide our responses.
Comment: A few commenters
supported the proposal because it could
improve care coordination for dually
eligible beneficiaries. One commenter
noted that because of this proposal, MA
plans and Medicaid MCO plans would
have the same data and health history
for an individual. One commenter
believed that this could help states that
do not have an easily accessible source
of data for knowing when their
Medicaid beneficiaries are enrolled for
Medicare. This commenter
recommended including enrollment
source and enrollment and
disenrollment dates in the data
exchanged between payers.
Response: We appreciate the
commenters’ support and the suggestion
noted. We will further evaluate this
suggestion for future consideration.
Comment: One commenter requested
additional information regarding how
plans should account for gaps in plan
coverage over the course of 5 years. The
commenter believed this will be
particularly important for dual eligible
and Medicaid beneficiaries who may
move in and out of a health plan
program as their status may change due
to changing circumstances.
Response: We appreciate the
commenter’s request for information.
We note that one payer would only be
obligated to send another payer
information that the payer maintains
(which could include data received
from other payers under this final rule
that must be incorporated into the
current payer’s records). If in the 5 years
prior to January 1, 2022, a patient was
in a Medicaid managed care plan for 1
year in 2019 and then there was a break
in service with the patient returning for
1 year in 2021, this Medicaid managed
care plan would be required to share
data from 2019 and 2021 if requested by
the patient. It would not be the managed
care plan’s responsibility to address the
gaps in the data that the plan maintains.
Assuming that the patient was enrolled
in an MA plan or another Medicaid
managed care plan in 2020, the patient
could request that the plan they had in
2020 independently send their data to
the payer they have indicated. In this
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
way, the indicated payer is now the
holder of the comprehensive
information, as under this requirement
a payer must incorporate the data
received from other payers under this
policy into their data system. If the
patient leaves to go to a new payer in
2023, the one payer that now maintains
their data from 2019 to 2022 would be
the one payer that could forward the
data to the new payer, in the electronic
form and format it was received. We
acknowledge that this may be complex
for dually eligible beneficiaries.
Comment: A few commenters noted
advantages, burdens, and complexities
associated with plans serving dually
eligible beneficiaries continuously
aggregating real-time member data from
multiple plans. One commenter noted
that each payer should only be
responsible for their own data set and
the coordination of data across multiple
plans and providers would be more
ideally done through a Trusted
Exchange Framework and Common
Agreement (TEFCA). This commenter
noted that additional technical
capabilities will be required due to the
possibility of overlapping coverage
when combining and incorporating
records.
Response: We appreciate these
thoughtful comments. We note that this
payer-to-payer data exchange is only
required when initiated by an enrollee’s
request, and only applies to the payers
who are subject to our final regulations
at 42 CFR 422.119(f)(1) and (h) for MA
organizations; 42 CFR 438.62(b)(1)(vi)
and (vii) for Medicaid managed care
plans (and by cross-reference from 42
CFR 457.1216, to CHIP managed care
entities); and at 45 CFR 156.221(f) and
(i) for QHP issuers on the FFEs. The
enrollee may request this payer-to-payer
exchange just once, or more frequently.
We did not propose, and are not
finalizing, any requirement for
continuous data exchange, however.
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments and in the CMS
Interoperability and Patient Access
proposed rule, we are finalizing with
modifications our proposal at 42 CFR
422.119(f)(1) and 438.62(b)(1)(vi), and at
45 CFR 156.221(f)(1) to require MA
organizations, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs to maintain a
process for the electronic exchange of, at
a minimum, the data classes and
elements included in the content
standard adopted at 45 CFR 170.213
(currently version 1 of the USCDI), as
outlined in section III. of this final rule.
Specifically, we are finalizing as
PO 00000
Frm 00060
Fmt 4701
Sfmt 4700
proposed that the payers subject to these
regulations incorporate the data they
receive into the enrollee’s record. In the
final regulation text, we are using the
language ‘‘with the approval and at the
direction’’ of the enrollee versus ‘‘at the
request’’ of the enrollee to align with the
language used for the API requirements.
We are finalizing modifications to the
proposed regulation text to streamline
the text and best specify the scope of the
policy as intended, as well as to align
the text for all payer types as
appropriate. Specifically, at 42 CFR
422.119(f)(1)(i), 438.62(b)(1)(vi)(A) (and
by cross-reference from 42 CFR
457.1216), and at 45 CFR
156.221(f)(1)(i), the regulation text states
that relevant payers ‘‘receive’’ versus
‘‘accept’’ data for current enrollees. At
42 CFR 422.119(f)(1)(ii),
438.62(b)(1)(vi)(B) (and by crossreference from 42 CFR 457.1216), and at
45 CFR 156.221(f)(1)(ii), the final
regulations provide that a payer must
send the defined information set to any
other payer. In addition, at 42 CFR
422.119(f)(1)(iii), 438.62(b)(1)(vi)(C)
(and by cross-reference from 42 CFR
457.1216), and at 45 CFR
156.221(f)(1)(iii), we specify that a payer
is only obligated to send data received
from another payer under this policy in
the electronic form and format it was
received. This is intended to reduce
burden on payers. We note the final
regulations do use the term ‘‘payer’’ in
place of ‘‘health care plan’’ to clarify
that the scope of the obligations are for
all payers impacted by this regulation.
Also at 45 CFR 156.221(f)(1), we
updated the title of the paragraph to
align with the parallel regulations for
other payers types, and we corrected an
incomplete sentence. Finally, we
specify that this policy also applies to
an enrollee’s personal representative.
We are also finalizing regulation text
to address when these regulated payers
must comply with these new
requirements at 42 CFR 422.119(h) for
MA organizations; at 42 CFR
438.62(b)(1)(vii) for Medicaid managed
care plans (and at 42 CFR 457.1216, to
CHIP managed care entities); and at 45
CFR 156.221(i) for QHP issuers on the
FFEs. Starting January 1, 2022, and for
QHP issuers on the FFEs starting with
plan years beginning on or after January
1, 2022, the finalized regulation requires
these payers to exchange data with a
date of service on or after January 1,
2016 that meets the requirements of this
section and which the payer maintains.
In this way, payers only have to prepare
an initial historical set of data for
sharing via this payer-to-payer data
exchange policy that is consistent with
the data set to be available through the
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Patient Access API, as finalized in
section III. of this final rule.
VI. Care Coordination Through Trusted
Exchange Networks: Trust Exchange
Network Requirements for MA Plans,
Medicaid Managed Care Plans, CHIP
Managed Care Entities, and QHP
Issuers on the FFEs Provisions, and
Analysis of and Responses to Public
Comments
We proposed to require MA plans,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs to participate in trust
networks in order to improve
interoperability in these programs. We
noted that we would codify this
requirement in, respectively, 42 CFR
422.119(f)(2), § 438.242(b)(5), and
§ 457.1233(d) (which cross-references
the requirements in 42 CFR
438.242(b)(5)) and 45 CFR 156.221(f). In
general, payers and patients’ ability to
communicate between themselves and
with health care providers could
considerably improve patient access to
data, reduce provider burden, and
reduce redundant and unnecessary
procedures. Trusted exchange networks
allow for broader interoperability
beyond one health system or point to
point connections among payers,
providers, and patients. Such networks
establish rules of the road for
interoperability, and with maturing
technology, such networks are scaling
interoperability and gathering
momentum with participants, including
several federal agencies, EHR vendors,
retail pharmacy chains, large provider
associations, and others.
The importance of a trusted exchange
framework to such interoperability is
reflected in section 4003(b) of the Cures
Act, which was discussed in more detail
in section I.D. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7612 through
7614). In section VI. of the CMS
Interoperability and Patient Access
proposed rule (84 FR 7642), we
discussed and explained our proposal to
require certain payers to participate in
trusted exchange networks. A trusted
exchange framework allows for the
secure exchange of electronic health
information with, and use of electronic
health information from, other health
IT. Widespread payer participation in
such a framework might allow for more
complete access and exchange of all
electronically accessible health
information for authorized use under
applicable state or federal law, which
we believe would lead to better use of
such data. We noted that while we
cannot require widespread payer
participation in trust networks, we
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
proposed to use our program authority
in the MA program, Medicaid managed
care program, CHIP managed care
program, and QHP certification program
for the FFEs to increase participation in
trust networks and to bring the potential
benefits of participating in such
programs, including improved
interoperable communication and care
coordination, which result in
opportunities for improved patient
outcomes and burden reduction.
We proposed to require, beginning
January 1, 2020, that MA plans,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs participate in a trusted
exchange network. The proposal was
based on our authority under: Sections
1856(b) and 1857(e) of the Act to adopt
standards and contract terms for MA
plans; section 1902(a)(4) of the Act to
adopt methods of administration for the
administration state Medicaid plans,
including requirements for Medicaid
managed care plans (MCOs, PIHPs, and
PAHPs); section 2101(a) for CHIP
managed care entities (MCOs, PIHPs,
and PAHPS); and section
3001(c)(9)(F)(iii) of the PHSA and
section 1311(e)(1)(B) of the Affordable
Care Act for QHP issuers on an FFE.
Under the proposal, and consistent with
section 4003(b) of the Cures Act,
participation would be required in a
trusted exchange framework that met
the following criteria:
(1) The trusted exchange network
must be able to exchange PHI, defined
at 45 CFR 160.103, in compliance with
all applicable state and federal laws
across jurisdictions.
(2) The trusted exchange network
must be capable of connecting both
inpatient EHRs and ambulatory EHRs.
(3) The trusted exchange network
must support secure messaging or
electronic querying by and between
patients, providers, and payers.
We proposed to codify these
requirements for these payers at 42 CFR
422.119(f)(2) for MA organizations,
§ 438.242(b)(5) for Medicaid managed
care plans, § 457.1233(d)(2) for CHIP
managed care entities, and 45 CFR
156.221(f) for QHPs on the FFEs.
On April 19, 2019, ONC released the
draft Trusted Exchange Framework and
Common Agreement (TEFCA Draft 2) for
public comment.48 Previous
commenters on draft 1 of the TEFCA,
particularly payers providing
comments, requested that existing trust
48 See https://www.healthit.gov/sites/default/
files/page/2019-04/FINALTEFCA
QTF41719508version.pdf. For additional
information about TEFCA, see https://
www.healthit.gov/topic/interoperability/trustedexchange-framework-and-common-agreement.
PO 00000
Frm 00061
Fmt 4701
Sfmt 4700
25569
networks that are operating successfully
be leveraged in further advancing
interoperability; thus, we considered a
possible future approach to payer-topayer and payer-to-provider
interoperability that leverages existing
trust networks to support care
coordination and improve patient access
to their data. We requested comments
on this approach and how it might be
aligned in the future with section
4003(b) of the Cures Act. We also
requested comments on the
applicability date we proposed for the
trusted exchange network participation
requirement and what benefits and
challenges the payers subject to our
proposal might face meeting this
requirement for additional
consideration in future rulemaking.
We summarize the public comments
we received on this topic and provide
our responses.
Comment: Although many
stakeholders supported the concept of
this proposal, there were strong
exceptions. Many commenters,
particularly payers, indicated that it was
premature for CMS to finalize a
proposal related to trusted exchange
network participation before the first
version of the Common Agreement
under ONC’s TEFCA was finalized.
Commenters noted that, even though
they supported using a trusted exchange
network, it would not be advisable until
after TEFCA as outlined in section 4003
of the 21st Century Cures Act was
available to facilitate this proposal.
Response: We appreciate that
although commenters supported the
general concept of trusted exchange
network participation and how it could
advance interoperability and data
exchange, the true value of this concept
might be best realized via TEFCA in the
future. We agree that trusted exchange
networks can play a positive role, but
given the concerns commenters raised
regarding the need for a mature TEFCA,
and appreciating the ongoing work on
TEFCA being done at this time, we are
not finalizing this policy at this time.
Comment: Some commenters noted
that more detail would be needed to
understand how this proposal would be
operationalized. These commenters also
indicated more information would be
needed to understand how this policy
would relate to existing Health
Information Exchanges (HIEs) and
Health Information Networks (HINs)
and whether these entities would
qualify as trusted exchange networks. A
few commenters indicated this policy
may be redundant appreciating the
existing role of HIEs and HINs.
Response: We appreciate the
commenters’ concerns and requests for
E:\FR\FM\01MYR2.SGM
01MYR2
25570
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
additional information. We will keep
these in mind as we consider possible
future proposals around participation in
trusted exchange networks.
Comment: Many commenters
expressed concerns with the proposed
implementation timeline. They did not
believe this policy could be
implemented by January 1, 2020.
Commenters indicated it would take
more time to meet the necessary
requirements and fully understand the
implications of the policy, particularly
for HIEs and HINs. Many commenters
suggested a delay ranging from 12 to 24
months. Other commenters suggested
CMS align the timeline of this proposal
with TEFCA implementation
milestones. In addition to a delay, some
commenters suggested an exemption
process.
Response: We appreciate the
commenters concerns, and based on
these concerns and those summarized
from other commenters, we are not
finalizing this proposal at this time. To
reflect this in this final rule, the
regulation text proposed for all
impacted payers is not being finalized.
In addition, as 42 CFR 438.242(b)(5) is
not being finalized, the regulation text
proposed at 42 CFR 438.242(b)(6) is
being redesignated as 42 CFR
438.242(b)(5).
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments, we are not finalizing
this proposal to require MA
organizations, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs to participate
in a trusted exchange network.
VII. Improving the Medicare-Medicaid
Dually Eligible Experience by
Increasing the Frequency of FederalState Data Exchanges Provisions, and
Analysis of and Responses to Public
Comments
A. Increasing the Frequency of FederalState Data Exchanges for Dually Eligible
Individuals
1. Background
The Medicare and Medicaid programs
were originally created as distinct
programs with different purposes. The
programs have different rules for
eligibility, covered benefits, and
payment. The programs have operated
as separate and distinct systems despite
a growing number of people who
depend on both programs (known as
dually eligible individuals) for their
health care. There is an increasing need
to align these programs—and the data
and systems that support them—to
improve care delivery and the
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
beneficiary experience for dually
eligible individuals, while reducing
administrative burden for providers,
health plans, and states. The
interoperability of state and CMS
eligibility and Medicaid Management
Information System (MMIS) systems is a
critical part of modernizing the
programs and improving beneficiary
and provider experiences. Improving
the accuracy of data on dual eligibility
by increasing the frequency of federalstate data exchanges is a strong first step
in improving how these systems work
together.
2. Data Exchanges To Support State
Buy-In for Medicare Parts A and B
States and CMS routinely exchange
data on who is enrolled in Medicare and
Medicaid, and which parties are liable
for paying that beneficiary’s Parts A and
B premiums. These data exchanges
support state, CMS, and Social Security
Administration (SSA) premium
accounting, collections, and enrollment
functions. Section 1843 of the Act
permits states to enter into an agreement
with the Secretary to facilitate state
‘‘buy-in,’’ that is, payment of Medicare
premiums, in this case Part B premiums,
on behalf of certain individuals. For
those beneficiaries covered under the
agreement, the state pays the
beneficiary’s monthly Part B premium.
Section 1818(g) of the Act establishes
the option for states to amend their buyin agreement to include enrollment and
payment of the Part A premium for
certain specified individuals. All states
and the District of Columbia have a Part
B buy-in agreement; 36 states and the
District of Columbia have a Part A buyin agreement.
To effectuate the state payment of
Medicare Part A or Part B premiums, a
state submits data on a buy-in file to
CMS via an electronic file transfer (EFT)
exchange setup. The state’s input file
includes a record for each Medicare
beneficiary for whom the state is adding
or deleting coverage, or changing buy-in
status. In response, CMS returns an
updated transaction record that
provides data identifying, for each
transaction on the state file, whether
CMS accepted, modified, or rejected it,
as well a Part A or Part B billing record
showing the state’s premium
responsibility. In addition, the CMS file
may ‘‘push’’ new updates obtained from
SSA to the state, for example, changes
to the Medicare Beneficiary Identifier
number or a change of address.
We have issued regulations for certain
details of the state buy-in processes. For
Medicare Part A, 42 CFR 407.40
describes the option for states to amend
the buy-in agreement to cover Part A
PO 00000
Frm 00062
Fmt 4701
Sfmt 4700
premiums for Qualified Medicare
Beneficiaries (QMBs). For Medicare Part
B, 42 CFR 406.26 codifies the process
for modifying the buy-in agreement to
identify the eligibility groups covered.
CMS subregulatory guidance,
specifically Chapter 3 of the State Buyin Manual,49 specifies that states should
exchange buy-in data with CMS at least
monthly, but describes the option for
states to exchange buy-in data with CMS
daily or weekly. Likewise, states can
choose to receive the CMS response data
file daily or monthly. We note that 35
states and the District of Columbia are
now submitting buy-in data to CMS
daily; 31 states and the District of
Columbia are now receiving buy-in
response files from CMS daily.
While many states submit and receive
buy-in files daily, some continue to only
do so on a monthly basis. We have
become increasingly concerned about
the limitations of monthly buy-in data
exchanges with states. The relatively
long lag in updating buy-in data means
that the state is not able to terminate or
activate buy-in coverage sooner, so the
state or beneficiary may be paying
premiums for longer than appropriate.
In most cases, funds must be recouped
and redistributed—a burdensome
administrative process involving debits
and payments between the beneficiary,
state, CMS, and SSA. Additionally,
transaction errors do occur in the
current data exchange processes. In a
monthly exchange, it can take multiple
months to correct and resubmit an
improperly processed transaction,
exacerbating the delays in appropriately
assigning premium liability, leading to
larger mispayment, recoupment, and
redistribution of premiums. Exchanging
the buy-in data with greater frequency
supports more timely access to
coverage.
All states’ systems already have the
capacity to exchange buy-in data. We
acknowledge that states that do not
already exchange data daily will need
an initial, one-time systems change to
do so. However, moving to a daily data
exchange would result in a net
reduction of burden for states, and
further, reduce administrative
complexity for beneficiaries and
providers. More frequent submission of
updates to individuals’ buy-in status
positively impacts all involved. For a
full discussion of the benefits, see the
CMS Interoperability and Patient Access
49 Centers for Medicare and Medicaid Services.
(2003). State Buy-In Manual: Chapter 3—Data
Exchange. Retrieved from https://www.cms.gov/
Regulations-and-Guidance/Guidance/Manuals/
downloads/buyin_c03.pdf. (Last accessed June 24,
2019).
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
proposed rule (84 FR 7643 through
7644).
While there exist opportunities to
modernize the platform for buy-in data
exchange, we believe that an important
first step is to promote the exchange of
the most current available data. Section
1843(f) of the Act specifies that Part B
buy-in agreements shall contain such
provisions as will facilitate the financial
transactions of the State and the carrier
with respect to deductions, coinsurance,
and otherwise, and as will lead to
economy and efficiency of operation.
Further, section 1818(g)(2)(A) of the Act
on Part A buy-in identifies this section
1843(f) requirement as applicable to Part
A buy-in. While the regulations
governing buy-in agreements (see 42
CFR 406.26 and 407.40) are silent on the
frequency of buy-in data exchanges,
current guidance articulates that the
required buy-in data may be submitted
daily, weekly, or monthly. Therefore,
we proposed to establish frequency
requirements in the regulations at 42
CFR 406.26(a)(1) and 407.40(c) to
require all states to participate in daily
exchange of buy-in data with CMS, with
‘‘daily’’ meaning every business day, but
that if no new transactions are available
to transmit, data would not need to be
submitted on a given business day. We
noted that we believe these
requirements will improve the economy
and efficiency of operation of the buyin process. We proposed that states
would be required to begin participating
in daily exchange of buy-in data with
CMS by April 1, 2022. We noted that we
believe this applicability date would
allow states to phase in any necessary
operational changes or bundle them
with any new systems implementation.
In the CMS Interoperability and Patient
Access proposed rule, we estimated that
19 states would need to make a system
change to send buy-in data to CMS daily
and 22 states would need to make a
system change to receive buy-in data
from CMS daily (84 FR 7668). Based on
more recent data, we estimate that 26
and 19 states would require such system
changes, respectively. We updated our
estimates to determine the one-time cost
to be $85,000 per state, per change, so
a state that needs to make systems
updates to both send buy-in data daily,
and receive buy-in data daily would
have a one-time cost of just over
$170,000. We sought comment on the
proposals.
We summarize the public comments
we received on data exchanges to
support state buy-in for Medicare Parts
A and B and provide our responses.
Comment: Almost all those who
commented on these provisions
supported the proposal to require that
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
all states participate in daily exchange
of buy-in data with CMS by April 1,
2022. Commenters stated that the
changes would improve the timeliness
and accuracy of eligibility and
enrollment data, and enhance capability
for coordination of benefits.
Response: We appreciate the strong
support for the proposed change to the
regulation.
Comment: One commenter supported
the change, but also encouraged CMS to
modify its own processes and systems to
effectively leverage daily data exchanges
to support enhanced care for dually
eligible individuals. Another
commenter requested clarification if the
daily state submission of the buy-in file
encompasses a reciprocal daily response
from CMS to the states.
Response: We agree that CMS and
states both play important roles in
implementing systems changes to
support the state buy-in process.
Currently, states can choose to exchange
buy-in data with CMS daily, weekly, or
monthly; and separately, they can
choose to receive the CMS response data
file daily, weekly, or monthly. We
proposed that all states both send data
to CMS and receive responses from CMS
on a daily basis. We will continue to
look for opportunities to optimize CMS
systems and processes to support better
care for dually eligible individuals.
Comment: One commenter supported
requiring frequent exchanges of this
data as a way to eliminate current
inefficiencies and improve benefit
coordination for the dually eligible
population so long as this requirement
does not impose additional reporting
requirements on clinicians.
Response: We appreciate the support
for our proposal. We confirm that the
regulation as proposed does not create
additional reporting requirements on
clinicians. As noted in the preamble to
the CMS Interoperability and Patient
Access proposed rule, we estimate that
the change to a daily submission would
result in a net reduction of burden for
states, and further, reduce
administrative complexity for
beneficiaries and providers.
Comment: One commenter noted that
the proposed applicability date of April
1, 2022 will be sufficient for this
change, but for overall unity in the
rule’s proposed changes, encouraged
CMS to consider aligning the
applicability date of this proposal with
an overall extended implementation
time frame of at least 2 years—and
ideally 5 years—for the remainder of the
rule’s provisions.
Response: We appreciate the value in
aligned implementation timelines.
However, given that other provisions in
PO 00000
Frm 00063
Fmt 4701
Sfmt 4700
25571
this rule for health plans and states are
distinct from this requirement, and will
be required beginning in 2020, we
continue to believe that the April 1,
2022 implementation timeline proposed
for daily exchange of buy-in data is
appropriate.
Comment: Commenters recommended
that CMS establish a process for states
to provide Medicare dual eligible
special needs plans (D–SNPs) with, at a
minimum, data on beneficiaries’
Medicaid coverage. Commenters
requested CMS align the eligibility and
enrollment information that health
plans receive with the information being
shared between states and the federal
government so there is a single ‘‘source
of truth’’ on these data. Commenters
noted this consistency is critical to
improving care coordination for dually
eligible individuals.
Response: D–SNPs have an important
role in supporting their enrollees’ access
to Medicaid benefits. We understand
that in many states D–SNPs have
limited access to timely data on
Medicaid enrollment. We note that we
do provide data to D–SNPs and other
MA plans on the Medicaid status of
their members. While we appreciate the
value of D–SNPs getting additional
Medicaid coverage data such as
Medicaid plan enrollment, we decline
to modify the regulations to require
states to do so as it is beyond the scope
of this proposal. However, we continue
to explore opportunities to provide
plans with data that would assist them
in better coordinating benefits and
coverage for their dually eligible
enrollees.
Comment: One commenter noted that
the CMS Interoperability and Patient
Access proposed rule does not require
states to input the latest eligibility data
in a specific timeframe on their claims
platforms. The commenter noted that
not having this clarity means that there
could be a potential for inconsistent
data. The commenter recommended that
CMS require state Medicaid programs to
update their claims platforms daily to
assist with accurate data exchanges.
Response: We appreciate the point the
commenter is making. Our proposal did
not explicitly address how states
incorporate eligibility data with claims
and other systems. We will consider this
recommendation for the future as we
gain additional experience with daily
data exchange.
Comment: Two commenters stated
that daily exchange of buy-in data
would require significant systems
changes and costs. One of these
commenters recommended that CMS
revise the proposal to update the
frequency of exchange from monthly to
E:\FR\FM\01MYR2.SGM
01MYR2
25572
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
weekly, rather than daily. The
commenter noted that it would seldom
have new information to send on a daily
basis, but that determining on a daily
basis whether there was any new
information to send would be a large
effort. Finally, the commenter requested
if CMS finalized the regulation to
require daily updates, that provisions be
made for states whose systems cycles
are other than within a calendar day, for
example, 6 p.m. to 6 a.m.
Response: We appreciate the costs
that the state may bear to make the
systems changes necessary to
implement these provisions. We will
provide technical assistance and
opportunities for shared learning
through webinars and training to
support states’ transition.
We also note that federal matching
funds at the standard rate of 50 percent
for administration will reduce the states’
costs. States may also be eligible for
enhanced 90 percent federal matching
funds for the costs of developing and
implementing any necessary system
changes required by regulation, and
enhanced 75 percent federal matching
funds for their system’s maintenance
and operation costs. These enhanced
federal matching funds would be
available for their Eligibility and
Enrollment (E&E) systems (and, if
necessary, their Medicaid Management
Information System (MMIS)). States
would request enhanced funding
through the Advance Planning
Document (APD) process.
Even though there are costs to the
states in implementing daily exchange
of buy-in data, other commenters
uniformly supported the value of daily
exchanges in improving the experience
of dually eligible individuals, and in
reducing burden on states, providers,
and plans to reconcile payment. As a
result, we decline to make the suggested
change.
With respect to the point that there
would often not be updates on a daily
basis, we reiterate that no file would be
required on business days where there
were no updates. We expect that states
would be able to automate their systems
so that they check daily for changes to
buy-in status that would need to be
submitted to CMS on the buy-in file, but
also automate a process by which the
system only generates a buy-in file upon
identifying such a change. We
appreciate the additional coding
required to implement this logic but
expect that once implemented, no
additional interventions would be
needed. We will work with states that
have implemented these changes to
identify and share best practices in
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
identifying data changes to trigger daily
submissions.
Finally, in response to the concern
about whether states that have an
overnight processing cycle would be
permitted to continue doing so, we
affirm that the proposed regulation
would permit this.
After consideration of the public
comments and for the reasons
articulated in the CMS Interoperability
and Patient Access proposed rule and
our responses to comments, we are
finalizing changes to 42 CFR 406.26 and
407.40 as proposed.
3. Exchange of State MMA Data Files
States submit data on files at least
monthly to CMS to identify all dually
eligible individuals, including fullbenefit and partial-benefit dually
eligible individuals (that is, those who
get Medicaid help with Medicare
premiums, and often for cost-sharing).
The file is called the ‘‘MMA file,’’ but
is occasionally referred to as the ‘‘State
Phasedown file.’’ The MMA file was
originally developed to meet the need to
timely identify dually eligible
individuals for the then-new Medicare
Part D prescription drug benefit. The
Medicare Modernization Act (MMA)
established that, beginning January 1,
2006, Medicare would be primarily
responsible for prescription drug
coverage for full-benefit dually eligible
individuals; established auto-enrollment
of full-benefit dually eligible
individuals into Medicare prescription
drug plans (with regulations further
establishing facilitated enrollment into
prescription drug plans for partialbenefit dually eligible individuals),
provided that dually eligible individuals
are treated as eligible for the Medicare
Part D Low Income Subsidy (LIS),
sometimes called Extra Help; defined
phased down state contributions to
partly finance Part D costs for dually
eligible individuals; and required riskadjusting capitation payments for LIS
(which include dually eligible) enrollees
of Part D plans. To support these new
requirements, we issued 42 CFR
423.910, establishing monthly reporting
by states, in which states would submit,
at least monthly, a data file identifying
dually eligible individuals in their state.
Over time, we used these files’ data on
dual eligibility status to support Part C
capitation risk-adjustment, and most
recently, to feed dual eligibility status to
Part A and B eligibility and claims
processing systems so providers,
suppliers, and individuals have accurate
information on beneficiary cost-sharing
obligations.
Currently, regulations require states to
submit at least one MMA file each
PO 00000
Frm 00064
Fmt 4701
Sfmt 4700
month. However, states have the option
to submit multiple MMA files
throughout the month (up to one per
day). Most states submit MMA data files
at least weekly. In the CMS
Interoperability and Patient Access
proposed rule, we estimated that 37
states and DC would need to make a
system change to send MMA data to
CMS daily (84 FR 7668). Based on more
recent data, we estimate that 36 states
and DC would require such system
changes. As CMS now leverages MMA
data on dual eligibility status into
systems supporting all four parts of the
Medicare program, it is becoming even
more essential that dual eligibility status
is accurate and up-to-date. Dual
eligibility status can change at any time
in a month. Waiting up to a month for
status updates can negatively impact
access to the correct level of benefit at
the correct level of payment. Based on
our experience with states that exchange
data daily, more frequent MMA file
submissions benefit states, individuals,
and providers, in a number of ways. For
a full discussion of the benefits, see the
CMS Interoperability and Patient Access
proposed rule (84 FR 7644).
As noted, current regulation requires
that each state submit an MMA file at
least monthly. We have implemented
‘‘work-arounds’’ for lags in dual
eligibility status for Part D, including
the ‘‘Best Available Evidence’’ policy
(see 42 CFR 423.800(d)), as well as the
Limited Income Newly Eligible
Transition demonstration, which
provides short term drug coverage for
dually eligible individuals with no Part
D plan enrollment in a given month (see
Medicare Prescription Drug Benefit
Manual, Chapter 3, Section 40.1.4).50
While these work-arounds provide
needed protections, more frequent data
exchanges would mitigate the need for
them.
Ensuring information on dual
eligibility status is accurate and up-todate by increasing the frequency of
federal-state data exchange is an
important step in the path to
interoperability. As a result, we
proposed to update the frequency
requirements in 42 CFR 423.910(d) to
require that, starting April 1, 2022, all
states submit the required MMA file
data to CMS daily, and to make
conforming edits to 42 CFR
423.910(b)(1). Daily would mean every
50 Centers for Medicare and Medicaid Services.
(2017). Medicare Prescription Drug Benefit Manual:
Chapter 3—Eligibility, Enrollment and
Disenrollment. Retrieved from https://
www.cms.gov/Medicare/Eligibility-and-Enrollment/
MedicarePresDrugEligEnrol/Downloads/CY_2018_
PDP_Enrollment_and_Disenrollment_Guidance_615-17.pdf. (Last accessed June 24, 2019).
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
business day, but that if no new
transactions are available to transmit,
states would not need to submit data on
a given business day. We proposed
requiring that states begin submitting
these data daily to CMS by April 1, 2022
because we believed this applicability
date would allow states to phase in any
necessary operational changes or bundle
them with any new systems
implementation. We estimated an
updated one-time cost for a state to be
$85,000 for this MMA data systems
change. For a detailed discussion of the
costs associated with these
requirements, we refer readers to section
XVI. of the CMS Interoperability and
Patient Access proposed rule (84 FR
7660 through 7673), as well as section
XVI of this final rule. We sought
comment on these proposals.
We summarize the public comments
we received on exchange of state MMA
data files and provide our responses.
Comment: Almost all those who
commented on this provision supported
the proposal to require all states to
participate in daily submission of MMA
file data with CMS by April 1, 2022.
Commenters noted that the changes
would improve the timeliness and
accuracy of eligibility and enrollment
data, enhance coordination of benefits,
and support greater integration of care.
Response: We appreciate the strong
support for the proposed change to the
regulation.
Comment: One commenter supported
the proposed change, but requested
CMS consider standardizing which file
types and data sets will be acceptable to
support standardized daily submissions,
for the overall purpose of improving the
state and CMS data exchanges.
Response: We understand the
suggestion that we standardize which
upstream data sets (for example, CMS
finder files, state eligibility data) states
should use to support daily MMA file
submissions. To that end, we will
provide technical assistance to states
that need to make changes to submit the
file daily. As part of that effort, we will
work with states that already submit
MMA files daily to understand and
share information on best practices on
the upstream data sets necessary to
implement daily MMA file submissions.
Comment: One commenter noted that
the proposed applicability date of April
1, 2022 will be sufficient for this
change, but for overall unity in the
rule’s proposed changes, encouraged
CMS to consider aligning the effective
date of this proposal with an overall
extended implementation time frame of
at least 2 years—and ideally 5 years—
for the remainder of the rule’s
provisions.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Response: We appreciate the value in
aligned implementation timelines.
However, given that other provisions in
this rule for health plans and states are
distinct from this requirement, and will
be required beginning in 2020, we
continue to believe that the April 1,
2022 implementation timeline proposed
for daily MMA file submissions is
appropriate.
Comment: A few commenters noted
the value of the data in the MMA file
to Medicaid managed care organizations
(MCO), Medicare dual eligible special
needs plans (D–SNPs), Health
Information Exchanges, and providers
for the purposes of coordinating
enrollment, benefits, and/or care for
dually eligible individuals. These
commenters requested access to the
daily MMA file. One commenter noted
that some states are sharing Medicare
plan enrolment data from these files
with their Medicaid MCOs while also
providing batch inquiry data sharing
mechanisms to D–SNPs on Medicaid
plan enrollment. This commenter
recommended that CMS encourage or
require all states to follow this process
at a minimum.
Commenters also encouraged CMS to
leverage the MMA file to support parties
complying with the D–SNP integration
standards recently issued in 42 CFR
422.2.
Response: We appreciate these
suggestions to promote access to data for
plans and providers serving dually
eligible individuals, and we will explore
these ideas further for potential future
consideration. However, we decline to
modify the regulation as suggested, as
the recommended changes are beyond
the scope of the proposal, which is
limited to the frequency of the file
exchange.
Comment: A few commenters made
additional suggestions for streamlining
data exchanges. In addition to making
the MMA files accessible to plans and
providers, some commenters
recommended adding Medicaid plan
enrollment information to MMA files to
create a single source of MedicareMedicaid enrollment data for dually
eligible individuals. Another
commenter suggested a potential
pathway to streamlining data exchanges
would be for CMS to allow state
Transformed Medicaid Statistical
Information System (T–MSIS) files to
serve as the beneficiary data source for
third-party applications.
Response: We appreciate the value of
streamlining data exchanges, including
access to a consistent data source on
eligibility and enrollment. We also
acknowledge the overlap of certain data
exchanged in the MMA and T–MSIS
PO 00000
Frm 00065
Fmt 4701
Sfmt 4700
25573
file, though we note we would need to
carefully explore the implications and
impacts of merging operational data
exchanges such as the MMA file—
which result in changes to an
individual’s Medicare benefit—with
informational exchanges such as T–
MSIS. We will consider exploring these
opportunities further for potential future
consideration. However, we decline to
modify the regulation as suggested, as
the recommended changes are beyond
the scope of the proposal, which is
limited to the frequency of the file
exchange.
Comment: Several commenters noted
significant system changes and cost to
update the frequency of exchanging
MMA files to daily. One commenter
stated that they believe HHS has
underestimated the cost to upgrade the
MMA system to support daily exchange.
The commenter encouraged CMS to
provide an updated estimate for the
costs to upgrade the system that include
additional operational costs. This
commenter and others encouraged CMS
to consider providing additional
funding to state Medicaid programs that
will need to upgrade their data systems.
One commenter questioned if CMS
would consider increasing the FMAP
states receive for interoperability
activities that support dual eligible
plans integrations and in particular, for
programmatic or systems changes to
come into compliance with D–SNP
integration. The commenter noted that
this increase could exceed existing
enhanced matches, for example
allowing the 90 percent match to apply
for ongoing systems operations that
facilitate care coordination.
Response: We appreciate the input on
the level of effort needed to submit the
MMA file daily. As noted elsewhere, we
will provide technical assistance and
opportunities for shared learning
through webinars and training to
support states’ transition. We also note
that federal matching funds of 50
percent for administration will reduce
the states’ costs. States may also be
eligible for enhanced 90 percent federal
matching funds for the costs of
developing and implementing any
necessary system changes required by
regulation, and enhanced 75 percent
federal matching funds for their
system’s maintenance and operation
costs. These enhanced federal matching
funds would be available for their
Eligibility and Enrollment systems (and,
if necessary, their Medicaid
Management Information System
(MMIS)). States would request enhanced
funding through the Advance Planning
Document (APD) process.
E:\FR\FM\01MYR2.SGM
01MYR2
25574
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
As commenters did not provide
specific information on the costs in
excess of our assessment, we find that
we have no basis to make a reasonable
adjustment. As such, we are
maintaining our estimate of the number
of hours required, as detailed in sections
XII. and XIII. of this final rule.
Comment: One commenter opposed
increasing states submission of the
MMA file from monthly to daily,
recommending instead that the
frequency be increased to weekly. The
commenter stated that determining on a
daily basis whether there was any new
information to send would be a
significant effort, as multiple upstream
systems may have to be changed, and
further, that there would seldom be new
data to send on a daily basis. The
commenter requested that if CMS
finalized the regulation to require daily
exchanges that states be permitted to
continue to existing processing cycles
that cross business, for example, run
overnight between 6:00 p.m. to 6:00 a.m.
Response: We acknowledge the
commenter’s concerns about resources,
but note that other commenters—even
those who echoed concerns about
resources—uniformly supported the
value of daily exchanges in improving
the experience of dually eligible
individuals and the ability of providers
and plans to coordinate eligibility,
enrollment, benefits, and/or care for this
population. As we note above, we are
committed to providing technical
assistance and federal matching funds to
support needed systems changes at the
state. As a result, we decline to make
the recommended change.
With respect to the point that there
would not be updates on a daily basis,
we reiterate that no file would be
required on business days when there
were no updates. We expect that states
would be able to automate their systems
so that they check daily for changes to
data that would need to be submitted to
CMS on the MMA file, but also
automate a process by which the system
only generates an MMA file upon
identifying such a change. We
appreciate the additional coding
required to implement this logic but that
that once implemented, no additional
interventions would be needed. We will
work with states that have implemented
these changes to identify and share best
practices in identifying data changes to
trigger daily submissions.
Finally, in response to the concern
about states that have an overnight
processing cycle to continue so to meet
the definition of ‘‘daily,’’ the proposed
regulation would permit this.
After consideration of the public
comments and for the reasons
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
articulated in the CMS Interoperability
and Patient Access proposed rule and
our responses to comments, we are
finalizing 42 CFR 423.910 as proposed.
B. Request for Stakeholder Input
In addition to the proposals discussed
above, we sought public comment for
consideration in potential future
rulemaking on how we can achieve
greater interoperability of federal-state
data for dually eligible individuals,
including in the areas of program
integrity and care coordination,
coordination of benefits and crossover
claims, beneficiary eligibility and
enrollment, and their underlying data
infrastructure. For more information on
our request for comment, see the CMS
Interoperability and Patient Access
proposed rule (84 FR 7645). We thank
commenters for their input. We will
consider the information received for
potential future rulemaking.
Final Action: We will require all
states to participate in daily exchange of
buy-in data, which includes both
sending data to CMS and receiving
responses from CMS daily, and require
all states submit the required MMA file
data to CMS daily by April 1, 2022.
These policies are being finalized in 42
CFR 406.26, 407.40, and 423.910,
respectively, as proposed. These
requirements will improve the
experience of dually eligible individuals
and the ability of providers and payers
to coordinate eligibility, enrollment,
benefits, and/or care for this population.
Federal matching funds of 50 percent
for administration are available to
support states’ costs. States may also be
eligible for enhanced 90 percent federal
matching funds for the costs of
developing and implementing any
necessary system changes required by
this regulation, and enhanced 75
percent federal matching funds for their
system’s maintenance and operation
costs. CMS will provide technical
assistance to the states that need to
make changes to submit their files daily,
including best practices on the upstream
data sets necessary to implement daily
MMA file submissions.
VIII. Information Blocking Background
and Public Reporting Provisions, and
Analysis of and Responses to Public
Comments
A. Information Blocking Background
1. Legislative Background and Policy
Considerations
The nature and extent of information
blocking has come into focus in recent
years. In 2015, at the request of the
Congress, ONC submitted a Report on
PO 00000
Frm 00066
Fmt 4701
Sfmt 4700
Health Information Blocking 51
(hereinafter referred to as the
‘‘Information Blocking Congressional
Report’’), in which ONC commented on
the then current state of technology,
health IT, and health care markets.
Notably, ONC observed that prevailing
market conditions create incentives for
some individuals and entities to
exercise their control over electronic
health information in ways that limit its
availability and use. Since that time,
ONC and other divisions of HHS have
continued to receive feedback from
patients, clinicians, health care
executives, payers, app developers and
other technology companies, registries
and health information exchanges,
professional and trade associations, and
many other stakeholders regarding
practices which may constitute
information blocking. Despite
significant public and private sector
efforts to improve interoperability and
data liquidity, engagement with
stakeholders confirms that adverse
incentives remain and continue to
undermine progress toward a more
connected health system.
Based on these economic realities and
first-hand experience working with the
health IT industry and stakeholders,
ONC concluded in the Information
Blocking Congressional Report that
information blocking is a serious
problem and recommended that the
Congress prohibit information blocking
and provide penalties and enforcement
mechanisms to deter these harmful
practices.
MACRA became law in the same
month that the Information Blocking
Congressional Report was published.
Section 106(b)(2)(A) of MACRA
amended section 1848(o)(2)(A)(ii) of the
Act to require that an eligible
professional must demonstrate that he
or she has not knowingly and willfully
taken action (such as to disable
functionality) to limit or restrict the
compatibility or interoperability of
certified EHR technology, as part of
being a meaningful EHR user. Section
106(b)(2)(B) of MACRA made
corresponding amendments to section
1886(n)(3)(A)(ii) of the Act for eligible
hospitals and, by extension, under
section 1814(l)(3) of the Act for CAHs.
Sections 106(b)(2)(A) and (B) of MACRA
provide that the manner of this
demonstration is to be through a process
specified by the Secretary, such as the
use of an attestation. To implement
these provisions, as discussed further
51 Office of the National Coordinator. (2015, April
9). Report to Congress on Health Information
Blocking. Retrieved from https://www.healthit.gov/
sites/default/files/reports/info_blocking_
040915.pdf.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
below, we established and codified
attestation requirements to support the
prevention of information blocking,
which consist of three statements
containing specific representations
about a health care provider’s
implementation and use of CEHRT. To
review our discussion of these
requirements, we refer readers to the CY
2017 Quality Payment Program final
rule (81 FR 77028 through 77035).
Recent empirical and economic
research further underscores the
complexity of the information blocking
problem and its harmful effects. For a
full discussion of the research, see the
CMS Interoperability and Patient Access
proposed rule (84 FR 7645 through
7646).
In December 2016, section 4004 of the
Cures Act added section 3022 of the
PHSA (the ‘‘PHSA information blocking
provision’’), which defines conduct by
health care providers, health IT
developers, and health information
exchanges and networks that constitutes
information blocking. The PHSA
information blocking provision was
enacted in response to ongoing concerns
that some individuals and entities are
engaging in practices that unreasonably
limit the availability and use of
electronic health information for
authorized and permitted purposes (see
the definition of electronic health
information proposed by ONC for HHS
adoption at 45 CFR 171.102 (84 FR
7588)). These practices undermine
public and private sector investments in
the nation’s health IT infrastructure and
frustrate efforts to use modern
technologies to improve health care
quality and efficiency, accelerate
research and innovation, and provide
greater value and choice to health care
consumers.
The information blocking provision
defines and creates possible penalties
and disincentives for information
blocking in broad terms, working to
deter the entire spectrum of practices
likely to interfere with, prevent, or
materially discourage access, exchange,
or use of electronic health information.
The PHSA information blocking
provision applies to health care
providers, health IT developers,
exchanges, and networks. The
information blocking provision also
provides that the ‘‘Secretary, through
rulemaking, shall identify reasonable
and necessary activities that do not
constitute information blocking for
purposes of the definition at section
3022(a)(1) of the PHSA.’’ ONC’s 21st
Century Cures Act proposed rule
proposed ‘‘exceptions’’ to the
information blocking provision. These
exceptions are reasonable and necessary
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
activities that would not constitute
information blocking. In addition to the
attestation discussed in this section, all
health care providers would also be
subject to the separate information
blocking regulations proposed by ONC
for HHS adoption at 45 CFR part 171 (84
FR 7601 through 7605).
B. Public Reporting and Prevention of
Information Blocking on Physician
Compare
Physician Compare (https://
www.medicare.gov/physiciancompare)
draws its operating authority from
section 10331(a)(1) of the Affordable
Care Act. Consistent with section
10331(a)(2) of the Affordable Care Act,
Physician Compare initiated a phased
approach to publicly reporting
performance scores that provide
comparable information on quality and
patient experience measures. A
complete history of public reporting on
Physician Compare is detailed in the CY
2016 Physician Fee Schedule (PFS) final
rule with comment period (80 FR 71117
through 71122). More information about
Physician Compare, including the
history of public reporting and regular
updates about what information is
currently available, can also be accessed
on the Physician Compare Initiative
website at https://www.cms.gov/
medicare/quality-initiatives-patientassessment-instruments/physiciancompare-initiative/.
As discussed in the CY 2018 Quality
Payment Program final rule (82 FR
53820), Physician Compare has
continued to pursue a phased approach
to public reporting under MACRA in
accordance with section 1848(q)(9) of
the Act. For a discussion of public
reporting on Physician Compare, see the
CMS Interoperability and Patient Access
proposed rule (84 FR 7646 through
7647).
Building upon the continuation of our
phased approach to public reporting
and understanding the importance of
preventing information blocking,
promoting interoperability, and the
sharing of information, we proposed to
make certain data about the attestation
statements on the prevention of
information blocking referenced in the
CMS Interoperability and Patient Access
proposed rule (84 FR 7645) available for
public reporting on Physician Compare,
drawing upon our authority under
section 10331(a)(2) of Affordable Care
Act, which required us to make publicly
available on Physician Compare
information on physician performance
that provides comparable information
for the public on quality and patient
experience measures. Section
10331(a)(2) of the Affordable Care Act
PO 00000
Frm 00067
Fmt 4701
Sfmt 4700
25575
provided that to the extent scientifically
sound measures that are developed
consistent with the requirements of
section 10331 of the Affordable Care Act
are available, such information shall
include, to the extent practicable, an
assessment of the coordination of care
and other information as determined
appropriate by the Secretary. We noted
our belief that section 10331(a)(2) of the
Affordable Care Act provided the
statutory authority to publicly report
certain data about the prevention of
information blocking attestation
statements as an assessment of care
coordination and as other information
determined appropriate by the
Secretary. Furthermore, the prevention
of information blocking attestation
statements are required for a clinician to
earn a Promoting Interoperability
performance category score, which is
then incorporated into the final score for
MIPS, and we are required to publicly
report both of these scores under section
1848(q)(9)(A) of the Act. Publicly
posting this information as an indicator
is consistent with our finalized policy to
publicly report, either on the profile
pages or in the downloadable database,
other aspects of the Promoting
Interoperability performance category,
such as objectives, activities, or
measures specified in the CY 2018
Quality Payment Program final rule (82
FR 53826 through 53827). We note that
we finalized at 42 CFR 414.1395(b), that,
with the exception of data that must be
mandatorily reported on Physician
Compare, for each program year, we rely
on the established public reporting
standards to guide the information
available for inclusion on Physician
Compare. The public reporting
standards require data included on
Physician Compare to be statistically
valid, reliable, and accurate; be
comparable across submission
mechanisms; and, meet the reliability
threshold. To be included on the public
facing profile pages, the data must also
resonate with website users, as
determined by CMS.
There are three prevention of
information blocking attestation
statements under 42 CFR
414.1375(b)(3)(ii)(A) through (C) to
which eligible clinicians reporting on
the Promoting Interoperability
performance category of MIPS must
attest. To report successfully on the
Promoting Interoperability performance
category, in addition to satisfying other
requirements, an eligible clinician must
submit an attestation response of ‘‘yes’’
for each of these statements. For more
information about these statements, we
refer readers to the preamble discussion
E:\FR\FM\01MYR2.SGM
01MYR2
25576
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
in the CY 2017 Quality Payment
Program final rule (81 FR 77028 through
81 FR 77035).
The Promoting Interoperability
performance category weight comprises
25 percent of a MIPS eligible clinician’s
final score for each MIPS payment year,
as specified at 42 CFR 414.1375(a). As
specified at 42 CFR 414.1405(b)(2),
MIPS eligible clinicians with a final
score below the performance threshold
receive a negative MIPS payment
adjustment factor on a linear sliding
scale. Certain MIPS eligible clinicians
who submit data for the Promoting
Interoperability performance category
may be eligible for reweighting, as
specified under 42 CFR 414.1380(c)(2).
As specified at 42 CFR 414.1405(a),
(b)(1), and (b)(2), MIPS eligible
clinicians may receive a positive,
neutral, or negative MIPS payment
adjustment factor. As specified at 42
CFR 414.1405(c), the applicable percent
for MIPS payment year 2021 is 7
percent. For MIPS payment year 2022,
and each subsequent MIPS payment
year, it is 9 percent. For more
information about the MIPS, we refer
readers to the preamble discussion in
the CY 2020 Quality Payment Program
final rule (84 FR 62946 through 63083).
We noted our belief that it would
benefit the public to know if eligible
clinicians have attested negatively to the
statements under 42 CFR
414.1375(b)(3)(ii) as this may assist the
patient in selecting a clinician or group
who collaborates with other clinicians,
groups, or other types of health care
providers by sharing information
electronically, and does not withhold
information that may result in better
care. Therefore, we proposed to include
an indicator on Physician Compare for
the eligible clinicians and groups that
submit a ‘‘no’’ response to any of the
three statements under 42 CFR
414.1375(b)(3)(ii)(A) through (C). In the
event that these statements are left
blank, that is, a ‘‘yes’’ or a ‘‘no’’
response is not submitted, the
attestations would be considered
incomplete, and we would not include
an indicator on Physician Compare. We
also proposed to post this indicator on
Physician Compare, either on the profile
pages or the downloadable database, as
feasible and appropriate, starting with
the 2019 performance period data
available for public reporting starting in
late 2020. We refer readers to the 2019
Promoting Interoperability Information
Blocking Factsheet at https://qpp-cmprod-content.s3.amazonaws.com/
uploads/282/2019%
20PI%20Information%20Blocking%20
Fact%20Sheet.pdf for more information
about the attestation statements.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Under 42 CFR 414.1395(b), these data
must meet our established public
reporting standards, including that to be
included on the public facing profile
pages, the data must resonate with
website users, as determined by CMS. In
previous testing with patients and
caregivers, we learned that effective use
of CEHRT is important to them when
making informed health care decisions.
For more information about previous
testing with patients and caregivers, we
refer readers to the Physician Compare
Technical Expert Panel (TEP) Summary
Report at https://www.cms.gov/
Medicare/Quality-Initiatives-PatientAssessment-Instruments/physiciancompare-initiative/Downloads/
Physician-Compare-TEP-Summary2018.pdf. To determine how to best
display and meaningfully communicate
the indicator on the Physician Compare
website, the exact wording and, if
applicable, profile page indicator would
be determined after user testing and
shared with stakeholders through the
Physician Compare Initiative page,
listservs, webinars, and other available
communication channels. We noted that
the proposal was contingent upon the
availability of and technical feasibility
to use the data for public reporting.
We summarize the public comments
we received on this topic and provide
our responses.
Comment: Most commenters
supported our proposal to publicly
report an indicator on the Physician
Compare website for the eligible
clinicians and groups that submit a
‘‘no’’ response to any of the three
prevention of information blocking
attestation statements, noting that the
indicator would discourage clinicians
and groups from information blocking
and help Medicare patients and
caregivers make informed health care
decisions.
Response: We thank commenters for
their support and agree that publicly
reporting an indicator on Physician
Compare will discourage clinicians and
groups from information blocking and
help Medicare patients and caregivers
make informed decisions.
Comment: Some commenters
expressed concern for various reasons
about publicly reporting an indicator on
the Physician Compare website for the
eligible clinicians and groups that
submit a ‘‘no’’ response to any of the
three prevention of information
blocking attestation statements. Several
of these commenters thought the
indicator would be redundant, since
there is already an incentive for
clinicians to attest to the prevention of
information blocking statements in
order to earn a MIPS Promoting
PO 00000
Frm 00068
Fmt 4701
Sfmt 4700
Interoperability performance category
score. Some commenters were
concerned that an indicator may not
accurately reflect whether a clinician or
group is knowingly or willfully
information blocking, since they may be
confused about the attestation
statements’ meanings. A few
commenters suggested delaying
Physician Compare’s indicator
implementation in order to give
clinicians and groups, particularly small
and rural practices, time to become
more familiar with the attestations.
Other commenters expressed concern as
to whether Medicare patients and
caregivers would find the indicator
useful; one of these commenters
suggested conducting a pilot study to
make such a determination. Finally,
several commenters suggested an appeal
process or an opportunity for clinicians
and groups to review their information
prior to public reporting.
Response: We appreciate the
commenters’ concerns. We believe
publicly reporting an indicator on
Physician Compare for the eligible
clinicians and groups that submit a
‘‘no’’ response to any of the three
prevention of information blocking
attestation statements is not redundant,
as Medicare patients and caregivers do
not currently have access to this type of
information, which could aid them in
making informed health care decisions.
Regarding concerns about clinicians,
including small and rural practices,
needing time to become familiar with
the attestations, we believe there has
been sufficient time for clinicians to
become familiar with them, since these
attestation statements have been a MIPS
Promoting Interoperability performance
category requirement since the 2017
performance period. We also believe
that webinars and educational materials
that CMS has made available have
provided clinicians and groups an
opportunity to become familiar with the
information blocking attestation
statements. We will also continue to
support small and rural practices by
offering free and customized resources
available within local communities,
including direct, one-on-one support
from the Small, Underserved, and Rural
Support Initiative along with our other
no-cost technical assistance (83 FR
59720). Regarding whether an
information blocking indicator would be
meaningful to patients and caregivers,
we note that under 42 CFR 414.1395(b),
these data must meet our established
public reporting standards, including
that to be posted on public facing profile
pages, the data must resonate with
website users, as determined by CMS.
Such user testing to date has shown that
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
effective CEHRT usage is important to
patients when making health care
decisions. In addition, as specified at 42
CFR 414.1375(b)(3)(ii), MIPS eligible
clinicians must attest to the prevention
of information blocking statements. For
more information about these
statements, we refer readers to the
preamble discussion in the CY 2017
Quality Payment Program final rule (81
FR 77028 through 81 FR 77035). In
addition, we note that section 4004 of
the Cures Act added section 3022 of the
PHSA, which directs HHS to identify
reasonable and necessary activities
conducted by health care providers,
health IT developers, and health
information exchanges and networks
that would not constitute information
blocking as defined in section 3022. For
more information, see the information
blocking discussion in ONC’s 21st
Century Cures Act final rule (published
elsewhere in this issue of the Federal
Register).
While we appreciate the commenter’s
suggestion to conduct a pilot study, we
believe that further user testing will
allow us to gain the additional
understanding necessary.
Regarding the comments requesting
an opportunity to review or an appeal
process, we note that, under 42 CFR
414.1395(d), for each program year,
CMS provides a 30-day preview period
for any clinician or group with Quality
Payment Program data before the data
are publicly reported on Physician
Compare. Although at this time we do
not preview indicator information,
clinicians and groups will be able to
preview their Promoting Interoperability
performance category information,
including their attestation responses to
the three statements during the MIPS
targeted review process. All
performance data publicly reported on
Physician Compare will reflect the
scores eligible clinicians and groups
receive in their MIPS performance
feedback, which will be available for
review and potential correction during
the targeted review process (83 FR
59912).
Comment: Many commenters
recommended additional actions to
prevent information blocking, beyond
publicly reporting an indicator on
Physician Compare. Some commenters
recommended implementing additional
penalties for clinicians and groups that
attest ‘‘no’’ to the prevention of
information blocking attestations, such
as corrective action. Other commenters
suggested CMS offer more positive
incentives. Several commenters
suggested having additional indicators,
such a positive one for those who attest
‘‘yes.’’ Another commenter
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
recommended treating a blank response
to the three attestation statements as a
‘‘no’’ response. A few commenters
recommended that the proposed
indicator not be used for clinicians and
groups that participate in trusted
exchange networks.
Response: We appreciate commenters’
suggestions and will consider them for
potential future rulemaking, to the
extent permitted by our authority. To
the extent of our authority, we will
consider treatment of attestation
statements that are left blank, use of a
positive indicator on the Physician
Compare profile pages or downloadable
database, and the use of the proposed
indicator for clinicians and groups that
participate in trusted exchange
networks for potential future
rulemaking.
Regarding commenters’ suggestions
for additional penalties, we note that
section 4004 of the Cures Act identifies
potential penalties and disincentives for
information blocking. Health care
providers determined by the Inspector
General to have committed information
blocking shall be referred to the
appropriate agency to be subject to
appropriate disincentives using
authorities under applicable federal law,
as the Secretary sets forth through
notice and comment rulemaking. In the
ONC 21st Century Cures Act proposed
rule, a request for information regarding
disincentives for health care providers
was included (84 FR 7553).
Comment: Some commenters
requested additional information on the
proposed information blocking
indicator. A few of these commenters
requested additional information on the
attestation requirements for clinicians
and groups participating in other
programs, such as Medicare Advantage.
Several commenters requested
additional guidance on exceptions to
the attestations. Another commenter
requested more information on the
implications for clinicians and groups
who leave the attestation statements
blank and do not attest ‘‘yes’’ or ‘‘no.’’
Several commenters questioned how
clinicians’ responses to the three
attestation statements would be verified
for accuracy.
Response: The three attestation
statements are required under the MIPS,
which is a Medicare FFS program. We
note that 42 CFR 414.1310(b) and (c)
provide that Qualifying APM
Participants (QPs) and Partial QPs who
do not report on applicable measures
and activities that are required to be
reported under MIPS for any given
performance period in a year are
excluded from this definition at 42 CFR
414.1305 of a MIPS eligible clinician per
PO 00000
Frm 00069
Fmt 4701
Sfmt 4700
25577
the statutory exclusions defined in
section 1848(q)(1)(C)(ii) and (v) of the
Act. Therefore, the prevention of
information blocking indicator would be
applicable only to MIPS eligible
clinicians and groups under Medicare
FFS and not to other programs, such as
MA. Under MIPS, the attestation
statements are required for all eligible
clinicians under the Promoting
Interoperability performance category of
MIPS, as specified at 42 CFR
414.1375(b)(3)(ii) (81 FR 77035). If the
attestation statements are left blank, that
is, a ‘‘yes’’ or ‘‘no’’ response is not
submitted, the attestations would be
considered incomplete and the clinician
or group would not receive a Promoting
Interoperability performance category
score. In this situation, we would not
have an affirmative or negative response
to the three attestation statements from
the clinician or group, and we would
not have enough information to
determine whether the clinician or
group is knowingly and willfully
information blocking. Regarding
exceptions to the attestation
requirements, under 42 CFR
414.1380(c)(2) the Promoting
Interoperability performance category
may be reweighted to zero percent of the
final score for a MIPS eligible clinician
in certain circumstances, and clinicians
who receive reweighting would not
have to submit data for the Promoting
Interoperability performance category,
including their responses to the
attestation statements. Regarding
verification of clinicians’ attestation
statements, we note that we finalized in
prior rulemaking that we will perform
ongoing monitoring of MIPS eligible
clinicians and groups on an ongoing
basis for data validation, auditing,
program integrity issues, and instances
of non-compliance with MIPS
requirements. If a MIPS eligible
clinician or group is found to have
submitted inaccurate data for MIPS, we
finalized that we would reopen and
revise the determination in accordance
with the rules set forth at 42 CFR
405.980 through 405.986 (81 FR 77362).
Final Action: After consideration of
the comments received, and for the
reasons outlined in our responses to
these comments, we are finalizing this
policy as proposed. Specifically, we are
finalizing to include an indicator on
Physician Compare for the eligible
clinicians and groups that submit a
‘‘no’’ response to any of the three
prevention of information blocking
attestation statements for MIPS under 42
CFR 414.1375(b)(3)(ii)(A) through (C), as
proposed. In the event that these
statements are left blank, that is, a ‘‘yes’’
E:\FR\FM\01MYR2.SGM
01MYR2
25578
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
or a ‘‘no’’ response is not submitted, the
attestations will be considered
incomplete, and we will not include an
indicator on Physician Compare. We
will post this indicator on Physician
Compare, either on the profile pages or
in the downloadable database, as
feasible and appropriate, starting with
the 2019 performance period data
available for public reporting starting in
late 2020.
C. Public Reporting and Prevention of
Information Blocking for Eligible
Hospitals and Critical Access Hospitals
(CAHs)
Section 1886(n)(4)(B) of the Act
requires the Secretary to post in an
easily understandable format a list of
the names and other relevant data, as
determined appropriate by the
Secretary, of eligible hospitals and
CAHs who are meaningful EHR users
under the Medicare FFS program, on a
CMS website. In addition, that section
requires the Secretary to ensure that an
eligible hospital or CAH has the
opportunity to review the other relevant
data that are to be made public with
respect to the eligible hospital or CAH
prior to such data being made public.
We noted in the CMS Interoperability
and Patient Access proposed rule (84 FR
7647) that we believed certain
information related to the prevention of
information blocking attestation
statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3) would
constitute other relevant data under
section 1886(n)(4)(B) of the Act.
Specifically, we referred to the three
prevention of information blocking
attestation statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3) to which
eligible hospitals and CAHs must attest
for purposes of the Promoting
Interoperability Program. As part of
successfully demonstrating that an
eligible hospital or CAH is a meaningful
EHR user for purposes of the Promoting
Interoperability Program, the eligible
hospital or CAH must submit an
attestation response of ‘‘yes’’ for each of
these statements. For more information
about these statements, we referred
readers to the preamble discussion in
the CY 2017 Quality Payment Program
final rule (81 FR 77028 through 77035).
We noted in the CMS Interoperability
and Patient Access proposed rule (84 FR
7647) that we believed it would be
relevant to the public to know if eligible
hospitals and CAHs have attested
negatively to the statements under 42
CFR 495.40(b)(2)(i)(I)(1) through (3) as it
could indicate that they are knowingly
and unreasonably interfering with the
exchange or use of electronic health
information in ways that limit its
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
availability and use to improve health
care. As we stated in the CY 2017
Quality Payment Program final rule, we
believed that addressing issues related
to information blocking would require
additional and more comprehensive
measures (81 FR 77029). In addition,
publicly posting this information would
reinforce our commitment to focus on
increased interoperability and the
appropriate exchange of health
information. We proposed to post
information on a CMS website available
to the public indicating that an eligible
hospital or CAH attesting under the
Medicare FFS Promoting
Interoperability Program submitted a
‘‘no’’ response to any of the three
statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3). In the
event that these statements are left
blank, that is, a ‘‘yes’’ or a ‘‘no’’
response is not submitted, we proposed
the attestations would be considered
incomplete, and we would not post any
information related to these attestation
statements for that hospital or CAH. We
proposed to post this information
starting with the attestations for the EHR
reporting period in 2019, and we
expected the information would be
posted in late 2020. In accordance with
section 1886(n)(4)(B) of the Act, we
proposed to establish a process for each
eligible hospital and CAH to review the
information related to their specific
prevention of information blocking
attestation statements before it is
publicly posted on a CMS website.
Specifically, for each program year, we
proposed a 30-day preview period for an
eligible hospital or CAH to review this
information before it is publicly posted.
During the 30-day preview period, we
proposed that all of the information that
we would publicly post would be
available for the eligible hospital or
CAH to review, and we would consider
making changes to the information on a
case-by-case basis (for example, in the
event the eligible hospital or CAH
identifies an error, and we subsequently
determine that the information is not
accurate). Additional information on the
review process would be provided
outside of the rulemaking process
through the usual communication
channels for the program.
We summarize the public comments
we received on this topic and provide
our responses.
Comment: Many commenters
indicated their strong support for this
proposal and suggested that we finalize
the proposal, as commenters believe it
is necessary in building an interoperable
health system. One commenter believes
that maintaining accountability and
enforcing penalties is critical to
PO 00000
Frm 00070
Fmt 4701
Sfmt 4700
maintaining individual health and
safety. Another commenter agreed,
stating that information blocking is
detrimental to the health, safety, and
welfare of patients. Many commenters
indicated that information blocking
should not be tolerated for competitive
or financial reasons, further indicating
that consumers and stakeholders should
be made aware of those who participate
in information blocking practices, as
this transparency can prevent potential
medical errors and improve the overall
quality of care.
Response: We thank commenters for
their support for the proposal. We agree
with the commenters and believe that
the proposed policy would be both
appropriate and effective in reinforcing
our commitment to focus on increasing
interoperability and the appropriate
exchange of health information.
Knowingly or willfully preventing,
avoiding, or withholding information
limits interoperability and prevents the
sharing of important health information.
Comment: Many commenters
indicated support for the promotion of
health information exchange and the
prevention of information blocking,
generally, but expressed several
concerns about the implementation of
this proposal. A couple of commenters
were concerned that there is not enough
time to develop the policies and
procedures needed to streamline the
proposed process, and in response,
suggested building in a period of nonenforcement (a practice period without
posting any information publicly).
Several commenters expressed concern
that there will not be an opportunity to
dispute information prior to
publication, and requested including a
guarantee of the proposed 30-day
preview period prior to the publication
of certain information on a CMS
website. Finally, commenters had
concerns about how policies related to
information blocking and changes to the
2015 Edition of certified health IT
proposed in ONC’s 21st Century Cures
Act proposed rule may impact the
prevention of information blocking
attestations under the Promoting
Interoperability Program.
Response: We appreciate the
commenters’ concerns and suggestions.
We are finalizing the proposal to post
this information starting with the
attestations for the EHR reporting period
in 2019, and we are targeting for this
information to be posted in late 2020.
Although we will not have a period of
non-enforcement (postponing posting of
information publicly), we are building
in a 30-day preview period during
which any discrepancies or concerns
may be addressed on a case-by-case
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
basis prior to posting. Additional
information on the preview period will
be provided outside of the rulemaking
process through the usual
communication channels for the
program. With regard to ONC’s 21st
Century Cures Act rule, the prevention
of information blocking attestation
statements under the Promoting
Interoperability Program are not affected
by ONC’s final rule policies and remain
unchanged.
Comment: A number of commenters
supported the prevention of information
blocking, but had concerns about the
additional burden this proposal may
add. One commenter requested
reassurance that this process will not
increase burden, while a few other
commenters shared concerns that this
process will increase burden.
Response: We appreciate the
commenters’ concerns. As eligible
hospitals and CAHs are already required
to respond to these three attestation
statements under the Promoting
Interoperability Program, we do not
believe this proposal would require
additional reporting effort, or thereby
increase burden. We do not believe the
30-day preview period would increase
burden as it will be an opportunity for
eligible hospitals and CAHs to ensure
the accuracy of the information that will
be posted publicly, should they choose
to take advantage of this opportunity.
Comment: Many commenters stated
that there should be an audit or spot
check process to validate the responses
provided to the three attestation
statements. Commenters indicated
concern that those who knowingly
participate in information blocking
practices will answer ‘yes’ to the three
attestation statements simply to
complete the question/answer
sequencing in the reporting system.
Further, commenters expressed concern
regarding how easy it could be for their
peers to respond dishonestly, and
requested more stringent auditing
practices from CMS. A number of
commenters requested additional
information on how a ‘‘blank’’ response
would be treated for purposes of this
proposal; one commenter believed that
a ‘‘blank’’ should be considered a ‘‘no’’,
and another commenter believed that a
‘‘blank’’ should simply be considered as
a ‘‘blank.’’
Response: We appreciate the
commenters’ concerns. We do not have
a specific auditing practice in place for
these specific attestation statements.
Instead, all eligible hospitals and CAHs
are required to submit responses to the
attestation statements under the
Promoting Interoperability Program and
must respond accurately, as any eligible
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
hospital or CAH participating in the
Promoting Interoperability Program may
be subject to an audit. In the event that
an eligible hospital or CAH leaves a
‘‘blank’’ response to an attestation
statement, where a ‘‘yes’’ or a ‘‘no’’
response is not submitted, the response
would be considered incomplete, and
no information would be posted related
to these attestation statements at this
time.
Comment: Many commenters
supported the effort to prevent
information blocking, though several
believed that posting certain
information on a CMS website of those
who attest ‘no’ to the prevention of
information blocking statements may
not strongly impact the issue. Of the
reasons given, one commenter remained
agnostic on whether such a policy
would have tangible success in
deterring information blocking, several
commenters stated that the information
posted on a CMS website will have little
meaning to consumers, and others
believed that this process would not
promote interoperability nor would it
improve patient access to information.
Response: We appreciate all of the
commenters’ concerns. As discussed in
the CY 2017 Quality Payment Program
Final Rule (81 FR 77029), the act of
information blocking is a systemic
problem that Congress has expressed
concerns about. Growing evidence has
established that there is a strong
incentive for health care providers to
unreasonably interfere with the
exchange of health information. We
believe that publicly posting certain
information on a CMS website is one
valuable tool in our continued effort to
deter these information blocking
practices.
As patients gain access to more data,
they become more empowered and more
informed decision makers. Knowing if a
physician may be information blocking
could influence their decision to see
that physician. In addition, knowing
patients can see this information may
deter physicians from engaging in this
behavior. For these reasons, we do
believe that this effort will have an
impact and be meaningful to consumers.
We do also believe that this policy will
promote interoperability and improve
patient access to information. With
patients becoming more empowered,
this drives health care providers to
move toward information sharing rather
than information blocking, which
directly leads to improved patient
access to information.
Comment: A couple commenters
suggested moving away from posting
public information, and instead
focusing on creating positive incentive
PO 00000
Frm 00071
Fmt 4701
Sfmt 4700
25579
programs, enhancing guidance,
providing more education, and fostering
change through encouraging the
prevention of information blocking.
Some commenters agreed with the
approach, but believed CMS could
develop more concrete measures that
would have a stronger justification for
posting information on a CMS website
versus using the three attestation
statements.
Response: Thank you for these
comments and suggestions. To the
extent that the commenters are
requesting that we create positive
incentive programs that include
incentive payments to eligible hospitals
and CAHs, we note that we can only do
so to the extent authorized by law. We
will take into consideration the
suggestions for enhancing prevention of
information blocking guidance,
providing more education, and fostering
change through encouragement in
potential future rulemaking.
Comment: A few commenters were in
favor of posting certain information on
eligible hospitals and/or CAHs that
provide a ‘‘no’’ response to the
prevention of information blocking
attestation statements, but have
requested additional ways to discourage
this practice. Commenters requested
that those who are knowingly and
willfully blocking the transfer of
information also be fined, per instance
or per patient, as a way of
disincentivizing this practice. A couple
commenters suggested strengthening
this provision by establishing an easy
way for stakeholders to report potential
information blocking activities.
Response: We appreciate the
commenters’ suggestions regarding
additional ways to discourage
information blocking. We refer
commenters to section 3022(b)(2)(B) of
the PHSA, which provides that any
health care provider determined by the
Office of the Inspector General (OIG) to
have committed information blocking
shall be referred to the appropriate
agency to be subject to appropriate
disincentives using authorities under
applicable federal law, as the Secretary
sets forth through notice and comment
rulemaking. Health care providers
would also be subject to the separate
information blocking regulations
proposed by ONC for HHS adoption at
45 CFR part 171 (84 FR 7601 through
7605). Further, we note that ONC’s 21st
Century Cures Act proposed rule
included a request for information
regarding disincentives for health care
providers (84 FR 7553).
Comment: Many commenters, while
in agreement with publicly posting
certain information related to
E:\FR\FM\01MYR2.SGM
01MYR2
25580
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
information blocking, had concerns that
eligible hospitals and CAHs are being
held accountable for the practices of
health IT vendors. Many commenters
were concerned that vendors are
restricting the transfer of data by data
embargoing, actively blocking, and
refusing or prohibiting the transfer of
data. Further, there were concerns that
vendors are requiring complex
programs, the purchase of many costly
programs, and requiring excessive fees
to conduct data transfer. Last, several
commenters requested that vendors be
penalized equally, and in the same
manner, as eligible hospitals and CAHs.
Response: We appreciate the
commenters’ support for the proposal,
and we also appreciate their concerns.
We emphasize that the information
blocking provision (section 4004 of the
Cures Act) applies to health IT
developers of certified health IT.
Section 3022(a)(1) of the PHSA, in
defining information blocking, refers to
four classes of individuals and entities
that may engage in information blocking
and which include: Health care
providers, health IT developers of
certified health IT, networks, and
exchanges. In the ONC 21st Century
Cures Act proposed rule, ONC proposed
to adopt definitions of these terms to
provide clarity regarding the types of
individuals and entities to whom the
information blocking provision applies
(84 FR 7601 through 7602).
Regarding penalties, section 4004 of
the Cures Act identifies potential
penalties and disincentives for
information blocking. Health IT
developers, health information
networks, and health information
exchanges that the Inspector General,
following an investigation, determines
to have committed information blocking
shall be subject to a civil monetary
penalty determined by the Secretary for
all such violations identified through
such investigation, which may not
exceed $1,000,000 per violation. Such
determination shall take into account
factors such as the nature and extent of
the information blocking and harm
resulting from such information
blocking, including, where applicable,
the number of patients affected, the
number of providers affected, and the
number of days the information
blocking persisted. Health care
providers determined by the Inspector
General to have committed information
blocking shall be referred to the
appropriate agency to be subject to
appropriate disincentives using
authorities under applicable Federal
law, as the Secretary sets forth through
notice and comment rulemaking.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Comment: One commenter suggested
a collaboration between CMS, ONC, and
OIG in order to address information
blocking together, to combat
information blocking consistently and
from all angles.
Response: We appreciate the
commenter’s suggestion, and note that
CMS, ONC, and OIG are consistently
working together on issues such as
information blocking so that our
policies are complementary and work
together to address the issue.
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments and in the CMS
Interoperability and Patient Access
proposed rule, we are finalizing this
policy as proposed. We will include
information on a CMS website available
to the public indicating that an eligible
hospital or CAH attesting under the
Medicare FFS Promoting
Interoperability Program submitted a
‘‘no’’ response to any of the three
prevention of information blocking
attestation statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3). We will
post this information starting with the
attestations for the EHR reporting period
in 2019, and expect the information will
be posted in late 2020. In the event that
an eligible hospital or CAH leaves a
‘‘blank’’ response to an attestation
statement, where a ‘‘yes’’ or a ‘‘no’’
response is not submitted, the
attestations will be considered
incomplete, and no information will be
posted related to these attestation
statements. We will establish a process
for each eligible hospital and CAH to
review the information related to their
specific prevention of information
blocking attestation statements before it
is publicly posted on the CMS website.
For each program year, we will have a
30-day preview period for an eligible
hospital or CAH to review this
information before it is publicly posted.
During the 30-day preview period, all of
the information that we will publicly
post will be available for the eligible
hospital or CAH to review, and we will
consider making changes to the
information on a case-by-case basis.
IX. Provider Digital Contact
Information Provisions, and Analysis of
and Responses to Public Comments
A. Background
Congress required the Secretary to
create a provider digital contact
information index in section 4003 of the
Cures Act. This index must include all
individual health care providers and
health care facilities, or practices, in
order to facilitate a comprehensive and
PO 00000
Frm 00072
Fmt 4701
Sfmt 4700
open exchange of patient health
information. Congress gave the
Secretary the authority to use an
existing index or to facilitate the
creation of a new index. In comments
received on the FY 2019 IPPS proposed
rule RFI, there was strong support for a
single, public directory of provider
digital contact information. Commenters
noted that digital communication could
improve interoperability by facilitating
efficient exchange of patient records,
eliminating the burden of working with
scanned paper documents, and
ultimately enhancing care coordination.
To ensure the index is accessible to
all clinicians and facilities, we updated
the National Plan and Provider
Enumeration System (NPPES) 52 to be
able to capture digital contact
information for both individuals and
facilities. It is important to note that the
aforementioned updates to the NPPES
entailed the addition of two additional
data fields. However, due to an
administrative oversight, the data
elements which allow for the digital
capture of contact information are not
OMB approved. CMS acknowledges this
violation of the Paperwork Reduction
Act of 1995 (PRA) and is currently
working to remediate the issue by
creating a new PRA package and thereby
come into compliance with the PRA.
Prior to its submission for OMB
approval, the new information
collection request will be made
available for public review and
comment as required by the PRA.
NPPES currently supplies National
Provider Identifier (NPI) numbers to
health care providers (both individuals
and facilities), maintains their NPI
record, and publishes the records
online. The Secretary adopted the NPI
as the HIPAA administrative
simplification standard identifier for
health care providers (69 FR 3434).
HIPAA covered entities, including
health care providers, health plans, and
health care clearinghouses, must use the
NPI in HIPAA transactions. All health
care providers that transmit health
information in electronic form in
connection with a HIPAA transaction
must obtain an NPI.
Health care providers are required to
communicate to the NPPES any
information that has changed within 30
days of the change (45 CFR
162.410(a)(4)). We review NPPES to
ensure a provider has a valid NPI as part
of the Medicare enrollment process, as
well as the revalidation process, which
occurs every 3 to 5 years depending on
the provider or supplier type.
52 The NPPES website at https://
nppes.cms.hhs.gov/.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Information in NPPES is publicly
accessible via both an online search
option and a downloadable database
option. As a result, adding digital
contact information to this existing
index is an efficient and effective way
to meet the Congressional requirement
to establish a digital contact information
index and to promote the sharing of
information.
As of June 2018, NPPES has been
updated to include the capability to
capture one or more pieces of digital
contact information that can be used to
facilitate secure sharing of health
information. For instance, providers can
submit a Direct address, which
functions similar to a regular email
address, but includes additional
security measures to ensure that
messages are only accessible to the
intended recipient in order to keep the
information confidential and secure.
‘‘Direct’’ is a technical standard for
exchanging health information. Direct
addresses are available from a variety of
sources, including EHR vendors, State
Health Information Exchange entities,
regional and local Health Information
Exchange entities, as well as private
service providers offering Direct
exchange capabilities called Health
Information Service Providers (HISPs)
(https://www.healthit.gov/sites/default/
files/directbasicsforprovidersqa_
05092014.pdf). NPPES can also capture
information about a wide range of other
types of endpoints that providers can
use to facilitate secure exchange of
health information, for instance a FHIR
server URL or query endpoint associated
with a health information exchange. We
strongly encourage the inclusion of this
FHIR endpoint information in NPPES in
support of the Patient Access API policy
discussed in section III. of this final rule
and the Provider Directory API policy
discussed in section IV. of this final
rule. Using NPPES as one way to make
these endpoints publicly known will
significantly support interoperability
throughout the health care system.
In addition, NPPES can now maintain
information about the type of contact
information providers and organizations
are associated with, along with the
preferred uses for each address. Each
provider in NPPES can maintain their
own unique information or associate
themselves with information shared
among a group of providers. Finally, in
March 2019, NPPES added a public API
which can be used to obtain the digital
contact information stored in the
database. Although NPPES is now better
equipped to maintain provider digital
contact information, many providers
have not submitted this information. In
the 2015 final rule, ‘‘Medicare and
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Medicaid Programs; Electronic Health
Record Incentive Program-Stage 3 and
Modifications to Meaningful Use in
2015 Through 2017’’ (80 FR 62901), we
finalized a policy to collect information
in NPPES about the electronic addresses
of participants in the EHR Incentive
Program (specifically, a Direct address
and/or other ‘‘electronic service
information’’ as available). However,
this policy was not fully implemented at
the time, in part due to the limitations
of the NPPES system which have since
been addressed. As a result, many
providers have not yet added their
digital contact information to NPPES
and digital contact information is
frequently out of date.
In light of these updates to the NPPES
system, all individual health care
providers and facilities can take
immediate action to update their NPPES
record online to add digital contact
information. This simple step will
significantly improve interoperability by
making valuable contact information
easily accessible. For those providers
who continue to rely on the use of
cumbersome, fax-based modes of
sharing information, we hope that
greater availability of digital contact
information will help to reduce barriers
to electronic communication with a
wider set of providers with whom they
share patients. Ubiquitous, public
availability of digital contact
information for all providers is a crucial
step towards eliminating the use of fax
machines for the exchange of health
information. We urged all providers to
take advantage of this resource to
implement Congress’ requirement that
the Secretary establish a digital contact
information index.
B. Public Reporting of Missing Digital
Contact Information
Entities seeking to engage in
electronic health information exchange
need accurate information about the
electronic addresses (for example, Direct
address, FHIR server URL, query
endpoint, or other digital contact
information) of potential exchange
partners. A common directory of the
electronic addresses of health care
providers and organizations could
enhance interoperability and
information exchange by providing a
resource where users can obtain
information about how to securely
transmit electronic health information
to a provider.
We proposed to increase the number
of providers with valid and current
digital contact information available
through NPPES by publicly reporting
the names and NPIs of those providers
who do not yet have their digital contact
PO 00000
Frm 00073
Fmt 4701
Sfmt 4700
25581
information included in the NPPES
system. We proposed to begin this
public reporting in the second half of
2020, to allow individuals and facilities
time to review their records in NPPES
and update the system with appropriate
digital contact information. We also
requested comment from stakeholders
on the most appropriate way to pursue
this public reporting initiative,
including where these names should be
posted, with what frequency, and any
other information stakeholders believed
would be helpful.
We noted that we believed this
information would be extremely
valuable to facilitate interoperability,
and we appreciated Congress’
leadership in requiring the
establishment of this directory. We
requested stakeholder comment on
additional possible enforcement
authorities to ensure that individuals
and facilities make their digital contact
information publicly available through
NPPES. For example, we questioned if
Medicare reporting programs, such as
MIPS, should require eligible clinicians
to update their NPPES data with their
digital contact information? Should
CMS require this information to be
included as part of the Medicare
enrollment and revalidation process?
How can CMS work with states to
promote adding information to the
directory through state Medicaid
programs and CHIP? Should CMS
require providers to submit digital
contact information as part of program
integrity processes related to prior
authorization and submission of
medical record documentation? We
noted that we would review comments
for possible consideration in future
rulemaking on these questions.
We summarize the public comments
we received on this topic and provide
our responses.
Comment: Many stakeholders shared
our goal of improving the accuracy and
completeness of data in the NPPES.
Response: We thank commenters for
their support and are finalizing this
policy as proposed.
Comment: Many commenters, while
supporting the ultimate goal of the
proposal, noted doubts about whether
the proposal would be effective at
increasing the accuracy and
completeness of digital contact
information in NPPES. Commenters
believed that a public reporting
mechanism would not serve as a
meaningful deterrent to providers
leaving their information blank. One
commenter stated that they believed,
even with the implementation of this
proposal, high rates of inaccuracies
would persist in NPPES, and
E:\FR\FM\01MYR2.SGM
01MYR2
25582
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
stakeholders would continue to rely on
internal sources of information. Several
commenters stated that, given the
likelihood that this proposal would not
result in meaningful improvements, this
proposal would represent unnecessary
administrative burden for providers.
Response: We thank commenters for
their feedback on the potential
effectiveness of this proposal. While we
believe that this proposal is an
important initial step toward increasing
the accuracy of information in NPPES,
we appreciate that this proposal may
not be sufficient to fully realize the goal
of NPPES serving as a comprehensive
index of provider digital contact
information. To this end, we requested
comment on other programs that CMS
could leverage to improve the
completeness and accuracy of
information in NPPES. The responses to
this comment solicitation are discussed
in more detail below.
Comment: Many commenters
recommended that, instead of pursuing
a policy based on ‘‘public shaming,’’ it
would be more effective for CMS to
consider incentive-based policies for
updating their digital contact
information in NPPES.
Response: We thank commenters for
their recommendations. While we
believe the proposed policy is an
important step toward increasing the
completeness and accuracy of
information in NPPES, we believe that
other policy initiatives using incentives
may be effective as well, such as
leveraging opportunities under the
MIPS program, and we will consider
these approaches for potential inclusion
in future rulemaking.
Comment: In the proposed rule, CMS
requested comment on additional
possible enforcement authorities to
ensure that individuals and facilities
make their digital contact information
publicly available through NPPES.
Many commenters supported the use of
other authorities to increase the
accuracy and completeness of digital
contact information in NPPES, stating
that they believe these authorities were
more likely to be effective than the
proposed policy for publicly reporting
the names and NPIs of those providers
that have not included digital contact
information in NPPES.
For instance, many commenters
believed that including this requirement
in the MIPS program would be a more
effective strategy for achieving the goals
of the policy. Commenters believed this
would be more effective due to the
incentives available through the MIPS
program. Commenters also believed that
use of the MIPS program would be more
effective since the Promoting
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Interoperability category of MIPS
already includes requirements to
electronically exchange health
information, and the goal of increasing
availability of digital contact
information would align with those
features of the program. Commenters
also believed that tying this policy to
the MIPS program would help to ensure
annual updates of digital contact
information as part of required MIPS
data submissions.
Several commenters also supported
the use of the Medicare enrollment or
revalidation process and the use of
program integrity processes as ways to
promote updating of digital contact
information in NPPES.
Response: We thank commenters for
their input on additional enforcement
mechanisms. We will take these
comments under consideration as we
consider potential future rulemaking or
operational changes to these programs
that are consistent with each program’s
statutory authority.
Comment: Many commenters
suggested that CMS provide additional
education and guidance about the
benefits of adding their digital contact
information to NPPES. These
commenters recommended that CMS
engage in public education as a
necessary step before proceeding with
public reporting in order to build
awareness among providers of the
importance of updating this
information. For instance, one
commenter noted that many hospitalbased physicians are not aware of their
digital contact information, currently
relying on their institution’s informatics
division to manage this data. Others
suggested that providers are not aware
of the new functionality in NPPES
allowing for submission of digital
contact information and that education
will be needed to familiarize providers
with this feature. Commenters
recommended that public education
initiatives be targeted at those providers
least likely to be familiar with the new
functionality, and that CMS should
work with specialty societies and other
provider representatives to ensure
education reaches a wide variety of
providers. Some commenters also stated
that a public education initiative alone
would be a more appropriate alternative
to public reporting of providers’ names
and NPIs.
Response: We appreciate commenters’
recommendations around the need for
public education. Since updating the
functionality in NPPES starting in 2018,
we have taken steps to familiarize the
provider community with these updates
and plan to continue and expand this
outreach. We agree that education
PO 00000
Frm 00074
Fmt 4701
Sfmt 4700
efforts will be important to ensure that
providers are aware of their
responsibilities and that they may be at
risk of having their names and NPIs
publicly reported if they do not update
their digital contact information in
NPPES in a timely manner. While
recognizing the importance of public
education, we also believe that more
aggressive steps are needed to accelerate
the accuracy of completeness of
information within NPPES, therefore we
are finalizing the policy to publicly
report the names and NPIs of providers
that do not include digital contact
information in NPPES.
Comment: CMS proposed to begin
public reporting in the second half of
2020. A number of commenters
suggested that CMS delay this
timeframe to allow providers more time
to be made aware of the policy, review
their NPPES record, and add missing
information. One commenter believed
that this timeline was not consistent
with the time that would be required for
CMS to reach small providers with
information about the new policy, and
recommended a delay of at least an
additional 12 months before public
reporting begins.
Response: We appreciate commenters’
concerns and suggestions regarding the
appropriate timeframe for public
reporting under this proposal. However,
we believe that the proposed timeline
allows sufficient time for outreach and
education to make providers aware of
the requirement. We are therefore
finalizing this timeframe as proposed.
Comment: Many commenters
expressed concerns about the accuracy
of information in NPPES, stating that
inaccurate information imposes a
burden on both providers and
consumers who may try to collect and
use this information only to find out
that it is incorrect. These commenters
noted inaccurate contact information
also poses a problem for providers who
are concerned with sending protected
health information to the wrong
recipient. One commenter stated that
these challenges raise questions about
whether a public file is appropriate to
serve as the basis for increasing
interoperability across provider systems.
Commenters suggested steps CMS
could take to improve the accuracy of
information in NPPES. One commenter
suggested that CMS establish a
requirement that providers update their
information within a set time period.
Another commenter suggested that
NPPES post the date that information
associated with a given NPI was last
updated so that individuals reviewing
the database could assess its accuracy.
Several commenters urged CMS to
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
conduct direct outreach to providers to
confirm their information, or to validate
provider information with other
sources, such as state licensing boards,
in order to increase accuracy.
Response: We appreciate commenters’
concerns about the accuracy of provider
contact information within NPPES. The
‘‘Last Updated’’ date is posted on the
‘‘NPI View’’ page for records in the
public NPPES NPI Registry. It should
also be noted that providers are required
to update information included in
NPPES within 30 days of a change (45
CFR 162.410(a)(4)). However, we
understand from commenters that in
practice these updates often do not
occur, contributing to historical
challenges with the accuracy of NPPES
data.
We appreciate commenters’
suggestions for ways to improve the
accuracy of data within NPPES, and we
will take these suggestions into
consideration.
Comment: Several commenters noted
that providers who have not
participated in the Promoting
Interoperability Program (formerly the
EHR Incentive Programs) are more likely
to not have digital contact information
available than those that have
participated and received incentives for
adoption of health information.
Commenters stated that these providers
would be at a disadvantage under the
proposed policy, and that identifying
these providers as noncompliant
through a public reporting mechanism
would be unfair. Commenters stated
that this group likely includes smaller
practices, rural clinicians, hospitalbased clinicians, and clinicians
employed at a variety of settings which
were not eligible for EHR incentives,
such as rehabilitation centers.
Response: We appreciate commenters’
concerns regarding those clinicians that
are less likely to have existing digital
contact information. While we
understand that it may take more time
for these clinicians to obtain and submit
digital contact information to NPPES,
we believe that the timeframe for
implementing this proposal will provide
sufficient notice to clinicians. We also
believe that obtaining digital contact
information, such as a Direct address, is
now widely available to clinicians,
including those who do not have
certified EHR systems. Accordingly, we
believe that these providers will be able
to obtain digital contact information and
add it to their NPPES record with
relatively minimal burden.
Comment: Many commenters
suggested that CMS establish a process
for offering providers a chance to review
their information and correct any issues
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
prior to the implementation of public
reporting. Commenters stated that CMS
should issue communication to
providers informing them of the status
of their digital contact information, and
that communications should include
mechanisms which allow the provider
to make corrections. One commenter
recommended that CMS institute a 60day review period prior to public
reporting similar to the review period
established for data included on the
Physician Compare website.
Response: We appreciate commenters’
suggestions regarding opportunities for
clinicians to review their information
prior to the implementation of this
public reporting policy. We have
already implemented multiple methods
for providers to review their information
allowing them to correct any issues with
their NPPES record. Providers can
review their information using the
NPPES NPI Registry (https://npiregistry.
cms.hhs.gov/), the NPPES NPI Registry
API (https://npiregistry.cms.hhs.gov/
registry/help-api), or the NPPES Data
Dissemination file (https://
www.cms.gov/Regulations-andGuidance/AdministrativeSimplification/NationalProvIdentStand/
DataDissemination). Each source
currently contains all the information
that will allow providers to determine
the correctness of their information. As
discussed above, we will also engage in
continued public education efforts to
ensure providers are aware of the
benefits of including digital contact
information in NPPES, as well as the
associated public reporting policy.
Comment: Several commenters
requested additional information about
what kind of digital contact information
would satisfy this requirement. One
commenter recommended that
providers should be able to specify
other digital endpoints besides a Direct
address. Another commenter requested
clarity on whether the digital fax
numbers would qualify as digital
contact information.
Response: As discussed in the
proposed rule, NPPES is able to capture
a variety of different digital endpoints.
A digital fax number is not considered
a digital endpoint for the purposes of
this proposal. For more information on
the digital contact information which
can be added to NPPES, see https://
nppes.cms.hhs.gov/webhelp/nppeshelp/
HEALTH%20INFORMATION%20
EXCHANGE.html.
Comment: Several commenters
recommended that CMS partner with
other centralized authorities that collect
provider information. Commenters
stated that relying on providers alone to
update their information will not
PO 00000
Frm 00075
Fmt 4701
Sfmt 4700
25583
provide the levels of accuracy necessary
for other providers to utilize NPPES for
routine exchange of electronic health
information. Commenters noted that
today, directory services that employ
appropriate identify proofing processes
and other means for ensuring records
are up-to-date are much more likely to
possess accurate information than
NPPES, and CMS should seek to
improve the quality of NPPES by
working with these partners.
Commenters believed that by working
with these entities, CMS could greatly
reduce provider burden associated with
entering information into and updating
information in NPPES.
Response: We appreciate commenters’
input regarding other strategies to
improve the accuracy of the digital
contact information within NPPES.
Comment: Several commenters
requested additional guidance on how
the public reporting mechanism would
operate. One commenter sought
information on where the names would
be publicly reported. Another
commenter questioned how CMS would
address public reporting of providers
that have an NPI but do not have active
practice locations where they are
providing services under Medicare or
engaging in communication with
patients.
Response: We thank commenters for
these questions. Following the
publication of the final rule, we will
release additional information around
the public reporting mechanism
including where we intend to publish
the names and NPIs of providers that do
not have digital contact information in
NPPES, as well as information about
whether certain providers would be
exempt from public reporting.
Comment: One commenter questioned
how providers would be expected to
know their digital contact information
as this information may not be visible to
providers in many EHR systems.
Response: We encourage providers,
especially clinicians, to work with
health IT administrators in their
organization or directly with their
health IT vendor if they are unclear on
where their digital contact information
can be found. We also note that NPPES
now provides for bulk uploading of
information to multiple NPI records,
and encourage clinicians to work with
health IT administrators in their
organization to develop streamlined
processes for updating this information
in a way that imposes minimal burden
on clinicians.
Comment: Several commenters noted
the Provider Enrollment, Chain, and
Ownership System (PECOS) system
E:\FR\FM\01MYR2.SGM
01MYR2
25584
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
would be the most appropriate location
for storing digital contact information.
Response: While we understand the
interest in using PECOS as the location
for storing digital contact information,
we are not considering this as an option
at this time. PECOS collects information
specific to provider and supplier
enrollment in the Medicare program and
the system is limited to the fields on the
CMS 855 Enrollment forms. Any other
data outside of this is optional. There
are also many operational and
systematic issues that prevent PECOS
from being utilized to implement the
digital contact information requirement.
Comment: Several commenters raised
questions about what entities would
have access to the information in
NPPES. One commenter stated that any
entity should be able to gain access to
NPPES in order to advance
interoperability. Another noted that
making digital endpoints publicly
accessible via an API that may be
accessible to third parties could pose a
risk to the security of protected health
information available through those
APIs, and recommended that CMS make
this information available to other
entities only if the third-party entity
requests access from the API owner.
Response: NPPES already furnishes a
public downloadable data
dissemination file as well as a public
API that provides the public
information available in the NPI
Registry. Both files are publicly
accessible. Please note that this proposal
is not related to the Patient Access API
discussed in section III. of this final rule
that can include patient protected
health information.
Comment: A number of commenters
requested additional information on
issues related to NPPES functionality,
and sought guidance on how to enter
digital contact information. For
instance, numerous commenters
believed that the NPPES does not allow
for a provider to enter information for
multiple practice and billing locations.
Several commenters sought information
about whether a provider could enter
multiple digital endpoints, for instance
if they employ different endpoints for
different types of communication. One
commenter requested information on
whether a provider could enter digital
contact information for his or her
employer, rather than individual
information.
Response: For more information on
how information is captured in NPPES,
we encourage commenters to review
information available on the NPPES
website at https://nppes.cms.hhs.gov/
webhelp/nppeshelp/HEALTH%20
INFORMATION%20EXCHANGE.html.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Comment: Several commenters
suggested that CMS develop a digital
contact information interoperability
standard for facilitating efficient
exchange of patient records.
Response: We appreciate commenters’
suggestions, and note that we continue
to collaborate with ONC, other federal
partners, and industry stakeholders, to
develop more robust provider directory
standards that can support exchange of
this information. We also direct
commenters to the discussion of the
Provider Directory API in section IV. of
this final rule.
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments and in the CMS
Interoperability and Patient Access
proposed rule, we are finalizing to
publicly report the names and NPIs of
those providers who do not have digital
contact information included in the
NPPES system beginning in the second
half of 2020 as proposed. Additionally,
we will engage in continued public
education efforts to ensure providers are
aware of the benefits of including digital
contact information in NPPES,
including FHIR API endpoints, and
when and where this information will
be posted.
X. Conditions of Participation for
Hospitals and Critical Access Hospitals
(CAHs) Provisions, and Analysis of and
Responses to Public Comments
A. Background
As noted in the CMS Interoperability
and Patient Access proposed rule (84 FR
7649 through 7653), we appreciate the
pathways Congress has created for
action on interoperability and have been
working diligently with ONC to
implement them. In order to ensure
broad stakeholder input to inform the
proposals, we published a Request for
Information (RFI) on interoperability in
several proposed rules, including the FY
2019 IPPS proposed rule (83 FR 20550).
Specifically, we published the RFI
entitled, ‘‘Promoting Interoperability
and Electronic Healthcare Information
Exchange Through Possible Revisions to
the CMS Patient Health and Safety
Requirements for Hospitals and Other
Medicare- and Medicaid-Participating
Providers and Suppliers.’’ We requested
stakeholders’ input on how we could
use the CMS health and safety standards
that are required for providers and
suppliers participating in the Medicare
and Medicaid programs (that is, the
Conditions of Participation (CoPs),
Conditions for Coverage (CfCs), and
Requirements for long term care
facilities) to further advance electronic
PO 00000
Frm 00076
Fmt 4701
Sfmt 4700
exchange of information that supports
safe, effective transitions of care
between hospitals and community
providers. Specifically, we requested
comment on revisions to the current
CMS CoPs for hospitals such as:
Requiring that hospitals transferring
medically necessary information to
another facility upon a patient transfer
or discharge do so electronically;
requiring that hospitals electronically
send required discharge information to
a community provider via electronic
means if possible and if a community
provider can be identified; and
requiring that hospitals make certain
information available to patients or a
specified third-party application (for
example, required discharge
instructions) via electronic means if
requested.
The RFI discussed several steps we
have taken in recent years to update and
modernize the CoPs and other health
and safety standards to reflect current
best practices for clinical care,
especially in the area of care
coordination and discharge planning.
For a complete discussion of this work,
see the proposed rule (84 FR 7649
through 7650).
In the September 30, 2019 Federal
Register, we published a final rule,
‘‘Medicare and Medicaid Programs;
Revisions to Requirements for Discharge
Planning’’ (84 FR 51836) (‘‘Discharge
Planning final rule’’), that revises the
discharge planning requirements that
hospitals (including psychiatric
hospitals, long-term care hospitals, and
inpatient rehabilitation facilities),
critical access hospitals (CAHs), and
home health agencies, must meet to
participate in Medicare and Medicaid
programs. The rule supports CMS’
interoperability efforts by promoting the
exchange of patient information
between health care settings, and by
ensuring that a patient’s necessary
medical information is transferred with
the patient after discharge from a
hospital, CAH, or post-acute care
services provider. By requiring that all
of the patient’s necessary medical
information, including his or her postdischarge goals of care and treatment
preferences, must be documented in the
patient’s medical record and transferred
along with the patient at the time of
discharge to an appropriate receiving
health care facility, such as a PAC
service provider or agency, and to other
outpatient service providers and
practitioners responsible for the
patient’s follow-up or ancillary care, the
rule aims to better prepare patients and
their caregivers to be active partners and
advocates for their health care and
community support needs upon
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
discharge from the hospital or postacute care setting.
While we finalized a broad
requirement for sending necessary
medical information in accordance with
all applicable laws, rather than listing
specific data elements (such as those
explicitly aligned with the data
referenced as part of the Common
Clinical Data Set (CCDS) that was
finalized in the 2015 final rule,
‘‘Medicare and Medicaid Programs;
Electronic Health Record Incentive
Program—Stage 3 and Modifications to
Meaningful Use in 2015 Through 2017’’
(80 FR 62762), we also ensured that the
revisions to the CoPs did not conflict
with the CCDS, or future standards
proposed for adoption for electronic
exchange of health information,
specifically the USCDI. The discharge
planning CoPs do not bar providers
from sending all additional appropriate
medical information regarding the
patient’s current course of illness and
treatment, post-discharge goals of care,
and treatment preferences in accordance
with applicable laws. However, we note
here that the Discharge Planning final
rule does not require hospitals, CAHs,
and HHAs to transfer the necessary
patient medical information exclusively
by electronic means nor does it require
that providers notify the appropriate
providers, suppliers, and practitioners
receiving the necessary medical
information of the patient’s discharge as
we are now requiring in this final rule.
Additionally, the Discharge Planning
final rule further supports
interoperability and a patient’s access to
his or her own medical records by
updating the hospital Patient Rights CoP
to now state that the patient has the
right to access his or her medical
records in the form and format
requested (including in an electronic
form or format when such medical
records are maintained electronically).
Therefore, the hospital CoPs now
include an explicit requirement that, as
a condition of participation, hospitals
must provide patients with access to
their medical records in an electronic
format upon the patient’s request if the
hospital has the capacity to do so.
In response to the RFI in the FY 2019
IPPS proposed rule, many stakeholders
supported our goals of increasing
interoperability, and acknowledged the
important role that hospital settings
play in supporting care coordination.
Stakeholders agreed that use of
electronic technology was an important
factor in ensuring safe transitions.
Multiple stakeholders emphasized that
electronic data exchange between
hospitals and physician offices, as well
as with hospices, HHAs, SNFs, and
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
other post-acute care services providers,
was especially important during care
transitions when maintaining access to
patient health information, including
medication information, and is
extremely relevant to the patient’s next
phase of care. Additionally,
stakeholders noted that giving patients
and their caregivers access to important
health information (such as discharge
information along with accurately
reconciled lists of discharge
medications) created a more patientcentered health care system, and
reduced the risk of errors and hospital
readmissions. But many stakeholders
also expressed concerns about
implementing policy changes within the
CoPs that might increase the compliance
burden on hospitals. However, several
stakeholders also strongly
recommended that CMS add details to
the CoPs, and require that hospitals
share not only medically necessary
information with physician offices,
HHAs, and SNFs (such as pending tests
and discharge summaries), but also
notifications of when patients were
admitted to the hospital as well as
discharged or transferred from the
hospital and admitted to the care of
applicable PAC services providers and
suppliers.
Given responses to the RFI, as well as
previous rulemaking activities, we
sought to further expand CMS
requirements for interoperability within
the hospital and CAH CoPs as part of
the CMS Interoperability and Patient
Access proposed rule by focusing on
electronic patient event notifications. In
addition, we noted that we were
committed to taking further steps to
ensure that facilities that are
electronically capturing information are
electronically exchanging that
information with providers who have
the capacity to accept it.
Infrastructure supporting the
exchange of electronic health
information across settings has matured
substantially in recent years. Research
studies have increasingly found that
health information exchange
interventions can affect positive
outcomes in health care quality and
public health, in addition to more
longstanding findings around
reductions in utilization and costs. A
recent review of how health information
exchange interventions can improve
cost and quality outcomes identified a
growing body of high-quality studies
showing that these interventions are
associated with beneficial results.53 The
53 Menachemi, N., Rahurkar, S., Harle, C.A., &
Vest, J.R. (2018). The benefits of health information
exchange: An updated systematic review. Journal of
PO 00000
Frm 00077
Fmt 4701
Sfmt 4700
25585
authors identified a number of studies
demonstrating positive effects on
outcomes associated with better care
coordination, such as reductions in 30day readmissions,54 55 56 and improved
medication reconciliation.57
Electronic patient event notifications
from hospitals, or clinical event
notifications, are one type of health
information exchange intervention that
has been increasingly recognized as an
effective and scalable tool for improving
care coordination across settings,
especially for patients at discharge. This
approach has been associated with a
reduction in readmissions following
implementation of such notifications.58
We noted that the evidence cited in this
section to support the use of innovative
health information exchange
interventions and approaches, such as
the patient event notifications that we
proposed to require, can be applied to
various types of hospitals, including
psychiatric hospitals, as well as to
CAHs, as discussed below.
Patient event notifications are
automated, electronic communications
from the discharging provider to another
facility, or to another applicable
community provider as identified by the
patient (such as a patient’s primary care
practitioner or practice group, postacute care services providers and
suppliers, and other practitioners and
providers that need the notification for
post-acute care coordination, treatment,
and/or quality improvement purposes),
the American Medical Informatics Association,
25(9), 1259–1265. doi: 10.1093/jamia/ocy035.
54 Yeaman, B., Ko, K., del Castillo, R. (2015). Care
transitions in long-term care and acute care: Health
information exchange and readmission rates. The
Online Journal of Issues in Nursing, 20(3). doi:
10.3912/OJIN.Vol20No03Man05.
55 Vest, J.R., Kern, L.M., Silver, M.D., & Kaushal,
R. (2015). The potential for community-based
health information exchange systems to reduce
hospital readmissions. Journal of the American
Medical Informatics Association, 22(2), 435–442.
doi: 10.1136/amiajnl-2014–002760.
56 Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest,
J.R. (2017). Hospitalization event notifications and
reductions in readmissions of Medicare fee-forservice beneficiaries in the Bronx, New York.
Journal of the American Medical Informatics
Association, 24(e1), e150–e156. doi: 10.1093/jamia/
ocw139.
57 Boockvar, K.S., Ho, W., Pruskowski, J., Dipalo,
K.E., Wong, J.J., Patel, J., . . . Hung, W. (2017).
Effect of health information exchange on
recognition of medication discrepancies is
interrupted when data charges are introduced:
Results of a cluster-randomized controlled trial.
Journal of the American Medical Informatics
Association, 24(6), 1095–1101. doi: 10.1093/jamia/
ocx044.
58 Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest,
J.R. (2017). Hospitalization event notifications and
reductions in readmissions of Medicare fee-forservice beneficiaries in the Bronx, New York.
Journal of the American Medical Informatics
Association, 24(e1), e150–e156. doi: 10.1093/jamia/
ocw139.
E:\FR\FM\01MYR2.SGM
01MYR2
25586
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
which alerts the receiving provider that
the patient has received care at a
different setting. Depending on the
implementation, information included
with these notifications can range from
conveying the patient’s name, other
basic demographic information, and the
sending institution to a richer set of
clinical data on the patient. Even with
a minimum set of information included,
these notifications can help ensure that
a receiving provider, facility, or
practitioner is aware that the patient has
received care elsewhere. The
notification triggers a receiving
provider, facility, or practitioner to
reach out to the patient and deliver
appropriate follow-up care in a timely
manner. By notifying the individuals
and entities that need notification of the
patient’s status for treatment, care
coordination, or quality improvement
purposes, the notification can help to
improve post-discharge transitions and
reduce the likelihood that a patient
would face complications from
inadequate follow-up care.
In addition to their effectiveness in
supporting care coordination, virtually
all EHR systems generate the basic
messages commonly used to support
electronic patient event notifications.
These notifications are based on
admission, discharge, and transfer
(ADT) messages, a standard message
used within an EHR as the vehicle for
communicating information about key
changes in a patient’s status as they are
tracked by the system (more information
about the current standard supporting
these messages is available at https://
www.hl7.org/implement/standards/
product_brief.cfm?product_id=144). As
noted in the Interoperability Standards
Advisory (ISA) published by ONC, this
messaging standard has been widely
adopted across the health care system
(see https://www.healthit.gov/isa/
sending-a-notification-a-patientsadmission-discharge-andor-transferstatus-other-providers).
ADT messages provide each patient’s
personal or demographic information
(such as the patient’s name, insurance,
next of kin, and attending physician),
when that information has been
updated, and also indicate when an
ADT status has changed. To create an
electronic patient event notification, a
system can use the change in ADT
status to trigger a message to a receiving
provider or to a health information
exchange system that can then route the
message to the appropriate provider. In
addition to the basic demographic
information contained in the ADT
message, some patient event notification
implementations attach more detailed
information to the message regarding
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
the patient’s clinical status and care
received from the sending provider.
B. Provisions for Hospitals (42 CFR
482.24(d))
We proposed to revise the CoPs for
Medicare- and Medicaid-participating
hospitals at 42 CFR 482.24 by adding a
new standard at paragraph (d),
‘‘Electronic Notifications,’’ that would
require hospitals to send electronic
patient event notifications of a patient’s
admission, discharge, and/or transfer to
another health care facility or to another
community provider or practitioner. We
proposed to require hospitals to convey,
at a minimum, the patient’s basic
personal or demographic information, as
well as the name of the sending
institution (that is, the hospital), and, if
not prohibited by other applicable law,
the patient’s diagnosis. In proposing
that patient event notifications sent by
a hospital’s medical records system
include diagnosis, where not prohibited
by other applicable law, we requested
comment on the technical feasibility of
this proposal, noting that we recognize
some existing ADT messages might not
include diagnosis, as well as the
challenges in appropriately segmenting
this information in instances where the
diagnosis may not be permitted for
disclosure under other applicable laws.
We also encouraged hospitals, as their
systems and those of the receiving
providers allowed, to work with
patients and their practitioners to offer
more robust patient information and
clinical data upon request in accordance
with applicable law.
For a hospital that currently possesses
an EHR system with the capacity to
generate the basic patient personal or
demographic information for electronic
patient event notifications, we proposed
that compliance with the proposed
standard within the Medical records
services CoP (42 CFR 482.24) would be
determined by the hospital
demonstrating to the surveyor or
accrediting organization that its system:
(1) Is fully operational and that it
operates in accordance with all state
and federal statutes and regulations
regarding the exchange of patient health
information; (2) utilizes the content
exchange standard incorporated by
reference at 45 CFR 170.205(a)(4)(i); (3)
sends notifications that would have to
include the minimum patient health
information (which, as noted above,
would be the patient’s name, treating
practitioner name, sending institution
name, and, if not prohibited by other
applicable law, patient diagnosis); and
(4) sends notifications directly, or
through an intermediary that facilitates
exchange of health information, and at
PO 00000
Frm 00078
Fmt 4701
Sfmt 4700
the time of the patient’s admission to
the hospital and either immediately
prior to or at the time of the patient’s
discharge and/or transfer from the
hospital.
We proposed to limit this requirement
to only those hospitals which currently
possess EHR systems with the technical
capacity to generate information for
electronic patient event notifications as
discussed below, recognizing that not
all Medicare- and Medicaidparticipating hospitals have been
eligible for past programs promoting
adoption of EHR systems. We noted our
goal in proposing the requirement was
to ensure that hospital EHR systems
have a basic capacity to generate
messages that can be utilized for
notifications by a wide range of
receiving providers, enabled by
common standards. We believed that a
system that utilizes the ADT messaging
standard, which is widely used as the
basis for implementing these
notifications and other similar use
cases, would meet this goal by
supporting the availability of
information that can be used to generate
information for patient event
notifications. Specifically, we proposed
that the system utilize the ADT
messaging standard incorporated by
reference at 45 CFR 170.205(a)(4)(i).59
We noted that, while there are no
criteria under the ONC Health IT
Certification Program which certifies
health IT to create and send electronic
patient event notifications, the ADT
standard is referenced by other
certification criteria under the program.
Specifically, this standard supports
certification criteria related to
transferring information to
immunization registries, as well as
transmission of laboratory results to
public health agencies as described at
45 CFR 170.315(f) under the 2015
Edition certification criteria, and at 45
CFR 170.314(f) under the 2014 Edition.
Thus, we expect systems that include
Health IT Modules certified to meet
criteria which reference this standard
will possess the basic capacity to
generate information for notification
messages. We further noted that
adopting certified health IT that meets
these criteria has been required for any
hospital seeking to qualify for the
Promoting Interoperability Programs
(formerly the EHR Incentive Programs).
We recognized that there is currently
significant variation in how hospitals
have utilized the ADT messages to
59 Health Level Seven Messaging Standard
Version 2.5.1 (HL7 2.5.1), an Application Protocol
for Electronic Data Exchange in Healthcare
Environments, February 21, 2007.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
support implementation of patient event
notifications. We also recognized that
many hospitals, which have already
implemented notifications, may be
delivering additional information
beyond the basic information included
in the ADT message (both automatically
when a patient’s status changes and
then upon request from receiving
providers) to receiving practitioners,
patient care team members, and postacute care services providers and
suppliers with whom they have
established patient care relationships
and agreements for patient health
information exchange as allowed by
law. We believe consensus standards for
ADT-based notifications may become
more widely adopted in the future (we
refer readers to ONC’s ISA 60 for more
information about standards under
consideration). However, at this time,
we stated that we did not wish to
restrict hospitals from pursuing more
advanced content as part of patient
notifications, nor to create redundant
requirements where hospitals already
have a suitable notification system in
place. Accordingly, while we specified
that hospitals subject to the proposal
possess a system utilizing this standard,
we proposed that hospitals could utilize
other standards or features to support
their notification systems. We requested
comment on the proposal, including
whether this requirement would achieve
the goal of setting a baseline for
hospitals’ capacity to generate
information for electronic notifications,
while still allowing for innovative
approaches that would potentially
increase the effectiveness of these
notifications toward improving patient
outcomes and safety during transitions
in care.
We further proposed that the hospital
would need to demonstrate that the
system’s notification capacity was fully
operational, that it operated in
accordance with all state and federal
statutes and regulations regarding the
exchange of patient health information.
We intended for these notifications to be
required, at minimum, for inpatients
admitted to, and discharged and/or
transferred from the hospital. However,
we also noted that patient event
notifications are an effective tool for
coordinating care across a wider set of
patients that may be cared for by a
hospital. For instance, a patient event
notification could ensure that a primary
care physician was aware that his or her
patient had received care at the
60 Office of the National Coordinator. (n.d.).
Admission, Discharge, and Transfer. Retrieved from
https://www.healthit.gov/isa/admission-dischargeand-transfer.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
emergency room, and initiate outreach
to the patient to ensure that appropriate
follow-up for the emergency visit was
pursued. While we encouraged
hospitals to extend the coverage of their
notification systems to serve additional
patients, outside of those admitted and
seen as inpatients, we also sought
comment on whether we should
identify a broader set of patients to
whom this requirement would apply,
and if so, how we should implement
such a requirement in a way that
minimizes administrative burden on
hospitals.
Additionally, we proposed that the
hospital would have to demonstrate that
its system sends notifications that
include the minimum patient health
information (specifically, patient name,
treating practitioner name, sending
institution name, and, if not prohibited
by other applicable law, patient
diagnosis). We proposed that the
hospital would also need to demonstrate
that the system sends notifications
directly, or through an intermediary that
facilitates exchange of health
information, at the time of the patient’s
hospital admission, discharge, or
transfer, to licensed and qualified
practitioners, other patient care team
members, and PAC services providers
and suppliers that: (1) Receive the
notification for treatment, care
coordination, or quality improvement
purposes; (2) have an established care
relationship with the patient relevant to
his or her care; and (3) the hospital has
reasonable certainty that such
notifications are received. We noted that
we believed the proposal would allow
for a diverse set of strategies that
hospitals might use when implementing
patient event notifications.
Through these provisions, we sought
to allow for different ways that a
hospital might identify those
practitioners, other patient care team
members, and PAC services providers
and suppliers that are most relevant to
both the pre-admission and postdischarge care of a patient. We proposed
that hospitals send notifications to those
practitioners or providers that had an
established care relationship with the
patient relevant to his or her care. We
recognized that hospitals and their
partners may identify appropriate
recipients through various methods. For
instance, hospitals might identify
appropriate practitioners by requesting
this information from patients or
caregivers upon arrival, or by obtaining
information about care team members
from the patient’s record. We expected
hospitals might develop or optimize
processes to capture information about
established care relationships directly,
PO 00000
Frm 00079
Fmt 4701
Sfmt 4700
25587
or work with an intermediary that
maintains information about care
relationships. In other cases, we noted
that hospitals may, directly or through
an intermediary, identify appropriate
notification recipients through the
analysis of care patterns or other
attribution methods that seek to
determine the provider most likely to be
able to effectively coordinate care postdischarge for a specific patient. The
hospital or intermediary might also
develop processes to allow a provider to
specifically request notifications for a
given patient for whom they are
responsible for care coordination as
confirmed through conversations with
the patient.
Additionally, we expected hospitals,
psychiatric hospitals, and CAHs to
comply with the HIPAA Rules set out at
45 CFR parts 160 and 164 if these
proposed CoP requirements for patient
event notifications were finalized. As
required at 42 CFR 482.11 for hospitals
and psychiatric hospitals and at 42 CFR
485.608 for CAHs, these providers must
comply with all pertinent currently
existing federal laws, including the
HIPAA Privacy and Security Rules. The
Privacy Rule permits patient event
notifications as disclosures for treatment
purposes (the proposed required
notifications, when finalized, also may
be treated as disclosures required by law
(see 45 CFR 164.502(a)).
We also recognized that factors
outside of the hospital’s control might
determine whether or not a notification
was successfully received and utilized
by a practitioner. Accordingly, we
proposed that a hospital would only
need to send notifications to those
practitioners for whom the hospital has
reasonable certainty of receipt. While
we stated that we expected hospitals
would, to the best of their ability, seek
to ensure that notification recipients
were able to receive notifications (for
instance, by obtaining a recipient’s
Direct address 61), we understood that
technical issues beyond the hospital’s
control could prevent successful receipt
and use of a notification.
Finally, we noted that hospitals have
an existing responsibility under the
CoPs at 42 CFR 482.43(d) to ‘‘transfer or
refer patients, along with necessary
medical information, to appropriate
facilities, agencies, or outpatient
services, as needed, for follow-up or
ancillary care.’’ We emphasized that the
proposal regarding patient event
notifications would be separate from the
61 For more information about obtaining a Direct
addresses, see https://www.healthit.gov/sites/
default/files/directbasicsforprovidersqa_
05092014.pdf.
E:\FR\FM\01MYR2.SGM
01MYR2
25588
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
requirement regarding necessary
medical information at 42 CFR
482.43(d). However, we recognized that
processes to implement the proposal, if
finalized, could intersect with the
hospital’s discharge planning process.
We noted that nothing in the proposal
would affect the hospital’s
responsibilities under 42 CFR 482.43(d).
However, we noted if the proposal was
finalized, hospitals might wish to
consider ways to fulfill these
requirements in ways that reduce
redundancy while still remaining
compliant with existing requirements.
For instance, where appropriate and
allowed by law, hospitals might seek to
include required necessary medical
information within the same message as
a patient event notification.
C. Provisions for Psychiatric Hospitals
(42 CFR 482.61(f))
Medicare- and Medicaid-participating
psychiatric hospitals must comply with
all of the hospital CoPs at 42 CFR 482.1
through 482.23 and at 42 CFR 482.25
through 482.57. They also must adhere
to special provisions regarding medical
records at 42 CFR 482.61 and staffing
requirements at 42 CFR 482.62. Since
the medical records requirements are
different for psychiatric hospitals, and
since these hospitals do not have to
comply with the regulations at 42 CFR
482.24, we proposed a new electronic
notification standard at 42 CFR 482.61(f)
within the special provisions for
psychiatric hospitals in this section.
Similar to the proposal for hospitals at
42 CFR 482.24(d), we proposed a new
standard at 42 CFR 482.61(f),
‘‘Electronic Notifications,’’ that would
require psychiatric hospitals to send
electronic patient event notifications of
a patient’s admission, discharge, and/or
transfer to another health care facility or
to another community provider.
As we proposed for hospitals, we
proposed to limit this requirement to
only those psychiatric hospitals which
currently possess EHR systems with the
technical capacity to generate
information for electronic patient event
notifications, defined as systems that
utilize the content exchange standard
incorporated by reference at 45 CFR
170.205(a)(4)(i). We proposed that that
for a psychiatric hospital that currently
possessed an EHR system with the
capacity to generate the basic patient
personal or demographic information
for electronic patient event (ADT)
notifications, compliance with the
proposed standard within the Special
medical records requirements for
psychiatric hospitals CoP (42 CFR
482.61) would be determined by the
hospital demonstrating that its system:
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
(1) Is fully operational and that it
operated in accordance with all state
and federal statutes and regulations
regarding the exchange of patient health
information; (2) utilizes the content
exchange standard incorporated by
reference at 45 CFR 170.205(a)(4)(i); (3)
sends notifications that would have to
include the minimum patient health
information (specifically, patient name,
treating practitioner name, sending
institution name, and, if not prohibited
by other applicable law, patient
diagnosis); and (4) sends notifications
directly, or through an intermediary that
facilitates exchange of health
information, and at the time of the
patient’s admission to the hospital and
either immediately prior to or at the
time of the patient’s discharge and/or
transfer from the hospital. We requested
comment on the policy as part of this
hospital proposal in section X.B. of the
CMS Interoperability and Patient Access
proposed rule (84 FR 7650 through
7652).
We also proposed that the hospital
would need to demonstrate that the
system sends notifications directly, or
through an intermediary that facilitates
exchange of health information, and
either immediately prior to or at the
time of the patient’s hospital admission,
discharge, or transfer, to licensed and
qualified practitioners, other patient
care team members, and PAC services
providers and suppliers that: (1) Receive
the notification for treatment, care
coordination, or quality improvement
purposes; (2) have an established care
relationship with the patient relevant to
his or her care; and (3) the hospital is
reasonably certain will receive such
notifications.
We referred readers to the extended
discussion of the proposals in sections
X.A. and B. of the CMS Interoperability
and Patient Access proposed rule (84 FR
7649 through 7652). We sought
comment on these proposals.
D. Provisions for CAHs (42 CFR
485.638(d))
We believe implementation of patient
event notifications are also important
for CAHs to support improved care
coordination from these facilities to
other providers in their communities.
Therefore, similar to the proposals for
the hospital and psychiatric hospital
medical records requirements as
discussed in the preceding sections, we
proposed to revise 42 CFR 485.638, by
adding a new standard to the CAH
Clinical records CoP at paragraph (d),
‘‘Electronic Notifications.’’ As
discussed, the proposed standard would
require CAHs to send electronic patient
event notifications of a patient’s
PO 00000
Frm 00080
Fmt 4701
Sfmt 4700
admission, discharge, and/or transfer to
another health care facility or to another
community provider.
We proposed to limit this requirement
to only those CAHs which currently
possess EHR systems with the technical
capacity to generate information for
electronic patient event notifications,
defined as systems that utilize the
content exchange standard incorporated
by reference at 45 CFR 170.205(a)(4)(i).
We proposed that for a CAH that
currently possessed an EHR system with
the capacity to generate the basic patient
personal or demographic information
for electronic patient event (ADT)
notifications, compliance with the
proposed standard within the Clinical
records services CoP (42 CFR 485.638)
would be determined by the CAH
demonstrating that its system: (1) Is
fully operational and that it operates in
accordance with all state and federal
statutes and regulations regarding the
exchange of patient health information;
(2) utilizes the content exchange
standard incorporated by reference at 45
CFR 170.205(a)(4)(i); (3) sends
notifications that would have to include
the minimum patient health information
(specifically, patient name, treating
practitioner name, sending institution
name, and, if not prohibited by other
applicable law, patient diagnosis); and
(4) sends notifications directly, or
through an intermediary that facilitates
exchange of health information, and at
the time of the patient’s admission to
the CAH and either immediately prior to
or at the time of the patient’s discharge
and/or transfer from the CAH. We
requested comment on the policy as part
of the hospital proposal in section X.B.
of the CMS Interoperability and Patient
Access proposed rule (84 FR 7650
through 7652).
Additionally, we proposed that the
CAH would need to demonstrate that
the system sends notifications directly,
or through an intermediary that
facilitated exchange of health
information, and at or immediately prior
to the time of the patient’s CAH
admission, discharge, or transfer, to
licensed and qualified practitioners,
other patient care team members, and
PAC services providers and suppliers
that: (1) Receive the notification for
treatment, care coordination, or quality
improvement purposes; (2) have an
established care relationship with the
patient relevant to his or her care; and
(3) the CAH is reasonably certain will
receive such notifications.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
E. Comments and Responses on the
Provisions of the Proposed Rule; Final
Actions and Provisions of the Final Rule
for Hospitals (42 CFR 482.24(d)),
Psychiatric Hospitals (42 CFR 482.61(f));
and CAHs (42 CFR 485.638(d))
We requested comments on the
proposals including stakeholder
feedback about how the proposals
should be operationalized. Additionally,
we sought comment on how CMS
should implement these proposals as
part of survey and certification guidance
in a manner that minimizes compliance
burden on hospitals, psychiatric
hospitals, and CAHs while ensuring
adherence with the standards. We also
sought stakeholder input about a
reasonable timeframe for
implementation of these proposals for
hospitals, psychiatric hospitals, and
CAHs, respectively.
We received more than 600 public
comments on this section that were
specific to the patient event notification
requirements proposed for inclusion in
the CoPs, but which generally did not
distinguish among the requirements
individually proposed for hospitals,
psychiatric hospitals, and CAHs at 42
CFR 482.24(d), 482.61(f), and
485.638(d), respectively. We summarize
the public comments we received on
our proposals related to the Conditions
of Participation and provide our
responses in this section. This summary
of the public comments and our
responses apply equally to all three
provider types included under this
proposed requirement and the specific
provisions proposed for each unless
otherwise noted. We provide the final
actions and the provisions of the final
rule at the end of this section.
Comment: Many commenters
supported the proposals to require
hospitals (including psychiatric
hospitals) and CAHs to send electronic
patient event notifications of a patient’s
admission, discharge, and/or transfer to
another health care facility or to another
community provider. Commenters
stated that they believed implementing
patient event notifications would be a
highly effective tool to improve care
transitions for patients moving between
a hospital and other settings, including
returning home. Commenters believed
that increasing the sharing of patient
event notifications at admission and
discharge can lead to improved
outcomes, higher quality, and lower cost
care. Commenters also pointed to many
instances in which these notifications
are being utilized today, stating that
they believe that patient event
notifications had effectively contributed
to improved care coordination. For
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
instance, one commenter pointed to the
statewide requirement for hospitals in
Maryland to transmit notifications,
noting that this has been an important
policy supporting care coordination in
the state. Several commenters noted that
the availability of notification
information is especially important for
the success of value-based payment
models, such as ACO initiatives, where
participants may be financially at risk
for costs associated with poor care
transitions.
Response: We appreciate commenters’
support for the proposal and are
finalizing our proposal with
modifications as discussed below.
Comment: While many commenters
agreed that patient event notifications
are an important way to improve care
coordination, some disagreed that the
CoPs were the appropriate vehicle for
advancing their use. Many commenters
stated that by placing the patient event
notification requirements in the CoPs,
CMS is putting hospitals’ participation
in Medicare at risk, which they stated
would be an excessive penalty for
failure to implement patient event
notifications in accordance with the
proposed requirements.
Commenters also stated that the
survey and certification process was not
well-suited to determining compliance
with the proposed CoP ‘‘Electronic
notifications’’ standard. These
commenters questioned how surveyors
would assess compliance with the
requirements, including one commenter
who questioned how a hospital would
demonstrate that its system sent
notifications that improve the
coordination of care, and not just show
that its system is merely functioning as
required. They further stated that a
survey team would need clear guidance
on how to assess providers for
compliance to ensure that hospitals are
transmitting patient information to, and
receiving it from, other providers.
Additionally, one commenter stated
that hospital accreditation programs are
not the appropriate entities to assess
compliance, due to the technical nature
of the requirements.
Commenters also expressed concern
that tying these requirements to the
CoPs could lead to hospitals sending
more information than is necessary to
ensure compliance, further increasing
excessive information received by
providers.
Response: We appreciate the
commenters’ concerns regarding use of
the CoPs to advance the use of patient
notifications; however, we disagree that
the CoPs are an inappropriate vehicle
for this purpose. We believe that the
capability to send patient event
PO 00000
Frm 00081
Fmt 4701
Sfmt 4700
25589
notifications should be a fundamental
feature of hospital medical record
systems to support effective care
transitions and promote patient safety
during transitions. This belief is
consistent with the statutory authority
for establishing and appropriately
updating the CoPs as that authority is
contained in section 1861(e) of the Act,
which defines institutions that meet the
definition of a hospital for Medicare
purposes. Specifically, section
1861(e)(2) of the Act requires that a
hospital ‘‘maintains clinical records on
all patients,’’ and section 1861(e)(9) of
the Act requires that a hospital ‘‘meets
such other requirements as the Secretary
finds necessary in the interest of the
health and safety of individuals who are
furnished services in the institution.’’
As discussed in the proposed rule (84
FR 7650), we believe patient event
notifications can help to improve care
coordination for patients discharged
from the hospital and reduce the
incidence of events such as hospital
readmissions that could have been
avoided through more timely follow-up
care.
Further, including a CoP requirement
for patient event notifications at the
time of a patient’s discharge or transfer
as we have proposed and are finalizing
in this rule is also consistent with
section 1861(ee)(2) of the Act, which
states that the Secretary shall develop
guidelines and standards for the
discharge planning process in order to
ensure a timely and smooth transition to
the most appropriate type of and setting
for post-hospital or rehabilitative care.
We believe patient event notifications
are an effective tool for ensuring that the
settings responsible for follow-up care
are made aware that their patients have
been discharged in an expeditious
manner. We believe that these
notifications can be utilized to more
effectively trigger care coordination
activities that promote timely
transitions. We have chosen to include
these requirements in the CoPs for
medical records services, and not those
for discharge planning, because we
believe that the medical records CoPs
provide a more global approach to the
notifications than do the discharge
planning CoPs, especially since we are
requiring notifications for inpatient
admissions as well as ED and outpatient
observation admissions or registrations
in addition to patient discharges and
transfers. Therefore, given this statutory
authority, we maintain that the CoPs are
an appropriate vehicle for advancing the
use of patient event notifications.
We also disagree that the CoPs are an
inappropriate vehicle for this policy due
to what the commenters’ characterize as
E:\FR\FM\01MYR2.SGM
01MYR2
25590
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the disproportionate penalties
associated with noncompliance with
this CoP. We note that while the CoPs
are a significant regulatory mechanism,
noncompliance with one subordinate
standard under one CoP must be
considered relative to a hospital’s
compliance or noncompliance with the
many other CoPs and standards as well
as the severity of the noncompliance
and the risk it poses to patient health
and safety. Under the heading,
‘‘Determining the Severity of
Deficiencies,’’ the State Operations
Manual (SOM), Appendix A—Survey
Protocol, Regulations and Interpretive
Guidelines for Hospitals cites the
regulations at 42 CFR 488.26 (‘‘The
decision as to whether there is
compliance with a particular
requirement, condition of participation,
or condition for coverage, depends upon
the manner and degree to which the
provider or supplier satisfies the various
standards within each condition.’’) as
the basis for determining the various
levels of noncompliance with the CoPs
during a survey (https://www.cms.gov/
Regulations-andGuidance/Guidance/
Manuals/downloads/som107ap_a_
hospitals.pdf; p.19).
From page 19 of the SOM, Appendix
A:
‘‘When noncompliance with a
condition of participation is noted, the
determination of whether a lack of
compliance is at the Standard or
Condition level depends upon the
nature (how severe, how dangerous,
how critical, etc.) and extent (how
prevalent, how many, how pervasive,
how often, etc.) of the lack of
compliance. The cited level of the
noncompliance is determined by the
interrelationship between the nature
and extent of the noncompliance.
‘‘A deficiency at the Condition level
may be due to noncompliance with
requirements in a single standard or
several standards within the condition,
or with requirements of noncompliance
with a single part (tag) representing a
severe or critical health or safety breach.
Even a seemingly small breach in
critical actions or at critical times can
kill or severely injure a patient, and
represents a critical or severe health or
safety threat.
‘‘A deficiency is at the Standard level
when there is noncompliance with any
single requirement or several
requirements within a particular
standard that are not of such character
as to substantially limit a facility’s
capacity to furnish adequate care, or
which would not jeopardize or
adversely affect the health or safety of
patients if the deficient practice
recurred.’’
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Regarding the comments questioning
how surveyors, either state surveyors or
those from one of the hospital
accreditation programs, would
determine compliance with the
notification requirements, we will issue,
as we do with all new or revised CoP
requirements, new interpretive
guidelines, which include survey
procedures, for the State Operations
Manual, following finalization of this
rule and prior to the rule’s effective
date. We will advise and train state
surveyors on the new requirements as is
the normal procedure when new and/or
revised CoPs and standards are
finalized. For example, the current
Medical Record Services CoP
requirements, contained at 42 CFR
482.24, and in which we are finalizing
these new patient event notification
requirements, primarily contain
provisions for administrative systems or
processes where the hospital is
responsible for demonstrating that the
various components of its medical
records system or process are in place
and operational in order to comply with
the overall requirements of the CoP.
Surveyors would then approach these
new requirements in a similar fashion
and apply similar survey procedures
and methods that do not require
surveyors to have deep technical
knowledge of various systems in order
to determine compliance. As with the
survey of the hospital’s total medical
records system, surveyors would utilize
basic and effective survey procedures
and methods such as:
• Review of the organizational
structure and policy statements and an
interview with the person responsible
for the medical records service to first
ascertain that the hospital has a system
that meets the initial requirements for
patient event notifications in order to
determine whether or not the hospital is
exempt from the specific patient event
notification requirements that follow.
• Review of a sample of active and
closed medical records for completeness
and accuracy, including any patient
event notifications, in accordance with
federal and state laws and regulations
and hospital policy.
• Interview of medical records and
other hospital staff, including
physicians and other practitioners, to
determine understanding of the patient
events notification function of the
system.
• Conducting observations and
interviews with medical records staff
and leadership to determine if
requirements for patient event
notifications are being met.
CMS-approved accreditation
organizations (AOs) with hospital
PO 00000
Frm 00082
Fmt 4701
Sfmt 4700
programs are required, at a minimum, to
enforce standards that meet or exceed
hospital CoP requirements, so each AO
will be responsible for training its
survey and accreditation staff on the
patient event notification requirements
finalized in this rule ahead of the
applicable date established by CMS.
Finally, the patient event notification
requirements that we are finalizing
require a hospital to send only a
minimal amount of patient information
in order to be in compliance with the
provisions. These requirements are
consistent with our belief that existing
patient event notification systems have
demonstrated that a minimal set of
information can achieve the desired
effect of improving care coordination
while imposing minimal burden on
providers. However, hospitals are not
prohibited from sending more detailed
information under these requirements
and we would expect each hospital is
fully aware of its own capacity to send
additional patient information, other
applicable laws governing this, and the
capacities of the intended recipients to
receive additional patient information,
and would base its decisions to send
additional information on these factors
as well as on what is best for the patient.
Based on our experience with hospitals,
we disagree with the commenter that a
hospital would unnecessarily send
‘‘excessive’’ amounts of patient
information in an attempt to ensure a
determination that the hospital was in
compliance. To prevent such confusion,
we have clearly delineated the patient
information requirements in this final
rule.
Comment: Many commenters stated
that the CoPs were not appropriate for
advancing goals related to
interoperability and the use of health IT.
Commenters stated that CMS currently
regulates provider use of technology
through a variety of other avenues, such
as the Promoting Interoperability
Programs, and that adding the proposed
requirements under the CoPs would add
an unnecessary additional mechanism
for addressing these issues. Commenters
believed this could lead to additional
provider burden and confusion, as
stakeholders would be required to
navigate duplicative requirements
around the electronic exchange of
information. Several commenters stated
that, by shifting focus to compliance
with the proposed requirements, and
requiring hospitals to engage in
duplicative reporting on information
exchange, this proposal could divert
funding and attention from necessary
investments in interoperable health
information exchange. Commenters
stated that they believed using the CoPs
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
in this fashion was inconsistent with
congressional intent for how HHS
should regulate the use of health IT.
Commenters also noted that HHS is
currently seeking to establish a range of
new policies designed to advance the
interoperable exchange of health
information. Commenters believed these
policies could have a significant impact
on the sharing of health information,
including the sharing of patient event
notifications, and that CMS should
refrain from rulemaking through the
CoPs until these polices have been
finalized. One commenter also noted
that, at the time the comment period on
the CMS Interoperability and Patient
Access proposed rule closed, CMS’
Discharge Planning rule (80 FR 68125)
had not yet been finalized, and that it
would be premature to add this
requirement in advance of finalizing
related revisions to the discharge
planning section of the CoPs.
Commenters further stated that HHS
has a variety of other mechanisms for
advancing electronic information
exchange and improving the
infrastructure for exchange that would
be more effective than adding
requirements to the CoPs. Several
commenters expressed concern that
using the CoPs would set static
requirements that are ill-suited to an
evolving technology environment and
the innovation needed to increase
adoption of notifications across
providers.
Response: We appreciate commenters’
input. As noted above, we disagree with
commenters who stated that the CoPs
are not an appropriate mechanism for
policy related to interoperability or the
use of health IT. Existing CoPs address
requirements related to medical records
systems as well as the transfer of health
information, and we believe there is no
reason that these regulations should not
address technology issues where the use
of technology may be relevant to patient
health and safety, provided that such
references to technology in the CoPs do
not lead to ‘‘static requirements’’ as
noted by the commenter, and which we
believe we have avoided doing in both
the proposed and final rules.
Furthermore, while a 2017 review of the
current available scientific evidence on
the impact of different health
information technologies on improving
patient safety outcomes, warned that
health care organizations ‘‘need to be
selective in which technology to invest
in, as literature shows that some
technologies have limited evidence in
improving patient safety outcomes,’’ the
review also stated that there ‘‘should be
no doubt that health information
technology is an important tool for
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
improving healthcare quality and
safety.’’ 62 According to the authors of
the review, evidence from a number of
studies shows that health IT offers
numerous opportunities for improving
and transforming health care that
includes the potential to reduce human
errors, improve clinical outcomes,
facilitate care coordination, improve
practice efficiencies, and track data over
time. Based on this evidence as well as
the evidence directly related to patient
event notifications that we cited
previously, we believe that the
requirements for patient event
notifications that we have proposed and
that we are finalizing in this rule will
have a positive impact on many of these
same areas, especially regarding the
facilitation of care coordination for
patients, leading to improved outcomes
and enhanced patient health and safety.
While we appreciate the importance
of aligning policies across different
programs to minimize provider burden,
we believe that the proposed
requirements are not addressed
elsewhere and are appropriate for
inclusion in the CoPs. Additionally, we
disagree with commenters who stated
that the proposed requirements will
require hospitals to engage in
duplicative reporting on information
exchange since the proposed
requirements do not require hospitals
and CAHs to do any type of reporting
to CMS in order to comply with the
requirements. We also understand that
other proposed or recently finalized
policies may be relevant to the proposed
requirements in this rule; however, we
believe these policies will complement
one another and serve to enable the
proposed requirements around patient
event notifications. As we noted above
regarding the final rule published on
September 30, 2019, Discharge Planning
final rule (84 FR 51836), the revised
discharge planning CoPs do not require
hospitals, CAHs, and HHAs to transfer
necessary patient medical information
exclusively by electronic means, nor do
they require that providers notify the
appropriate providers, suppliers, and
practitioners receiving the necessary
medical information of the patient’s
discharge (or admission) as we are now
are requiring in this final rule. We
believe that the two rules, as written
and finalized, do not conflict, but
instead complement and support each
other in CMS’ goal of improving patient
care transitions. Therefore, we disagree
with the comments stating that the
62 Alotaibi, Y., & Federico, F. (2017). The impact
of health information technology on patient safety.
Saudi Medical Journal, 38(12), 1173–1180. doi:
10.15537/smj.2017.12.20631.
PO 00000
Frm 00083
Fmt 4701
Sfmt 4700
25591
patient event notification requirements
are premature or duplicative in relation
to the final discharge planning
requirements for hospitals, CAHs, and
HHAs.
Regarding concerns that it will be
challenging to update the CoPs to reflect
changing technology requirements, our
proposal sought to focus primarily on
functional requirements that will allow
hospitals the flexibility to pursue
innovation and adapt their systems over
time, similar to other functional
requirements under the Medical
Records Services CoP. Where we do
reference a specific standard, in order to
determine whether or not a hospital’s
system would be subject to the proposed
‘‘Electronic notifications’’ standard, we
reference a content exchange standard at
45 CFR 170.205(d)(2) common to many
EHRs that we believe is unlikely to
undergo changes that would require
frequent updates.
Comment: Commenters stated that
including these requirements under the
CoPs would significantly increase the
compliance burden for providers.
Commenters believed that the proposed
policy was contrary to other recent HHS
burden reduction initiatives for
providers. Commenters also believed
that this proposal would add additional
layers of regulation to what is a common
practice for many hospitals today,
further increasing provider burden.
Several commenters stated that CMS
had underestimated the burden
associated with this proposal. They
disagreed that implementing patient
event notifications would be largely
limited to a one-time cost, and stated
that there would be substantial work
required prior to implementing the
proposal and continuous work around
receiving notifications from other
providers. Commenters suggested that
CMS pursue other initiatives to alleviate
costs, such as standardizing the data set
for patient event notifications.
Stakeholders also urged CMS to ensure
that providers have cost-effective
choices for required technology
solutions, and to not create an
environment that encourages overpricing of solutions.
Response: We appreciate commenters’
concerns about additional provider
burden. While we understand that this
new requirement may impose some
additional implementation burden on
hospitals, commenters also expressed
that there are many ways for hospitals
to minimize this burden through the use
of existing technologies and services,
such as health information exchanges
and other service providers which
capture notification information from a
hospital’s EHR and route it to
E:\FR\FM\01MYR2.SGM
01MYR2
25592
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
appropriate recipients. We believe that
there is sufficient flexibility in the
current proposal to ensure hospitals
have a broad range of options for
implementation and will be able to
comply in a way that aligns with their
existing capabilities.
We believe that care coordination can
have a significant positive impact on the
quality of life, consumer experience,
and health outcomes for patients.
However, we acknowledge that though
such activities can have positive impact,
they will likely generate some costs. We
believe it is difficult to quantify the
impact of these changes because EHR
implementation across care settings
varies in maturity rates, leading to
potential variance in cost and impact
across such settings. Nonetheless, we
have attempted to estimate the burden
for those hospitals and CAHs that
currently utilize electronic medical
records systems or other electronic
administrative systems that are
conformant with the content exchange
standard at 45 CFR 170.205(d)(2), and
which generate information to support
the basic messages commonly used for
electronic patient event notifications,
but which are not currently transmitting
notifications. The cost of implementing
these changes will include a one-time
cost related to initial implementation of
the notification system. Additionally,
we have also estimated recurring
maintenance costs for either those
hospitals or CAHs that use hospital or
CAH IT services staff to perform this
recurring maintenance, or for those
hospitals and CAHs that contract with
third party outside services providers to
perform this maintenance. We also
stress that the requirements that we are
finalizing here do not mandate that a
hospital or CAH must purchase and
implement a new EHR system. Rather,
as finalized here, the provisions require
a hospital or a CAH to demonstrate
compliance with all of the provisions
contained at 42 CFR 482.24(d),
482.61(f), and 485.638(d) only if it
utilizes an electronic medical records
system or other electronic
administrative system that is
conformant with the content exchange
standard at 45 CFR 170.205(d)(2). We
note here then that a hospital or a CAH
that does not meet the basic
requirements denoted in the standard
language at paragraphs 42 CFR
482.24(d), 482.61(f), and 485.638(d) is
exempt from demonstrating compliance
with the requirements that follow and
will not be surveyed for those specific
provisions once a surveyor determines
that the system used by the hospital or
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
CAH is not conformant with the content
exchange standard discussed here.
Comment: Many commenters
supported the proposal to limit the
application of the proposed
requirements to hospitals that possess a
system capable of generating
information for patient event
notifications, while several disagreed
with CMS and thought that CMS should
not limit these requirements to only
certain hospitals. Numerous
commenters also sought additional
information on how CMS will
determine whether a hospital’s system
is subject to the proposed CoP standard.
Commenters stated that the proposed
rule did not indicate how surveyors
would determine which electronic
records systems possess required
attributes, and that surveyors would not
have the technical expertise required to
make this determination.
Response: In the CMS Interoperability
and Patient Access proposed rule, we
proposed to limit this requirement to
only those hospitals which currently
possess EHR systems with the technical
capacity to generate information for
electronic patient event notifications.
We defined a system with this capacity
as one that utilizes the ADT messaging
standard, Health Level Seven (HL7®)
Messaging Standard Version 2.5.1 (HL7
2.5.1)) incorporated by reference at 45
CFR 170.205(a)(4)(i). We noted that this
standard is referenced by certification
criteria related to transferring
information to immunization registries,
as well as transmission of laboratory
results to public health agencies as
described at 45 CFR 170.315(f), and that
adoption of certified health IT that
meets these criteria has been required
for any hospital seeking to qualify for
the Promoting Interoperability Program.
We believe hospitals and surveyors will
be able to determine whether an EHR
system possesses the capacity to
generate information for electronic
patient event notifications, defined for
the purposes of the CoP as a system
conformant with the specified ADT
messaging standard (HL7 2.5.1), based
on existing requirements for other
programs, such as the Promoting
Interoperability Program. In general, we
believe that information about whether
a system complies with this provision
will be easy to obtain from a hospital’s
health IT developer.
As discussed below, we are finalizing
a citation to the ADT messaging
standard (HL7 2.5.1) at 45 CFR
170.205(d)(2).
Comment: A commenter noted that in
some instances a hospital’s patient
event notification system is connected
to the hospital’s registration system
PO 00000
Frm 00084
Fmt 4701
Sfmt 4700
rather than its EHR system, which is
used for clinical purposes only.
Response: We appreciate the
comment and the opportunity to note
here that the ‘‘electronic medical
records system’’ described in the CoPs
is not limited to the EHR system used
for the management of clinical data.
Hospitals would also be permitted to
send patient event notifications using
their registration system. Based on this
comment, we are revising the language
at 42 CFR 482.24(d), 482.61(f), and
485.638(d) in this final rule to now state
that if the hospital (or psychiatric
hospital or CAH), ‘‘. . . utilizes an
electronic medical records system or
other electronic administrative system,’’
then the hospital (or psychiatric
hospital or CAH) would need to
demonstrate that its system complies
with the provisions that follow in this
section.
Comment: In the proposed rule we
sought comment on whether we should
identify a broader set of patients to
whom this requirement would apply,
beyond those admitted and treated as
inpatients. For instance, we noted that
a patient event notification could ensure
a primary care physician is aware that
their patient has received care at the
emergency room, and initiate outreach
to the patient to ensure that appropriate
follow-up for the emergency visit is
pursued (84 FR 7651).
Many stakeholders responded to this
request for comment by stating that they
supported extending this policy to also
include patients seen in a hospital’s
emergency department (ED).
Commenters stated that requiring
systems to be able to send these
notifications would be an important
way to support better care coordination
and prevent unnecessary repeat visits to
the emergency department. Commenters
also suggested that this requirement
should include patients seen in the
hospital for ‘‘observational’’ stays, but
who are not admitted as inpatients.
Response: We agree with the
commenters that ED patients should be
included in the patient event
notification system, and have revised
the regulatory text at 42 CFR 482.24(3)(i)
and (4)(i), 482.61(3)(i) and (4)(i), and
485.638(3)(i) and (4)(i) to include these
patients. Many patients registered in the
ED are eventually discharged home after
being treated, while others are either
held for observation in a hospital bed as
outpatients or admitted as inpatients to
the hospital. The revisions we are
finalizing here would require a
hospital’s system to send patient event
notifications for patients who are
registered in the ED, if applicable, and
then also for patients admitted as
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
inpatients, regardless if the patient was
admitted from the ED, from an
observation stay, or as a direct
admission from home, from their
practitioner’s office, or as a transfer from
some other facility. We agree with the
commenters and believe that if we were
not to include ED patients in the
notification requirements in this final
rule, we would miss an important
opportunity for positively impacting the
care transitions and the continuing care
of a significant number of patients seen
in the nation’s hospital emergency
departments. Including ED patients in
the patient event notification
requirements is consistent with the
purpose of the CoPs as a regulatory
means of promoting and protecting the
overall health and safety of all hospital
patients, regardless of their physical
location in the hospital.
To illustrate when a patient event
notification is, and is not, required, we
would like to point out the following
scenarios. A hospital’s system would be
expected to send one notification when
a patient is first registered in a hospital’s
ED or as an observational stay (that is,
in both of these cases, the patient would
be considered an outpatient and not an
inpatient at this point in time), and a
second notification if the same patient
was then later admitted to a hospital
inpatient services unit (for example,
medical unit, labor and delivery unit,
telemetry unit, neurology unit, surgical
unit, intensive care unit (ICU), etc.), or
if the same patient was admitted for
inpatient services, but was being
boarded in the ED while waiting for an
inpatient unit bed. In contrast, a second
patient event notification would not be
required if an already admitted
inpatient was transferred from one
inpatient services unit of the hospital to
another (for example, if the patient was
admitted to the hospital’s ICU, but was
then later transferred to the hospital’s
‘‘step-down’’ or ‘‘intermediate care’’
unit or to a medical unit, in which case,
the patient continued to remain an
inpatient of the hospital), or if an
already admitted patient was being
boarded in the ED and then was
transferred to an inpatient unit when a
bed became available. However, while
the requirements do not prohibit a
hospital from electing to send a patient
event notification when a patient is
transferred to one inpatient services unit
of the hospital to another, the
requirements finalized in this rule are
based on a change in the patient’s status
from outpatient to inpatient, and not
necessarily on the physical location of
the patient.
Finally, in all cases, a patient’s
discharge or transfer from the hospital,
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
either from the ED or an observational
stay or an inpatient services unit, would
still require the hospital to send another
and separate patient event notification
to the applicable entities as required
under this rule.
Comment: We proposed that hospitals
should send notifications to those
practitioners or providers that have an
established care relationship with the
patient relevant to his or her care (84 FR
7652). Many commenters sought
additional information about the term
‘‘established care relationship’’ and how
hospitals should discern who has an
established care relationship with a
patient. Commenters noted that the list
of providers who have an ‘‘established
care relationship’’ with a patient could
be very extensive and requested more
information on the extent of the
specialization of care team members
covered by the requirement. One
commenter suggested CMS indicate that
the term ‘‘established care relationship’’
only applies to one that is current and
directly related to the patient’s
diagnosis for which the notification is
sent. Another commenter suggested that
CMS define ‘‘established care
relationship’’ as the principle physician
identified by the patient and any
institution that the patient identifies.
Several commenters suggested that CMS
replace the term ‘‘established care
relationship’’ with ‘‘active
relationship,’’ and noted that this would
also ensure payers received the
notifications, as their relationship with
a patient may not be included under the
definition of a ‘‘care’’ relationship. One
commenter suggested that CMS note
that hospitals have the latitude to
choose the recipient of the notification.
Commenters also sought direction on
how hospitals should approach a
situation in which a patient does not
have a primary care provider, or in
which a provider who has an
established care relationship with the
patient cannot be easily identified.
Several commenters noted that effective
notification systems are often organized
around a subscription model, in which
receiving providers are responsible for
identifying those patients for whom
they would like to receive notifications.
Response: We appreciate commenters’
input. We agree that the term
‘‘established care relationship’’ could be
subject to an overly broad interpretation
that is not consistent with our goal to set
a minimum floor for these requirements
under the CoPs. Accordingly, we are
finalizing a more limited set of
recipients to whom a hospital’s system
must send patient event notifications for
the purposes of meeting this CoP. We
are finalizing at 42 CFR 482.24(d)(5),
PO 00000
Frm 00085
Fmt 4701
Sfmt 4700
25593
482.61(f)(5), and 485.638(d)(5)
requirements that the hospital’s system
send notifications to the following
recipients as applicable: The patient’s
established primary care practitioner;
the patient’s established primary care
practice group or entity; or other
practitioners or practice groups or
entities, identified by the patient as the
practitioner, or practice group or entity,
primarily responsible for his or her care.
We believe that the use of the modifier
‘‘established,’’ as finalized here in the
context of a patient’s established
primary care practitioner or his or her
established primary care practice group
or entity, more clearly signifies a care
relationship that the patient recognizes
as primary or one that is evidenced by
documentation of the relationship in the
patient’s medical record. As an
example, if the patient’s established
primary care practitioner refers the
patient to the hospital, this primary care
practitioner should receive the event
notification. We believe this language
improves upon the proposed term
‘‘established care relationship,’’ which
commenters correctly noted is too vague
in meaning, too broad in scope, and too
open to various interpretations, all of
which could prove burdensome for
hospitals to demonstrate compliance
with the requirements here. We note
that this final policy does not prevent a
hospital from sending patient event
notifications to other practitioners, in
accordance with all applicable laws,
who may be relevant to a patient’s postdischarge care and would benefit from
receiving patient event notifications, nor
would it prevent a hospital from seeking
to identify these other practitioners.
However, we believe this more limited
set of recipients is more appropriate to
our goal of setting baseline requirements
and will provide hospitals with
sufficient specificity to comply with the
requirements.
In cases where a hospital is not able
to identify a primary care practitioner
for a patient, the patient has not
identified a provider to whom they
would like information about their care
to be sent, or there is no applicable PAC
provider or supplier identified, we
would not expect a hospital to send a
patient event notification for that
patient. We note that under the CoP, a
hospital would be required to
demonstrate that its system sends
notifications to appropriate recipients.
We expect that hospitals would
demonstrate this capability in variety of
ways, for instance, by demonstrating
that the hospital has processes and
policies in place to identify patients’
primary care practitioners and
E:\FR\FM\01MYR2.SGM
01MYR2
25594
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
incorporate this information into the
patient event notification system, or
through recording information received
from patients about their providers.
Comment: Commenters stated that
obtaining information about providers
who have an ‘‘established care
relationship’’ with a given patient and
maintaining lists of these providers and
contact information for delivery of
patient event notifications would
impose significant burden on hospitals.
One commenter noted that patients may
not reliably provide information about
their providers, and recommended that
in those cases the recipient of the
patient event notification should
identify their relationship with a patient
in advance.
Several commenters noted that, to the
extent hospitals already have
operational processes and infrastructure
in place to determine destinations for
notifications, these processes should be
left in place. Several commenters noted
that, in order to successfully route
messages to the appropriate provider,
hospitals would need to be able to
overcome challenges associated with
patient matching: The ability for a
hospital to accurately match records
about a patient with the records held by
a receiving provider. Commenters stated
that challenges with patient matching
could inhibit patient event notifications
from being received by the correct
provider and will lead to frequent
pushback from providers about
receiving notifications regarding
patients they are not affiliated with.
Commenters also noted the importance
of community-wide directories that map
the address of a provider to their
electronic endpoint destination, which
would allow a hospital to query a
directory and find the destination of the
patient’s choice.
Response: As noted, we are finalizing
a more limited minimum set of
recipients for patient event notifications
than originally proposed. This set of
recipients is focused on a patient’s
established primary care practitioner (or
established primary care practice group
or entity) or any other practitioner (or
practice group or entity) identified by
the patient as primarily responsible for
his or her care. However, we are
retaining inclusion in this final rule of
PAC providers and suppliers as required
recipients of notifications as originally
proposed. In order to clarify the PAC
services providers and suppliers that are
required recipients, we are modifying
this proposal to refer to ‘‘all applicable
PAC services providers and suppliers.’’
For purposes of this policy, applicable
PAC services providers and suppliers
would be those PAC services providers
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
and suppliers with whom the patient
has an established care relationship
prior to admission or to whom the
patient is being transferred or referred.
Similar to our modification to reference
the patient’s established primary care
practitioner, these PAC services
providers and suppliers would be those
with an established care relationship
immediately preceding the hospital
registration or admission (such as a PAC
services provider or supplier from
which the patient was transferred to the
hospital) or those with which a
relationship is being established for
purposes of treatment and/or care
coordination post-discharge from the
hospital. The potential recipients of
patient event notifications will be
limited to only those that need to
receive notification of the patient’s
status for treatment, care coordination,
or quality improvement purposes. We
believe that this final policy will reduce
potential operational burden associated
with a broader ‘‘established care
relationship’’ definition. We believe that
increasing numbers of hospitals now
commonly seek to identify patients’
primary care practitioners and their
contact information, including any
digital contact information, or partner
with intermediaries that identify
primary care practitioners, and that
many hospitals will be able to continue
to use their existing processes to satisfy
the CoP. If a hospital has processes in
place for identifying patients’ primary
care practitioners and other applicable
providers, but is not able to identify an
appropriate recipient for a patient event
notification for a specific patient, the
hospital would not be expected to send
a notification for that patient.
Research using CMS data on
readmission rates in Medicareparticipating hospitals from 2007 to
2015 shows that the readmission rates
for targeted conditions (that is, a set of
specific diagnoses measured by
Medicare) declined from 21.5 percent to
17.8 percent, and rates for non-targeted
conditions declined from 15.3 percent
to 13.1 percent.63 While this decline in
readmissions rates is attributable to
multiple factors, we believe that one of
the significant factors driving down
avoidable patient readmissions is
identification by the hospital of the
patient’s established primary care
practitioner (or practice group) and his
or her contact information prior to
discharge and/or transfer. Increased and
early identification of the patient’s
63 Alper,
E., O’Malley, T.A., & Greenwald, J.
(n.d.). Hospital discharge and readmission.
Retrieved from https://www.uptodate.com/
contents/hospital-discharge-and-readmission.
PO 00000
Frm 00086
Fmt 4701
Sfmt 4700
primary care practitioner is more likely
to lead to more accurate and timely
transfer of patient health information
from hospital-based practitioners to
community-based primary care
practitioners. Additionally, early
identification of a patient’s primary care
practitioner along with the patient event
notification to the practitioner that his
or her patient is about to be discharged
from the hospital is most likely to have
a net positive effect on scheduled postdischarge follow-up rates for patients
most at risk for avoidable readmissions.
We appreciate commenters concerns
about patient matching challenges. This
is a larger issue beyond the scope of this
CoP proposal and this current rule, but
we will consider this issue for future
revisions and updates to the CoPs. With
the continued increase in the use of
electronic data in health care
organizations and among providers of
health care services, there has been a
continued need for patient matching, or
patient identity management (PIM)
processes, in health care organizations,
including hospitals. PIM has been
defined as the ability to uniquely
ascertain the identity of a patient, assign
that patient’s record an identifier that is
unique within the organization, system,
or exchange network, and match that
patient’s record within and between
systems using a number of demographic
data elements, such as the patient’s first
name, last name, address, and date of
birth. Effective PIM supports patient
identity integrity, which the National
Association of Healthcare Access
Management defines as accurately
identifying and matching the right
patient with his or her complete
medical record, every time, in every
provider setting.64 Accurate patient
identity management is critical to
successfully delivering the right care to
the correct patients.
Capturing incorrect or incomplete
data can result in critical patient care
issues and risk privacy breaches. Health
care organizations are more likely to
have their EHR system filled with
duplicate patient records and inaccurate
information about their patients when
they are not managing an effective PIM
process. Having an ineffective PIM
process will most definitely negatively
impact a hospital’s patient event
notification system, which is one of the
many reasons why a rigorous PIM
process is essential to patient care as
health IT moves forward. Additionally,
PIM has become crucial in order to (1)
64 National Association of Healthcare Access
Management. (2016, March 17). NAHAM Public
Policy Statement on Patient Identity Integrity.
Retrieved from https://nahamnews.blogspot.com/
2016/03/naham-public-policy-statement-on.html.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
enable health record document
consumers to obtain trusted views of
their patient subjects; (2) facilitate data
exchange projects; (3) abide by the
current regulations concerning patient
information-related transparency,
privacy, disclosure, handling, and
documentation; and (4) make the most
efficient use of limited health care
resources by reducing redundant data
collection.65
Nationally recognized practices and
standards for ensuring patient identity
integrity have been identified by
organizations such as the National
Association of Healthcare Access
Management, American Health
Information Management Association,
the Agency for Healthcare Research and
Quality, and ONC. These standards
include standardizing demographic data
fields and internally evaluating the
accuracy of patient matching within
health care organizations.
We believe this presents an
opportunity for the health IT industry to
lead the way in developing innovative
solutions to patient matching, or PIM,
that can benefit all facets of the health
care industry. However, appreciating
the importance of accurate patient
matching, CMS will continue to
evaluate ways to support improved
patient matching solutions.
Comment: Several commenters
suggested additional provider types that
should receive patient event
notifications. For instance, commenters
suggested health plans should be
included on the list of recipients for
patient event notifications, noting that
this information would be valuable to
plans responsible for coordinating
services for beneficiaries and reducing
readmissions. One commenter also
recommended sending notifications to
public health departments. Several
commenters also requested that specific
health care professionals be identified
as recipients. Commenters also
suggested that other caregivers such as
relatives be included on the list of
recipients.
Response: We appreciate commenters’
suggestions about adding additional
recipients for patient event
notifications. While there may be other
entities that could benefit from
receiving patient event notifications, we
believe it is more appropriate for the
purposes of the CoP requirements to
focus on a minimal set of recipients for
notifications. This approach would not
preclude hospitals from sending
65 Gliklich, R., Dreyer, N., & Leavy, M. (Eds.).
(2014). Registries for Evaluating Patient Outcomes:
A User’s Guide (3rd ed.). Rockville, MD: AHRQ
Publication. Retrieved from https://
www.ncbi.nlm.nih.gov/books/NBK208616/.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
notifications to other entities, including
health plans, provided hospitals comply
with applicable laws and regulations
regarding sharing of patient data.
Comment: Many commenters
suggested that CMS should consider
approaches that aim to incentivize
providers to implement patient event
notifications, rather than requiring
hospitals to do so through the CoPs.
Commenters stated that adding this
requirement would result in
unnecessary and burdensome
duplication of requirements that
hospitals are already subject to as part
of existing programs focused on
advancing health information exchange.
Specifically, many commenters
recommended that CMS seek to advance
these goals through the Promoting
Interoperability Program. Commenters
suggested CMS consider adding a
measure to the program based on patient
event notifications, noting that such a
measure could mirror the ‘‘active
engagement’’ concept currently used for
public health measures under the
program or be assessed through an
attestation similar to current attestations
related to information blocking. Several
commenters also noted our discussion
of potentially establishing a set of
‘‘health IT activities’’ under the
Promoting Interoperability Program (84
FR 7618) that would not be linked to
performance measures, noting that such
a concept would be well-suited to
advancing patient event notifications.
One commenter noted that the
Promoting Interoperability Program,
with its annual performance assessment,
is more appropriate to supporting
progress on technology goals than the
CoPs, and that a measure reported
annually could better assess the degree
to which providers are improving their
usage of patient event notifications.
Commenters also recommended other
alternative strategies that CMS could
engage in to incentivize use of patient
event notifications, such as models
established under Innovation Center
authority. Commenters believed that
highlighting the use of patient event
notifications in connection with
alternative payment models could help
to strengthen the business case for this
intervention. Another commenter
recommended that the use of patient
event notifications could be
incentivized through an offset or bonus
in a hospital-focused quality program,
or through offering regulatory flexibility
(for instance around telehealth) to
hospitals that choose to implement a
system for notifications.
Response: We appreciate commenters’
suggestions to encourage the use of
patient event notifications through the
PO 00000
Frm 00087
Fmt 4701
Sfmt 4700
25595
Promoting Interoperability Program. In
order for an action to serve as the basis
for a measure under the Promoting
Interoperability Program, the action
must require the use of certified health
IT. As discussed in the CMS
Interoperability and Patient Access
proposed rule, at this time there is no
certification criterion included in ONC’s
certification program for the creation
and transmission of patient event
notifications (84 FR 7651). As discussed
elsewhere in this final rule, ONC does
not believe there is a widely adopted
consensus standard for patient event
notifications at this time. ONC will
continue to monitor adoption of
standards for this use case and consider
whether it would be appropriate to
develop a certification criterion for this
functionality. Accordingly, we believe it
would not be feasible to add a measure
related to patient event notifications to
the Promoting Interoperability Program
at this time.
We appreciate commenters input
about other programs that could
advance the use of patient event
notifications, such as models
established under Innovation Center
authority, and will take these under
consideration.
Comment: Several commenters
addressed the use of the ADT standard
for patient event notifications. One
commenter noted that the ADT
messaging standard is very broad and
that implementations are subject to
significant variability and
customization. Commenters highlighted
the fact that there is significant variation
in the implementation of the ADT
standard, limiting interoperability
across interfaces using this standard,
and suggested that CMS clarify specific
content and triggering events for ADT
data exchange. Another commenter
noted that the lack of an
implementation guide for the use of
ADT messages for notifications is
challenging, as this guidance is essential
for understanding what information
must be sent and how. Commenters who
believed that the reference to the ADT
standard would require the
establishment of new interfaces for
exchanging ADT messages stated that
recipient providers would not be able to
receive ADT messages if they do not
have an inbound ADT interface in place.
Many commenters believed that
specifying the HL7 2.5.1 ADT message
standard would be overly restrictive and
recommended that CMS not specify a
specific standard for these transactions
at this time. Commenters urged CMS to
focus on creating functional
requirements rather than identifying
specific mechanisms or standards for
E:\FR\FM\01MYR2.SGM
01MYR2
25596
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the data. Other commenters stated that
any standard should be required as a
floor, rather than a ceiling. One
stakeholder recommended that CMS
compile stakeholder feedback to better
understand which standard would be
preferred by the industry.
Several commenters supported
adoption of the ADT message standard
(HL7 2.5.1), stating that it is the most
frequently used standard for the
transmission of patient event
notifications. One commenter urged
CMS to avoid policies that allow a
hospital to deviate from a required
standard, and to align with standards
proposed by ONC to ensure consistency
across different types of data exchange.
One commenter suggested that CMS
explore moving to later versions of the
HL7 2.5.1 standard, which provide
additional message types, segments, and
codes while others noted that additional
work will be needed by standards
setting bodies such as HL7 to develop a
more robust standard in the future.
Other commenters supported the
flexibility discussed in the CMS
Interoperability and Patient Access
proposed rule with respect to using
other standards and features to support
sending patient event notifications. One
commenter supported the flexibility
provided in the proposed rule, but
believed that this flexibility may
introduce challenges for those providers
receiving and incorporating information
provided by a hospital.
Several commenters urged CMS to not
require the use of certified EHR
technology (CEHRT) to send ADT
messages, noting that hospitals
currently use a variety of solutions to
send patient event notifications. One
commenter noted that the HL7 protocol
cannot be sent using Direct messaging or
other exchanges used for continuity of
care documents. One commenter noted
that ADT information is not available in
real time, and that an open API for both
the hospital and receiving provider
would be needed to enable real-time
notifications. Commenters
recommended that CMS instead focus
on the use of standards-based feeds from
the hospital’s technology of choice.
Response: We appreciate commenters’
feedback. We recognized in the CMS
Interoperability and Patient Access
proposed rule that there is currently
significant variation in how hospitals
have utilized ADT messages to support
implementation of patient event
notifications (84 FR 7651). In
recognition of this current state, we
proposed to require that a hospital
would be subject to this CoP if its
system complied with the ADT
messaging standard, but we did not
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
propose to require that hospitals use a
specific standard to format or deliver
patient event notifications. We believe
this flexibility is necessary due to
significant variation in how HL7 2.5.1
messages have been used to support
notifications, and allows providers to
use other standards for structuring and
delivering this information that they
may be currently using to implement
patient event notifications, or may
prefer to use for other reasons.
As noted, our intent is to allow
flexibility; therefore, we have refrained
from specifying a standard for delivery
of patient event notifications that could
be overly limiting for hospitals. We are
finalizing revised regulation text at 42
CFR 482.24(d), 482.61(f), and 485.638(d)
that specifies that a hospital system’s
conformance with the ADT standard
will be used solely to determine
whether a hospital is subject to the CoP.
Requirements regarding the content and
format of the patient event notifications,
which a hospital’s system must send to
satisfy the CoP, are limited to the
minimal information elements
described elsewhere in this final rule.
We are not specifying a standard for the
content, format, or delivery of these
notifications.
We also note that we did not specify
that hospitals must use a specific
technology to send patient event
notifications; for instance, we did not
specify that a hospital must use the
capabilities of certified health IT to send
notifications, nor that hospitals must
send notifications via an interface
adhering to the HL7 messaging
standard. We hope that this response
addresses commenters’ concerns, and
clarifies that the reference to the HL7
messaging standard in these
requirements does not preclude use of
other standards for transporting patient
event notifications. In addition, we note
that our understanding is that many
successful patient event notification
implementations have used the content
of HL7 messages in conjunction with
other forms of transport, such as Direct
messages.
While we agree with commenters that
common usage of a single, strictly
defined standard would increase
interoperability for these transactions,
we do not believe that this is possible
at this time. At the same time, we
strongly encourage hospitals, and any
intermediaries a hospital may partner
with, to adopt standards-based
approaches to the structure and
transmission of patient event
notifications, including the many
standards-based solutions described by
commenters. We acknowledge that, at
this time, the use of different standards
PO 00000
Frm 00088
Fmt 4701
Sfmt 4700
may result in decreased ability for
certain providers to receive notifications
from sending hospitals, depending on
the attributes of their respective
systems. We will consider whether there
are additional ways we can encourage
hospitals to move towards increased
interoperability for these transactions in
the future.
We also wish to address and clarify a
discrepancy in the way we referenced
the ADT messaging standard in the
proposed rule. Specifically, in the
preamble of the proposed rule we cited
45 CFR 170.299(f)(2), where the HL7
2.5.1 messaging standard is listed for
incorporation by reference. However, in
the regulation text of the proposed rule,
we erroneously cited to 45 CFR
170.205(a)(4)(i), which contains the C–
CDA standard instead of HL7 2.5.1. The
C–CDA standard is referenced in
certification criteria related to summary
of care records (84 FR 7678). As
discussed above, we are finalizing our
policy that a hospital will be subject to
the requirements in this section if it
uses a system conformant with the HL7
2.5.1 content exchange standard, which
indicates a system has the basic capacity
to generate information for patient event
notifications. In this final rule, we are
revising the regulation text and
finalizing a citation to the HL7 2.5.1
content exchange standard where it is
currently referenced at 45 CFR
170.205(d)(2). We believe that this
citation is the most appropriate way to
reference the HL7 2.5.1 standard.
Comment: Several commenters
requested that CMS indicate whether it
would be acceptable to transmit
information using other standards than
the ADT message, specifically
delivering messages using the C–CDA
standard, which providers must use to
satisfy the requirements of the
transitions of care measures under the
Promoting Interoperability Programs.
Several commenters stated that they
would prefer to format messages using
this standard, which they already use
for the Promoting Interoperability
Program, and that a requirement to
deliver messages according to the HL7
ADT messaging standard would result
in duplicative work. Others questioned
whether transmitting notifications via a
FHIR®-based API would be permissible.
Response: In the proposed rule, we
stated that a hospital’s medical records
system is a compliant system if it
utilizes the ADT messaging standard.
However, we did not propose a specific
format or standard for the patient event
notification that a hospital would be
required to send under the proposed
CoP. Thus, hospitals would be allowed
to transmit patient event notifications
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
using other standards, such as the C–
CDA or via a FHIR-based API.
Comment: Many commenters
supported the inclusion of diagnosis in
patient event notifications where
permitted by law, stating that this
information is helpful for supporting
care coordination between a hospital
and other providers. One commenter
noted that this information can be
included by leveraging certain segments
of the HL7 ADT feed, and that this
segment can also be filtered for sensitive
diagnoses that are prohibited for
transmission under certain state or
federal laws.
A number of commenters expressed
concerns about requiring the inclusion
of diagnosis, noting that hospitals may
not have this information at the time of
admission, when only the presenting
symptom may be available, or
immediately at discharge. Other
commenters noted that while this is
important information for improving
care coordination, diagnosis is not
included in the most basic versions of
the HL7 ADT messaging standard. Other
commenters noted that clinical data is
more appropriate for transfer through
other standards for sharing clinical data,
such as the C–CDA standard, which is
specified to support the exchange of
clinical summaries using certified
health IT. These commenters noted that
rather than requiring the inclusion of
diagnosis in the patient event
notification, it would make more sense
to allow hospitals to transfer this
information by attaching a clinical
summary to the notification, or by
providing this information upon request
from a receiving provider.
Response: We agree with commenters
that diagnosis is an important data
element to share during care transitions.
However, our intention for this proposal
has been to set a minimal floor for
patient event notifications, allowing for
significant flexibility, in recognition of
the wide variety of ways that providers
are currently implementing patient
event notifications. We are concerned
that the proposed requirement to
include diagnosis could introduce
unnecessary burden for hospitals that
will be seeking to satisfy this
requirement utilizing the most basic
information available in an ADT
message to support patient event
notifications. As a result, we are not
finalizing a requirement that diagnosis
must be included in patient event
notifications at 42 CFR 482.24(d)(2),
482.61(f)(2), and 485.638(d)(2). We wish
to reiterate that this final policy in no
way precludes hospitals from including
additional information, such as
diagnosis, in a patient event
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
notification. We also note that hospitals
are required to send other necessary
medical information to receiving
providers under the hospital CoP on
Discharge Planning at 42 CFR 482.43. In
addition, certain clinical information
such as diagnosis is included in the
summary of care record which hospitals
must be capable of transferring
electronically in order to meet the
health information exchange measures
under the Promoting Interoperability
Program.
Comment: Several commenters
suggested CMS require hospitals to
include additional informational
elements in patient event notifications,
such as: Discharge disposition; chief
complaint; medication profile;
insurance policy coverage information;
additional information about the
hospital, such as address and tax ID;
contact information for a variety of
resources such as social services
agencies and legal assistance providers;
and other information that can be used
for patient matching. Commenters
believe that additional information
would have a positive impact on care
coordination. Other commenters
supported the proposal to require only
a limited data set. One commenter
recommended that CMS impose
additional parameters on the
information included as part of patient
event notifications, including a
requirement that data must be recent
and relevant to patient care.
Response: We appreciate commenters’
suggestions, and agree that this
additional information can have a
positive impact on care coordination,
patient matching, and other
requirements. However, we do not
believe that this information should be
required within the CoPs for patient
event notifications. We have heard from
many stakeholders that even patient
event notifications with extremely
limited information can have a positive
effect on care coordination when they
are delivered in a timely manner. In
addition, we understand that hospitals
are currently delivering patient event
notifications with widely varying sets of
information. Finally, we note that
hospitals are required to send other
necessary medical information to
receiving providers under the hospital
CoP on Discharge Planning at 42 CFR
482.43. While we decline to require
additional data at this time, to ensure
that hospitals are able to satisfy the
requirement with minimal effort, we
encourage hospitals to consider other
information that can be added to patient
event notifications to support care
coordination.
PO 00000
Frm 00089
Fmt 4701
Sfmt 4700
25597
Comment: Many commenters
suggested that CMS work with ONC to
add a certification criterion or a
condition of certification related to the
transmission of patient event
notifications under ONC’s certification
program. Many commenters stated that
hospitals should not be required to
comply with the proposed requirements
until they have had an opportunity to
adopt certified technology supporting
these requirements. Commenters
believed this would assure hospitals
that their systems are compliant with
the proposed requirements. Moreover,
commenters expressed concern that
without complementary regulation
directed toward health IT developers,
the burden for ensuring these technical
capabilities would rest on hospital
providers alone. Some commenters
suggested that ONC should also include
data elements related to patient event
notifications in the USCDI, or seek to
standardize notification data elements
in another way, to ensure that
notifications can be received by other
EHR systems. Commenters also pointed
to a variety of emerging initiatives
which focus on barriers to information
exchange, such as TEFCA, policies to
address information blocking, and
updates to API technology under the
ONC certification program. Commenters
urged CMS to leverage these initiatives
to advance the use of patient event
notifications, for instance, by
incorporating patient event notification
functionality through the networks
established as part of TEFCA.
Response: We appreciate commenters’
input. As we noted in the CMS
Interoperability and Patient Access
proposed rule, there is currently no
certification criterion specific to
creating and sending electronic patient
event notifications included in ONC’s
certification program (84 FR 7651).
While ONC monitors the development
of consensus standards for patient event
notifications as part of its ISA (https://
www.healthit.gov/isa/admissiondischarge-and-transfer), ONC has not
yet proposed to develop a certification
criterion based on any of these
standards. Instead of focusing on the use
of a specific certification criterion, we
have sought to allow hospitals
flexibility in how they satisfy the
proposed CoP. We believe this is
consistent with current practices around
patient event notifications that have
been implemented in a wide variety of
ways across hospitals. We appreciate
that many other policy initiatives may
intersect with how hospitals implement
patient event notification requirements.
While we believe that providers will be
E:\FR\FM\01MYR2.SGM
01MYR2
25598
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
able to implement patient event
notifications based on existing systems
and infrastructure, we believe that many
of the initiatives commenters mentioned
will help to enable and enhance
notification capabilities as they are
introduced.
Comment: A number of commenters
stated that the proposal would
disproportionately burden rural and
critical access hospitals. Commenters
noted that providers in these settings
may not have an EHR system, or may be
unable to upgrade to the newest edition
of certified technology. For small and
rural providers that do have an EHR
system, commenters expressed concern
about the implementation costs
providers would need to incur as they
work with their EHR vendors to deploy
new functionality. Commenters noted
that, while working with an
intermediary could substantially reduce
the burden associated with this
proposal, many small and rural
hospitals are operating in geographic
areas that are not yet served by entities
such as health information exchanges
that could serve as intermediaries,
requiring these hospitals to dedicate
significant resources to developing a
compliant solution. This lack of access
to appropriate infrastructure would put
small and rural hospitals at
disproportionate risk of noncompliance
with the CoP standard, despite the
significant effects penalties for
noncompliance may have on
underserved communities. Several
commenters raised concerns about these
providers’ ability to shoulder
compliance costs with the proposed
requirements, and suggested CMS
provide funding opportunities to these
hospitals to mitigate the potential
burden associated with the proposal.
Response: We appreciate commenters’
concerns about the impact of this
proposal on small, rural, and critical
access hospitals (CAHs). We note that
those hospitals without an EHR system
with the technical capacity to generate
information for electronic patient event
notifications, defined as a system
conformant with the ADT messaging
standard (HL7 2.5.1), will not be subject
to this final rule. Furthermore, we
believe that changes finalized in this
rule will ease some of the potential
compliance burden associated with the
rule, and make it easier for these
hospitals to comply successfully with
the CoP standard. For example, our final
policy extends the applicable date for
the requirements as well as defining a
more limited set of a recipients to whom
hospitals must send notifications for the
purposes of compliance with the CoP.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Comment: Many commenters noted
that patient event notifications are most
effective when they take into account
receiving providers’ preferences.
Commenters noted that recipients need
flexibility to determine the information
that they want to be notified about, the
frequency of notification delivery, and
how they would like notifications
delivered; otherwise providers may
experience ‘‘signal fatigue’’ due to
receiving an excessive number of
messages that do not contain
information the provider finds useful.
Commenters expressed concern that,
under the proposed requirements,
hospitals would not have flexibility to
take into account receiving providers’
preferences for receiving patient event
notifications. They further believed that
the proposed requirements would result
in hospitals sending information to all
providers regardless of their interest in
receiving notifications, while
implementation experience has shown
that notifications are more successful
when receiving providers can request
the information they would like to
receive.
Response: We appreciate commenters’
concerns about the importance of
incorporating provider recipients’
preferences when implementing patient
notification systems. We understand
from stakeholders that a key feature of
successful patient event notification
implementations is flexibility with
respect to the manner in which
notifications are delivered, to allow for
better alignment with individual
providers’ workflows. Without such
flexibility, providers are more likely not
to find notification systems useful,
reducing their effectiveness to improve
care coordination.
We note that under the proposed
requirement, hospital systems must
send patient notifications in accordance
with the proposed requirements.
However, this would not preclude
hospitals, working either directly with
providers or through an intermediary,
from tailoring the delivery of patient
notifications in a manner consistent
with individual provider preferences.
For instance, while a hospital’s system
must be able to send notifications at
both admission and discharge, as well
as at the time of registration in the
emergency department, if a specific
provider prefers only to receive
notifications upon discharge, nothing
would prevent the hospital from
limiting the notifications sent to that
provider accordingly.
We note that our revised regulation
text states that hospitals must send
notifications to those recipients that
‘‘need to receive notification of the
PO 00000
Frm 00090
Fmt 4701
Sfmt 4700
patient’s status for treatment, care
coordination, or quality improvement
purposes.’’ We believe that this standard
will allow hospitals the discretion to
determine which recipients need to
receive notifications, for instance, by
declining to send certain notifications
where a practitioner has stated that such
notifications are not necessary or
effective for supporting care
coordination. In cases where the
hospital has partnered with an
intermediary to deliver notifications, the
intermediary may exercise this
discretion on behalf of a hospital.
Comment: Many commenters
supported the proposal to allow use of
an intermediary to deliver patient event
notifications. Commenters stated that
use of an intermediary could reduce
operational burden on hospitals by
maintaining recipient information,
supporting more effective patient
matching, and delivering notifications
in accordance with receiving providers’
preferences. Commenters pointed to
numerous examples of how
intermediaries, such as health
information exchanges, are successfully
facilitating the delivery of more
complete and accurate patient event
notifications from today.
Response: We thank commenters for
their support and agree that the use of
intermediaries to deliver patient
notifications can reduce burden on
hospitals and support effective
notification systems.
Comment: Several commenters sought
additional information on our proposals
with respect to the use of an
intermediary, and whether exclusive
use of an intermediary, provided other
requirements are met, would satisfy the
CoP. Commenters stated that they
believe hospitals should be able to
exclusively make use of an
intermediary. Other commenters
suggested that CMS should ‘‘deem’’ a
hospital compliant with the CoP if they
demonstrate that they are using an
intermediary to deliver notifications, as
long as the intermediary has not been
found to violate information blocking
rules.
Response: In the CMS Interoperability
and Patient Access proposed rule, we
stated that, if finalized, hospitals would
be required to send notifications
‘‘directly or through an intermediary
that facilitates exchange of health
information.’’ We believe this would
allow exclusive use of either method, or
a combination of these methods,
provided other requirements of the CoP
are met. For instance, if a hospital
makes exclusive use of an intermediary
to satisfy the CoP, the hospital would
still be subject to the requirement that
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
notifications must be sent to the set of
recipients we are finalizing in this rule,
specifically all applicable post-acute
care services providers and suppliers as
well as a patients’ primary care
practitioners or practice groups and
entities primarily responsible for a
patient’s care, as well as practitioners
identified by the patient. Given this
requirement, exclusive use of an
intermediary with a limited ability to
deliver notifications to the specified set
of recipients, for instance an
intermediary which restricts its delivery
to only those providers within a specific
integrated health care system, would not
satisfy the CoP. Alternatively, if a
hospital demonstrates that an
intermediary connects to a wide range
of recipients and does not impose
restrictions on which recipients are able
to receive notifications through the
intermediary, exclusive use of such an
intermediary would satisfy the CoP.
Comment: Commenters sought
additional information on whether it
would be permissible for a hospital to
delegate responsibility for making a
determination about the existence of a
patient’s care relationships to an
intermediary that facilitates delivery of
a patient notification.
Response: In the CMS Interoperability
and Patient Access proposed rule we
discussed a variety of methods through
which hospitals can identify recipients
for patient notifications, including
through partnering with intermediaries
such as health information exchanges
(84 FR 7652). We reiterate that we
believe this is one way that hospitals are
currently identifying recipients for
notifications, and that using an
intermediary to do so may reduce
operational burden for hospitals. Thus,
hospitals would be permitted to
delegate this authority.
Comment: Several commenters
requested additional information on
whether ACOs would be entitled to
receive patient event notifications.
Commenters stated that ACOs represent
groups of providers and suppliers and
work directly on their behalf. Therefore,
it was unclear whether they would be
considered intermediaries or providers
and suppliers for the purposes of the
proposed CoP. Commenters stated that
patient event notifications are used by
many ACOs today, and that ACOs both
receive notifications directly from
hospitals and through other
intermediaries such as health
information exchanges.
Response: We note that the proposed
CoP does not create an entitlement for
any specific provider or intermediary to
receive patient event notifications.
Rather, it requires hospitals to
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
demonstrate that their medical records
system sends patient event notifications
in a manner compliant with the
proposed requirements. We believe
there is nothing in the proposed
requirements that would prevent ACOs
that have business associate
relationships with the intended primary
care practitioner or practice group or
entity from receiving patient event
notifications on behalf of that
practitioner, group, or entity so long as
their business associate agreement
allows them to fulfill that role.
Comment: Several commenters
suggested that CMS should develop a
mechanism for allowing community
providers to report that they have not
received notifications from a given
hospital, or that the notifications
received are incomplete or unreasonably
delayed. Commenters believe that such
a mechanism would ensure patient
event notification systems are functional
and help to establish delivery
parameters across a community.
Response: We appreciate commenters’
input, but are unclear here as to whether
the commenters are requesting that we
develop a regulatory mechanism within
the CoP provisions to allow for a
community provider to report to a
hospital any issues it may be
experiencing with the hospital’s
notification system or if the request is
for CMS to develop some other type of
mechanism to accomplish this, such as
an incentive-based payment mechanism
as a means of encouraging a hospital to
include this reporting function as part of
its notification system. If it is the latter
type of request, then such a mechanism
would be outside the scope of the CoPs
and this section of the rule. However, if
it is the former type of request, we will
consider these ideas as we evaluate
future updates and revisions to the CoPs
with regard to patient event
notifications.
Comment: We proposed that a
hospital would only need to send
notifications to those practitioners for
whom the hospital has reasonable
certainty of receipt (84 FR 7652). We
further explained that we expected
hospitals would, to the best of their
ability, seek to ensure that notification
recipients were able to receive
notifications, but that we recognized
that factors outside of the hospital’s
control may determine whether or not a
notification was successfully received
and utilized by a practitioner.
Many commenters stated that a
standard of ‘‘reasonable certainty’’
would hold hospitals responsible for
factors outside of their control that
prevent delivery of notifications, and
that hospitals should only be held
PO 00000
Frm 00091
Fmt 4701
Sfmt 4700
25599
accountable for transmission of
information, not receipt. Commenters
stated that it would be very difficult for
hospitals to obtain reasonable certainty
given the limitations of the
infrastructure that is currently available
for sharing health information. Several
commenters believed that the phrase
‘‘reasonable certainty’’ would impose a
new affirmative duty to validate receipt
of notifications, which would result in
significant additional administrative
burden for hospitals. Several
commenters suggested that CMS replace
the term ‘‘reasonable certainty’’ with
alternatives such as ‘‘reasonable effort’’
or ‘‘reasonable confidence.’’ They
believed these alternative standards
would better reflect actions within the
hospital’s control.
Response: We appreciate commenters’
feedback. In proposing that hospitals
send notifications to those practitioners
for whom the hospital has reasonable
certainty of receipt, we sought to adapt
a similar standard currently identified
in guidance for the Promoting
Interoperability Program (see https://
www.cms.gov/Regulations-andGuidance/Legislation/EHRIncentive
Programs/Downloads/MedicareEH_
2019_Obj2-.pdf) regarding the
expectations of participants in that
program when they transfer a summary
of care record to another provider.
However, we concur with commenters
that a standard of ‘‘reasonable
certainty,’’ while appropriate for the
Promoting Interoperability Program, in
which participants are required to use
certified technology for the transmission
and receipt of summary of care
documents, may not be appropriate in
the context of this proposal, which
permits flexibility in both the
technology used to send and receive
patient event notifications and the
format of the notification itself. We
agree that a standard that better reflects
actions within the hospital’s control
would be much more appropriate in this
circumstance. Accordingly, we are
revising our final policy (at 42 CFR
482.24(d)(5), 482.61(f)(5), and
485.638(d)(5)) to now require that a
hospital (or a CAH) must demonstrate
that it ‘‘has made a reasonable effort to
ensure that’’ the system sends the
notifications to any of the following that
need to receive notification of the
patient’s status for treatment, care
coordination, or quality improvement
purposes to all applicable post-acute
care services providers and suppliers
and: (1) The patient’s established
primary care practitioner; (2) the
patient’s established primary care
practice group or entity; or (3) other
E:\FR\FM\01MYR2.SGM
01MYR2
25600
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
practitioner, or other practice group or
entity, identified by the patient as the
practitioner, or practice group or entity,
primarily responsible for his or her care.
We believe that this modified
standard will provide hospitals and
CAHs with appropriate flexibility and
can account for the constraints of
providers’ existing systems. We also
believe that this modified standard takes
into account the fact that some
recipients may not be able to receive
patient event notifications, or may not
be able to receive notifications in a
manner consistent with a hospital
system’s capabilities, and the fact that
hospitals and CAHs may not be able to
identify provider recipients for some
patients. We expect that surveyors will
evaluate whether a hospital is making a
reasonable effort to send patient event
notifications while working within the
constraints of its existing technology
infrastructure.
Comment: Several commenters
offered their assessments of readiness
across hospitals to implement patient
event notifications. One commenter
pointed to hospitals’ high levels of
engagement in some form of health
information exchange as an indication
that hospitals are well-positioned to
distribute patient event notifications,
and stated that establishing ADT-based
notification feeds did not impose
significant burdens on hospitals.
Another commenter agreed that the
technical capabilities to implement
notifications exists today, and stated
that the primary challenge for hospitals
would be in updating business and
operational practices to comply.
Other commenters stated that
functionality to use ADT message
information for patient event
notifications is not part of certified
electronic health record technology and
that not all EHRs are capable of
generating notifications. They stated
that EHRs are not able to automatically
send and receive notifications and
cautioned CMS against oversimplifying
the development burden associated with
implementation. One commenter
suggested that CMS should provide
supplemental funding to support
hospitals’ costs, workflow changes, and
technical expertise associated with
implementation.
Response: We thank commenters for
their insights. We share the assessment
of commenters who stated that most
hospitals will be able to implement
patient event notifications with minimal
burden due to the widespread adoption
of technology systems that can be
utilized to support generating and
sending these notifications. Patient
event notifications have been widely
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
recognized as an important way to
support patient safety, by enabling
providers and suppliers responsible for
the post-discharge care of a patient to
quickly initiate care coordination
protocols that can mitigate the risk of
deterioration of a patient’s condition
following a hospital stay. We
understand some commenters’ concerns
that the ability to send patient event
notifications has not been included as a
capability certified under the ONC
certification program, and that there is
no widely adopted, uniform approach to
sending patient event notifications at
this time. However, as noted by many
commenters, we believe there are a wide
variety of available, low-cost solutions
that providers can adopt to fulfill the
minimal requirements described in this
final rule. Accordingly, we have
provided significant flexibility for
providers to meet these requirements by
not including additional technical
specifications about how patient event
notifications must be formatted and
shared. We believe that this approach
allows flexibility for hospitals to
establish patient event notifications that
meet the requirements in ways that
minimize implementation burden;
however, we recognize that the lack of
a uniform approach may lead to
instances where a provider is unable to
receive notifications sent by a hospital
in a seamless, interoperable fashion.
Comment: Commenters stated that
national infrastructure for health
information exchange was not yet
mature enough to support the
widespread implementation of patient
event notifications and that successful
implementation of notifications requires
the ability to acquire data feeds and a
rules engine to support alerting routing
and delivery, as well as a patient index
function to create and verify patient
panels. While many commenters
believed that this infrastructure might
be available in the future, for instance,
through establishment of the TEFCA,
they stated that it is not ubiquitous
today. Without this infrastructure,
commenters noted that providers would
be required to support a large number of
point-to-point interfaces with other
providers that lack scalability, and will
be highly costly, inefficient, and
burdensome to develop and maintain.
One commenter recommended that
CMS establish that, for compliance
purposes, a hospital would only be
required to demonstrate a notification
has been sent for a single patient. This
would allow surveyors to confirm that
the system is functional while allowing
for variation across hospitals depending
on their capabilities to send
PO 00000
Frm 00092
Fmt 4701
Sfmt 4700
notifications under different
circumstances. One commenter
suggested that CMS should focus on
incentivizing providers to participate in
existing scalable networks that support
health information exchange, including
patient event notifications.
Response: We agree with commenters
that the national health information
exchange infrastructure to support
patient event notifications is not yet
ubiquitous. However, we believe that
the health information infrastructure
that exists today will be sufficient to
provide substantial support for the
requirements we are finalizing in this
rule. As other commenters noted,
organizations such as health
information exchanges are supporting
the sharing of patient event notifications
in many areas today. While we
understand there is variation in
availability of this infrastructure, we
believe there are options increasingly
available for hospitals to implement
basic patient event notifications that
will allow hospitals to demonstrate they
have made a ‘‘reasonable effort’’ to
ensure their system sends the required
notifications, as per the policy finalized
in this final rule.
We appreciate the suggestion that the
CoP should specify a hospital could
achieve compliance through
demonstrating that a notification has
been sent for a single patient, and that
this would ease compliance concerns
expressed by stakeholders. However, we
believe that these concerns are
addressed through the more limited
standard in our final policy that requires
a hospital (or CAH) to make a
‘‘reasonable effort’’ to ensure that its
system sends these notifications. In
addition, and as previously noted,
survey and certification interpretive
guidelines utilize a variety of
approaches to evaluate whether a
hospital has satisfied the CoP, and in
this final rule we decline to employ
overly prescriptive regulatory language
that might significantly limit options for
surveyors as they assess compliance.
Comment: Many commenters
identified challenges related to the
proposal that a hospital demonstrate
that its system sends notifications to
licensed and qualified practitioners,
other patient care team members, and
post-acute care services providers and
suppliers meeting certain conditions (84
FR 7651). Commenters stated that the
proposal seemed to require a hospital to
be able to send a notification to any
other health care provider and assumed
that the receiving provider would have
the technological capabilities to receive
this information. Commenters stated
that this is not realistic given the current
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
state of technology adoption among
receiving providers, and that recipients
would need to develop capabilities to
receive, incorporate, and use these
notifications for the proposal to be
effective.
Commenters stated that, today,
notifications would only be likely to
reach recipients only a percentage of the
time citing many factors related to the
limitations of EHR technology that
prevent providers and clinicians from
incorporating electronic information
into their EHRs. For instance,
commenters noted that EHRs must be
able to confidentially match transferred
data to a patient, incorporate the
notification into the EHR, and ensure
that it is reviewed and stored in a
clinically appropriate way to ensure it is
effectively used. Commenters stated that
CMS should consider complementary
requirements and/or supports for
ambulatory and other facilities to ensure
they are able to receive patient event
notifications provided by hospitals.
Commenters requested additional
information on the expectations for
receiving providers to successfully
receive and incorporate patient event
notifications, and noted they may face
significant burden associated with
technical development if expected to be
able to receive these notifications.
Moreover, commenters expressed
concerns about the capacity of specific
providers, including small and rural
physician practices and post-acute care
providers and suppliers, to receive
patient event notifications. Commenters
specifically noted that post-acute care
providers were not provided financial
incentives under the HITECH, and
therefore many post-acute care
providers are not using EHRs or are
using EHRs that are not able to exchange
information with hospital EHRs. Several
commenters recommended that CMS
not hold hospitals accountable for
delivering patient event notifications to
post-acute care suppliers, given the
difficulties these suppliers would have
in receiving these notifications. Others
stated that the inability of these
providers to receive notifications would
limit the effectiveness of the proposed
requirements.
Response: We appreciate commenters
input on this issue. In the CMS
Interoperability and Patient Access
proposed rule, we stated that a hospital
subject to the proposed requirements
must demonstrate that its system sends
notifications to certain recipients. We
do not expect that a hospital would
‘‘demonstrate’’ that its system meets
these requirements through meeting a
comprehensive measure of performance.
Likewise, we would not expect a
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
hospital’s system to be capable of
electronically communicating with
every possible provider, facility, or
practitioner system, or of satisfying
every possible preference for delivery of
patient event notifications that a
provider, facility, or practitioner might
attempt to impose on the hospital. As
noted above, we are modifying our
proposal to require that a hospital
makes a ‘‘reasonable effort’’ to ensure
that its system sends patient event
notifications to the specified recipients.
Under the survey and certification
process we would expect a hospital to
demonstrate its system’s compliance
with the CoP in a variety of ways,
subject to the system’s capabilities. For
instance, if a given system sends
notifications via Direct messaging, we
might expect surveyors to review
whether the hospital has a process in
place for capturing Direct addresses of
patients’ primary care practitioners to
enable the system to send patient event
notifications to these recipients.
Finally, with regard to comments
about PAC services providers and
suppliers that were not eligible for
incentives for EHR adoption under the
EHR Incentive Programs established by
the HITECH Act, we again note that the
requirements in this final rule are
limited to only those hospitals and
CAHs that possess and utilize EHR or
other administrative systems with the
technical capacity to generate
information for electronic patient event
notifications. Moreover, a hospital or
CAH with such a system must only
demonstrate that it has made a
‘‘reasonable effort’’ to ensure that its
system sends notifications to any of the
specified recipients, including all
applicable post-acute care services
providers and suppliers (that is, to those
PAC services providers and suppliers to
whom the patient is being transferred or
referred).
Comment: In the CMS Interoperability
and Patient Access proposed rule, we
did not explicitly address the effective
implementation date for the proposed
revisions to the CoPs. However, we note
that revisions to the CoPs are generally
applicable 60 days from the publication
of a final rule.
Many commenters recommended
CMS allow additional time for
implementation beyond the usual
applicable date of these revisions.
Commenters stated that additional time
was required to allow providers to
complete technical upgrades and train
staff on new workflows. One commenter
suggested that CMS finalize different
timeframes based on whether hospitals
are in an area with existing
infrastructure for transmitting patient
PO 00000
Frm 00093
Fmt 4701
Sfmt 4700
25601
event notifications. Another commenter
suggested that CMS develop working
groups to determine appropriate
timelines for implementation.
Response: We agree with commenters
that additional time would be
appropriate for hospitals and CAHs to
implement the proposed requirements.
Therefore, we are finalizing that the
requirements will be applicable 12
months after the publication date of this
final rule.
Comment: Multiple commenters
addressed privacy implications of the
proposed requirements. Commenters
sought clarity on whether patient
consent would be required to send a
patient event notification, or whether
hospitals would be able to honor a
patient’s request to opt-out of sharing
information with providers in the form
of a patient event notification.
Commenters urged CMS to issue further
guidance about privacy and security
challenges associated with sending
patient event notifications, for instance,
how hospitals should address cases
where they cannot confirm the identity
of a provider, and/or where
transmission could risk improper
disclosure of protected health
information. Several commenters
suggested that concerns about
noncompliance could lead some
hospitals to be overly hasty in sending
patient event notifications without
considering the privacy impact of the
transmission, potentially leading to
inappropriate disclosures of
information.
Response: We appreciate commenters’
concerns about preserving patient
privacy. Nothing in this proposed rule
should be construed to supersede
hospitals’ compliance with HIPAA or
other state or federal laws and
regulations related to the privacy of
patient information. We note that
hospitals would not be required to
obtain patient consent for sending a
patient event notification for treatment,
care coordination, or quality
improvement purposes as described in
this final policy. However, we also
recognize that it is important for
hospitals to be able to honor patient
preferences to not share their
information. While the CoP would
require hospitals to demonstrate that
their systems can send patient event
notifications, we do not intend to
prevent a hospital from recording a
patient’s request to not share their
information with another provider, and,
where consistent with other law, restrict
the delivery of notifications as requested
by the patient and consistent with the
individual right to request restriction of
uses and disclosures established in the
E:\FR\FM\01MYR2.SGM
01MYR2
25602
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
HIPAA Privacy Rule. Similarly, if a
hospital is working with an
intermediary to deliver patient event
notifications, the intermediary may
record information about a patient’s
preferences for how their information is
shared, and, where consistent with
other law, restrict the delivery of
notifications accordingly. Based on
commenters’ concerns regarding a
patient’s ability to request that his or her
medical information (in the form of a
patient event notification) is not shared
with other settings, we are revising and
finalizing a requirement in this rule that
a hospital (or CAH) must demonstrate
that its notification system sends
notifications, ‘‘to the extent permissible
under applicable federal and state law
and regulations and not inconsistent
with the patient’s expressed privacy
preferences.’’
Regarding improper disclosure of
health information where a hospital
cannot confirm the identity of a
receiving provider, we note that under
this policy a hospital would not be
under any obligation to send a patient
event notification in this case. Under
our final policy, hospitals would be
required to make a ‘‘reasonable effort’’
to ensure their systems send
notifications to the specified recipients.
We believe this standard will account
for instances in which a hospital (or its
intermediary) cannot identify an
appropriate recipient for a patient event
notification despite establishing
processes for identifying recipients, and
thus is unable to send a notification for
a given patient.
Comment: Many commenters raised
concerns about how hospitals would be
able to implement the proposed patient
event notifications while complying
with state and federal laws and
regulations around the transmission of
sensitive data. Commenters noted these
issues are particularly relevant for
psychiatric hospitals included in the
proposal. Commenters noted that some
states have more stringent privacy and
consent requirements that apply to
individuals treated in mental health
facilities which may impact the sending
of patient event notifications. One
commenter noted that hospitals with
behavioral health units do not disclose
patient event information as part of their
primary system data feed due to
requirements that disclosure of this
information must be accompanied by
written consent. Commenters also noted
that appropriately segregating this data
is expensive and time consuming.
Response: Nothing in this
requirement should be construed as
conflicting with hospitals’ ability to
comply with laws and regulations
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
restricting the sharing of sensitive
information. While hospitals subject to
the CoP would need to demonstrate
their system sends notifications to
appropriate recipients, hospitals would
not be expected to share patient
information through a notification
unless they have obtained any consents
necessary to comply with existing laws
and regulations.
Comment: Many commenters
supported the proposal to require a
hospital’s system demonstrate that it
sends patient event notifications at the
time of admission, and at, or just prior
to, the time of discharge. Commenters
emphasized that it is important for
notification information to be timely in
order for it to be effective in improving
care coordination. One commenter
stated that some providers find that
notifications triggered by an ADT
message are triggered too early, prior to
the availability of a discharge summary,
and sought additional information about
whether hospitals may use other triggers
for a patient event notification.
Response: We appreciate commenters’
support for the proposal. We believe
patient event notifications are most
useful when tied to admission (or
registration, as is the term generally
used for patients seen in the ED) and
discharge events, as receiving near-real
time information about a patient’s
hospitalization can ensure receiving
providers, facilities, and practitioners
are able to act quickly to ensure
successful care coordination. While we
agree that sending available clinical
information along with a patient event
notification can be helpful, we believe
that delaying notifications until all of
the information about a patient’s
hospitalization is available would likely
decrease the value of the notification.
Comment: Several commenters
suggested that the requirements should
be limited to external providers and not
include providers that may share the
same EHR as the hospital as part of an
integrated delivery system. Commenters
noted that organizations may have other
ways to notify these providers about a
discharge, and that hospitals should be
exempt from sending notifications to
these providers.
Response: Under the proposed
requirements, we are not specifying a
format or transport method for patient
event notifications. Accordingly,
hospitals could use a mix of approaches
to deliver patient event notifications, for
instance, by partnering with an
intermediary to deliver notifications to
external providers, while using features
internal to a shared EHR system to
transmit information to providers that
are part of the same organization.
PO 00000
Frm 00094
Fmt 4701
Sfmt 4700
Comment: Several commenters sought
clarity on how the patient event
notifications would relate to
information blocking policy, and urged
CMS to ensure that any new CoP
requirements are aligned with other
policies around information blocking.
Several commenters suggested that, as
an alternative to the proposed
requirements, CMS should establish a
standard under the CoPs that states
hospitals will not engage in information
blocking, to be aligned with policies
established by ONC in the 21st Century
Cures Act final rule.
Response: We note that there are
currently three prevention of
information blocking attestation
statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3) to which
eligible hospitals and CAHs must attest
for purposes of the Promoting
Interoperability Program. As part of
successfully demonstrating that an
eligible hospital or CAH is a meaningful
EHR user for purposes of the Promoting
Interoperability Program, the eligible
hospital or CAH must submit an
attestation response of ‘‘yes’’ for each of
these statements. These attestations are
discussed further in section VIII. of this
final rule. We also refer commenters to
section 3022(b)(2)(B) of the Public
Health Service Act (PHSA), which
provides that any health care provider
determined by the OIG to have
committed information blocking shall
be referred to the appropriate agency to
be subject to appropriate disincentives
using authorities under applicable
federal law, as set forth by the Secretary
through notice and comment
rulemaking. Further, we refer
commenters to the ONC 21st Century
Cures Act proposed rule for additional
discussion on disincentives (84 FR
7553).
Final Action: After consideration of
the comments received, and for the
reasons outlined in our response to
these comments and in the CMS
Interoperability and Patient Access
proposed rule, we are finalizing these
proposals with some modifications and
reorganization of the provisions. These
policies are being finalized at 42 CFR
482.24(d), 482.61(f), and 485.638(d) for
Conditions of Participation for
hospitals, psychiatric hospitals, and
specialized providers (CAHs).
Based on public comments, and to
further advance electronic exchange of
information that supports effective
transitions of care for patients between
hospitals and CAHs and their
community PAC services providers and
suppliers as well as their primary care
practitioners, the following
requirements at 42 CFR 482.24(d),
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
482.61(f), and 485.638(d) are being
finalized here with modifications and
reorganization from the proposed
requirements (84 FR 7678):
• We are revising 42 CFR 482.24(d)
by deleting the reference to ‘‘paragraph
(d)(2) of this section’’;
• We are revising 42 CFR 482.61(f) by
deleting the reference to ‘‘paragraph
(d)(2) of this section’’;
• We are revising 42 CFR 485.638(d)
by deleting the reference to ‘‘paragraph
(d)(2) of this section’’;
• We are revising 42 CFR 482.24(d)
by adding new language to the
regulatory text so that it now includes
‘‘or other electronic administrative
system, which is conformant with the
content exchange standard at 45 CFR
170.205(d)(2),’’;
• We are revising 42 CFR 482.61(f) by
adding new language to the regulatory
text so that it now includes ‘‘or other
electronic administrative system, which
is conformant with the content
exchange standard at 45 CFR
170.205(d)(2),’’;
• We are revising 42 CFR 485.638(d)
by adding new language to the
regulatory text so that it now includes
‘‘or other electronic administrative
system, which is conformant with the
content exchange standard at 45 CFR
170.205(d)(2),’’;
• We are deleting all of the regulatory
text proposed at 42 CFR 482.24(d)(2),
482.61(f)(2), and 485.638(d)(2),
including the inaccurate references to
‘‘45 CFR 170.205(a)(4)(i);’’
• We are redesignating 42 CFR
482.24(d)(3), 482.61(f)(3), and
485.638(d)(3) as 42 CFR 482.24(d)(2),
482.61(f)(2), and 485.638(d)(2),
respectively, and also revising the
regulatory text to now state that the
system sends notifications that must
include at least patient name, treating
practitioner name, and sending
institution name;
• We are redesignating 42 CFR
482.24(d)(4), 482.61(f)(4), and
485.638(d)(4) as 42 CFR 482.24(d)(3),
482.61(f)(3), and 485.638(d)(3),
respectively, and also revising the
regulatory text to now state that, ‘‘to the
extent permissible under applicable
federal and state law and regulations,
and not inconsistent with the patient’s
expressed privacy preferences, the
system sends notifications directly, or
through an intermediary that facilitates
exchange of health information, at the
time of: the patient’s registration in the
hospital’s [or CAH’s] emergency
department (if applicable); or the
patient’s admission to the hospital’s [or
CAH’s] inpatient services (if
applicable).’’
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
• We are redesignating 42 CFR
482.24(d)(5), 482.61(f)(5), and
485.638(d)(5) as 42 CFR 482.24(d)(4),
482.61(f)(4), and 485.638(d)(4),
respectively, and also revising the
regulatory text to state that, ‘‘to the
extent permissible under applicable
federal and state law and regulations,
and not inconsistent with the patient’s
expressed privacy preferences, the
system sends notifications directly, or
through an intermediary that facilitates
exchange of health information, at the
time of: the patient’s discharge or
transfer from the hospital’s [or CAH’s]
emergency department (if applicable):
or the patient’s discharge or transfer
from the hospital’s [or CAH’s] inpatient
services (if applicable).’’
• We are deleting the regulatory text
proposed at 42 CFR 482.24(d)(5),
482.61(f)(5), and 485.638(d)(5) and
adding new regulatory text to state that,
‘‘the hospital [or CAH] has made a
reasonable effort to ensure that the
system sends the notifications to all
applicable post-acute care services
providers and suppliers, as well as to
any of the following practitioners and
entities, which need to receive
notification of the patient’s status for
treatment, care coordination, or quality
improvement purposes: the patient’s
established primary care practitioner;
the patient’s established primary care
practice group or entity; or other
practitioner, or other practice group or
entity, identified by the patient as the
practitioner, or practice group or entity,
primarily responsible for his or her
care.’’
Finally, recognizing that hospitals,
including psychiatric hospitals and
CAHs, are on the front lines of the
COVID–19 public health emergency,
and in response to the number of
comments received regarding concerns
with the applicability date for this rule,
we are establishing an applicability date
of 12 months after finalization of this
rule for hospitals, including psychiatric
hospitals, and CAHs to allow for
adequate and additional time for these
institutions, especially small and/or
rural hospitals as well as CAHs, to come
into compliance with the new
requirements.
XI. Provisions of the Final Regulations
Generally, this final rule incorporates
the provisions of the CMS
Interoperability and Patient Access
proposed rule as proposed. The
following provisions of this final rule
differ from the proposed rule.
We are finalizing four proposals with
modifications.
1. We are requiring MA organizations,
Medicaid managed care plans, CHIP
PO 00000
Frm 00095
Fmt 4701
Sfmt 4700
25603
managed care entities, and QHP issuers
on the FFEs to maintain a process for
the electronic exchange of, at a
minimum, the data classes and elements
included in the content and vocabulary
standard finalized by HHS in the ONC
21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) at 45 CFR 170.213
(currently version 1 of the USCDI), via
a payer-to-payer data exchanged as
outlined in this section V. of this final
rule. Specifically, we are finalizing as
proposed that impacted payers
incorporate the data they receive into
the enrollee’s record. We are finalizing
that with the approval and at the
direction of a current or former enrollee,
a payer must send the defined
information set to any other payer. In
addition, we specify that a payer is only
obligated to send data received from
another payer under this policy in the
electronic form and format it was
received.
Starting January 1, 2022, and for QHP
issuers on the FFEs starting with plan
years beginning on or after January 1,
2022, the finalized regulation requires
these payers to make data available with
a date of service on or after January 1,
2016 that meets the requirements of this
section and which the payer maintains.
In this way, payers only have to prepare
an initial historical set of data for
sharing via this payer-to-payer data
exchange policy that is consistent with
the data set to be available through the
Patient Access API, as finalized in
section III. of this final rule.
2. Regarding the Patient Access API,
we are finalizing requirements for MA
organizations, Medicaid and 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 that meets the technical
standards as finalized by HHS in the
ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the
Federal Register) at 45 CFR 170.215,
that include the data elements specified
in this final rule, and that permit thirdparty applications to retrieve, with the
approval and at the direction of a
current enrollee, data specified at 42
CFR 422.119, 431.60, 457.730, and 45
CFR 156.221. Specifically, we are
finalizing that the Patient Access API
must, at a minimum, make available
adjudicated claims; encounters with
capitated providers; provider
remittances; enrollee cost-sharing; and
clinical data, including laboratory
results (where maintained by the
impacted payer). We are not finalizing
a requirement to include Provider
Directory information as part of the
E:\FR\FM\01MYR2.SGM
01MYR2
25604
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Patient Access API. Instead, to limit
burden, we are only requiring provider
and, in the case of MA–PD plans,
pharmacy directory information, be
included in the Provider Directory API
discussed in section IV. of this final
rule. Data via the Patient Access API
must be made available no later than
one (1) business day after a claim is
adjudicated or encounter data are
received by the impacted payer. We are
finalizing that MA organizations,
Medicaid state agencies, Medicaid
managed care plans, CHIP state
agencies, and CHIP managed care
entities must make available the date
they maintain with a date of service on
or after January 1, 2016 beginning
January 1, 2021, and for QHP issuers on
the FFEs beginning with plan years
beginning on or after January 1, 2021.
3. We are finalizing a Provider
Directory API for MA organizations,
Medicaid state agencies, Medicaid
managed care plans, CHIP state
agencies, and CHIP managed care
entities making standardized
information about their provider
networks available via a FHIR-based API
conformant with the technical standards
finalized by HHS in the ONC 21st
Century Cures Act final rule (published
elsewhere in this issue of the Federal
Register) at 45 CFR 170.215 (which
include HL7 FHIR Release 4.0.1),
excluding the security protocols related
to user authentication and
authorization, or any other protocols
that restrict the availability of this
information to anyone wishing to access
it. At a minimum, these payers must
make available via the Provider
Directory API provider names,
addresses, phone numbers, and
specialties. For MA organizations that
offer MA–PD plans, they must also
make available, at a minimum,
pharmacy directory data, including the
pharmacy name, address, phone
number, number of pharmacies in the
network, and mix (specifically the type
of pharmacy, such as ‘‘retail
pharmacy’’). This Provider Directory
API must be fully implemented by
January 1, 2021 for all payers subject to
this new requirement. Under this final
rule, MA organizations, Medicaid and
CHIP FFS programs, Medicaid managed
care plans, and CHIP managed care
entities must make the Provider
Directory API accessible via a publicfacing digital endpoint on their website
to ensure public discovery and access.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Modifications being finalized for the
timelines for these policies will provide
impacted payers ample time to build
and test the required standards-based
APIs to meet the new API requirements.
In addition, providing more time for
payer-to-payer data exchange between
impacted payers will ensure successful
implementation, and better enable plans
to use a standards-based API to meet
this requirement if they so choose. We
are not finalizing the Care Coordination
through Trusted Exchange Networks
proposal. Although some commenters
did show support for the proposal,
others raised strong concerns. Given the
concerns commenters raised specifically
regarding the need for a mature TEFCA
to be in place first, and appreciating the
ongoing work on the TEFCA being done
at this time, we are not finalizing this
trusted exchange proposal in this rule.
4. We are finalizing the Revisions to
the Conditions of Participation for
Hospitals and Critical Access Hospitals
proposal with modifications that are
based on public comments.
Additionally, and based on strong
support from commenters, we are
including patient event notification
requirements for any patient who
accesses services in a hospital (or CAH)
emergency department. In response to
the number of comments received
regarding concerns with the applicable
date for this policy, we are finalizing an
applicability date of 12 months after
publication of this rule for hospitals,
including psychiatric hospitals, and
CAHs to allow for adequate time for
these institutions, especially small and/
or rural hospitals as well as CAHs, to
come into compliance with the new
requirements.
All other policies are being
substantially finalized as proposed.
XII. Collection of Information
Requirements
Under the Paperwork Reduction Act
of 1995, we are required to provide 30day notice in the Federal Register and
solicit public comment before a
collection of information requirement is
submitted to the Office of Management
and Budget (OMB) for review and
approval. In order to fairly evaluate
whether an information collection
should be approved by OMB, section
3506(c)(2)(A) of the Paperwork
Reduction Act of 1995 requires that we
solicit comment on the following issues:
• The need for the information
collection and its usefulness in carrying
out the proper functions of our agency.
PO 00000
Frm 00096
Fmt 4701
Sfmt 4700
• The accuracy of our estimate of the
information collection burden.
• The quality, utility, and clarity of
the information to be collected.
• Recommendations to minimize the
information collection burden on the
affected public, including automated
collection techniques.
We solicited public comment on each
of these issues for the following sections
of this document that contain
information collection requirements
(ICRs):
A. Background
Payers should have the ability to
exchange data instantly with other
payers for care and payment
coordination or transitions, and with
providers to facilitate more efficient
care. Payers are in a unique position to
provide patients a complete picture of
their claims and encounter data,
allowing patients to piece together their
own information that might otherwise
be lost in disparate systems. To advance
our commitment to interoperability, we
are finalizing our proposals for the
Patient Access API, the Provider
Directory API, and the payer-to-payer
data exchange as discussed above.
We noted that these proposals were
designed to empower patients by
making sure that they have access to
health information about themselves in
a usable digital format and can make
decisions about how, with whom, and
for what uses they will share it. By
making claims data readily available
and portable to the enrollee, these
initiatives supported efforts to reduce
burden and cost and improve patient
care by reducing duplication of services,
adding efficiency to patient visits to
providers; and, facilitating identification
of fraud, waste, and abuse.
B. Wage Estimates
To derive average costs, we used data
from the U.S. Bureau of Labor Statistics’
(BLS) May 2018 National Occupational
Employment and Wage Estimates
(https://www.bls.gov/oes/current/oes_
nat.htm). Table 1 presents the mean
hourly wage, the cost of fringe benefits
(calculated at 100 percent of salary), and
the adjusted hourly wage. In the CMS
Interoperability and Patient Access
proposed rule, Table 1 was based on the
latest 2017 wage data (84 FR 7658). In
this final rule, we have updated Table
1 to reflect 2018 wage data, which is
now the latest available data.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
25605
TABLE 1—OCCUPATION TITLES AND WAGE RATES
Occupation
code
Occupation title
Administrators and Network Architects ............................................................
Security Engineer ............................................................................................
Computer and Information Analysts ................................................................
General Operations Manager ..........................................................................
Operations Research Analysts ........................................................................
Software Developers, Applications ..................................................................
Computer and Information Systems Managers ...............................................
Designers .........................................................................................................
Technical Writer ...............................................................................................
Computer Systems Analysts ............................................................................
Network and Computer Systems Administrators .............................................
Medical Records and Health Information Technician ......................................
Medical and Health Service Managers ............................................................
As indicated, we are adjusting the
employee hourly wage estimates by a
factor of 100 percent. This is necessarily
a rough adjustment, both because fringe
benefits and overhead costs vary
significantly from employer to
employer, and because methods of
estimating these costs vary widely from
study to study. Nonetheless, there is no
practical alternative and we believe that
doubling the hourly wage to estimate
total cost is a reasonable accurate
estimation method.
C. Information Collection Requirements
(ICRs)
1. ICRs Regarding MMA File
Requirements (42 CFR 423.910)
States transmit system generated data
files, at least monthly, to CMS to
identify all dually eligible individuals,
including full-benefit and partial-benefit
dually eligible beneficiaries (that is,
those who get Medicaid help with
Medicare premiums, and often for costsharing). The file is called the MMA file,
but is occasionally referred to as the
‘‘State Phasedown file.’’ Section
423.910(d) requires states to transmit at
least one MMA file each month.
However, states have the option to
transmit multiple MMA files throughout
the month (up to one per day). Most
states transmit at least weekly. This
information collection activity is
currently approved under OMB control
number 0938–0958.
Ensuring information on dual
eligibility status is accurate and up-todate by increasing the frequency of
federal-state data exchange is an
important step toward interoperability.
As a result, we proposed to update the
frequency requirements in 42 CFR
423.910(d) to require that starting April
1, 2022, all states transmit the required
MMA file data to CMS daily, and to
make conforming edits to 42 CFR
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
15–1140
17–2199
15–1120
11–1021
15–2031
15–1132
11–3021
27–1020
27–3042
15–1121
15–1142
29–2071
11–9111
423.910(b)(1). Daily would mean every
business day, but if no new transactions
are available to transmit, data would not
need to be transmitted on a given
business day. We estimate it would take
a computer systems analyst about 6
months (approximately 960 hours) to
complete the systems updates necessary
to process and transmit the MMA data
daily. After completion of system
updates, these system generated reports
would be set to run and transmitted to
CMS on an automated production
schedule.
As a result of updated information,
we are revising the number of states
currently transmitting MMA daily data
from 13 states, as stated in the CMS
Interoperability and Patient Access
proposed rule, to 15 states.
Consequently, we estimate a one-time
aggregate burden for 36 entities (51 total
entities (50 states and the District of
Columbia) minus the 15 states currently
transmitting MMA daily data) to comply
with the requirement of transmission of
daily MMA data at an aggregate burden
of $3,111,091 (36 entities * 960 hours *
$90.02 per hour for a computer system
analyst to perform the updates). We
have only estimated the cost of system
updates since the system transfers are
done automatically and this has no
additional cost. We will be revising the
information collection request currently
approved under 0938–0958 to include
the requirements discussed in this
section.
2. ICRs Regarding API Proposals (42
CFR 422.119, 422.120, 431.60, 431.70,
438.242, 457.730, 457.760, 457.1233,
and 45 CFR 156.221)
To promote our commitment to
interoperability, we are finalizing new
requirements for a Patient Access API
for MA organizations at 42 CFR 422.119,
Medicaid FFS at 42 CFR 431.60, CHIP
PO 00000
Frm 00097
Fmt 4701
Sfmt 4700
Mean
hourly
wage
($/hr)
Fringe
benefit
($/hr)
$45.09
47.80
45.67
59.56
42.48
51.96
73.49
24.05
36.30
45.01
41.86
21.16
54.68
$45.09
47.80
45.67
59.56
42.48
51.96
73.49
24.05
36.30
45.01
41.86
21.16
54.68
Adjusted
hourly
wage
($/hr)
$90.18
95.60
91.34
119.12
84.96
103.92
146.98
48.10
72.60
90.02
83.72
42.32
109.36
FFS at 42 CFR 457.730, Medicaid
managed care at 42 CFR 438.242(b)(5),
CHIP managed care at 42 CFR
457.1233(d), and QHP issuers on the
FFEs at 45 CFR 156.221. Additionally,
we are finalizing a publicly available
Provider Directory API for MA
organizations at 42 CFR 422.120, at 42
CFR 431.70 for Medicaid FFS, at 42 CFR
438.242(b)(6) for Medicaid managed
care, at 42 CFR 457.760 for CHIP FFS,
and at 42 CFR 457.1233(d)(3) for CHIP
managed care. We proposed to require
these entities to establish standardsbased APIs that permit third-party
applications to retrieve standardized
data for adjudicated claims, encounters
with capitated providers, provider
remittances, beneficiary cost-sharing,
reports of lab test results, provider
directories (and pharmacy directories
for MA–PDs), and preferred drug lists,
where applicable. We finalized the
requirement for a Patient Access API
and a Provider Directory API; this final
rule requires generally the same
information as proposed to be available
through APIs but we are finalizing the
requirement for two APIs. Additionally,
we proposed and are finalizing at 42
CFR 422.119(f)(1) and 438.62(b)(1)(vi),
and at 45 CFR 156.221(f)(1) to require
MA organizations, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs to
maintain a process for the electronic
exchange of, at a minimum, the data
classes and elements included in the
content standard adopted at 45 CFR
170.213 (currently version 1 of the
USCDI). To implement the new
requirements for APIs and payer to
payer data exchange, we estimate that
plans and states will conduct three
major work phases: Initial design,
development and testing, and long-term
support and maintenance. In the
proposed rule, we provided detailed
E:\FR\FM\01MYR2.SGM
01MYR2
25606
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
estimations of the required labor
categories and number of hours required
to implement the API provisions (84 FR
7659). We originally estimated a onetime burden of $789,356.00 per
organization or state per
implementation, with an ongoing
maintenance cost $158,359.00 per
organization or state (84 FR 7659). We
noted that, in the initial design phase,
we believed tasks would include:
Determining available resources
(personnel, hardware, cloud space, etc.);
assessing whether to use in-house
resources to facilitate an API connection
or contract the work to a third party;
convening a team to scope, build, test,
and maintain the API; performing a data
availability scan to determine any gaps
between internal data models and the
data required for the necessary FHIR
resources; and, mitigating any gaps
discovered in the available data.
During the development and testing
phase, we noted that plans and states
would need to conduct the following:
Map existing data to HL7 66 FHIR
standards, which would constitute the
bulk of the work required for
implementation; allocate hardware for
the necessary environments
(development, testing, production);
build a new FHIR server or leverage
existing FHIR servers; determine the
frequency and method by which
internal data are populated on the FHIR
server; build connections between the
databases and FHIR server; perform
capability and security testing; and vet
third-party applications, which includes
potentially asking third-party
applications to attest to certain privacy
provisions.
After the completion of the API
development, plans and states would
need to conduct the following
throughout each year: Allocate
resources to maintain the FHIR server,
which includes the cost of maintaining
the necessary patient data, and perform
capability and security testing.
In the proposed rule, we proposed a
new requirement for MA plans,
Medicaid managed care plans, CHIP
managed care entities, and QHP issuers
on the FFEs to maintain a process to
coordinate care between plans by
exchanging, at a minimum, the USCDI
at the enrollee’s request (84 FR 7640).
Originally, we noted that we would
66 Health Level Seven International (HL7®) is a
not-for-profit, ANSI-accredited standards
development organization (SDO) focused on
developing consensus standards for the exchange,
integration, sharing, and retrieval of electronic
health information that supports clinical practice
and the management, delivery and evaluation of
health services. Learn more at ‘‘About HL7’’ web
page, last accessed June 27, 2018.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
allow multiple methods for electronic
exchange of the information, including
use of the APIs. Although we
considered requiring the use of the
FHIR-based API, we understood that
some geographic areas might have a
regional health information exchange
that could coordinate such transactions.
We also noted other ways to exchange
this data, such as: Direct plan-to-plan
exchange; leveraging connections to
HIEs, or beneficiary-facing third-party
applications. Since the requirements for
the payer-to-payer data exchange and
the API provisions share a content and
vocabulary standard and because plans
will be investing in the development of
the APIs in this final rule, we believe
that plans would overwhelmingly use
these APIs to meet the payer to payer
data exchange requirements. As we had
no reliable way to determine which
plans would utilize any of the available
methods to meet the payer-to-payer data
exchange requirement or how to
determine the cost of each of these
methods, given that each plan could be
at a different technology maturity level,
we accounted for costs for all impacted
payers assuming the use of a newly
developed API to implement the payerto-payer data exchange requirements, as
this would account for a higher effort
options, and included this in our
original estimates for the API
provisions.
We summarize the public comments
we received on concerns raised
regarding our proposed cost of
implementing and maintaining the APIs
and provide our responses.
Comment: Some commenters
expressed concern that CMS
underestimated the complexity of
implementing the API requirements and
did not agree with the agency’s
estimation that the API implementation
is a one-time cost. These commenters
noted that additional costs include: The
costs to contract with third-party
applications, the costs of ongoing
education, and the cost of answering
questions from members about data and
errors. Commenters argued that the
proposed API requirements significantly
add to overhead costs and will increase
costs for providers and payers, rather
than facilitate information exchange and
better care for patients. One commenter
estimated a range of between $1 million
and $1.5 million to implement the API
requirements, with an additional
$200,000 to maintain the API. Another
commenter argued that the costs of
implementation could be as high as four
times the estimates CMS provided.
Response: We thank commenters for
their input and understand their
concerns associated with the cost
PO 00000
Frm 00098
Fmt 4701
Sfmt 4700
required to implement the requirements
of this final rule. We understand that
our estimates regarding the
implementation of the API provisions
may vary depending on a number of
factors, including, but not limited to a
payer’s current knowledge of and
experience with implementing FHIRbased APIs, and whether an impacted
payer will develop this technology inhouse or seek a third party contractor to
support this effort.
To further develop our cost estimates,
we reviewed the cost estimates
associated with updating Blue Button
from Blue Button 1.0 to 2.0 to include
a standards-based API, similar to the
requirements of this final rule. This
update was estimated at $2 million.
However, we believe that the estimates
associated with updating the existing
Blue Button 1.0 to a standards-based
API for Blue Button 2.0 do not
accurately represent the costs for payers
impacted by this final rule. Blue Button
1.0 was developed across several federal
agencies, including the Departments of
Defense, Health and Human Services,
and Veterans Affairs, with a capability
to allow beneficiaries online access to
their own personal health records, such
as the ability to download PDF
documents. Unlike the standards-based
APIs required under this final rule, Blue
Button 1.0 was not originally developed
with a prescribed set of standards that
allow for third-party apps to connect
and retrieve data via an API. The
estimates for Blue Button account for
upgrading an existing technology
platform that was not originally
developed to allow third-party app
access via an API, which we believe
adds additional cost that may not
impact all payers under this final rule.
Additionally, we note that costs related
to federal procurement and the need to
engage multiple contractors to
implement the updates to Blue Button,
while at the same time maintaining
access to the original system, caused the
cost of implementing standards-based
APIs for Blue Button 2.0 to be higher
than those costs for payers impacted by
this final rule. Therefore, we believe
that the estimates for upgrading Blue
Button from 1.0 to 2.0 are not truly
representative of the cost to implement
the standards-based API required by this
final rule, but nonetheless are valuable
in further informing our cost estimates.
As noted above, we did receive one
comment that suggested a cost range
between $1 million and $1.5 million to
implement the API requirements of this
final rule, with another commenter
indicating a four-fold increase in costs
relative to the estimates included in the
proposed rule. While disagreeing with
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
our bottom line, these commenters did
not provide where in our detailed
analysis we underestimated costs. For
example, it is unclear if the commenters
were including voluntary provider
costs, or other costs when calculating
the dollar amounts for compliance.
Therefore, without specific examples of
additional costs that need to be
accounted for in this impact analysis,
we believe that our estimates are
reasonable. To address commenters’
concerns regarding ongoing costs, we
remind readers that we specifically are
accounting for a cost of $157,656 per
organization, for costs throughout the
year to include: Allocating resources to
maintain the FHIR server, which
includes the cost of maintaining the
necessary patient data, and perform
capability and security testing.
However, in an effort to take into
account the additional information that
commenters presented regarding our
costs estimates, and understanding there
are many factors that may influence the
cost of implementing these policies, as
noted above, we are adjusting our cost
estimates to reflect a range instead of a
point estimate. We believe that our cost
projections for an initial one-time cost
to implement the API requirements of
this final rule of $718,414 per
organization, reflecting 6 months of
work by a team of ten professionals, can
now serve as a minimum estimate; in
other words, we do not believe it is
technically feasible to implement the
requirements of this final rule in less
than 6 months. For a primary estimate,
we have increased our cost estimates by
a factor of 2 to account for cost
variation. We note that using this factor
of 2, the cost per organization is
consistent with the commenter stating a
$1 million to $1.5 million per
organization cost. For a high estimate
we have increased our cost estimates by
a factor of 3. Although, one commenter
noted a factor of 4 should be included,
all other information available to us,
including the commenter who noted a
range between $1 million and $1.5
million, and our estimates for upgrading
Blue Button, a factor of 4 does not
appear to be reflective of the costs for
implementation and represents more of
an outlier for cost estimating purposes.
As shown in section XIII. of this final
rule, we have revised down our estimate
of affected individual market enrollees
from 76 million (all commercial market
enrollees) to 17.5 million (those
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
individual market enrollees directly
affected by this final rule). This
reduction by a factor of 4 (76 million
former estimate/17.5 million revised
estimate) raises the cost per individual
market enrollee per year by a factor of
4 consistent with the commenter’s
suggested factor of 4. This factor of 4,
however, only affects cost per enrollee
per year; it does not affect total costs as
calculated in Table 2.
Additionally, we note that as part of
our original estimated costs associated
with the annual burden of the
requirements of this final rule, we
accounted for additional capability
testing and long-term support of the
APIs, increased data storage needs, such
as additional servers, or cloud storage to
store any additional patient health
information, and allocation of resources
to maintain the FHIR server, and
perform capability and security testing.
Therefore, our estimates related to the
annual burden account for the ongoing
cost, and we are not providing
additional estimates for maintenance as
this is already factored in.
The burden estimate related to the
new requirements for implementing and
maintaining the APIs reflects the time
and effort needed to collect the
information described above and
disclose this information. We now
estimate:
• An initial set one-time costs
associated with the implementing the
API requirements.
• An ongoing maintenance cost after
the system is set up, and the costs
associated with additional data storage,
system testing, and maintenance.
Consistent with our discussion above,
we now regard this as a low or
minimum estimate, the argument being
that a complex system cannot be
designed in less than 6 months. Our
high estimate now reflects 18 months of
work (4,320 hours) for administrators
and network architects. This is obtained
by using a factor of 3 (4,320 hours (high
estimate) = 3*1440 hours, the original
estimate). For a primary estimate, we
estimate 12 months of work or 2,880
hours (1,440 hours * 2) for
administrators and network architects.
The use of a factor of 2 is consistent
with a $2 million cost per entity and
consistent with the commenter who
estimated an implementation cost of $1
million to $1.5 million. We note that, in
terms of actual implementation, this
assumption is focused on the 2,880
PO 00000
Frm 00099
Fmt 4701
Sfmt 4700
25607
hours of work that could be conducted
in less than 12 months through
necessary personnel or third-party
contractor allocation, if needed. As a
result, the ‘‘12-month’’ assumption is
also consistent with the implementation
of the new API requirements, which
must be implemented by January 1,
2021.
As can be seen from the bottom rows
of Table 2:
• For a low estimate, first year
implementation will require a total of
8,400 hours per organization at a cost of
$718,414.40 per organization (this
number is obtained by adding the
products of hourly wages and hours
required in each row, for example
1440*$90.18 + 960*$95.60, etc.).
• For a high estimate, first year
implementation will require a total of
25,200 hours per organization at a cost
of $2,365,243 per organization (this
number is obtained by adding the
products of hourly wages and hours
required in each row).
• For a primary estimate, first year
implementation will require a total of
16,800 hours of work per organization at
a cost of $1,576,829 per organization.
• Therefore, the aggregate burden of
the first year implementation across 345
parent organizations 67 is 2,898,000
hours (8400 * 345) at a cost of $272
million ($718,414 * 345) for the low
estimate. Similar calculations show that
the primary estimate is 5,796,000 hours
at an aggregate cost of $544,005,936
million, and the high estimate is
8,694,000 hours at a cost of
$816,008,904.
• Similarly, ongoing maintenance
after the first year will require a total of
1,710 hours per organization at a cost of
$157,656.60 per organization.
• Therefore, the aggregate burden of
ongoing implementation across 345
parent organizations is $54.4 million
($157,656.60 * 345).
We explicitly note that a low and high
estimate were only provided for the first
year, but not for subsequent years.
67 We provide a detailed rationale for how we
determined the number of parent organizations in
section XIII.C.1. of this final rule. In that analysis
we determined that 288 issuers and 56 states,
territories, and U.S. commonwealths, which operate
FFS programs, will be subject to the API provisions
for Medicare, Medicaid, and the commercial
market. To this we added the one state that operates
its CHIP and Medicaid separately. Thus, we have
a total of 345 parent entities (288+56+1).
E:\FR\FM\01MYR2.SGM
01MYR2
25608
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 2—FIRST YEAR AND MAINTENANCE COST OF THE API PROVISIONS
Occupation title
Administrators and
Network Architects
Security Engineer .....
Computer and Information Analysts ....
General Operations
Manager ...............
Operations Research
Analysts ................
Software Developers,
Applications ..........
Computer and Information Systems
Managers ..............
Designers .................
Technical Writer .......
Computer Systems
Analysts ................
Network and Computer Systems Administrators ...........
Total Hours per
System ..........
Total Cost per
system (Dollars) (millions)
Total hours for
345 Organizations (hours) ..
Total Cost for
345 Organizations (millions
$) ...................
Occupation
code
Mean
hourly
wage
($/hr)
Adjusted
hourly
wage
($/hr)
First year
hours
(low estimate)
First year
hours
(primary
estimate)
First year
hours
(high estimate)
Maintenance
hours
15–1140
17–2199
$45.09
47.80
$45.09
47.80
$90.18
95.60
1440
960
2880
1920
4320
2880
180
240
15–1120
45.67
45.67
91.34
480
960
1440
60
11–1021
59.56
59.56
119.12
720
1440
2160
90
15–2031
42.48
42.48
84.96
960
1920
2880
120
15–1132
51.96
51.96
103.92
960
1920
2880
240
11–3021
27–1020
27–3042
73.49
24.05
36.30
73.49
24.05
36.30
146.98
48.10
72.60
720
960
240
1440
1920
480
2160
2880
720
90
120
30
15–1121
45.01
45.01
90.02
960
1920
2880
120
15–1142
41.86
41.86
83.72
........................
0
0
420
..................
..................
..................
..................
8,400
16,800
25,200
1,710
..................
..................
..................
..................
788,414
1,576,829
2,365,243
157,657
..................
..................
..................
..................
2,898,000
5,796,000
8,694,000
589,950
..................
..................
..................
..................
272,002,968
544,005,936
816,008,904
54,391,527
3. ICRs Regarding Conditions of
Participation for Hospitals and Critical
Access Hospitals (42 CFR 482.24(d),
482.61(f), 485.638(d))
We are expanding our requirements
for interoperability within the hospital
and CAH CoPs by focusing on electronic
patient event notifications. We are
implementing new requirements in
section X. of this final rule for hospitals
at 42 CFR 482.24(d), for psychiatric
hospitals at 42 CFR 482.61(f), and for
CAHs at 42 CFR 485.638(d).
Specifically, for hospitals, psychiatric
hospitals, and CAHs, we are finalizing
similar requirements to revise the CoPs
for Medicare- and Medicaidparticipating hospitals, psychiatric
hospitals, and CAHs by adding a new
standard, ‘‘Electronic Notifications,’’
that will require hospitals, psychiatric
hospitals, and CAHs to make electronic
patient event notifications available to
applicable post-acute care services
providers and suppliers, and to
community practitioners such as the
patient’s established primary care
practitioner, established primary care
practice group or entity, or other
VerDate Sep<11>2014
Fringe
benefit
($/hr)
08:09 May 01, 2020
Jkt 250001
practitioner or practice group or entity
identified by the patient as primarily
responsible for his or her care. We are
limiting this requirement to only those
hospitals, psychiatric hospitals, and
CAHs that utilize electronic medical
records systems, or other electronic
administrative systems, which are
conformant with the content exchange
standard at 45 CFR 170.205(d)(2),
recognizing that not all Medicare- and
Medicaid-participating hospitals have
been eligible for past programs
promoting adoption of EHR systems. If
the hospital’s (or CAH’s) system
conforms to the content exchange
standard at 45 CFR 170.205(d)(2), the
hospital (or CAH) must then
demonstrate that its system’s
notification capacity is fully operational
and that the hospital (or CAH) uses it in
accordance with all state and federal
statutes and regulations applicable to
the hospital’s (or CAH’s) exchange of
patient health information, and that its
system (to the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
the patient’s expressed privacy
preferences) sends the notifications
PO 00000
Frm 00100
Fmt 4701
Sfmt 4700
either directly, or through an
intermediary that facilitates exchange of
health information. It must also
demonstrate that the notifications
include at least patient name, treating
practitioner name, and sending
institution name.
Upon the patient’s registration in the
emergency department or admission to
inpatient services, and also either
immediately prior to, or at the time of,
the patient’s discharge or transfer (from
the emergency department or inpatient
services), the hospital (or CAH) must
also demonstrate that it has made a
reasonable effort to ensure that its
system sends the notifications to all
applicable post-acute care services
providers and suppliers, as well as to
any of the following practitioners and
entities, which need to receive
notification of the patient’s status for
treatment, care coordination, or quality
improvement purposes: (1) The patient’s
established primary care practitioner;
(2) the patient’s established primary
care practice group or entity; or (3) other
practitioner, or other practice group or
entity, identified by the patient as the
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
practitioner, or practice group or entity,
primarily responsible for his or her care.
These requirements will help support
coordination of a patient’s care between
settings or with services received
through different care settings.
Electronic patient event notifications
from these care settings, or clinical
event notifications, are one type of
health information exchange
intervention that has been increasingly
recognized as an effective and scalable
tool for improving care coordination
across settings. These notifications are
typically automated, electronic
communications from the admitting or
discharging provider to applicable postacute care services providers and
suppliers, and also to community
practitioners identified by the patient,
that alert the receiving providers or
community practitioners that a patient
is receiving, or has received, care at a
different setting.
These notifications are frequently
based on ‘‘admission, discharge, and
transfer (ADT)’’ messages, a standard
message used within an EHR as the
vehicle for communicating information
about key changes in a patient’s status
as they are tracked by the system (more
information about the current standard
supporting these messages is available
at https://www.hl7.org/implement/
standards/product_brief.cfm?product_
id=144). As noted in the ISA published
by ONC, this messaging standard has
been widely adopted across the health
care system (see https://www.healthit.
gov/isa/sending-a-notification-apatients-admission-discharge-andortransfer-status-other-providers).
We continue to believe that care
coordination can have a significant
positive impact on the quality of life,
consumer experience, and health
outcomes for patients. As we have noted
in the preamble to this rule, virtually all
EHR systems (as well as older legacy
electronic administrative systems, such
as electronic patient registrations
systems, and which we are including in
this final rule) generate information to
support the basic messages commonly
used for electronic patient event
notifications. While we acknowledge
that some level of implementation cost
would be realized for those providers
not already transmitting notifications,
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
we also note there is substantial
agreement that implementation of these
basic messaging and notification
functions within such existing systems
constitutes a relatively low cost burden
for providers, particularly when such
costs are considered alongside the
innovative and beneficial patient care
transition solutions and models for best
practices they provide.
Although we do not have current data
on how many facilities are already
transmitting electronic patient event
notifications, 59 percent of hospitals
were found to be routinely
electronically notifying a patient’s
primary care provider upon his or her
entry to the hospital’s emergency
department in 2015, which is an over 50
percent increase since 2012.68 By using
this historical data to plot a power trend
line (R-Squared: 0.9928), we estimate
that approximately 71 percent of
hospitals may have been routinely
transmitting patient event notifications
by 2018; therefore, we assume that 29
percent of hospitals, or approximately
1,392, will incur costs associated with
updating or configuring their respective
EHR systems for electronic patient event
notifications. While we do not have
parallel data for CAHs, we assume that
a similar percentage, or approximately
394 CAHs, will incur this burden. We
note that this upwards trend of patient
event notification adoption may
continue to some unknown extent
absent this final rule; however, we are
limiting our projection of hospitals that
are most affected by these requirements
to 2018 due to the amount of
uncertainty involved in quantifying this
burden.
We assume that this process will
primarily require the services of two
medical records and health information
technicians at approximately $42.32/
hour for 16 hours each, and 3 hours of
time from a medical and health services
manager at approximately $109.36/hour,
including the costs of overhead and
fringe benefits. Thus, the total burden
68 Office of the National Coordinator. (n.d.).
Hospital Routine Electronic Notification: Percent of
U.S. Hospitals that Routinely Electronically Notify
Patient’s Primary Care Provider upon Emergency
Room Entry, 2015. Retrieved from https://
dashboard.healthit.gov/quickstats/pages/FIGHospital-Routine-Electronic-Notification.php.
PO 00000
Frm 00101
Fmt 4701
Sfmt 4700
25609
per facility is anticipated to be 35 hours,
or approximately $1,682.32 ((16 hours *
$42.32/hour * 2 health information
technicians) + (3 hours * $109.36/hour
* 1 manager)). We assume that the
ongoing burden associated with
maintenance of these systems would be
approximately one quarter of these
amounts for the 2 medical records and
health information technicians, or 4
hours each, for a total of 8 hours and
$338.56 per facility (4 hours * $42.32/
hour * 2 health information
technicians).
In this lower-bound scenario, we
estimate that the total first-year burden
for hospitals and psychiatric hospitals is
approximately 48,720 hours (35 hours *
1,392 hospitals) or $2,341,789
($1,682.32 * 1,392 hospitals). In
subsequent years, we estimate the
burden is approximately 11,136 hours (8
hours * 1,392 hospitals) or $471,276
($338.56 * 1,392 hospitals).
For CAHs we estimate that the total
first-year burden is approximately
13,790 hours (35 hours * 394 CAHs) or
$662,834 ($1,682.32 * 394 CAHs). In
subsequent years, we estimate the
burden for CAHs is approximately 3,152
hours (8 hours * 394 CAHs) or $133,393
($338.56 * 394 CAHs).
Due to the amount of uncertainty
involved in these estimates, we are also
presenting estimates for a scenario in
which the number of hospitals that
routinely electronically notify primary
care providers both inside and outside
of the hospital’s system is assumed to
have remained static at the 2015 rate of
29 percent. This upper-bound scenario
would indicate that in 2018
approximately 3,407 hospitals and 964
CAHs did not routinely utilize patient
event notification, and therefore several
thousand additional providers would
incur the previously estimated burden
per facility.
For the purposes of the PRA, we are
assuming the midpoint of this range of
effects. In this scenario 2,400 hospitals
and psychiatric hospitals, and 679
CAHs would incur the estimated
burden. The burden estimates
associated with the revised CoPs are
detailed in Table 3. This information
collection will be submitted to OMB
under OMB Control Number 0938–New.
E:\FR\FM\01MYR2.SGM
01MYR2
25610
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 3—SUMMARY OF HOUR AND DOLLAR BURDEN BY NUMBER OF AFFECTED PROVIDERS
Hospitals and psychiatric hospitals
Subsequent
years
Year 1
Lower Bound ............................
Affected Providers ....................
48,720
$2,341,789.44
Affected Providers ....................
Upper Bound ............................
394
11,136
$471,275.52
13,790
$662,834.08
2,400
Total Burden (hours) ................
Total Cost .................................
84,000
$4,037,568.00
Affected Providers ....................
19,200
$812,544.00
119,245
$5,731,664.24
3,152
$133,392.64
679
23,765
$1,142,295.28
3,407
Total Burden (hours) ................
Total Cost .................................
Subsequent
years
Year 1
1,392
Total Burden (hours) ................
Total Cost .................................
Primary Estimate ......................
CAHs
5,432
$229,882.24
964
27,256
$1,153,473.92
33,740
$1,621,756.48
7,712
$326,371.84
4. Summary of Information Collection
Burdens
TABLE 4—SUMMARY OF PRIMARY INFORMATION COLLECTION BURDENS
Hourly labor
cost of
reporting
($)
960
16,800
34,560
5,796,000
$90.02
Varies
3,111,091
544,005,936
3,111,091
0
345
1,710
589,950
Varies
....................
54,391,527
2,400
2,400
35
84,000
Varies
4,037,568
....................
0938–New ............
2,400
2,400
8
19,200
Varies
....................
812,544
0938–New ............
0938–New ............
679
679
679
679
35
8
23,765
5,432
Varies
Varies
1,142,295
....................
....................
229,882.24
...............................
....................
6,884
Varies
6,552,907
Varies
552,296,890
58,545,044
Number of
respondents
Number of
responses
OMB control No.
§ 423.910 ...............
§ 422.119,
§ 431.60,
§ 457.730,
§ 438.242,
§ 457.1233 and
§ 156.221.
§ 422.119,
§ 431.60,
§ 457.730,
§ 438.242,
§ 457.1233, and
§ 156.221.
§ 482.24(d) and
§ 482.61(f).
§ 482.24(d) and
§ 482.61(f).
§ 485.638(d) ..........
§ 485.638(d) ..........
0938–0958 * ..........
0938–New ............
36
345
36
345
0938–New ............
345
0938–New ............
Total ...............
Burden per
response
(hours)
Total labor
cost 1st
year
($)
Total labor
cost
subsequent
years
($)
Total annual
burden
(hours)
Regulation
section(s)
* This currently approved ICR will be revised to include the burden discussed in this rule.
XIII. Regulatory Impact Analysis
A. Statement of Need
As described in detail in section III.
of this rule, the changes to 42 CFR parts
422, 431, 438, 457, and 45 CFR part 156
are part of the agency’s broader efforts
to empower patients by ensuring that
they have full access to their own health
care data, through common technologies
and without special effort, while
keeping that information safe and
secure. Interoperability and the
capability for health information
systems and software applications to
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
communicate, exchange, and interpret
data in a usable and readable format,
such as PDF or text, is vital, but
allowing access to health care data
through PDF and text format also limits
the utility and sharing of data. Moving
to a system in which patients have
access to their health care data will help
empower them to make informed
decisions about their health care, as
well as share their data with providers
who can assist these patients with their
health care. The policies are designed to
move Medicare, MA, Medicaid, CHIP,
and QHP issuers on the FFEs further to
PO 00000
Frm 00102
Fmt 4701
Sfmt 4700
that ultimate goal of empowering their
enrollees. As technology has advanced,
we have encouraged states, payers, and
providers to adopt various forms of
technology to improve the accurate and
timely exchange of standardized health
care information. The policies in this
final rule enable patients to be active
partners in the exchange of electronic
health care data by easily monitoring or
sharing their data.
States and CMS routinely exchange
data on who is enrolled in Medicare,
and which parties are liable for paying
that beneficiary’s Parts A and B
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
premiums. These ‘‘buy-in’’ data
exchanges support state, CMS, and SSA
premium accounting, collections, and
enrollment functions. We have become
increasingly concerned about the
limitations of monthly buy-in data
exchanges with states. The relatively
long lag in updating buy-in data means
that the state is not able to terminate or
activate buy-in coverage sooner, so the
state or beneficiary may be paying
premiums for longer than appropriate.
We note that once the data catch up,
states and CMS reconcile the premiums
by recouping and re-billing, so
premiums collected are ultimately
accurate, but only with an
administratively burdensome process
involving debits and payments between
the beneficiary, state, CMS, SSA, and
potentially providers. Daily buy-in data
exchange will reduce this
administrative burden.
States submit data on files at least
monthly to CMS to identify all dually
eligible individuals, including fullbenefit and partial-benefit dually
eligible beneficiaries (that is, those who
get Medicaid help with Medicare
premiums, and often for cost-sharing).
The MMA file was originally developed
to meet the need to timely identify
dually eligible beneficiaries for the thennew Medicare Part D prescription drug
benefit. Over time, we use these files’
data on dual eligibility status to support
Part C capitation risk-adjustment, and
most recently, feeding dual eligibility
status to Part A and B eligibility and
claims processing systems so providers,
suppliers, and beneficiaries have
accurate information on beneficiary
cost-sharing obligations. As CMS now
utilizes MMA data on dual eligibility
status in systems supporting all four
parts of the Medicare program, it is
becoming even more essential that dual
eligibility status is accurate and up-todate. Dual eligibility status can change
at any time in a month. Waiting up to
a month for status updates can
negatively impact access to the correct
level of benefit at the correct level of
payment. As described in detail in
section VII. of this rule, the changes to
42 CFR parts 406, 407, and 423 establish
frequency requirements that necessitate
all states to participate in daily
exchange of buy-in data, and updates
frequency requirements to require all
states to participate in daily exchange of
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
MMA file data, with CMS by April 1,
2022.
B. Overall Impact
We have examined the impacts of this
final rule as required by Executive
Order 12866 on Regulatory Planning
and Review (September 30, 1993),
Executive Order 13563 on Improving
Regulation and Regulatory Review
(January 18, 2011), the Regulatory
Flexibility Act (RFA) (September 19,
1980, Pub. L. 96–354), section 1102(b) of
the Social Security Act, section 202 of
the Unfunded Mandates Reform Act of
1995 (March 22, 1995; Pub. L. 104–4),
Executive Order 13132 on Federalism
(August 4, 1999), the Congressional
Review Act (5 U.S.C. 804(2)), and
Executive Order 13771 on Reducing
Regulation and Controlling Regulatory
Costs (January 30, 2017).
Executive Orders 12866 and 13563
direct agencies to assess all costs and
benefits of available regulatory
alternatives and, if regulation is
necessary, to select regulatory
approaches that maximize net benefits
(including potential economic,
environmental, public health and safety
effects, distributive impacts, and
equity). Section 3(f) of Executive Order
12866 defines a ‘‘significant regulatory
action’’ as an action that is likely to
result in a rule: (1) Having an annual
effect on the economy of $100 million
or more in any 1 year, or adversely and
materially affecting a sector of the
economy, productivity, competition,
jobs, the environment, public health or
safety, or state, local or tribal
governments or communities (also
referred to as ‘‘economically
significant’’); (2) creating a serious
inconsistency or otherwise interfering
with an action taken or planned by
another agency; (3) materially altering
the budgetary impacts of entitlement
grants, user fees, or loan programs or the
rights and obligations of recipients
thereof; or (4) raising novel legal or
policy issues arising out of legal
mandates, the President’s priorities, or
the principles set forth in the Executive
Order.
A regulatory impact analysis (RIA)
must be prepared for major rules with
economically significant effects ($100
million or more in any 1 year). We
estimate that this rulemaking is
‘‘economically significant’’ as measured
PO 00000
Frm 00103
Fmt 4701
Sfmt 4700
25611
by the $100 million threshold, and
hence also a major rule under the
Congressional Review Act. Accordingly,
we have prepared an RIA that to the best
of our ability presents the costs and
benefits of the rulemaking. Table 5
summarizes the estimated costs
presented in section XII. of this final
rule.
In the proposed rule, we provided
detailed estimations of the required
labor categories and number of hours
required to implement standards-based
APIs (84 FR 7659). We originally
estimated a one-time burden of
$789,356 per organization or state, per
implementation, with an ongoing
maintenance cost $158,359.80 per
organization or state (84 FR 7659). As
we detailed in section XII., to account
for additional information commenters
presented regarding our costs estimates,
we are adjusting our original cost
estimates to reflect a range, instead of a
point estimate. Our original estimate for
the initial one-time cost to implement
the API requirements of this final rule
of $788,414 per organization will now
serve as a minimum estimate. We have
increased our primary cost estimate by
a factor of 2 to an initial one-time cost
of $1,576,829 per organization or state.
Additionally, we are increasing our
original cost estimate by a factor of 3 for
an initial one-time cost of $2,365,243
per organization or state to serve as a
high estimate (detailed cost estimates
are located in Table 5).
Table 5 reflects updated wages for
2018, the latest available from the
Bureau of Labor Statistics (BLS) website;
the CMS Interoperability and Patient
Access proposed rule used 2017 wage
estimates. Nevertheless, the change in
total impact was small. We note that
estimates below do not account for
enrollment growth or higher costs
associated with medical care. This is
because the cost of requirements to
implement patient access through APIs
and for states to comply with data
exchange requirements are not impacted
by enrollment growth or higher costs
associated with medical care. Per OMB
guidelines, the projected estimates are
expressed in constant-year dollars (in
this case, using 2018 prices and wages).
Table 5 forms the basis for allocating
costs by year and program to the federal
government, state Medicaid agencies,
and parent organizations.
E:\FR\FM\01MYR2.SGM
01MYR2
25612
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 5—ESTIMATED COSTS (MILLIONS) OF FINAL RULE BY PROVISION
Provision
Dual eligible
care
coordination
Regulatory
text
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
§ 406.26,
§ 407.40,
§ 423.910
Patient
access API
(low
estimate)
§ 422.119,
§ 431.60,
§ 438.242,
§ 457.730,
§ 457.123,
§ 156.221
Patient
access API
(primary
estimate)
Patient
access API
(high
estimate)
Total cost
(low
estimate)
Total cost
(primary
estimate)
Total cost
(high
estimate)
Months in
year for
compliance
for dual
eligible
provisions
Percent of
25 month
window for
compliance
with dual
eligible
provisions
.........
.........
.........
.........
.........
.........
.........
.........
.........
.........
2.8
3.4
0.8
0.0
0
0.0
0.0
0.0
0.0
0.0
272.0
54.4
54.4
54.4
54.4
54.4
54.4
54.4
54.4
54.4
544.0
54.4
54.4
54.4
54.4
54.4
54.4
54.4
54.4
54.4
816.0
54.4
54.4
54.4
54.4
54.4
54.4
54.4
54.4
54.4
274.8
57.8
55.2
54.4
54.4
54.4
54.4
54.4
54.4
54.4
546.8
57.8
55.2
54.4
54.4
54.4
54.4
54.4
54.4
54.4
818.8
57.8
55.2
54.4
54.4
54.4
54.4
54.4
54.4
54.4
10
12
3
....................
....................
....................
....................
....................
....................
....................
40
48
12
....................
....................
....................
....................
....................
....................
....................
Total ..
7.0
761.5
1033.5
1305.5
768.5
1040.5
1312.5
25.0
100
Note: Totals may not equal sum of parts due to rounding.
Allocation of Cost Impact by Payer:
As stated in section XII. of this final
rule, cost estimates have been
aggregated at the parent organization
level because we believe that an
organization that offers QHPs on the
FFEs, Medicare, Medicaid, and CHIP
products would create one system that
would be used by all ‘‘plans’’ to whom
it offers access to data via APIs. We note
that due to the implementation of APIs
across multiple business lines, there is
no straightforward method to
immediately estimate parent
organization expenditures on how much
of the cost is born by each payer.
Although this section provides such
estimates it is important to understand
how they are arrived at. A summary by
Table in this section is provided in
Table 6. As shown in Table 6:
• We first ascertain total costs of
implementing this final rule by
provision in (Table 5);
• As indicated earlier, we have no
straightforward way of ascertaining total
costs by payer since we do not have
internal data for each parent
organization on how it allocates costs by
program;
• Therefore, to approximate costs we
developed approximated proportions of
total cost of each parent organization by
payer (Medicare, Medicaid, CHIP, and
Individual market, including individual
market plans sold on and off the
Exchanges, as we expect that, among
parent organizations of issuers that offer
QHPs on the FFEs, costs will be passed
on through all plans the issuers offer in
the individual market. Since this rule
does not apply to QHP issuers offering
QHPs only on Federally-facilitated
Small Business Health Options Program
Exchanges (FF–SHOPs) they were not
included in our analysis.
• Our use of available data includes
many approximations due to data
limitations discussed in detail below
(Table 7);
• Table 7 then allows us to obtain
proportions of total costs for this final
rule by payer (Table 8);
• Since we know the way federal
payments for both Medicare and
Medicaid are calculated, we can then
obtain total costs by payer incurred by
the federal government (Table 9);
• We next subtracted federal
payments by payer (Table 9) from total
costs by payer (Table 8) to obtain the
non-federal costs of this final rule by
payer (Table 10);
• Table 11 presents the same data as
Table 10; Table 10 presents total nonfederal costs per payer, while Table 11
presents average non-federal costs per
enrollee per payer;
• Table 12 presents the same data as
Table 9; while Table 9 presents total
costs to the federal government by
payer, Table 12 presents average federal
costs per enrollee by payer; and
• Table 13 lists potential means for
payers to deal with new costs.
TABLE 6—OUTLINE OF THE FLOW OF LOGIC BY TABLE FOR THIS IMPACT ANALYSIS
Table
Content of table
Comments on table
5 ...........................................
Total costs by provision (API, Dual) ...............................
7 ...........................................
Proportion of premiums by program (2016–2018) used,
in later tables, as a proxy for proportion of cost by
program.
8 ...........................................
API costs total cost by year and Program (Medicare,
Medicaid, Individual market plans, and CHIP). This
total cost is divided by cost to the federal government
(Table 9) and non-federal costs to plans and enrollees (Table 10).
Costs are fully developed in the Collection of Information section of this final rule (section XII. of this final
rule).
There is no straightforward way to directly assess parent organization cost by payer. Therefore, for each
payer we develop approximate percentages of cost
per payer.
We obtain the total API costs for this final rule per program by multiplying the API costs (for all programs)
of this final rule (Table 5) by the proportion of premiums presented in Table 7.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
PO 00000
Frm 00104
Fmt 4701
Sfmt 4700
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
25613
TABLE 6—OUTLINE OF THE FLOW OF LOGIC BY TABLE FOR THIS IMPACT ANALYSIS—Continued
Table
Content of table
Comments on table
9 ...........................................
Total costs incurred by the federal government by program and year.
10 .........................................
Non-federal total costs for API by program by year .......
11 .........................................
Average non-federal cost per enrollee per year by program for plans.
12 .........................................
Average federal cost per enrollee per year by program
for the federal government.
13 .........................................
How payers would defray the remaining costs ...............
Based on how federal payments are calculated in Medicare and Medicaid, we have projected federal proportions of the total cost and these are applied to Table
8 to obtain Table 9.
Table 9 = Table 8–Table 10—non-federal costs are obtained by subtracting federal costs (Table 9) from
total costs (Table 8).
Tables 11 and 10 present the same data in different
forms. Table 10 presents total non-federal cost by
program for states and plans, while Table 11 presents average non-federal costs per enrollee per
year for states and plans.
Tables 12 and 9 present the same data in different
forms. Table 9 presents total cost to the federal government (due to matching programs), while Table 12
presents average cost per enrollee to the federal
government.
This table lists potential means for a plan to deal with
extra costs. We have no way of predicting what will
actually happen.
Preliminary Estimates: This section
provides several detailed estimates of
cost by payer (Table 7); we also account
for federal matching for Medicaid and
payments by the Trust Fund for
Medicare Advantage organizations
(Table 9); we indicate remaining burden
on plans (Tables 10, 11) and how they
might account for it (Table 12).
However, these estimates are
approximate as explained in detail
below.
Data Sources for Cost by Payer: To
obtain allocation of cost by payer we
used the CMS public use files for MLR
data, for 2016.69 The MLR data sets are
for private insurance plans but the
issuers of that private insurance in
many cases also have contracts to
provide MA, Medicaid, and CHIP
managed care plans and report revenue,
expense, and enrollment data for these
plans on the private insurance MLR
reporting form.
Thus, these MLR data sets omit
organizations that only have Medicare
or Medicaid. The data from the CMS
MLR files also omit: (1) The CHIP
program; and (2) state Medicaid
agencies. We now discuss these
omissions to assess the accuracy of
using these MLR files.
CHIP: Eighty-five percent of the 194
CHIP managed care plans also offer
Medicaid and hence are covered by the
parent entity. We believe it reasonable
that the remaining CHIP plans also have
commercial offerings since it would be
inefficient to operate a CHIP-only plan,
69 Center for Consumer Information and
Insurance Oversight. (n.d.). Medical Loss Ratio Data
and System Resources. Retrieved from https://
www.cms.gov/CCIIO/Resources/Data-Resources/
mlr.html.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
as the total national CHIP enrollment is
currently only about 7 million.
Similarly, except for one state, CHIP
programs are run through the state
Medicaid agency; again, there would be
one interoperability cost for the one
state agency since the resulting software
and systems would be used both for
Medicaid and CHIP. Thus, while we are
leaving out CHIP programs in this
analysis since they are not in the CMS
MLR files, we do not believe this
materially alters the overall picture.
Medicare Advantage: We compared
the CMS MLR files with the CMS
Trustee Report.70 According to the
Trustee Report (Table IV.C2), total MA
revenue for 2016 was $189.1 billion.
Thus, the reported amount in the CMS
MLR files of $157 billion for MA
represents 83 percent (157/189.1) of all
MA activity reflected in the Trustee
Report. Therefore, we believe the
proportions obtained from these MLR
files are accurate.
Medicaid: For the year for which
these MLR files provide data (2016),
about 70 percent of Medicaid enrollees
were enrolled in Medicaid managed
care.71 Thus, although the MLR files
70 See Table IV.C2 in, Boards of Trustees (Federal
Hospital Insurance and Federal Supplementary
Medical Insurance Trust Funds). (2018, June 5). The
2018 Annual Report of The Boards of Trustees of
the Federal Hospital Insurance and Federal
Supplementary Medical Insurance Trust Funds.
Retrieved from https://www.cms.gov/ResearchStatistics-Data-and-Systems/Statistics-Trends-andReports/ReportsTrustFunds/Downloads/
TR2018.pdf.
71 Centers for Medicare and Medicaid Services.
(2018, November 8). CMS Proposes Changes to
Streamline and Strengthen Medicaid and CHIP
Managed Care Regulations. Retrieved from https://
www.cms.gov/newsroom/press-releases/cmsproposes-changes-streamline-and-strengthenmedicaid-and-chip-managed-care-regulations.
PO 00000
Frm 00105
Fmt 4701
Sfmt 4700
omit state agencies, we believe that the
70 percent of Medicaid enrollees
enrolled in Medicaid managed care
provides a good approximation.
Individual and small group market
plans: The MLR files contain data on all
commercial parent organizations
whether these organizations have other
lines of business, such as Medicare
Advantage or Medicaid, or not. In
discussing commercial plans, we
account for: (A) Large group market
plans; (B) small group market plans,
including SHOP plans; (C) individual
market Exchange plans; and (D)
individual market off-Exchange plans.
• We have carved out the large
employer plans since the provisions of
this final rule do not apply to them, and
we do not believe that parent
organizations would pass on costs for
individual and small group market
plans to large group employersponsored plans.
• We have noted that the provisions
of this final rule do not apply to QHP
issuers offering QHPs only on FF–
SHOPs, so we are not including small
group market plans in this analysis.
• We believe it is reasonable, that
even though the provisions of this final
rule do not apply to off-Exchange
individual market plans, issuers subject
to this rule offering QHPs on the FFEs
will spread the cost to all plans issuers
offer in the individual market. They will
also likely offer the benefits of the APIs
to all covered lives, as they can be
marketed as a value add service, and it
is logistically more challenging to offer
a service to only a limited number of
enrollees.
• We estimate that off-Exchange plans
offered by issuers who offer no QHPs on
E:\FR\FM\01MYR2.SGM
01MYR2
25614
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
FFEs are about 7 percent of total
individual market enrollment.
Therefore, to the extent that we are
including off-Exchange plans, the
calculations below will be an
approximation, but given this low
proportion of off-Exchange-only issuers,
we do not believe including them in this
approximation will have a major
impact.
Best Estimates of Impact per Program
and Payer: We present two methods to
obtain an estimate of cost by program
and payer, both for purposes of
assessing impact on: (1) Small entities;
(2) the federal government; (3) payers
(states and plans); and (4) enrollees. We
could assume costs proportional to
current enrollment, or alternatively, we
could assume costs proportional to total
premium. For purposes of analyzing
impact on small entities and impacts of
the provision on the federal
government, payers, plans, and
enrollees we are using the method of
assuming costs proportional to total
premium (the method of assuming costs
proportional to current enrollment will
be used below to assess impact on
transfers to enrollees).
The CMS Interoperability and Patient
Access proposed rule used 2016 CMS
MLR files (84 FR 7662). Since its
publication, 2017 and 2018 data have
become available. However, we are only
using these data to obtain proportions
and, as Table 7 shows, the proportions
for premiums have not changed
significantly (only one quarter to one
third percent for Medicare and
Medicaid). Therefore, we retain and
continue to use the 2016 proportions for
purposes of this analysis with a note
that they generally have remained
constant. These proportions of
premiums are being used as a proxy to
approximate total cost.
In the proposed rule we used the full
$370 billion in commercial premium in
determining our proportions (84 FR
7662). As discussed above, we are
revising the estimates because upon
further consideration, we have
concluded that issuers in the
commercial group markets are unlikely
to spread the costs through increasing
premium rates on those types of plans
because issuers are not required to
implement and maintain the API
requirements of this final rule in the
group markets and there are no
indications that employer groups in
these markets would be willing to pay
for this provision through increased
premium rates. Consequently, the $370
billion commercial premium is being
reduced to $77 billion and the 76
million enrollees are being reduced to
17.5 million.
As discussed above, the $370 billion
(and 76 million enrollees) represented
both individual and small group and
large group market plans; the $77 billion
and 17.5 million enrollees represent all
individual market plans whether they
are sold on and/or off-Exchange. We
note that this reduction from our
original estimate is due to the fact that
most plans are large employer plans,
and the individual market is only 20 to
23 percent of the full health insurance
market. This refinement better aligns
with the proportion of the market
impacted by this final rule.
Among issuers with products in both
the individual market and MA or the
individual market and Medicaid, the
2016 CMS MLR files show $77 billion
reported in premium for individual
market plans, $157 billion reported for
MA, and $113 billion reported for
Medicaid. Consequently, the proportion
of interoperability cost for each of the
programs is 22.19 percent (77/
(77+157+113)), 45.24 percent (157/
(77+157+113)), and 32.56 percent (113/
(77+157+113)) for individual market
plans, MA, and Medicaid respectively.
Table 7 shows similar proportions for
2017 and 2018.
TABLE 7—PROPORTION OF PREMIUMS (IN BILLIONS) FOR MEDICARE, MEDICAID, AND INDIVIDUAL MARKET PLANS
Year
2016 Premium (billions) ...................................................................................
2017 Premium (billions) ...................................................................................
2018 Premium (billions) ...................................................................................
2016 Percentage (used in this RIA in all estimates) of total costs by program .............................................................................................................
2017 Percentage .............................................................................................
2018 Percentage .............................................................................................
As indicated earlier, since cost
allocation at the parent organization
level and the allocations of each parent
organization may differ by program
(Medicare, Medicaid, CHIP, and
Individual market plans) and is an
Individual
market
plans
Medicare
Advantage
Medicaid
Totals
113
119.5
127
157
170.3
184
77
86
91
347
376
402
32.56%
31.78%
31.62%
45.24%
45.29%
45.81%
22.19%
22.93%
22.56%
100.00%
100.00%
100.00%
internal business decision, we cannot
directly assess per-payer costs.
However, using the MLR tables, we can
assess the proportions of cost by
program. We can then multiply these
proportions (as presented in Table 7) by
the total costs of this final rule as
presented in Table 5 to obtain Table 8,
which breaks out the total column in
Table 5, the total cost by year of
implementing and maintaining the API,
to offer API costs by year and program.
TABLE 8—API COSTS (IN MILLIONS) BY YEAR AND PROGRAM
Full
implementation
and maintenance
costs (millions)
(from Table 5)
for API
provision
Year
2020
2020
2020
2021
2022
(Low estimate) ........................................................................
(Primary estimate) ..................................................................
(High Estimate) .......................................................................
.................................................................................................
.................................................................................................
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
PO 00000
Frm 00106
Fmt 4701
272.0
544.0
816.0
54.4
54.4
Sfmt 4700
Individual
market plans
(22.19%)
Medicaid and
CHIP
(32.56%)
60.4
120.7
181.1
12.1
12.1
E:\FR\FM\01MYR2.SGM
88.6
177.2
265.7
17.7
17.7
01MYR2
Medicare
Advantage
(45.24%)
123.1
246.1
369.2
24.6
24.6
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
25615
TABLE 8—API COSTS (IN MILLIONS) BY YEAR AND PROGRAM—Continued
Full
implementation
and maintenance
costs (millions)
(from Table 5)
for API
provision
Year
2023
2024
2025
2026
2027
2028
2029
Individual
market plans
(22.19%)
Medicaid and
CHIP
(32.56%)
Medicare
Advantage
(45.24%)
.................................................................................................
.................................................................................................
.................................................................................................
.................................................................................................
.................................................................................................
.................................................................................................
.................................................................................................
54.4
54.4
54.4
54.4
54.4
54.4
54.4
12.1
12.1
12.1
12.1
12.1
12.1
12.1
17.7
17.7
17.7
17.7
17.7
17.7
17.7
24.6
24.6
24.6
24.6
24.6
24.6
24.6
Total (Low Estimate) ................................................................
Total (Primary Estimate) ...........................................................
Total (High Estimate) ................................................................
761.5
1033.5
1305.5
169.0
229.3
289.7
248.0
336.6
425.1
344.6
467.6
590.7
Methods of Bearing Cost by Payer
QHPs on the FFEs: Individual market
plans have the option to deal with
increased costs by either temporarily
absorbing them (for purposes of market
competitiveness), increasing premiums
to enrollees, or reducing non-essential
health benefits. To the extent that
issuers increase premiums for
individual market plans on the FFEs,
there would be federal premium tax
credit (PTC) impacts. The purpose of the
PTC is to assist enrollees in paying
premium costs. Since PTCs are only
available if an individual purchases an
individual market plan on an Exchange,
the PTC estimates apply only to
Exchange plans. In the PTC estimate, we
have accounted for the fact that some
issuers have both Exchange and nonExchange plans, and some issuers have
only non-Exchange plans. We reflected
these assumptions with global
adjustments, so we believe the estimates
are reasonable in aggregate.
Medicare Advantage: MA
organizations may increase bids to
reflect the costs of this final rule. Some
of these expected increased bid costs
may increase Medicare Trust Fund
payments. For those (most) MA
organizations whose bid amount is
below the benchmark, the Trust Fund
provides total expenditures to the MA
organizations consisting of: (1) Full
payment of the bid amount; and (2) the
rebate, a portion of the difference
between the benchmark and the bid
amount. Since MA organizations are
increasing their bid amounts to reflect
the costs of this final rule, it follows that
the rebate, equaling the difference
between the benchmark and bid, is
decreased, resulting in less rebates paid
to the MA organizations. Based on our
past experience and projections for the
future, the rebate is estimated as 34
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
percent of the difference between
benchmark and bid. Thus, although the
Trust Fund pays the bid in full,
nevertheless, 66 percent of the increased
bid costs arising from this final rule, are
reduced from the rebates. The MA
organizations in its submitted bid, can
address this reduction of rebates by
either: (1) Temporarily, for marketing
purposes, absorbing the loss by reducing
its profit margin; (2) reducing the
supplemental benefits it provides the
enrollee paid for by the rebate; or (3)
raising enrollee premiums in order to
provide supplemental benefits for
which premiums are not paid by the
rebate. The decision of what approach
to use is an internal business decision
in part motivated by unforeseen forces
of marketing; we therefore have no way
of predicting what will happen.
Medicaid: State Medicaid agencies
may be allowed to allocate the costs of
state information retrieval systems
between the costs attributable to design,
development, installation, or
enhancement of the system—at a 90
percent federal match—and for ongoing
operations of the system—at a 75
percent federal match.
For Medicaid managed care entities,
we assume an MCO, PIHP, and PAHP
cost for implementing the standardsbased API provisions would be built
into the capitation rates and paid for by
the state Medicaid agency, with the state
Medicaid agency being reimbursed at
the state’s medical assistance match
rate. For purposes of these estimates we
use the weighted FMAP, 58.44, which is
based on our past experience with this
program.
Medicaid managed care costs
constitute 52 percent of the Medicaid
program costs.72
Consequently, for the first year
(implementation year), the federal
matching is (0.48*0.90+0.52*0.5844) of
the total program costs, reflecting the 90
percent first year implementation
matching for state agencies which
comprise 48 percent of the program cost
plus 58.44 percent matching for the
Medicaid managed care plans which
comprise 52 percent of the program
costs. Similarly, for years after the first
the federal costs are
(0.48*0.75+0.52*0.5844) of total
program costs.
CHIP: Most states operate Medicaid
and CHIP from the same state agency.
One state is a notable exception in that
it has a separate Medicaid and CHIP
agency. The federal government pays an
enhanced federal medical assistance
percentage (EFMAP) to states for all
costs associated with CHIP, including
systems costs (this is unlike Medicaid
where there are different FMAPs for
different types of costs). For federal FY
2019, the EFMAPs will range from 88 to
100 percent. For federal FY 2020, the
EFMAPs will range from approximately
76.5 to 93 percent. After federal FY
2020, the EFMAPs will range from
approximately 65 to 81.5 percent. Since
the CHIP program federal rebate ranges
include the 90 percent and 75 percent
federal matching proportions of the
Medicaid program, we are applying the
90 percent and 75 percent from
Medicaid to the CHIP programs. Since
the CHIP program is small relative to the
Medicaid program, we believe this
approach reasonable.
Table 9 uses these proportions to
estimate the impact of the API on the
federal government. For example, the
$65.2 million cost to the federal
government for Medicaid/CHIP for 2020
72 Allen, K. (2019, April 18). Medicaid Managed
Care Spending in 2018. Retrieved from https://
www.healthmanagement.com/blog/medicaidmanaged-care-spending-in-2018/.
PO 00000
Frm 00107
Fmt 4701
Sfmt 4700
E:\FR\FM\01MYR2.SGM
01MYR2
25616
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
(low estimate), the implementation year
of the API, is obtained by multiplying
the total $88.6 million (low estimate)
cost listed in Table 8 by
(0.48*0.90+0.52*0.5844) the ratio
indicated in the previous paragraphs.
These assumptions on all first-year
federal expenses are reflected in Table
9 which includes PTC payments as well
as federal matching in Medicaid and
Medicare. For PTC and Medicare we
have assumed Federal payment in 2021.
We note that we are not discussing at
this point how parent organizations will
bear these costs. This will be discussed
below. However, the basis for the
discussion is the calculation of nonfederal cost born by enrollees and plans
which is obtained by subtracting federal
costs from total costs.
TABLE 9—COSTS INCURRED BY FEDERAL GOVERNMENT PROGRAM AND YEAR
[In Millions]
For individual
market plans
Year
2020
2020
2020
2021
2021
2022
2022
2023
2024
2025
2026
2027
2028
2029
For Medicaid
CHIP
For Medicare
Advantage
(Low estimate) ....................................................................................................................
(Primary estimate) ..............................................................................................................
(High Estimate) ...................................................................................................................
(Low estimate) ....................................................................................................................
(Primary Estimate) ..............................................................................................................
(High Estimate) ...................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
0.0
0.0
0.0
6.1
6.1
6.1
6.2
6.2
6.3
6.3
6.3
6.3
6.3
6.4
65.2
130.4
195.5
11.8
11.8
11.8
11.8
11.8
11.8
11.8
11.8
11.8
11.8
11.8
0.0
0.0
0.0
50.2
92.1
133.9
8.4
8.4
8.4
8.4
8.4
8.4
8.4
8.4
Total (Low Estimate) ............................................................................................................
56.4
171.0
117.1
Total (Primary Estimate) .......................................................................................................
56.4
236.2
159.0
Total (High Estimate) ............................................................................................................
56.4
301.4
200.8
Note: The following percentages were applied to Table 8 to obtain Table 9: 0 percent for individual market plans, 34 percent for Medicare advantage plans and 0.48*0.90+0.52*0.5844 (1st year) and 0.48*0.75+0.52*0.5844 (later years) for Medicaid. Furthermore, as discussed above,
federal payments to Medicare Advantage for implementation occurs fully in 2021.
By taking the difference between the
respective cells in Tables 8 (total costs
by program) and 9 (total matching by
the federal government), we obtain the
remaining costs for the API for Medicare
Advantage plans and for state Medicaid
agencies. To this amount (which only
deals with the API provisions) must be
added the coordination cost for the dual
eligible (column 3 of Table 5) multiplied
by the proportion of costs presented in
Table 7. This remaining cost born by
Medicare Advantage plans and state
Medicaid agencies is presented in Table
10. Since the federal government does
not match QHP costs, the total cost for
QHPs on the FFEs is born in its entirety
by the plans. This also is listed in Table
10; however, in subtracting Table 9 from
Table 8, we exclude PTC costs. These
are federal costs, but unlike Medicare
Advantage and Medicaid, the QHPs on
the FFEs must account for the full cost
of implementation. These PTC costs are
not used to defray API costs.
For example, Table 10 lists for 2020
(low estimate), Medicaid/CHIP a
remaining cost to states of $24.3 million
($88.6 million total (low estimate) cost
for 2020 (Table 8)¥$65.2 million
matched by the federal government
(Table 9) + ($2.8 million total cost for
coordination of dual eligibles (Table 5)
* 32.56 percent (proportion of total costs
incurred by Medicaid/CHIP (Table 7)).
(There are minor differences due to
rounding.)
TABLE 10—REMAINING COSTS BY PROGRAM FOR API BY YEAR
[In millions]
For individual
market plans
Year
2020 (Low estimate) ....................................................................................................................
2020 (Primary estimate) ..............................................................................................................
2020 (High Estimate) ...................................................................................................................
2021 (Low estimate) ....................................................................................................................
2021(Primary Estimate) ...............................................................................................................
2021 (High Estimate) ...................................................................................................................
2022 .............................................................................................................................................
2023 .............................................................................................................................................
2024 .............................................................................................................................................
2025 .............................................................................................................................................
2026 .............................................................................................................................................
2027 .............................................................................................................................................
2028 .............................................................................................................................................
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
PO 00000
Frm 00108
Fmt 4701
Sfmt 4700
E:\FR\FM\01MYR2.SGM
61.0
121.3
181.7
12.8
12.8
12.8
12.3
12.1
12.1
12.1
12.1
12.1
12.1
01MYR2
For Medicaid/
CHIP
24.3
47.7
71.1
7.0
7.0
7.0
6.2
6.0
6.0
6.0
6.0
6.0
6.0
For Medicare
Advantage
124.3
247.4
370.1
-24.1
-65.9
-107.8
16.6
16.2
16.2
16.2
16.2
16.2
16.2
25617
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 10—REMAINING COSTS BY PROGRAM FOR API BY YEAR—Continued
[In millions]
For individual
market plans
Year
For Medicaid/
CHIP
For Medicare
Advantage
2029 .............................................................................................................................................
12.1
6.0
16.2
Total (Low Estimate) ............................................................................................................
170.5
79.3
230.6
Total (Primary Estimate) .......................................................................................................
230.9
102.6
311.8
Total (High Estimate) ............................................................................................................
291.3
126.0
392.7
We next discuss in Tables 11 through
13 how payers and the federal
government will deal with these extra
costs. We also discuss whether the costs
are excessive for existing plans as well
as how new plans might deal with these
costs.
The further discussion of bearing
these costs is illustrated by
reformulating the costs in terms of costs
per enrollee (per year), which is
obtained by dividing the total cost to the
payer for all programs in which it
participates (Medicare, Medicaid, CHIP,
and Individual market plans) by its total
enrollment. As an example, if a payer
hypothetically spent $1 billion in a year
for 100,000 enrollees then the cost per
enrollee per year is $10,000 ($1 billion/
100,000).
As can be seen from this example, the
cost per enrollee metric facilitates
comparison of costs. Since program
expenditures for both Medicaid and MA
are typically hundreds of millions (or
billions) of dollars, concepts like burden
and negligibility may not have intuitive
meaning, as opposed to the costs per
enrollee, which are more manageable
and understandable.
To provide background, the 2018
Medicare Trust Fund Report 73 states
that costs per enrollee are projected to
be roughly $12,000—$14,000 for
contract years 2020—2023 (Table
IV.C3). The costs per enrollee for the
Medicaid program are similarly several
thousand dollars. The estimates in the
2019 Medicare Trust Fund Report are
identical.74
For purposes of indicating the cost
per enrollee, we estimate 110.5 million
enrollees will be affected by these
provisions since currently there are
17.5, 66,75 20,76 and 7 77 million
enrollees covered by payers in the
individual market, Medicaid, MA, and
separate CHIP programs, respectively.
Table 11 presents costs per enrollee by
program for payers after reducing total
costs by federal matching, while Table
12 presents costs per enrollee by
program for the federal government.
For example, the 2020 (low estimate)
cost per enrollee for commercial
individual market plans is $3.48 (Table
11), which is obtained by dividing the
total, 2020, low-estimate, non-federal,
individual market plan cost of $61
million (Table 10) by 17.5 million
enrollees. (This is based on the low
estimate of cost for API; the high
estimate of cost would be $10.38 =
$181.7 million/17.5 million).
The 2022 cost per enrollee for state
Medicaid agencies after federal
matching is 9 cents per enrollee (Table
11), which is obtained by dividing the
total non-federal cost per program after
federal matching, $6.2 million (Table
10) by 73 million enrollees (66 million
in Medicaid + 7 million in CHIP). Each
of these three calculations restates total
spending per program per stakeholder
(government, state Medicaid agencies,
or Medicare Advantage plans) in terms
of cost per enrollee.
TABLE 11—AVERAGE COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM FOR PAYERS
Individual
market plans
(17.5)
Current enrollment by payer (millions)
2020 (Low estimate) ....................................................................................................................
2020 (Primary estimate) ..............................................................................................................
2020 (High Estimate) ...................................................................................................................
2021 (Low estimate) ....................................................................................................................
2021(Primary Estimate) ...............................................................................................................
2021 (High Estimate) ...................................................................................................................
2022 .............................................................................................................................................
2023 .............................................................................................................................................
2024 .............................................................................................................................................
2025 .............................................................................................................................................
73 Boards of Trustees (Federal Hospital Insurance
and Federal Supplementary Medical Insurance
Trust Funds). (2018, June 5). The 2018 Annual
Report of The Boards of Trustees of the Federal
Hospital Insurance and Federal Supplementary
Medical Insurance Trust Funds. Retrieved from
https://www.cms.gov/Research-Statistics-Data-andSystems/Statistics-Trends-and-Reports/Reports
TrustFunds/Downloads/TR2018.pdf.
74 See page 154 in, Boards of Trustees (Federal
Hospital Insurance and Federal Supplementary
Medical Insurance Trust Funds). (2019, April 22).
The 2019 Annual Report of The Boards of Trustees
of the Federal Hospital Insurance and Federal
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Supplementary Medical Insurance Trust Funds.
Retrieved from https://www.cms.gov/ResearchStatistics-Data-and-Systems/Statistics-Trends-andReports/ReportsTrustFunds/Downloads/
TR2019.pdf.
75 Centers for Medicare and Medicaid Services.
(n.d.). October 2019 Medicaid & CHIP Enrollment
Data Highlights. Retrieved from https://
www.medicaid.gov/medicaid/program-information/
medicaid-and-chip-enrollment-data/reporthighlights/.
76 Centers for Medicare and Medicaid Services.
(n.d.). Monthly Contract Summary Report—August
PO 00000
Frm 00109
Fmt 4701
Sfmt 4700
3.48
6.93
10.38
0.73
0.73
0.73
0.70
0.69
0.69
0.69
Medicaid
plans (73)
0.33
0.65
0.97
0.10
0.10
0.10
0.09
0.08
0.08
0.08
Medicare
Advantage
plans (20)
6.22
12.37
18.51
-1.20
-3.30
-5.39
0.83
0.81
0.81
0.81
2018. Retrieved from https://www.cms.gov/
Research-Statistics-Data-and-Systems/StatisticsTrends-and-Reports/MCRAdvPartDEnrolData/
Monthly-Contract-and-Enrollment-SummaryReport-Items/Contract-Summary-2018-08.html?
DLPage=1&DLEntries=10&
DLSort=1&DLSortDir=descending.
77 Centers for Medicare and Medicaid Services.
(n.d.). October 2019 Medicaid & CHIP Enrollment
Data Highlights. Retrieved from https://
www.medicaid.gov/medicaid/program-information/
medicaid-and-chip-enrollment-data/reporthighlights/.
E:\FR\FM\01MYR2.SGM
01MYR2
25618
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 11—AVERAGE COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM FOR PAYERS—Continued
Individual
market plans
(17.5)
Current enrollment by payer (millions)
Medicaid
plans (73)
Medicare
Advantage
plans (20)
2026 .............................................................................................................................................
2027 .............................................................................................................................................
2028 .............................................................................................................................................
2029 ......................................................................................................................................
0.69
0.69
0.69
0.69
0.08
0.08
0.08
0.08
0.81
0.81
0.81
0.81
Total (Low Estimate) ............................................................................................................
9.7
1.1
11.5
Total (Primary Estimate) .......................................................................................................
13.2
1.4
15.6
Total (High Estimate) ............................................................................................................
16.6
1.7
19.6
TABLE 12—AVERAGE COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM FOR FEDERAL GOVERNMENT
Individual
market plans
(17.5)
Current enrollment by payer (millions)
Medicaid
plans (73)
Medicare
Advantage
plans (20)
2020 (Low estimate) ....................................................................................................................
2020 (Primary estimate) ..............................................................................................................
2020 (High Estimate) ...................................................................................................................
2021 (Low estimate) ....................................................................................................................
2021(Primary Estimate) ...............................................................................................................
2021 (High Estimate) ...................................................................................................................
2022 .............................................................................................................................................
2023 .............................................................................................................................................
2024 .............................................................................................................................................
2025 .............................................................................................................................................
2026 .............................................................................................................................................
2027 .............................................................................................................................................
2028 .............................................................................................................................................
2029 .............................................................................................................................................
0.00
0.00
0.00
0.35
0.35
0.35
0.35
0.35
0.36
0.36
0.36
0.36
0.36
0.37
0.89
1.79
2.68
0.16
0.16
0.16
0.16
0.16
0.16
0.16
0.16
0.16
0.16
0.16
0.00
0.00
0.00
2.51
4.60
6.69
0.42
0.42
0.42
0.42
0.42
0.42
0.42
0.42
Total (Low Estimate) ............................................................................................................
3.2
2.3
5.9
Total (Primary Estimate) .......................................................................................................
3.2
3.2
7.9
Total (High Estimate) ............................................................................................................
3.2
4.1
10.0
In Table 13, we explain possible ways
payers may deal with these extra costs.
We emphasize that Table 13 lists
potential legal possibilities. What
actually happens will depend on market
dynamics and internal business
decisions, and we have no
straightforward way of predicting what
these actual behaviors and responses
will be.
Individual Market Plans: As noted
above, individual market plans have the
option of absorbing costs or passing
costs to enrollees either in the form of
higher premiums or reduced benefits
that are non-essential health benefits
(EHBs). The average estimated cost per
enrollee in 2021 through 2028 is under
a dollar, which we assume issuers
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
would pass on to enrollees. However,
for purposes of market competitiveness,
it is possible that some of the 2020
average estimated cost of $3.48 per
enrollee (low estimate) or $10.38 per
enrollee per year (high estimate) would
be absorbed by each QHP issuer on an
FFE.
Medicaid: State Medicaid agencies
and CHIP are adding a cost under 10
cents per enrollee for 2021 through
2029. Total costs per enrollee for the
Medicaid program are several thousand
dollars. We note, the federal government
is incurring costs capped at $2.68 per
enrollee per year in 2020 and at 16 cents
per enrollee per year in 2021 through
2029.
Medicare Advantage: In their bids
(submitted the June prior to the
PO 00000
Frm 00110
Fmt 4701
Sfmt 4700
beginning of the coverage year),
Medicare Advantage plans would
address the reduced rebates (arising
from increased bid costs due to the
increased costs of this final rule being
included in the bid) by either: (1)
Temporarily absorbing costs by
reducing profit margins; (2) reducing the
supplemental benefits paid for by the
rebates; or (3) raising enrollee cost
sharing or premiums (however, we
believe many plans for competitive
reasons would chose to remain zero
premium and either absorb losses for
one year or reduce rebate-funded
supplemental benefits in the amount per
enrollee shown in Table 9). Table 13
summarizes these methods of bearing
the remaining costs.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
25619
TABLE 13—HOW PAYERS WOULD DEFRAY REMAINING COSTS
Individual Market Plans .......................................
Medicaid/CHIP ....................................................
Medicare Advantage (MA) ..................................
PTC Impact: First, we note that there
will be no impact on the expected 2020
PTC payment because 2020 premium
rates were finalized last year, so even if
issuers incur expenses that they did not
anticipate when setting rates, they will
not be able to reflect those expenses in
the premium rates, and therefore, the
expected PTC payments for 2020 will
not change.
Table 10 shows that for 2021 through
2029 the estimated impact to QHPs on
the FFEs is a $12 million expense. This
estimated $12 million expense burden
represents an increase to annual FFE
premium of approximately 0.03 percent.
Within the FFE states, the estimated
expense burden will impact premium
rates in the individual market, and is
spread across both Exchange and nonExchange QHPs. PTCs are only paid for
QHPs offered through Exchanges, and
are calculated as a function of the
second lowest cost silver plan. Because
of the wide variability of Exchange
plans we make the simplifying
assumption that the industry would
increase the second-lowest-cost silver
plan premium rate in the same amount
as the overall premium rate increase as
a result of the RIA expense estimate. We
can then apply the overall rate increase
to the projected PTC payments in the
FFE states to estimate the impact to PTC
payments.
Therefore, we estimate that impact to
PTCs in the FFE states will be
approximately $6 million per year
starting in 2021, which is about 0.02
percent of the total 2021 expected PTC
payment in FFE states. Again, the
calculated PTC impacts in 2021 through
2029 are included with all federal
impacts in Table 9.
We next summarize the public
comments we received on our estimated
impacts and provide our responses.
Comment: Some commenters
requested that the government share
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
Individual market plans generally have the option of absorbing costs (for example, for reasons
of market competitiveness), increasing premiums to enrollees, or modifying cost-sharing or
non-EHB covered benefits. Cost would be spread over all parent organization enrollees in a
specified state and the individual market in FFE states. Small commercial individual market
issuers seeking certification of plans as QHPs on the FFEs may request an exception to the
API provisions.
State Medicaid agencies would bear the cost (under 10 cents per enrollee). Medicaid plans
are fully capitated but may have to defer first year costs.
MA plans in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by
either: (1) Temporarily absorbing costs by reducing profit margins; (2) reducing additional
benefits paid for by the rebates; or (3) raising enrollee cost sharing (however, many plans
for competitive reasons would chose to remain zero premium and either absorb losses for
one year or reduce additional, rebate-funded benefits in the amount per enrollee shown in
Table 9). Tax deferment and amortization as applicable ameliorates cost. Capital costs are
spread over entire parent organization enrollees. New plans are allowed to enter with initial
negative margins with the expectation that they will stabilize over the first few years.
more in the associated costs of the open,
standards-based API implementation for
both MA and Medicaid plans. These
commenters noted that additional
financial sharing by the federal
government would help remedy offsets
potentially being absorbed by the health
plan that may result in decreased
benefits and/or increase premiums.
Medicare Advantage: Some
commenters requested that the costs be
included in MA bids. Other commenters
recommended that if CMS is going to
make specific technological
requirements around implementation of
the CMS Interoperability and Patient
Access proposed rule then health plans
should be allowed to include a
percentage of these costs in their MA
bids. One commenter recommended
that CMS could consider adding a fixed
dollar amount to MA bids if health
plans complied with the requirements
of the proposed rule, or CMS could add
it into the bid tool.
Medicaid: Similar comments were
made for Medicaid plans. One
commenter recommended that CMS
provide states with a 100 percent federal
matching to facilitate implementation
and that state Medicaid agencies be
required to include plan
implementation costs into capitation
rates. Another commenter requested
that CMS require state Medicaid
agencies to include a fixed amount of
dollars or a percentage of
implementation costs into plan
administrative costs to remedy the cost
impact of implementation.
Response: We appreciate the
commenters’ concerns and suggestions.
As noted previously in this RIA, we
have assumed traditional federal sharing
of costs for both the MA and Medicaid
programs. The results have been
presented in Tables 9 through 12 with
Table 13 indicating how payers and the
federal government would defray costs.
PO 00000
Frm 00111
Fmt 4701
Sfmt 4700
In Tables 11 and 12 the average
estimated costs per enrollee (under $15)
is compared with overall costs per
enrollee (several thousand dollars).
Additionally, we have been careful in
our analysis to distinguish between
federal matching to state Medicaid
entities in the first year, federal
matching to state Medicaid entities in
later years, and federal matching of state
payment of capitation rates to state
Medicaid agencies. We take note that
the commenter’s concerns for specific
federal matching for the provisions of
this final rule would require legislative
action. Consequently, when writing the
CMS Interoperability and Patient Access
proposed rule, we did not believe it was
necessary to propose additional federal
spending beyond the already existing
federal reimbursement to MA, Medicaid
plans, and state agencies.
Comment: A few commenters
expressed concern that the CMS
Interoperability and Patient Access
proposed rule was not clear with regard
to whether or not state Medicaid
agencies would be allowed to allocate
the costs of this implementation—at a
90 percent federal match—and for
ongoing operations of the system—at a
75 percent federal match. Commenters
requested that CMS provide clarity
around the use of such language and
exactness of ‘‘pay fors’’ since this is vital
for state Medicaid agencies’ cost
estimates in implementing the
requirements of this rule.
Response: We agree with the
commenters. We therefore have revised
the calculations to Table 10 to reflect
the following more precise accounting
of costs: (1) 90 percent of state Medicaid
costs are paid or matched by the federal
government in the first year of
implementing new systems; (2) 75
percent of Medicaid costs are matched
for maintenance costs; and (3) on
average, state Medicaid agencies are
E:\FR\FM\01MYR2.SGM
01MYR2
25620
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
matched 58.44 percent. We believe this
heightened level of detail should satisfy
commenter concerns. The revised
numbers are reflected in Tables 10 and
Table 11.
Comment: One commenter noted that
the developers of APIs may want
additional fees to implement or provide
access to their APIs. The commenter
noted that these fees severely limit
innovation in the marketplace for health
IT solutions for storing and utilizing
patient data, both on the patient and
provider side of the equation.
Response: The data that must be
shared via the API under this policy are
data that the payers have and must
currently make available to patients. We
also anticipate that many payers will
develop the APIs in-house. If this
commenter is more referencing the
vendors creating apps, versus APIs for
payers, we also do not believe it is
appropriate to charge a fee, as discussed
in section III. of this final rule. If fees
are charged for certain apps, it is not the
data that are generating the fee, it is the
product or services; indeed, there is a
logical connection between the potential
benefits of this rule (facilitated by new
or enhanced services) and nonquantified potential costs (possibly
including those associated with the
development or improvement of such
services). Currently there are vendors
that collect the publicly available
directory data, clean these data,
supplement these data, and offer this
enhanced data product back to payers
and providers. It is not the data the
vendors are charging for as much as it
is the service of cleaning and enhancing
these data. Vendors may generate
revenue from their third-party apps, but
a major component of this is the service
they are providing—building the app,
making the data the patient directs to
them most usable and valuable—that
generates the revenue. Payers must
already make these data available to
patients. These data alone may also
drive revenue, but it is the patient’s
prerogative to provide their data to a
third party in order to get a service in
exchange
Comment: A few commenters noted
that RIA does not contain any costs for
provider EHR connectivity. One
commenter noted that EHR developers’
contracts with providers and health
systems do not include the cost of
system updates that will be required to
comply with this proposal. Another
commenter was concerned that EHR
developers will charge providers
significant fees to perform the updates
required to comply with CMS’
proposals, and providers will likely
need to make additional investments to
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
learn how to use standards-based APIs
and other new technologies. Another
commenter believes that for the clinical
data to be available in any API, the
CEHRT used by providers needs to be
connected to a trusted exchange
network. For many clinicians, the
commenter noted the costs for
connecting their CEHRT to a trusted
network continues to remain a barrier.
Response: To address commenters’
concerns with API connectivity to an
EHR, we note that there is no
requirement for a payer to link the
Patient Access API to an EHR in this
final rule, and there are associated
challenges, as discussed elsewhere in
this RIA, with attributing impacts to
various interacting regulatory and other
policies. Indeed, we do note that if a
provider does elect to connect an EHR
to the APIs finalized in this rule, they
would be required to meet all the
requirements of ONC’s Health IT
Certification Program.78 As part of that
program, the 2015 CEHRT includes, for
example, ‘‘application access’’
certification criteria that requires health
IT to demonstrate it can provide
application access to the Common
Clinical Data Set (CCDS) via an API.79
Furthermore, nearly a third of EHR
vendors are also using the FHIR
standard to meet 2015 CEHRT
requirements.80
C. Anticipated Effects
The RFA, as amended, requires
agencies to analyze options for
regulatory relief of small businesses, if
a rule has a significant impact on a
substantial number of small entities. For
purposes of the RFA, small entities
include small businesses, nonprofit
organizations, and small governmental
jurisdictions.
The API requirements in this final
rule affect: 1) QHP issuers on the FFEs,
2) MA organizations, including those
that are also Part D sponsors of MA–PD
plans, as well as 3) Medicaid MCOs
with a minimum threshold for small
business size of $41.5 million (https://
www.sba.gov/federal-contracting/
contracting-guide/size-standards).
78 Office of the National Coordinator. (2019,
March 27). About the ONC Health IT Certification
Program. Retrieved from https://www.healthit.gov/
topic/certification-ehrs/about-onc-health-itcertification-program.
79 Centers for Medicare and Medicaid Services.
(n.d.). 2019 Promoting Interoperability Programs:
2015 Edition Certified EHR Technology Fact Sheet.
Retrieved from https://www.cms.gov/Regulationsand-Guidance/Legislation/EHRIncentivePrograms/
Downloads/CEHRT2015Ed_FactSheet-.pdf.
80 Posnack, S. & Baker, W. (2018, October 1). Heat
Wave: The U.S. is Poised to Catch FHIR in 2019.
Retrieved from https://www.healthit.gov/buzz-blog/
interoperability/heat-wave-the-u-s-is-poised-tocatch-fhir-in-2019.
PO 00000
Frm 00112
Fmt 4701
Sfmt 4700
Assessment of impact is complicated
by the fact that costs have been
aggregated at the parent organization
level. A typical parent organization
might have products with QHP issuers
on the FFEs, MA, or Medicaid/CHIP
programs. We have no way of directly
assessing the size of parent
organizations. Therefore, as a proxy, we
analyze each payer separately.
Medicare Advantage: We first assess
the impact on MA plans. To clarify the
flow of payments between these entities
and the federal government, we note
that MA organizations submit proposed
plan designs and estimates of the
amount of revenue necessary to cover
the cost of those plan designs (called
bids) by the first Monday in June of the
year preceding the coverage year.
Regulations governing this process are
in 42 CFR part 422, subpart F. These
bids must be broken down in the
following:
(1) The revenue requirements for
providing Medicare Part A and Part B
benefits with actuarially equivalent cost
sharing (this is the ‘‘basic benefit bid’’);
(2) The revenue requirements for
providing supplemental benefits;
(3) The revenue requirements for NonBenefit Expenses such as Sales &
Marketing, Direct and Indirect
Administration, Net Cost of
Reinsurance, and Insurance Fees; and
(4) For MA–PD plans, a Part D bid
consistent with Part D regulations in 42
CFR part 423.
These bids project payments to
hospitals, providers and staff for
covered benefits, as well as the cost of
plan administration and profits. Because
the API requirements finalized in this
rule will apply to every MA plan and
each MA plan must furnish at least the
Medicare Part A and Part B benefits, the
cost of the API will be built into the
administrative component of the basic
benefit bid. These bids in turn
determine one component of the
payments of the Medicare Trust Fund to
the MA organizations who reimburse
providers and subcontractors for their
services. A second component of the
Trust Fund payment to MA
organizations are the rebates, which are
a portion of the difference between the
basic benefit bid compared to an
administratively-set benchmark for the
MA plan’s service area (currently, based
on our past and projected experience,
rebates vary by plan and are
approximately 66 percent). Benchmarks
are based on a formula using an estimate
of the Medicare FFS per capita cost for
the geographic area, which are adjusted
to reflect the per capita cost of each
county in the U.S. and its territories and
adjusted for the enrollees’ health status
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
which is also known as the risk score.
Payments from the Medicare Trust
Funds for monthly capitation rates (for
basic benefits) are capped at the
benchmark; for basic benefit bids under
the benchmark, a portion, currently
approximately 66 percent, of the
difference between the bid and
benchmark is made available to the MA
organization to either: (1) Pay for
additional supplemental benefits; (2)
include reductions in cost sharing in the
plan design; or (3) provide buy-downs
of Part B or Part D premiums. Basic
benefit bids that are at or above the
benchmark receive payment from the
Trust Funds of the benchmark amount,
with any excess charged to the enrollee
as a premium.
MA organizations are made aware of
the benchmark through the annual CMS
publication, ‘‘Announcement of
Calendar Year [X] Medicare Advantage
Capitation Rates and Medicare
Advantage and Part D Payment
Policies,’’ which, consistent with
section 1853 of the Act, is released prior
to MA organizations submission of bids.
This publication of the benchmark
when coupled with plan awareness that
they will receive rebates if their plan
bids fall below the benchmark facilitates
that bids of most MA organizations are
below the benchmark and consequently
most MA organizations receive from the
Trust Fund a total expenditure equaling
payment for the bid plus the rebate.
Because of these API provisions, we
assume that MA organizations will be
raising the June-submitted bid amount
to reflect additional administrative
costs. While the Trust Fund pays these
bid amounts in full, the rebate goes
down as the bid increases: That is, since
the bid amount goes up, the rebate,
equaling the difference between the
benchmark and bid, decreases and
results in less rebate payment to the MA
organization. The MA organization has
several options of dealing with these
increased bid costs and reduced rebates:
The MA organization might decide to:
(1) Temporarily absorb the loss by
reducing its profit margin (so as to
reduce the bid amount and thereby
increase the rebates); (2) reduce
additional benefits paid to the enrollee
from the rebates; or (3) raise enrollee
premiums so as to compensate for the
reduction of enrollee premium that
would have happened if the bid had not
been increased (note: for marketing
purposes, many plans operate at zero
premium, and we do not consider this
third option a likely possibility). In this
RIA, we have referred to options (2) and
(3) (reduction of additional benefits and
raising of enrollee premiums) as
‘‘passing the costs to the enrollee’’ so
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
that the ‘‘effect’’ of reduced rebates is
fewer supplemental benefits or higher
enrollee premiums than would have
happened had the cost of the complying
with the API provisions of this final rule
not been imposed.
There are various types of Medicare
health plans, including MA HMOs, POS
plans, and PPOs; Demonstration plans;
Cost Plans; Prescription Drug Plans
(PDP); and Programs of All-Inclusive
Care for the Elderly (PACE) organization
plans. This final rule affects MA HMOs,
MA POS plans, and MA PPOs including
those that are MA–PDs, but does not
affect Cost Plans, stand-alone
Prescription Drug Plans, nor PACE
organizations.
There are a variety of ways to assess
whether MA organizations meet the
$41.5 million threshold for small
businesses. The assessment can be done
by examining net worth, net income,
cash flow from operations and projected
claims as indicated in their bids. Using
projected monetary requirements and
projected enrollment for 2018 from
submitted bids, approximately 30
percent of the MA organizations fell
below the $41.5 million threshold for
small businesses. Additionally, an
analysis of 2016 data, the most recent
year for which we have actual data on
MA organization net worth, shows that
approximately 30 percent of all MA
organizations fall below the minimum
threshold for small businesses.
Medicaid: We next assess the impact
on Medicaid managed care plans. Since
Medicaid managed care plans receive
100 percent capitation from the state,
we generally expect that the costs
associated with the API provisions of
this final rule, will be included in their
capitation rates and may be reasonable,
appropriate, and attainable costs
whether they are a small business or
not.
QHP issuers on the FFEs: Based on
the 2016 CMS MLR data, approximately
85 out of 494, or 17 percent of
companies (that either had only
individual market business, or had
individual market plus Medicare and/or
Medicaid business) had total premium
revenue of less than $41,500,000. In
other words, for MA, Medicaid, and
QHP issuers on the FFEs, a significant
number of small plans are affected. The
RFA requires us to assess whether the
rule has a significant impact on the
plans, which we do next.
If a rule has a substantial impact on
a substantial number of small entities,
the rule must discuss steps taken,
including alternatives, to minimize
burden on small entities. While a
significant number (more than 5
percent) of not-for-profit organizations
PO 00000
Frm 00113
Fmt 4701
Sfmt 4700
25621
and small businesses are affected by this
final rule, the impact is not significant.
To assess impact, we use the data in
Table 5, which shows that the total raw
(not discounted) net effect of this final
rule over 10 years is $714 million.
Medicare Advantage: We first assess
impact on MA plans. Comparing the
$714 million number to the total
monetary amounts projected to be
needed just for 2018, the most recent
year on which we have finalized plan
submitted bid data (and which is
expected to be less than the need in
future years including 2019), we find
that that the impact of this final rule is
significantly below the 3 percent–5
percent threshold for significant impact
for MA plans.
Medicaid: We next assess impact on
Medicaid managed care plans. The total
projected capitation payment and
premiums for 2019 is projected to be
$337.6 billion.81 Hence, the total cost of
this final rule over 10 years, $714
million, is significantly below the 3
percent–5 percent threshold for
significant impact to Medicaid managed
care plans.
QHP issuers on the FFEs: As
discussed prior to Table 6 based on data
in the public CMS MLR files,
commercial health insurance issuers
had premium revenue of $77 billion for
individual market plan coverage in
2016. Therefore, the aggregate raw cost
of this final rule over 10 years, $762
million (low estimate) and $1.3 billion
(high estimate), is significantly below
the 3 percent to 5 percent threshold for
significant impact to commercial plans.
We believe, that although a significant
number of small plans under each
program are affected by this rule, on
average this impact is not significant.
Additionally, we note that for those
small entities that do find the cost of the
provisions of this final rule
burdensome, an exception process has
been described in section III.C. of this
final rule. Specifically, we note that we
may provide an exceptions process
through which the FFEs may certify
health plans that do not provide patient
access through a standards-based API,
but otherwise meet the requirements for
QHP certification. This process could
apply for small issuers, issuers who are
only in the individual or small group
market, financially vulnerable issuers,
or new entrants to the FFEs who
demonstrate that deploying standards81 See ‘‘Capitation payments & premiums’’ in
Table 17 of Appendix D in, Office of the Actuary
(Centers for Medicare and Medicaid Services).
(2016). 2016 Actuarial Report on the Financial
Outlook for Medicaid. Retrieved from https://
www.medicaid.gov/medicaid/finance/downloads/
medicaid-actuarial-report-2016.pdf.
E:\FR\FM\01MYR2.SGM
01MYR2
25622
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
based API technology consistent with
the required interoperability standards
would pose a significant barrier to the
issuer’s ability to provide coverage to
consumers, and not certifying the
issuer’s QHP or QHPs would result in
consumers having few or no plan
options in certain areas.
Consequently, the Secretary has
determined that this final rule will not
have a significant economic impact on
a substantial number of small entities
and the requirements of the RFA have
been met. Please see our detailed
analysis of apportionment of costs per
payer in Tables 6 through 13 and
section XIII.H. of this final rule for
further details.
In addition, section 1102(b) of the Act
requires CMS to prepare an RIA if a rule
may have a significant impact on the
operations of a substantial number of
small rural hospitals. This analysis must
conform to the provisions of section 604
of the RFA. For purposes of section
1102(b) of the Act, we define a small
rural hospital as a hospital that is
located outside a Metropolitan
Statistical Area and has fewer than 100
beds. We are not preparing an analysis
for section 1102(b) of the Act because
we have determined, and the Secretary
certifies, that this final rule would not
have a significant impact on the
operations of a substantial number of
small rural hospitals.
Section 202 of the Unfunded
Mandates Reform Act of 1995 (UMRA)
(Pub. L. 104–04, enacted March 22,
1995) also requires that agencies assess
anticipated costs and benefits before
issuing any rule whose mandates,
except those that are conditions of
federal program participation, require
spending in any 1 year of $100 million
in 1995 dollars, updated annually for
inflation. In 2020, that is approximately
$156 million. This rule does not impose
any such unfunded mandates.
Executive Order 13132 establishes
certain requirements that an agency
must meet when it promulgates a
proposed rule (and subsequent final
rule) that imposes substantial direct
requirement costs on state and local
governments, preempts state law, or
otherwise has federalism implications.
This final rule will not have a
substantial direct effect on state or local
governments, preempt state law, or
otherwise have a federalism
implication. Therefore, the requirements
of Executive Order 13132 are not
applicable.
If regulations impose administrative
costs, such as the time needed to read
and interpret this final rule, we should
estimate the cost associated with
regulatory review. There are currently
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
288 organizations and 56 states and
territories. We assume each organization
will have one designated staff member
who will read the entire rule.
Using the wage information from the
BLS for medical and health service
managers (Code 11–9111), we estimate
that the cost of reviewing this rule is
$139.14 per hour, including overhead
and fringe benefits (https://www.bls.gov/
oes/current/naics5_524114.htm).
Assuming an average reading speed, we
estimate that it would take
approximately 6 hours for each person
to review this final rule. For each payer
that reviews the rule, the estimated cost
is $834.84 (6 hours × $139.14).
Therefore, we estimate that the total cost
of reviewing this regulation is $288,020
($834.84 × 345 reviewers).
1. Requirements for Patient Access
Through APIs
To promote our commitment to
interoperability, we are implementing
new requirements in section III. of this
final rule for MA organizations at 42
CFR 422.119, Medicaid FFS at 42 CFR
431.60, Medicaid managed care at 42
CFR 438.242, CHIP FFS at 42 CFR
457.730, CHIP managed care at 42 CFR
457.1233, and QHP issuers on the FFEs,
excluding QHP issuers offering only
SADPs or only FF–SHOP plans, at 45
CFR 156.221 to implement standardsbased APIs for making certain data
available to current enrollees. The
Patient Access API will permit thirdparty applications to retrieve data
concerning adjudicated claims,
encounters with capitated providers,
provider remittances, patient costsharing, a subset of clinical data
including lab test results, if maintained
by the payer, and, preferred drug lists,
and for MA–PD plans only, formulary
data that includes covered Part D drugs,
and any tiered formulary structure or
utilization management procedure,
which pertains to those drugs for MA–
PD plans.
At 42 CFR 422.120 for MA
organizations, at 42 CFR 431.70 for state
Medicaid agencies, at 42 CFR
438.242(b)(6) for Medicaid managed
care plans, at 42 CFR 457.760 for CHIP
state agencies, and at 42 CFR
457.1233(d)(3) for CHIP managed care
entities, we are finalizing the Provider
Directory API. We believe that these
policies are designed to empower
patients by requiring that impacted
payers take steps—by implementing the
two required APIs—to enable enrollees
to have access to their data in a usable
digital format and have (potentially)
easier means to share that data. By
making these data readily available and
portable to the patient, these initiatives
PO 00000
Frm 00114
Fmt 4701
Sfmt 4700
may help patients have the ability to
move from payer to payer, provider to
provider, and have both their clinical
and administrative information travel
with them throughout their health care
journey. Payers are in a unique position
to provide enrollees with a
comprehensive picture of their claims
and encounter data, allowing patients to
piece together their own information
that might otherwise be lost in disparate
systems. This information can
contribute to better informed decision
making, helping to inform the patient’s
choice of coverage options and care
providers to more effectively manage
their own health, care, and costs. By
encouraging them to take charge of and
better manage their health and having
access to their health information,
patients will have the ability to share
this information with their other
providers, which may reduce
duplication of services, add efficiency to
provider visits, and facilitate
identification of fraud, waste, and
abuse.
To estimate the number of impacted
payers, we reviewed parent
organizations of health plans across MA
organizations, Medicaid MCOs, and
QHP issuers on the FFEs to remove
organizations that would not be subject
to the policy, such as issuers that offer
only SADPs; transportation plans, and
brokers such as non-emergency medical
transportation (NEMTs) brokers; PACE;
visiting nurse and home health care
organizations; senior organizations such
as Area Agencies on Aging; and other
organizations such as community action
programs. After removing these
organizations, we then reviewed the
remaining names of parent
organizations and health plans in the
National Association of Insurance
Commissioners (NAIC) Consumer
Information Support (CIS) system to
determine the legal name of the entity
and whether the entity was registered
with the NAIC. We also used the 2018
NAIC Listing of Companies to determine
whether various health plans had
associated parent organizations using
the NAIC’s Group coding and
numbering system. If the health plan or
parent organization did not appear in
the NAIC CIS or in the 2018 NAIC
Listing of Companies, we then reviewed
the name of the entity in the Securities
and Exchange online Edgar system to
locate the entity’s Form 10–K filing,
which includes an Exhibit (Exhibit 21)
that requires the entity to list its
subsidiaries. If the health plan or
organization did not appear in these
online systems or listings, an online
internet search using Google search
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
engine was conducted. After review, we
have determined that 288 issuers and 56
states, territories, and U.S.
commonwealths, which operate FFS
programs, will be subject to the API
provisions for Medicare, Medicaid, and
QHP issuers on the FFEs. To this we
add the one state that operates its CHIP
and Medicaid separately. Thus, we have
a total of 345 parent organizations
(288+56+1). We note that although 42
states have some lower-income children
in an expansion of Medicaid, and some
higher-income children or pregnant
women in a separate CHIP, all but one
of these programs are operated out of
the same agency. Although the CHIP
programs may be distinct, we believe
they will use the same infrastructure
built for Medicaid. Thus, the addition of
1 parent organization for CHIP is
reasonable and plausible.
As noted in section XII.C.3. of this
final rule, to implement the Patient
Access API together with the payer-topayer data exchange policies to facilitate
a payer maintaining a cumulative health
record for their current enrollees, we
estimated that organizations and states
would conduct three major work
phases: Initial design; development and
testing; and long-term support of the
APIs, including increased data storage,
such as additional servers, or cloud
storage to store patient health
information and maintain it, and
allocation of resources to maintain the
FHIR server, and perform capability and
security testing. (For a detailed
description of these phases, see section
XII.C.3. of this final rule.)
As part of our research into the
regulatory impact, we reviewed a
sample of health plan organizations
offering MA plans to determine whether
any currently offer patient portal
functionality with the MA plan. If yes,
we reviewed whether they offered the
opportunity to connect to Medicare’s
Blue Button 2.0. Health plan
organizations offering MA plans were
identified from June 2018 data and
statistics compiled at https://
www.cms.gov/Research-Statistics-Dataand-Systems/Statistics-Trends-andReports/MCRAdvPartDEnrolData/
index.html. We initially reviewed the
functionality offered by three
organizations, which together enroll
over half of MA members through
review of publicly-available information
such as press releases and website
informational materials. We found from
this review that these organizations not
only offered patient portals primarily
focused on claims and user-entered data
on their website, but that all three also
offered enrollees the opportunity to
connect to Blue Button. We then
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
identified a selection of other health
plan organizations at random and
conducted the same evaluation. Results
indicate that the majority of the health
plan organizations we reviewed offer
patients a way to access claims data and
other information via their websites and
sometimes via applications.
We also cross-referenced health plan
organizations offering MA plans with
health plan organizations that offer
plans in the Federal Employees Health
Benefits (FEHB) Program because a
percentage of those organizations offer
plans with patient portal access and
Blue Button functionality. The FEHB
Program, administered by the Office of
Personnel Management (OPM), reported
in 2014 that 90 percent of its
participating plans offered enrollees
access to a personal health record on the
organization’s website. In addition,
OPM reported that over half of the
FEHB participating plans expected to
offer Blue Button functionality by
January 1, 2016. We sought to learn
whether there was any overlap between
these two lists of organizations to gauge
whether additional organizations may
already have the capability to offer
either patient portals or Blue Button,
albeit in a different business arm, as
having internal capability may assuage
some of the cost of building out a new
API to support patient access to claims
data. While we found significant
overlap between UnitedHealthcare and
the Blue Cross Blue Shield Affiliates, we
also were able to identify other
organizations that offer both MA plans
and plans included in the FEHB. While
not definitive, this data allows us to
draw the conclusion that a number of
health plan organizations have the
technology in place to offer patient
portals to MA enrollees and, further,
also have the ability to offer MA
enrollees Blue Button functionality.
As detailed in section XII. of this final
rule and summarized in Table 5, given
the current state of interoperability, we
estimate the burden related to the new
requirements for APIs to have an initial
set one-time costs of $788,414 per
implementation or an aggregate cost of
$272 million ($788,414 × 345 parent
organizations) minimum estimate; an
initial one-time cost of $1,576,829 per
organization or state or an aggregate cost
of $544 million ($1,576,829 × 345 parent
organizations) primary estimate; and, an
initial one-time cost of $2,365,243 per
organization or organization or an
aggregate $816 million ($2,365,243 ×
345 parent organizations) high estimate.
For a detailed discussion of the onetime costs associated with
implementing the API requirements we
refer readers to section XII.C.3. of this
PO 00000
Frm 00115
Fmt 4701
Sfmt 4700
25623
final rule. Once the API is established,
we believe that there will be an annual
cost for performing necessary capability
and security testing, performing
necessary upgrades, vetting of thirdparty applications, and maintaining
patient health information. We estimate
the burden related to the requirements
for APIs to have an annual cost of
$157,657 per implementation or an
aggregate cost of $54 million (345 parent
organizations × $157,657). For a detailed
discussion of the annual costs
associated with implementing the API
requirements, we refer readers to section
XII.C.3. of this final rule.
We are committed to fulfilling our
role in promoting interoperability,
putting patients first and ensuring they
have access to their health care data. We
recognize that there are significant
opportunities to modernize access to
patient data and its ability to share
across the health ecosystem. We realize
the importance of interoperability and
the capability for health information
systems and software applications to
communicate, exchange, and interpret
data in a usable and readable format.
Although allowing access to health care
data through pdf and text format is vital,
it limits the utility of the data, and its
ability to be easily accessed and shared.
Additionally, we realize that moving to
a system in which patients have access
to their health care data will ultimately
empower them to make informed
decisions about their health care. Our
policies here do not go as far as our
goals for how patients will be ultimately
empowered, but take steps in that
direction.
We note that the federal government
has spent over $35 billion under the
EHR Incentive Programs 82 to
incentivize the adoption of EHR
systems; however, despite the fact that
78 percent of physicians and 96 percent
of hospitals now use an EHR system,83
progress on system-wide data sharing
has been limited. Previous attempts to
advance interoperability have made
incremental progress but have failed to
align the necessary stakeholders to drive
momentum in a single direction. In
2018, the Administration launched the
82 Centers for Medicare and Medicaid Services.
(2018, May). EHR Incentive Program, Payment
Summary Report. Retrieved from https://
www.cms.gov/Regulations-and-Guidance/
Legislation/EHRIncentivePrograms/Downloads/
May2018_SummaryReport.pdf.
83 Office of the National Coordinator. (2015).
Health IT Dashboard—Office-based Physician
Health IT Adoption: State rates of physician EHR
adoption, health information exchange &
interoperability, and patient engagement. Retrieved
from https://dashboard.healthit.gov/apps/
physician-health-it-adoption.php.
E:\FR\FM\01MYR2.SGM
01MYR2
25624
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
MyHealthEData initiative.84 This
government-wide initiative aims to
empower patients by ensuring that they
have access to their own health care
data and the ability to decide how their
data will be used, while keeping that
information safe and secure.
MyHealthEData aims to break down the
barriers that prevent patients from
gaining electronic access to their health
care data and allow them to access that
data from the device or application of
their choice that will connect to a plan’s
API, empowering patients and taking a
critical step toward interoperability and
patient data exchange.
Payers should have the ability to
exchange data instantly with other
payers for care coordination or
transitions, and with providers to
facilitate more efficient care. Payers are
in a unique position to provide
enrollees a complete picture of their
claims and encounter data, allowing
patients to piece together their own
information that might otherwise be lost
in disparate systems. We are committed
to solving the issue of interoperability
and achieving complete patient access
in the U.S. health care system and are
taking an active approach using all
available policy levers and authorities
available to move all participants in the
health care market toward
interoperability and the secure exchange
of health care data. The modern internet
app economy thrives on a standardsbased API software environment. Part of
the health care API evolution is
incorporating many of the current
protocols from leading standards
development organizations with the
newer FHIR web developer-friendly way
of representing clinical data.
2. Increasing the Frequency of FederalState Data Exchanges for Dually Eligible
Individuals
We routinely exchange data with
states on who is enrolled in Medicare,
and which parties are liable for paying
that beneficiary’s Part A and B
premiums. These buy-in data exchanges
support state, CMS, and SSA premium
accounting, collections, and enrollment
functions. CMS subregulatory guidance,
specifically Chapter 3 of the State Buyin Manual, specifies that states should
exchange buy-in data with CMS at least
monthly, but provides the option for
states to exchange buy-in data with CMS
daily or weekly. Likewise, states can
84 Centers for Medicare and Medicaid Services.
(2018, May 6). Trump Administration Announces
MyHealthEData Initiative to Put Patients at the
Center of the US Healthcare System. Retrieved from
https://www.cms.gov/Newsroom/MediaRelease
Database/Press-releases/2018-Press-releases-items/
2018-03-06.html.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
choose to receive the CMS response data
on a file daily or monthly.
We are establishing the frequency
requirements in the regulation itself to
require all states to participate in daily
exchange of buy-in data to CMS, with
‘‘daily’’ meaning every business day, but
that if no new transactions are available
to transmit, data would not need to be
submitted on a given business day.
States will be required to begin
participating in daily exchange of buyin data with CMS by April 1, 2022.
To estimate impact, we first note that
there are a total of 51 entities, consisting
of the 50 states and the District of
Columbia that can be affected by buy-in.
Currently, 25 entities (24 states and the
District of Columbia) now submit buyin data files to CMS daily and 32
entities (31 states and the District of
Columbia) receive buy-in data files from
CMS daily. Consequently, we expect a
one-time burden for 26 states (51 total
entities minus 25 entities currently
submitting daily buy-in data) to comply
with the daily buy-in data submissions,
and a similar one-time burden for 19
states (51 total entities minus 32 entities
currently receiving buy-in data) to
comply with the receipt of daily buy-in
data.
These numbers changed from those in
the CMS Interoperability and Patient
Access proposed rule to reflect the most
current data available to CMS as of July
1, 2019. Between July 1 and publication
of the final rule it is likely that the
numbers may change more. However, as
can be seen from Table 5, this aspect of
the rule has minor impact (only a few
million dollars) compared with the
overall impact of the rule (several
hundred million). Consequently, we are
using these July 1 numbers in the final
rule.
We estimate that each required
change, whether to submit buy-in data
or receive buy-in data, would take 6
months of work (approximately 960
hours) by a programmer working at an
hourly rate of $90.02 per hour. Since
there are 45 required changes (19 states
that need to comply with receiving data
plus 26 states that need to comply with
submitting data) we estimate an
aggregate burden of $3,888,864 (45
changes * 960 hours of programming
work * $90.02/hour).
The cost per state per change is
approximately $85,000 (960 * $90.02 =
$86,419 exactly) and the costs for both
changes (to both send and receive buyin data daily would be approximately
$170,000 (2 * $85,000).
We did not estimate any savings
related to exchanging buy-in data with
greater frequency, as data lags only
delay when states are billed for
PO 00000
Frm 00116
Fmt 4701
Sfmt 4700
premium costs; delays do not impact the
applicability date and total costs. While
we did not estimate premium savings
(since premium collection is ultimately
correct), we anticipate that states may
experience longer term reduction in
administrative burden of making those
corrections.
As noted in section XII.C. of this final
rule, we are updating the frequency
requirements in 42 CFR 423.910(d) to
require that starting April 1, 2022, all
states submit the required MMA file
data to CMS daily, and to make
conforming edits to 42 CFR
423.910(b)(1). Daily would mean every
business day, but that if no new
transactions are available to transmit,
data would not need to be submitted on
a given business day. As noted in
section XII.C. of this final rule, the
estimated burden across impacted states
is $3,111,091.
Thus, the total burden to comply with
increased frequency of submission of
MMA files and increased frequency of
submission and receipt of daily buy-in
data files is $7 million ($3,888,864 total
cost for the buy-in provision plus
$3,111,091 total cost for the MMA file
requirements).
We estimate a 25-month
implementation period for these system
updates, from March 2020 to and
including March 2022. In the CMS
Interoperability and Patient Access
proposed rule, we assumed a 3-year
implementation period reflecting a May
1st start date and an April 1, 2022
applicability date. The revised 25month implementation period reflects
an expected publication of this final
rule in March 2020, with
implementation beginning March 2020,
and with the applicability date of April
1, 2022 unchanged. Although the
implementation period is shorter (25
months versus 36 months) the purpose
of the 25-month window is to give
organizations flexibility in finding a 6month period to perform updates as
indicated in section XII. of this final
rule. Although the flexibility window
for this 6-month period is shortened
(plans have less choice of which 6
months to work in), data are lacking
with which to refine the cost estimates
to reflect the shortened compliance
period.
States will have the ability to choose,
in consultation with CMS, when in the
25-month implementation period they
want to make this change, with
numerous factors impacting in which
year they would do so. For the purposes
of this impact analysis, we estimated a
uniform distribution beginning in
March 2020 and ending in April 2022 as
calculated in Table 5.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Therefore, since, as noted above, the
total cost impact over 25 months is $7
million, when apportioned uniformly
over the 25 months, the resulting
impacts $2.8, $3.4, and $0.8 million for
2020, 2021, and 2022 respectively
corresponding to 10 months, 12 months,
and 3 months in 2020, 2021 and 2022
respectively. These calculations are
transparently presented in Table 5.
3. Revisions to the Conditions of
Participation for Hospitals and Critical
Access Hospitals (CAHs)
We are expanding CMS’ requirements
for interoperability within the hospital
and CAH CoPs by focusing on electronic
patient event notifications. We are
implementing new requirements in
section X. of this final rule for hospitals
at 42 CFR 482.24(d), for psychiatric
hospitals at 42 CFR 482.61(f), and for
CAHs at 42 CFR 485.638(d).
Specifically, for hospitals, psychiatric
hospitals, and CAHs, we are finalizing
similar requirements to revise the CoPs
for Medicare- and Medicaidparticipating hospitals, psychiatric
hospitals, and CAHs by adding a new
standard, ‘‘Electronic Notifications,’’
that will require hospitals, psychiatric
hospitals, and CAHs to make electronic
patient event notifications available to
applicable post-acute care services
providers and suppliers, and to
community practitioners, such as the
patient’s established primary care
practitioner, established primary care
practice group or entity, or other
practitioner or practice group or entity
identified by the patient as primarily
responsible for his or her care. We are
limiting this requirement to only those
hospitals, psychiatric hospitals, and
CAHs that utilize electronic medical
records systems, or other electronic
administrative systems, which are
conformant with the content exchange
standard at 45 CFR 170.205(d)(2),
recognizing that not all Medicare- and
Medicaid-participating hospitals have
been eligible for past programs
promoting adoption of EHR systems. If
the hospital’s (or CAH’s) system
conforms to the content exchange
standard at 45 CFR 170.205(d)(2), the
hospital (or CAH) must then
demonstrate that its system’s
notification capacity is fully operational
and that it operates in accordance with
all state and federal statutes and
regulations regarding the exchange of
patient health information, and that its
system, to the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
the patient’s expressed privacy
preferences, sends the notifications
either directly, or through an
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
intermediary that facilitates exchange of
health information. It must also
demonstrate that the notifications
include at least patient name, treating
practitioner name, and sending
institution name.
Upon the patient’s registration in the
emergency department or admission to
inpatient services, and also either
immediately prior to, or at the time of,
the patient’s discharge or transfer (from
the emergency department or inpatient
services), the hospital (or CAH) must
also demonstrate that it has made a
reasonable effort to ensure that its
system sends the notifications to all
applicable post-acute care services
providers and suppliers, as well as to
any of the following practitioners and
entities, which need to receive
notification of the patient’s status for
treatment, care coordination, or quality
improvement purposes: (1) The patient’s
established primary care practitioner;
(2) the patient’s established primary
care practice group or entity; or (3) other
practitioner, or other practice group or
entity, identified by the patient as the
practitioner, or practice group or entity,
primarily responsible for his or her care.
As we noted, infrastructure
supporting the exchange of electronic
health information across settings has
matured substantially in recent years.
Research studies have increasingly
found that health information exchange
interventions can effectuate positive
outcomes in health care quality and
public health outcomes, in addition to
more longstanding findings around
reductions in utilization and costs.
Electronic patient event notifications
from hospitals, or clinical event
notifications, are one type of health
information exchange intervention that
has been increasingly recognized as an
effective and scalable tool for improving
care coordination across settings,
especially for patients at discharge. This
approach has been identified with a
reduction in readmissions following
implementation.85
In addition, the CMS Innovation
Center has been partnering with states
through the State Innovation Models
Initiative to advance multi-payer health
care payment and delivery system
reform models. Through this initiative
34 states have been awarded over $900
million to implement their respective
State Health Care Innovation Plans,
many of which included enhancements
85 Unruh, M. A., Jung, H., Kaushal, R., & Vest, J.
R. (2017). Hospitalization event notifications and
reductions in readmissions of Medicare fee-forservice beneficiaries in the Bronx, New York.
Journal of the American Medical Informatics
Association, 24(e1), e150–e156. doi: 10.1093/jamia/
ocw139.
PO 00000
Frm 00117
Fmt 4701
Sfmt 4700
25625
in HIT and HIE. While these models are
ongoing, evaluation reports thus far are
reporting that many states are
experiencing favorable outcomes on ED
visit rates and other quality measures.86
Although patient event notifications are
only a small piece of these models, we
want to continue the momentum
towards nationwide adoption.
These notifications are automated,
electronic communications from the
provider to applicable post-acute care
services providers and suppliers, and
also to community practitioners
identified by the patient. These
automated communications alert the
receiving provider or practitioner that
the patient has received care at a
different setting. Information included
with these notifications can range from
simply conveying the patient’s name,
basic demographic information, and the
sending institution, to a richer set of
clinical data depending upon the level
of technical implementation. Even with
a minimum set of information included,
these notifications can help ensure that
a receiving provider or community
practitioner is aware that the patient has
received care elsewhere. The
notification triggers a receiving provider
or practitioner to reach out to the
patient to deliver appropriate follow-up
care in a timely manner. By providing
timely notifications, the alert may
improve post-discharge transitions and
reduce the likelihood of complications
resulting from inadequate follow-up
care.
We believe that care coordination can
have a significant positive impact on the
quality of life, consumer experience,
and health outcomes for patients. As we
have noted in the preamble to this rule,
virtually all EHR systems (as well as
older legacy electronic administrative
systems, such as electronic patient
registrations systems, and which we are
including in this final rule) generate the
basic messages commonly used to
support electronic patient event
notifications. In addition, while we
acknowledge that some level of
implementation cost would be realized
for those providers not already sending
notifications, we also note there is also
substantial agreement that
implementation of these basic
messaging and notification functions
within such existing systems constitutes
a relatively low cost burden for
providers, particularly when such costs
are considered alongside the innovative
and beneficial patient care transition
86 Centers for Medicare and Medicaid Services.
(2019, December 6). State Innovation Models
Initiative: General Information. Retrieved from
https://innovation.cms.gov/initiatives/StateInnovations/.
E:\FR\FM\01MYR2.SGM
01MYR2
25626
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
solutions and models for best practices
they provide.
As detailed in section XI., we estimate
that the total cost imposed on hospitals,
psychiatric hospitals, and CAHs by
these provisions to be approximately
$5,179,863 in the first year and
$1,042,426 in subsequent years.
4. Effects of Other Policy Changes
In addition to those policy changes
discussed previously that we are able to
model, we are finalizing various other
changes in this final rule. Generally, we
have limited or no specific data
available with which to estimate the
impacts of the policy changes. Our
estimates of the likely impacts
associated with these other changes are
discussed in this section.
a. Care Coordination Across Payers
The majority of the 64 million people
on Medicare are covered by FFS,
however, about 34 percent are covered
in MA plans. Since 2003, the number of
beneficiaries enrolled in MA plans has
increased fivefold from 4.6 million in
2010 to 22 million in 2019.87 Given the
growth in MA enrollment and the
ability for MA beneficiaries to change
plans, we believe it is important to
supporting efficient care coordination
by requiring the sharing of key patient
health information when an enrollee
requests it. Therefore, we are requiring
MA organizations, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs to
maintain a process for the electronic
exchange of, at a minimum, the data
classes and elements included in the
content standard finalized by HHS in
the ONC 21st Century Cures Act final
rule (published elsewhere in this issue
of the Federal Register) at 45 CFR
170.213 (currently version 1 of the
USCDI), via a payer-to-payer data
exchanged as outlined in this section V.
of this final rule. Furthermore, we are
finalizing as proposed a regulatory
requirement at 42 CFR 422.119(f)(1) and
438.62(b)(1)(vi), and at 45 CFR
156.221(f)(1) to require MA
organizations, Medicaid managed care
plans, CHIP managed care entities, and
QHP issuers on the FFEs to incorporate
the data they receive into the payer’s
record about the enrollee. We are also
finalizing that with the approval and at
the direction of an enrollee, a payer
must send the defined information set to
any other payer. We specify that a payer
87 Medicare Payment Advisory Commission.
(2019, July 19). A Data Book: Health Care Spending
and the Medicare Program—June 2019. Retrieved
from https://www.medpac.gov/docs/default-source/
data-book/jun19_databook_entirereport_
sec.pdf?sfvrsn=0.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
is only obligated to send data received
from another payer under this policy in
the electronic form and format it was
received. However, we have noted that
such transactions will need to be made
in compliance with any other applicable
laws.
We believe that sending and receiving
these data will help both plan enrollees
and health care providers in
coordinating care and reducing
administrative burden. We believe that
this entails utilizing all tools available
to us to ensure that plans provide
coordinated high-quality care in an
efficient and cost-effective way that
protects program integrity. Leveraging
interoperability to facilitate care
coordination among plans can, with
thoughtful execution, significantly
reduce unnecessary care, as well as
ensure that health care providers are
able to spend their time providing care
rather than performing unnecessary
administrative tasks. For instance,
effective information exchange between
plans could improve care coordination
by reducing the need for health care
providers to write unneeded letters of
medical necessity; by reducing
instances of inappropriate step therapy;
and by reducing repeated utilization
reviews, risk screenings, and
assessments.
We believe that this policy will
impose minimal additional costs on
plans. We note that we are not
specifying a transport standard and
anticipate that plans may opt to use
APIs, such as the Patient Access API
that this final rule also requires. We also
anticipate that plans may choose to
utilize a regional health information
exchange. We believe it is difficult to
quantify the impact of this change
because plans will likely implement
different transport methods, and we
cannot predict the selected method
plans will choose.
b. Care Coordination Through Trusted
Exchange Networks
In section VI. of the CMS
Interoperability and Patient Access
proposed rule, we proposed requiring
MA organization, Medicaid managed
care plans, CHIP managed care entities,
and QHP issuers on the FFEs to
participate in trust networks in order to
improve interoperability. We also listed
the requirements for participation in a
trusted exchange network.
As a result of comments and reexamination of our desired policies, we
have decided not to finalize this
provision. However, as pointed out in
the proposed rule, had this provision
been finalized, it would impose
minimal additional costs on plans.
PO 00000
Frm 00118
Fmt 4701
Sfmt 4700
Consequently, not finalizing this policy
does not impact this RIA.
5. Non-Mandatory Effects and
Regulatory Interaction
We note in this RIA when we had
difficulty quantifying costs due to lack
of applicable research or data. More
specifically, the establishment of a
health care information ecosystem could
only be achieved with new actions that
are conducted widely throughout the
health care field—including by entities,
especially non-hospital providers, for
whom costs have not been estimated in
either this RIA or the RIA for the
accompanying ONC 21st Century Cures
Act final rule (published elsewhere in
this issue of the Federal Register).
Although data limitations have
prevented the quantification of these
costs, the benefits of the two rules—
some of which have been quantified in
the ONC RIA—and the rules’ potential
transfer impacts—including reductions
in fraudulent payments, as discussed by
Parente et al. (2008) 88—are largely
contingent upon such costs being
incurred. Additionally, there are
ongoing regulatory and policy activities
outside of this final rule that might
influence the rule’s impact in an
unquantifiable manner. When possible,
we acknowledge these complexities as
well.
D. Alternatives Considered
In March 2018, the White House
Office of American Innovation and the
CMS Administrator announced the
launch of MyHealthEData, and CMS’s
direct, hands-on role in improving
patient access and advancing
interoperability. As part of the
MyHealthEData initiative, we are taking
a patient-centered approach to health
information access and moving to a
system in which patients have
immediate access to their electronic
health information and can be assured
that their health information will follow
them as they move throughout the
health care system from provider to
provider, payer to payer. This final rule
contains a range of policies. It provides
descriptions of the statutory provisions
that are addressed, identifies the
policies, and presents rationales for our
decisions and, where relevant,
alternatives that were considered. We
carefully considered alternatives to the
policies we are adopting in this final
rule but concluded that none of the
88 Parente, Stephen T., Karen Mandelbaum, Susan
P. Hanson, Bonnie S. Cassidy and Donald W.
Simborg. ‘‘Crime and Punishment: Can the NHIN
Reduce the Cost of Healthcare Fraud?’’ Journal of
Healthcare Information Management 22(3): 42–51.
June 2008.
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
alternatives would adequately and
immediately begin to address the
critical issues of the lack of patient
access and interoperability, or the
difficulty exchanging health care data
within the health care system.
As we noted in the CMS
Interoperability and Patient Access
proposed rule, we believe the following
three attributes of standards-based APIs
are particularly important to achieving
the goal of offering individuals
convenient access, through applications
they choose, to available and relevant
electronic health and health-related
information: the API technologies
themselves, not just the data accessible
through them, are standardized; the
APIs are technically transparent; and
the APIs are implemented in a procompetitive manner (84 FR 7620). The
API requirements proposed and
finalized in this rule were developed to
ensure these goals are met.
Some of the reasons that we selected
the FHIR standard were due to the
flexibility it provides and the wide
industry adoption that it offers. The
open and extensible nature of FHIR
allows for health care integration to be
transparent and accessible. FHIR is open
source, and as such, it has garnered a
community that includes developers
and vendors. For example, large
consumer brands are becoming a driving
force behind the adoption of FHIR.
Apple is implementing FHIR in Apple
Health as part of iOS 11.3, and serves as
a member of the Argonaut Project and
CARIN Alliance—two HL7 FHIR
Accelerators; 89 Google supports FHIR
by partnering with HL7, as well as
through its membership in the CARIN
Alliance; and Microsoft published an
Azure API for FHIR to create and deploy
FHIR service health data solutions.90
Furthermore, according to an ONC
report, nearly 51 percent of health IT
developers appear to be using a version
of FHIR combined with OAuth 2.0 to
respond to requests for patient data.
Additionally, of the hospitals and Meritbased Incentive Payment System (MIPS)
eligible clinicians that use certified
89 The HL7 FHIR Accelerator Program is designed
to assist communities and collaborative groups
across the global health care spectrum in the
creation and adoption of high quality FHIR
Implementation Guides or other standard artifacts
to move toward the realization of global health data
interoperability. For further details, see https://
www.hl7.org/about/fhir-accelerator/.
90 Shrestha, R., Mohan, S., & Grieve, G. (2018,
February 14). State of the Healthcare API Economy
(An Innovation Forum Session: Session 217).
Retrieved from https://365.himss.org/sites/
himss365/files/365/handouts/552739129/handout219_FINAL.pdf. See also https://
azure.microsoft.com/en-us/services/azure-api-forfhir/ and https://www.apple.com/healthcare/healthrecords/.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
products, almost 87 percent of hospitals
and 69 percent of MIPS eligible
clinicians are served by health IT
developers with product(s) certified to
any FHIR version.91
For additional ways to allow
consumers access to their health data,
we note that we did receive comments
that CMS could consider allowing
payers and providers to upload patient
data directly to a patient portal that is
owned and managed by the patient. One
option would allow for HIEs and HINs
to serve as a central source for patients
to obtain aggregated data in a single
location. While HIEs and HINs can
provide patients with valuable
information via a portal, research has
indicated that portals have not gained
widespread use by patients. According
to ONC, as of 2017, 52 percent of
individuals have been offered online
access to their medical records by a
health provider or payer. Of the 52
percent that were offered access, only
half of those viewed their record.92
Additionally, we believe that there
would be additional burden associated
with using portals because providers
and patients would need to access
multiple portals and websites to access
patient data, instead of a single app.
Unlike portals that would require
developers to link systems or ensure
system-level compatibility, FHIR-based
APIs have the ability to make data
available without the need to link
multiple systems or portals and would
provide a patient a single-point of
access to their data. Having APIs that
can be accessed by third-party apps
permits the patient to choose how they
want to access their data, and it
promotes innovation in industry to find
ways to best help patients interact with
their data in a way that is most
meaningful and helpful to them.
Additionally, we believe it would be
very difficult to evaluate the cost
impacts of making individual portals
available via an HIE or HIN because
business models and process are varied,
and there is a lack of standardization in
the way the information is stored and
transmitted across HIEs and HINs.
Other alternatives that we considered
were how broadly or narrowly to apply
the policies and requirements. For
example, we could have required health
91 Posnack, S. & Baker, W. (2018, October 1). Heat
Wave: The U.S. is Poised to Catch FHIR in 2019.
Retrieved from https://www.healthit.gov/buzz-blog/
interoperability/heat-wave-the-u-s-is-poised-tocatch-fhir-in-2019.
92 Patel, V. & Johnson, C. (2018, April).
Individuals’ Use of Online Medical Records and
Technology for Health Needs (ONC Data Brief No.
40). Retrieved from https://www.healthit.gov/sites/
default/files/page/2018-03/HINTS-2017-ConsumerData-Brief-3.21.18.pdf.
PO 00000
Frm 00119
Fmt 4701
Sfmt 4700
25627
plans to provide more data elements via
a standards-based API then just data for
adjudicated claims, encounters with
capitated providers, provider
remittances, beneficiary cost-sharing,
clinical data including laboratory
results, provider directories (and
pharmacy directories for MA–PDs), and
preferred drug lists, where applicable.
In the CMS Interoperability proposed
rule, we originally required MA
organizations, state Medicaid FFS
programs, Medicaid managed care
plans, CHIP FFS programs, and CHIP
managed care entities to make available
provider directory data through the
Patient Access API (84 FR 7633) and
publicly available to current and
prospective enrollees (84 FR 7639).
After consideration of public comments,
we have removed the requirements that
these impacted payers make provider
directory information available through
the Patient Access API. MA
organizations, state Medicaid FFS
programs, Medicaid managed care
plans, CHIP FFS programs, and CHIP
managed care entities will only need to
make provider directory information
available via a publicly accessible
Provider Directory API. We note the
Provider Directory API does not need to
conform to the security protocols
finalized by HHS at 45 CFR
170.215(a)(3) and (b) that are specific to
authenticating users and confirming
individuals’ authorization or request to
disclose their personal information to a
specific application through an API,
namely the SMART IG (using the OAuth
2.0 standard) and OpenID Connect Core
1.0. By only requiring the Provider
Directory API make these otherwise
publicly accessible data available, we
are seeking to avoid duplicative effort
and additional burden.
Additionally, several commenters
suggested additional information be
added to the requirement for provider
directory information to be available
through an API, such as NPIs for
individual and group providers, practice
group name, health system name, as
well as the specific plan(s) and tiers a
provider participates in ‘‘provider
demographics;’’ whether the provider is
accepting new patients; and information
about which providers are in-network
for a plan by geography and/or
specialty. While we agreed with
commenters that this information would
be helpful to patients, we did not
modify the proposed requirements for
the information that is required to be
made available by the Provider
Directory API because we believe
additional data would be a cost driver.
By not adding additional required
E:\FR\FM\01MYR2.SGM
01MYR2
25628
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
information we are seeking to minimize
the burden for the regulated payers that
must comply with this policy. Instead
we are identifying a minimum set of
provider directory information that
aligns with existing requirements
applicable to MA organizations
(including MA organizations that offer
MA–PD plans), state Medicaid and CHIP
FFS programs, Medicaid managed care
plans, and CHIP managed care entities
that beneficiaries can currently access.
We also looked at policy alternatives
related to specific aspects of the API
requirements. For instance, we
considered whether to modify the
requirement to make claims and
encounter data, as well as clinical data,
available through the Patient Access API
no later than one (1) business day after
a payer receives it. We reviewed several
suggested alternatives such as
increasing the timeframe to three (3) or
five (5) business days to account for
vendor-adjudicated claims. While we
considered these alternatives, we
ultimately decided not to adjust the
proposed requirements because having
access to this information within one (1)
business day could empower patients to
have the information they need, when
they need it to inform care coordination.
Patients have a right to see the full
lifecycle of their claims and encounter
information as soon as it is available,
even if the payment amounts may
change due to appeal. Additionally, as
we noted in section XII. of this final
rule, the burden related to API
requirements is in the initial
implementation of the system to make
this information available in one (1)
business day once received. This
requirement is being implemented in
the design and build phase and the
system update cost for electronic
availability would be the same
regardless of the number of days the
system is set up to accommodate. There
is also no data on whether providing
three (3) or five (5) days, versus one (1)
day, will provide patients with more
complete or accurate data.
As an alternative, we considered
requiring all QHP issuers on all
Exchanges to meet the new API
requirements as part of QHP
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
certification. Consistent with some other
QHP certification requirements, we
opted not to require SBEs to include this
as part of their certification
requirements, but we strongly urge them
to do so to ensure equitable treatment of
issuers nationally and to allow
consumers to access their health
information through a third-party
application no matter where they are
insured across the country. States are
the most knowledgeable about their
consumers and insurance markets and
are responsible for issuer compliance
activities. While we believe that these
API requirements have the potential to
provide great benefit to consumers,
complying with them will be mainly
operational and SBE states would be
required to assess QHP issuer
compliance. Therefore, we believe that
SBE states should be given the
flexibility to determine whether or not
these requirements are required of their
QHP issuers.
An additional alternative that we
considered was based off one
commenter’s suggestion to incentivize
plans who meet the required
implementation dates through higher
Healthcare Effectiveness Data and
Information Set (HEDIS) scores.
Although the commenter was not clear
regarding a specific recommendation as
to how to implement changes to the
HEDIS score, we evaluated options such
as adding a new measure specific to
data exchange using HL7 FHIR-based
APIs between payers and third-parties
on the behalf of patients, or adding
bonus points to the total score or some
appropriate measure set for
implementing the FHIR-based APIs
required. However, after further
evaluation, we believe that this is not a
viable alternative at this time. CMS
cannot give a higher HEDIS score for
using a digital specification because it
would not be an accurate measure of
plan performance. To consider adding a
bonus to the highest rating if the plan
meets certain standards would
necessitate requiring a new adjustment
to the star rating methodology. This
would be a significant change to how
the current star ratings are calculated
and would have to be proposed through
PO 00000
Frm 00120
Fmt 4701
Sfmt 4700
notice and comment rulemaking. Given
the implementation date for the API
provisions for MA organizations,
Medicaid FFS programs, Medicaid
managed care plans, CHIP FFS
programs, and CHIP managed care
entities is January 1, 2021, and for QHP
issuers on the FFEs beginning with plan
years beginning on or after January 1,
2021, implementing changes to the star
ratings would not be achievable within
the available timeframe to incentivize
implementation as the commenter
suggested.
As we recognize that advancing
interoperability is no small or simple
matter, we continue to explore
alternatives and potential future
policies. In the CMS Interoperability
and Patient Access proposed rule, we
requested comment for consideration in
future rulemaking or subregulatory
guidance on a number of alternatives
related to whether additional policies or
requirements, beyond those proposed,
should be imposed to promote
interoperability. For example, the CMS
Innovation Center sought comment on
general principles around promoting
interoperability as part of the design and
testing of innovative payment and
service delivery models. Additionally,
we sought comment on how we may
leverage our program authority to
provide support to those working on
improving patient matching. For
example, we requested comment on
whether CMS should require impacted
payers use a particular patient matching
software solution with a proven success
rate of a certain percentage validated by
HHS or a third party. We also noted that
we will continue to consider feedback
received from RFIs issued in various
rules over the course of the past 2 years
and incorporate those suggestions into
our strategy. We thank commenters for
their input on these RFIs. We will
consider the comments received for
potential future rulemaking.
E. Accounting Statement and Table
In accordance with OMB Circular A–
4, Table 14 depicts an accounting
statement summarizing the assessment
of the benefits, costs, and transfers
associated with this regulatory action.
E:\FR\FM\01MYR2.SGM
01MYR2
25629
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 14—ACCOUNTING STATEMENT
Units
Primary
estimate
Category
Year dollars
Discount rate
(percent)
Period
covered
Benefits
Qualitative ........................................................................................................
• API requirements will alleviative the burden for patients to go
through separate processes to obtain access to each system,
and the need to manually aggregate information that is delivered
in various, often non-standardized, formats (not necessarily additional to the benefits assessed in the RIA for the accompanying ONC 21st Century Cures Act final rule, (published elsewhere in this issue of the Federal Register)).
• API requirement allows for the administration of a more efficient
and effective Medicaid program by taking advantage of commonly used methods of information sharing and data standardization.
• API requirements would help to create a health care information
ecosystem that allows and encourages the health care market
to tailor products and services to compete for patients, thereby
increasing quality, decreasing costs, providing potential benefits
(not necessarily additional to the benefits assessed in the RIA
for the accompanying ONC final rule), and helping them live better, healthier lives.
• Privacy and security policies are being implemented that permit
payers to request third-party apps to attest to privacy and security provisions prior to providing the app access to the payer’s
API.
Costs
Annualized Monetized $ millions/year (low estimate) .....................................
Annualized Monetized $ millions/year (primary estimate) ...............................
Annualized Monetized $ millions/year (high estimate) ....................................
85.2
80.8
122.0
112.4
158.8
144.0
2019
2019
2019
2019
2019
2019
7
3
7
3
7
3
2020–2029
2020–2029
2020–2029
2020–2029
2020–2029
2020–2029
Non-Quantified Costs: Non-hospital provider costs associated with development of a broad health care information ecosystem (regulatory benefits and fraud reduction are largely contingent upon these non-mandatory costs being incurred).
Transfers from the Federal Government to Enrollees of Commercial Plans (PTC)
Annualized Monetized $ millions .....................................................................
Annualized Monetized $ millions .....................................................................
5.4
5.5
2019
2018
7
3
2020–2029
2020–2029
Non-Quantified Transfers: Reduced fraudulent payments to providers from the federal government and other payers.
The preceding discussion was an
actual cost impact (not a transfer) since
goods and computer services are being
paid for. Plans have the option of
transferring their expenses to enrollees.
In practice, because of market
competitive forces a plan may decide to
operate at a (partial) loss and not
transfer the entire cost. It is important
to estimate the maximum the transfer
could be. Some costs are transferred to
the states (for Medicaid and CHIP) and
ultimately to the federal government (for
Medicare, Medicaid, and CHIP, and
potentially for QHP issuers on the FFEs
in the form of higher PTCs)), mitigating
the amount transferred to enrollees. One
approach to estimate impact on
enrollees was made in section XII.B. of
this RIA. However, this analysis did not
take into account transfers.
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
We now re-estimate the potential full
transfer. As noted in Tables 5 through
10, we have in 2021 through 2029 under
a dollar increase in premiums as the
worst-case scenario, and we used actual
costs per year. In this alternate analysis,
we use actual amounts for each of 2021
through 2029 with the initial 1-year cost
amortized over 9 years. In other words,
we assume an aggregate annual cost of
$84.6 million ($272 million/9 + $54.4
million), this is based on the low
estimate 1st year cost of $272 million.
If we use the high estimate cost $816
million we obtain $145 million average
($816 million/9 + $54.4 million).
We note that this premium increase
could be counterbalanced by projected
savings arising from the provisions in
this final rule. More specifically, we
expect the availability of portable
PO 00000
Frm 00121
Fmt 4701
Sfmt 4700
electronic transfer of medical data
proposed by this rule will help patients
have the ability to move from payer to
payer, provider to provider, and have
both their clinical and administrative
information travel with them
throughout their health care journey.
Allowing patients to piece together their
own information that might otherwise
be lost in disparate systems could help
make better informed patients and may
lead to increase prevention of future
medical illnesses due to improvements
in care coordination due to better data
accessibility. The savings from avoiding
one illness or one cheaper procedure
would offset the under one-dollar
impact. However, we have no way, at
this point, of estimating this aspect of
the future savings of the rule.
E:\FR\FM\01MYR2.SGM
01MYR2
25630
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
We present two estimates. First, we
estimate using the enrollment figures
used in Table 9 of this RIA. Table 9
shows that we have 110.5 million
enrollees (17.5+73+20) in programs that
will be spending about $84.6 million
per year. Ignoring federal subsidies, and
assuming that all costs will be passed on
to enrollees (which is contrary to our
experience), the 110.5 million enrollees
would each incur an extra 77 cents per
enrollee ($84.6 million/110.5 million) a
year to achieve the $84.6 million goal.
This is the low estimate cost. The
corresponding high estimate cost would
be $1.31 per enrollee per year ($145
million/110.5 million). We next
estimate using premium versus
enrollment as was done in section XII.B.
of this RIA.
Prior to discussing potential transfers
to enrollees, we discuss how this final
rule may affect patients not covered by
plans subject to this rule. It is both
possible and likely that an organization
offering a plan subject to this rule may
also offer plans not subject to this rule,
and comply with the requirements of
this rule for all of its plans, including
those not subject to this rule.
Consequently, it is possible that to cover
the cost of complying with this rule for
plans that are subject to this rule and
plans that are not subject to this rule,
organizations may raise premiums for
their plans that are subject to this rule
and their plans that are not subject to
this rule. It is possible (and we contend
likely) that this final rule will affect
enrollees in individual market plans
other than QHPs on the FFEs, even
though there is no requirement for such
coverage to comply with this rule.
Therefore, we calculate the cost impact
per enrollee should organizations
offering plans not subject to this rule
choose to comply with this rule with
regard to those plans. The rest of the
discussion below explores this
possibility.
QHP issuers on the FFEs: Rebates are
required under section 2718(b)(1)(A) of
the PHSA and the implementing
regulations at 45 CFR part 158 when an
issuer does not meet the applicable
threshold. The commercial market MLR
is generally calculated as the percent of
each dollar of after-tax premium
revenue spent by the issuer on
reimbursement for clinical services, and
activities that improve the quality of
health care. If the issuer’s MLR for a
state market is below the applicable
threshold, then the issuer must return
the difference to policyholders. It
follows, that if costs of complying with
this rule raise plan costs, and if
additionally, the issuers pass on the full
cost in the form of premium and/or are
able to treat these costs as QIAs, then
premiums and rebates will change. The
following two highly simplified
examples are illustrative.
Suppose the MLR threshold is 80
percent (in practice it can vary by state
market), but the issuer’s MLR is below
the threshold at 70 percent. Then, the
issuer would have to return the 10
percent as a rebate. If the costs of
complying with this rule for an issuer
are on average 6 percent of premium
and the issuer treats these expenses as
QIA, the issuer will now have to rebate
only 4 percent instead of 10 percent
(that is, the issuer’s MLR would be 76
percent rather than 70 percent).
Similarly, if both the applicable
threshold and issuer MLR are 80
percent, then the issuer would not owe
a rebate.
There are two effects of recognizing
these costs as QIA: (1) For issuers
subject to this rule who are below the
applicable MLR threshold, the rebate
from issuers to policyholders would go
down by some amount between $0 and
the cost of complying with this rule; and
(2) for issuers subject to this rule who
are at or above the MLR standards, the
premium transfers from enrollees to
issuers will go up by some amount
between $0 and the cost of complying
with this rule. We note that both MLR
and rebates are calculated by combining
all of an issuer’s business (on- and offExchange) within a state and market.
To estimate these amounts, we used
the public use 2016 MLR files on the
CMS website that were used for Tables
6 through 9 of this RIA. The total
reported 2016 premium revenue on the
commercial side for individual market
plans was approximately $77 billion
(See Table 7). Of the $77 billion, the
total reported 2016 premium revenue of
issuers that were below the commercial
MLR standard (80 or 85 percent,
depending on the market) was
approximately $4 billion.
As mentioned earlier, to proceed
further we use the estimates of the costs
of complying with this rule, which are
$84.6 million per year. This cost is for
all parent organizations with each
parent organization possibly dealing
with up to four lines of business subject
to MLR requirements and the
requirements of this rule: MA (including
Part D sponsors); Medicaid; CHIP; and
QHP issuers on the FFEs. Thus, of the
$84.6 million level annual cost of
complying with this rule, we estimate
$18.8 million (22.19 percent commercial
proportion * $84.6 million level annual
cost complying with this rule) to be the
cost for individual market plans.
In estimating the transfers to
policyholders in individual market
plans, we must distinguish between the
$4 billion of premium revenues of
issuers whose MLR was below the
applicable threshold and the $73 billion
of premium revenues ($77 billion total
revenue for individual market plans– $4
billion) of individual market issuers
whose MLR was at or above the
applicable threshold. We can now
calculate the estimated aggregate
transfer in the commercial health
insurance market from individual
market policyholders to issuers whether
through premium or rebates as follows:
• Percentage cost of complying with
this rule = 0.0244 percent of revenue
premium ($18.8 million cost/$77 billion
total revenue).
• Reduced MLR rebates = $1 million
(0.0244 percent × $4 billion premium
from issuers below the applicable MLR
threshold).
• Increased premiums = Up to $17.8
million (0.0244 percent × ($77 billion
total revenue¥$4 billion premium from
issuers below the applicable MLR
threshold)).
• Total transfer from enrollees = Up
to $418.8 million ($17.8 million
increased premium + $1 million
reduced rebate).
• Transfer per enrollee = $1.07
($418.8 million/17.5 million
commercial health insurance enrollees).
We note that the $1.07 (under a dollar
per enrollee) is consistent with the
results obtained in Tables 6 through 10
(with exact raw amounts by year
without amortization of a large first year
expense). These calculations are
summarized in Table 15. The $1.07 is
the low estimate of first year costs. The
high estimate $1.85 per enrollee per
year is obtained by replacing the low
estimate cost of $272 million with $816
million.
TABLE 15—TRANSFERS TO ENROLLEE RESULTING FROM THE FINAL RULE
Label
Item
(A) ..................
First year cost of interoperability (Low estimate) ...................
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
PO 00000
Amount
Frm 00122
Fmt 4701
Sfmt 4700
272.0
Source
Estimated in this proposed
rule.
E:\FR\FM\01MYR2.SGM
01MYR2
Comments
In millions.
25631
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 15—TRANSFERS TO ENROLLEE RESULTING FROM THE FINAL RULE—Continued
Label
Item
Amount
Source
(B) ..................
(C) ..................
First year cost amortized over 9 years ..................................
Continuation year cost of interoperability ...............................
30.2
54.4
(D) ..................
Level interoperability cost per year ........................................
84.6
Comments
(A) / 9 .....................................
Estimated in this proposed
rule.
(B) + (C) .................................
In millions.
In millions.
347
Table 7 ...................................
In billions.
77
22.19% ...................................
Table 7.
157
45.24% ...................................
Table 7.
113
32.56% ...................................
Table 7.
In millions.
Commercial Percent of Premium Revenues
(E) ..................
(F) ..................
(G) ..................
(H) ..................
Total premium revenues in Individual market, Medicaid and
Medicare.
Individual market plans premium revenues (dollar amount
and percent).
Medicare Advantage premium revenues (Dollar amount and
percent).
Medicaid premium revenues (Dollar amount and percent) ...
Annual interoperability cost as a percent of commercial individual market health insurance premium revenues
(I) ....................
(J) ...................
(K) ..................
(L) ...................
Annual Level interoperability cost ..........................................
Percent of total individual market plans revenues .................
Interoperability cost for individual market plans .....................
Commercial premium revenues for individual market plans ..
84.6
22.19%
18.8
77,000
(M) ..................
Interoperability cost as a percent of total commercial revenue for individual market plans.
0.0244%
(D) ..........................................
(F).
(I) × (J) ...................................
(E) ..........................................
In millions.
In millions.
2016 data in
millions.
(K) / (L).
Individual market plans revenue broken out by whether above or below MLR threshold (requiring rebate)
(N) ..................
(O) ..................
(P) ..................
Total individual market plan revenue .....................................
Revenues of individual market health plans whose MLR is
below regulatory threshold.
Revenues of individual market plans whose MLR is below
regulatory threshold.
77,000
4,037
72,963
(E) ..........................................
2016 CMS MLR Data in millions.
(N)¥(O) .................................
In millions.
In millions.
In millions.
Transfer to enrollee per enrollee from decreased rebates and increased premium
(Q) ..................
(T) ..................
Reduction in rebates from interoperability in those plans
paying rebates.
Premium increase from interoperability in those plans not
paying rebates.
Total increase to commercial individual market plans enrollees from interoperability.
Number commercial enrollees in individual market plans .....
(U) ..................
(V) ..................
Dollar increase in premium per enrollee (Low estimate) .......
Dollar increase in premium per enrollee (Medium Estimate)
$1.07
$1.46
(W) .................
Dollar increase in premium per enrollee (High Estimate) ......
$1.84
(R) ..................
(S) ..................
1.0
(N) × (P).
18.8
(Q) + (R) ................................
In millions.
17.5
From 2016 MLR files, in millions.
(S) / (T).
Obtained by replacing 272
million in row (A) with $544
million.
Obtained by replacing 272
million in row (A) with $816
million.
In millions.
on the estimated costs of this final rule
can be found in the preceding analysis.
Executive Order 13771, titled
Reducing Regulation and Controlling
Regulatory Costs, was issued on January
30, 2017 and requires that the costs
associated with significant new
regulations ‘‘shall, to the extent
permitted by law, be offset by the
elimination of existing costs associated
with at least two prior regulations.’’
This final rule is considered an E.O.
13771 regulatory action. We estimate
that this rule generates $77.8 million in
annualized costs, discounted at 7
percent relative to year 2016, over an
infinite time horizon estimate. Details
G. Conclusion
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
The analysis above, together with the
preceding preamble, provides an RIA.
In accordance with the provisions of
Executive Order 12866, this regulation
was reviewed by the Office of
Management and Budget.
List of Subjects
42 CFR Part 406
Health facilities, Diseases, Medicare.
42 CFR Part 422
Administrative practice and
procedure, Health facilities, Health
maintenance organizations (HMO),
Medicare, Penalties, Privacy, Reporting
and recordkeeping requirements.
42 CFR Part 423
Administrative practice and
procedure, Emergency medical services,
Health facilities, Health maintenance
organizations (HMO), Medicare,
Penalties, Privacy, Reporting and
recordkeeping requirements.
Medicare.
PO 00000
Frm 00123
Fmt 4701
Sfmt 4700
In millions.
17.8
F. Regulatory Reform Analysis Under
E.O. 13771
42 CFR Part 407
(N) × (O) .................................
E:\FR\FM\01MYR2.SGM
01MYR2
25632
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
42 CFR Part 431
Grant programs—health, Health
facilities, Medicaid, Privacy, Reporting
and recordkeeping requirements.
42 CFR Part 438
Grant programs—health, Medicaid,
Reporting and recordkeeping
requirements.
PART 407—SUPPLEMENTARY
MEDICAL INSURANCE (SMI)
ENROLLMENT AND ENTITLEMENT
42 CFR Part 457
Administrative practice and
procedure, Grant programs—health,
Health insurance, Reporting and
recordkeeping requirements.
3. The authority citation for part 407
is revised to read as follows:
■
Authority: 42 U.S.C 1302 and 1395hh.
4. Section 407.40 is amended by
adding paragraph (c)(4) to read as
follows:
■
42 CFR Part 482
Grant programs—health, Hospitals,
Medicaid, Medicare, Reporting and
recordkeeping requirements.
§ 407.40 Enrollment under a State buy-in
agreement.
42 CFR Part 485
Grant programs—health, Health
facilities, Medicaid, Privacy, Reporting
and recordkeeping requirements.
45 CFR Part 156
Administrative practice and
procedure, Advertising, Advisory
committees, Brokers, Conflict of
interests, Consumer protection, Grant
programs—health, Grants
administration, Health care, Health
insurance, Health maintenance
organization (HMO), Health records,
Hospitals, Indians, Individuals with
disabilities, Loan programs—health,
Medicaid, Organization and functions
(Government agencies), Public
assistance programs, Reporting and
recordkeeping requirements, State and
local governments, Sunshine Act,
Technical assistance, Women, Youth.
For the reasons set forth in the
preamble, the Centers for Medicare &
Medicaid Services (CMS) amends 42
CFR chapter IV and the Office of the
Secretary (HHS) amends 45 CFR subtitle
A, subchapter B, as set forth below:
TITLE 42—PUBLIC HEALTH
CHAPTER IV—CENTERS FOR MEDICARE &
MEDICAID SERVICES, DEPARTMENT OF
HEALTH AND HUMAN SERVICES
PART 406—HOSPITAL INSURANCE
ELIGIBLIITY AND ENTITLEMENT
1. The authority citation for part 406
is revised to read as follows:
■
Authority: 42 U.S.C 1302 and 1395hh.
2. Section 406.26 is amended by
adding paragraph (a)(1)(i) and adding
and reserving paragraph (a)(1)(ii) to read
as follows:
■
§ 406.26
Enrollment under State buy-in.
(a) * * *
(1) * * *
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
(i) Any State that has a buy-in
agreement in effect must participate in
daily exchanges of enrollment data with
CMS.
(ii) [Reserved]
*
*
*
*
*
*
*
*
*
*
(c) * * *
(4) Any State that has a buy-in
agreement in effect must participate in
daily exchanges of enrollment data with
CMS.
PART 422—MEDICARE ADVANTAGE
PROGRAM
5. The authority citation for part 422
continues to read as follows:
■
Authority: 42 U.S.C 1302 and 1395hh.
6. Section 422.119 is added to read as
follows:
■
§ 422.119 Access to and exchange of
health data and plan information.
(a) Application Programming
Interface to support MA enrollees. A
Medicare Advantage (MA) organization
must implement and maintain a
standards-based Application
Programming Interface (API) that
permits third-party applications to
retrieve, with the approval and at the
direction of a current individual MA
enrollee or the enrollee’s personal
representative, data specified in
paragraph (b) of this section through the
use of common technologies and
without special effort from the enrollee.
(b) Accessible content. (1) An MA
organization must make the following
information accessible to its current
enrollees or the enrollee’s personal
representative through the API
described in paragraph (a) of this
section:
(i) Data concerning adjudicated
claims, including claims data for
payment decisions that may be
appealed, were appealed, or are in the
process of appeal, and provider
remittances and enrollee cost-sharing
pertaining to such claims, no later than
one (1) business day after a claim is
processed;
PO 00000
Frm 00124
Fmt 4701
Sfmt 4700
(ii) Encounter data from capitated
providers, no later than one (1) business
day after data concerning the encounter
is received by the MA organization; and
(iii) Clinical data, including
laboratory results, if the MA
organization maintains any such data,
no later than one (1) business day after
the data is received by the MA
organization.
(2) In addition to the information
specified in paragraph (b)(1) of this
section, an MA organization that offers
an MA–PD plan must make the
following information accessible to its
enrollees through the API described in
paragraph (a) of this section:
(i) Data concerning adjudicated claims
for covered Part D drugs, including
remittances and enrollee cost-sharing,
no later than one (1) business day after
a claim is adjudicated; and,
(ii) Formulary data that includes
covered Part D drugs, and any tiered
formulary structure or utilization
management procedure which pertains
to those drugs.
(c) Technical requirements. An MA
organization implementing an API
under paragraph (a) of this section:
(1) Must implement, maintain, and
use API technology conformant with 45
CFR 170.215;
(2) Must conduct routine testing and
monitoring, and update as appropriate,
to ensure the API functions properly,
including assessments to verify that the
API is fully and successfully
implementing privacy and security
features such as, but not limited to,
those required to comply with HIPAA
privacy and security requirements in 45
CFR parts 160 and 164, 42 CFR parts 2
and 3, and other applicable law
protecting the privacy and security of
individually identifiable data;
(3) Must comply with the content and
vocabulary standard requirements in
paragraphs (c)(3)(i) and (ii) of this
section, as applicable to the data type or
data element, unless alternate standards
are required by other applicable law:
(i) Content and vocabulary standards
at 45 CFR 170.213 where such standards
are applicable to the data type or
element, as appropriate; and
(ii) Content and vocabulary standards
at 45 CFR part 162 and § 423.160 of this
chapter where required by law or where
such standards are applicable to the
data type or element, as appropriate.
(4) May use an updated version of any
standard or all standards required under
paragraph (c)(1) or (3) of this section,
where:
(i) Use of the updated version of the
standard is required by other applicable
law; or
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
(ii) Use of the updated version of the
standard is not prohibited under other
applicable law, provided that:
(A) For content and vocabulary
standards other than those at 45 CFR
170.213, the Secretary has not
prohibited use of the updated version of
a standard for purposes of this section
or 45 CFR part 170;
(B) For standards at 45 CFR 170.213
and 45 CFR 170.215, the National
Coordinator has approved the updated
version for use in the ONC Health IT
Certification Program; and
(C) Use of the updated version of a
standard does not disrupt an end user’s
ability to access the data described in
paragraph (b) of this section through the
API described in paragraph (a) of this
section.
(d) Documentation requirements for
APIs. For each API implemented in
accordance with paragraph (a) of this
section, an MA organization must make
publicly accessible, by posting directly
on its website or via publicly accessible
hyperlink(s), complete accompanying
documentation that contains, at a
minimum the information listed in this
paragraph. For the purposes of this
section, ‘‘publicly accessible’’ means
that any person using commonly
available technology to browse the
internet could access the information
without any preconditions or additional
steps, such as a fee for access to the
documentation; a requirement to receive
a copy of the material via email; a
requirement to register or create an
account to receive the documentation;
or a requirement to read promotional
material or agree to receive future
communications from the organization
making the documentation available;
(1) API syntax, function names,
required and optional parameters
supported and their data types, return
variables and their types/structures,
exceptions and exception handling
methods and their returns;
(2) The software components and
configurations an application must use
in order to successfully interact with the
API and process its response(s); and
(3) All applicable technical
requirements and attributes necessary
for an application to be registered with
any authorization server(s) deployed in
conjunction with the API.
(e) Denial or discontinuation of access
to the API. An MA organization may
deny or discontinue any third party
application’s connection to the API
required under paragraph (a) of this
section if the MA organization:
(1) Reasonably determines, consistent
with its security risk analysis under 45
CFR part 164 subpart C, that allowing an
application to connect or remain
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
connected to the API would present an
unacceptable level of risk to the security
of protected health information on the
MA organization’s systems; and
(2) Makes this determination using
objective, verifiable criteria that are
applied fairly and consistently across all
applications and developers through
which enrollees seek to access their
electronic health information, as
defined at 45 CFR 171.102, including
but not limited to criteria that may rely
on automated monitoring and risk
mitigation tools.
(f) Coordination among payers. (1) An
MA organization must maintain a
process for the electronic exchange of, at
a minimum, the data classes and
elements included in the content
standard adopted at 45 CFR 170.213.
Such information received by an MA
organization must be incorporated into
the MA organization’s records about the
current enrollee. With the approval and
at the direction of a current or former
enrollee or the enrollee’s personal
representative, the MA organization
must:
(i) Receive all such data for a current
enrollee from any other payer that has
provided coverage to the enrollee within
the preceding 5 years;
(ii) At any time an enrollee is
currently enrolled in the MA plan and
up to 5 years after disenrollment, send
all such data to any other payer that
currently covers the enrollee or a payer
the enrollee or the enrollee’s personal
representative specifically requests
receive the data; and
(iii) Send data received from another
payer under this paragraph (f) in the
electronic form and format it was
received.
(2) [Reserved]
(g) Enrollee resources regarding
privacy and security. An MA
organization must provide in an easily
accessible location on its public website
and through other appropriate
mechanisms through which it ordinarily
communicates with current and former
enrollees seeking to access their health
information held by the MA
organization, educational resources in
non-technical, simple and easy-tounderstand language explaining at a
minimum:
(1) General information on steps the
individual may consider taking to help
protect the privacy and security of their
health information including factors to
consider in selecting an application
including secondary uses of data, and
the importance of understanding the
security and privacy practices of any
application to which they will entrust
their health information; and
PO 00000
Frm 00125
Fmt 4701
Sfmt 4700
25633
(2) An overview of which types of
organizations or individuals are and are
not likely to be HIPAA covered entities,
the oversight responsibilities of the
Office for Civil Rights (OCR) and the
Federal Trade Commission (FTC), and
how to submit a complaint to:
(i) The HHS Office for Civil Rights
(OCR); and
(ii) The Federal Trade Commission
(FTC).
(h) Applicability. (1) An MA
organization must comply with the
requirements in paragraphs (a) through
(e) and (g) of this section beginning
January 1, 2021, and with the
requirements in paragraph (f) beginning
January 1, 2022 with regard to data:
(i) With a date of service on or after
January 1, 2016; and
(ii) That are maintained by the MA
organization.
(2) [Reserved]
■ 7. Section 422.120 is added to read as
follows:
§ 422.120 Access to published provider
directory information.
(a) An MA organization must
implement and maintain a publicly
accessible, standards-based Application
Programming Interface (API) that is
conformant with the technical
requirements at § 422.119(c), excluding
the security protocols related to user
authentication and authorization and
any other protocols that restrict the
availability of this information to
particular persons or organizations, the
documentation requirements at
§ 422.119(d), and is accessible via a
public-facing digital endpoint on the
MA organization’s website.
(b) The API must provide a complete
and accurate directory of—
(1) The MA plan’s network of
contracted providers, including names,
addresses, phone numbers, and
specialties, updated no later than 30
calendar days after the MA
organizations receives provider
directory information or updates to
provider directory information; and
(2) For an MA organization that offers
an MA–PD plan, the MA–PD’s
pharmacy directory, including the
pharmacy name, address, phone
number, number of pharmacies in the
network, and mix (specifically the type
of pharmacy, such as ‘‘retail pharmacy’’)
updated no later than 30 calendar days
after the MA organization receives
pharmacy directory information or
updates to pharmacy directory
information.
(c) This section is applicable
beginning January 1, 2021.
E:\FR\FM\01MYR2.SGM
01MYR2
25634
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
§ 431.60 Beneficiary access to and
exchange of data.
8. Section 422.504 is amended by
adding paragraph (a)(18) to read as
follows:
■
§ 422.504
Contract provisions.
*
*
*
*
*
(a) * * *
(18) To comply with the requirements
for access to health data and plan
information under §§ 422.119 and
422.120 of this chapter.
*
*
*
*
*
PART 423—VOLUNTARY MEDICARE
PERSCRIPTION DRUG BENEFIT
9. The authority citation for part 423
is revised to read as follows:
■
Authority: 42 U.S.C. 1302, 1306, 1395w–
101 through 1395w–152, and 1395hh.
10. Section 423.910 is amended—
a. In paragraph (b)(1) introductory text
by removing the phrase ‘‘monthly
reporting requirement for the monthly
enrollment reporting’’ and adding in its
place the phrase ‘‘state enrollment
reporting requirement described in
paragraph (d) of this section’’;
■ b. In paragraph (d) by revising the
paragraph heading and by redesignating
the text of paragraph (d) introductory
text as paragraph (d)(1).
■ c. In newly redesignated paragraph
(d)(1), by removing the phrase ‘‘Effective
June 2005, and each subsequent month,
States must submit an electronic file, in
a manner specified by CMS’’ and by
adding the following phrase ‘‘States
must submit an electronic file as
specified in paragraph (d)(2) of this
section,’’; and
■ d. By adding paragraph (d)(2).
The revision and addition read as
follows:
■
■
§ 423.910
Requirements.
*
*
*
*
*
(d) * * *
(2)(i) For the period prior to April 1,
2022, States must submit the file at least
monthly and may submit updates to that
file on a more frequent basis.
(ii) For the period beginning April 1,
2022, States must submit the file at least
monthly and must submit updates to
that file on a daily basis.
*
*
*
*
*
PART 431—STATE ORGANIZATION
AND GENERAL ADMINISTRATION
11. The authority citation for part 431
is revised to read as follows:
■
Authority: 42 U.S.C. 1302.
12. Section 431.60 is added to subpart
B to read as follows:
■
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
(a) Application Programming
Interface to support Medicaid
beneficiaries. A State must implement
and maintain a standards-based
Application Programming Interface
(API) that permits third-party
applications to retrieve, with the
approval and at the direction of a
current beneficiary or the beneficiary’s
personal representative, data specified
in paragraph (b) of this section through
the use of common technologies and
without special effort from the
beneficiary.
(b) Accessible content. A State must
make the following information
accessible to its current beneficiaries or
the beneficiary’s personal representative
through the API described in paragraph
(a) of this section:
(1) Data concerning adjudicated
claims, including claims data for
payment decisions that may be
appealed, were appealed, or are in the
process of appeal, and provider
remittances and beneficiary cost-sharing
pertaining to such claims, no later than
one (1) business day after a claim is
processed;
(2) Encounter data no later than one
(1) business day after receiving the data
from providers, other than MCOs,
PIHPs, and PAHPs, compensated on the
basis of capitation payments;
(3) Clinical data, including laboratory
results, if the State maintains any such
data, no later than one (1) business day
after the data is received by the State;
and
(4) Information about covered
outpatient drugs and updates to such
information, including, where
applicable, preferred drug list
information, no later than one (1)
business day after the effective date of
any such information or updates to such
information.
(c) Technical requirements. A State
implementing an API under paragraph
(a) of this section:
(1) Must implement, maintain, and
use API technology conformant with 45
CFR 170.215;
(2) Must conduct routine testing and
monitoring, and update as appropriate,
to ensure the API functions properly,
including assessments to verify that the
API is fully and successfully
implementing privacy and security
features such as, but not limited to,
those required to comply with HIPAA
privacy and security requirements in 45
CFR parts 160 and 164, 42 CFR parts 2
and 3, and other applicable law
protecting the privacy and security of
individually identifiable data;
PO 00000
Frm 00126
Fmt 4701
Sfmt 4700
(3) Must comply with the content and
vocabulary standards requirements in
paragraphs (c)(3)(i) and (ii) of this
section, as applicable to the data type or
data element, unless alternate standards
are required by other applicable law:
(i) Content and vocabulary standards
at 45 CFR 170.213 where such standards
are applicable to the data type or
element, as appropriate; and
(ii) Content and vocabulary standards
at 45 CFR part 162 and § 423.160 of this
chapter where required by law, or where
such standards are applicable to the
data type or element, as appropriate.
(4) May use an updated version of any
standard or all standards required under
paragraph (c)(1) or (3) of this section,
where:
(i) Use of the updated version of the
standard is required by other applicable
law, or
(ii) Use of the updated version of the
standard is not prohibited under other
applicable law, provided that:
(A) For content and vocabulary
standards other than those at 45 CFR
170.213, the Secretary has not
prohibited use of the updated version of
a standard for purposes of this section
or 45 CFR part 170;
(B) For standards at 45 CFR 170.213
and 45 CFR 170.215, the National
Coordinator has approved the updated
version for use in the ONC Health IT
Certification Program; and
(C) Use of the updated version of a
standard does not disrupt an end user’s
ability to access the data described in
paragraph (b) of this section through the
API described in paragraph (a) of this
section.
(d) Documentation requirements for
APIs. For each API implemented in
accordance with paragraph (a) of this
section, a State must make publicly
accessible, by posting directly on its
website or via publicly accessible
hyperlink(s), complete accompanying
documentation that contains, at a
minimum the information listed in this
paragraph. For the purposes of this
section, ‘‘publicly accessible’’ means
that any person using commonly
available technology to browse the
internet could access the information
without any preconditions or additional
steps, such as a fee for access to the
documentation; a requirement to receive
a copy of the material via email; a
requirement to register or create an
account to receive the documentation;
or a requirement to read promotional
material or agree to receive future
communications from the organization
making the documentation available;
(1) API syntax, function names,
required and optional parameters
supported and their data types, return
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
variables and their types/structures,
exceptions and exception handling
methods and their returns;
(2) The software components and
configurations an application must use
in order to successfully interact with the
API and process its response(s); and
(3) All applicable technical
requirements and attributes necessary
for an application to be registered with
any authorization server(s) deployed in
conjunction with the API.
(e) Denial or discontinuation of access
to the API. A State may deny or
discontinue any third-party
application’s connection to the API
required under paragraph (a) of this
section if the State:
(1) Reasonably determines, consistent
with its security risk analysis under 45
CFR part 164 subpart C, that allowing an
application to connect or remain
connected to the API would present an
unacceptable level of risk to the security
of protected health information on the
State’s systems; and
(2) Makes this determination using
objective, verifiable criteria that are
applied fairly and consistently across all
applications and developers through
which beneficiaries seek to access their
electronic health information as defined
at 45 CFR 171.102, including but not
limited to criteria that may rely on
automated monitoring and risk
mitigation tools.
(f) Beneficiary resources regarding
privacy and security. The State must
provide in an easily accessible location
on its public website and through other
appropriate mechanisms through which
it ordinarily communicates with current
and former beneficiaries seeking to
access their health information held by
the State Medicaid agency, educational
resources in non-technical, simple and
easy-to-understand language explaining
at a minimum:
(1) General information on steps the
individual may consider taking to help
protect the privacy and security of their
health information, including factors to
consider in selecting an application
including secondary uses of data, and
the importance of understanding the
security and privacy practices of any
application to which they will entrust
their health information; and
(2) An overview of which types of
organizations or individuals are and are
not likely to be HIPAA covered entities,
the oversight responsibilities of the
Office for Civil Rights (OCR) and the
Federal Trade Commission (FTC), and
how to submit a complaint to:
(i) The HHS Office for Civil Rights
(OCR); and
(ii) The Federal Trade Commission
(FTC).
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
(g) Data availability. (1) The State
must comply with the requirements in
paragraph (a) through (f) of this section
beginning January 1, 2021 with regard to
data:
(i) With a date of service on or after
January 1, 2016; and
(ii) That are maintained by the State.
(2) [Reserved]
■ 13. Section 431.70 is added to subpart
B to read as follows:
§ 431.70 Access to published provider
directory information.
(a) The State must implement and
maintain a publicly accessible,
standards-based Application
Programming Interface (API) that is
conformant with the technical
requirements at § 431.60(c), excluding
the security protocols related to user
authentication and authorization and
any other protocols that restrict the
availability of this information to
particular persons or organizations, the
documentation requirements at
§ 431.60(d), and is accessible via a
public-facing digital endpoint on the
State’s website.
(b) The API must provide a complete
and accurate directory of—
(1) The State’s provider directory
information specified in section
1902(a)(83) of the Act, updated no later
than 30 calendar days after the State
receives provider directory information
or updates to provider directory
information.
(2) [Reserved]
(c) This section is applicable
beginning January 1, 2021.
PART 438—MANAGED CARE
14. The authority citation for part 438
is revised to read as follows:
■
Authority: 42 U.S.C. 1302.
15. Section 438.62 is amended by
adding paragraphs (b)(1)(vi) and (vii) to
read as follows:
■
§ 438.62
Continued services to enrollees.
*
*
*
*
*
(b) * * *
(1) * * *
(vi) A process for the electronic
exchange of, at a minimum, the data
classes and elements included in the
content standard adopted at 45 CFR
170.213. Such information received by
the MCO, PIHP, or PAHP must be
incorporated into the MCO’s, PIHP’s, or
PAHP’s records about the current
enrollee. With the approval and at the
direction of a current or former enrollee
or the enrollee’s personal representative,
the MCO, PIHP, or PAHP must:
(A) Receive all such data for a current
enrollee from any other payer that has
PO 00000
Frm 00127
Fmt 4701
Sfmt 4700
25635
provided coverage to the enrollee within
the preceding 5 years;
(B) At any time the enrollee is
currently enrolled in the MCO, PIHP, or
PAHP and up to 5 years after
disenrollment, send all such data to any
other payer that currently covers the
enrollee or a payer the enrollee or the
enrollee’s personal representative
specifically requests receive the data;
and
(C) Send data received from another
payer under this paragraph in the
electronic form and format it was
received.
(vii) Applicability.
(A) The MCO, PIHP, or PAHP must
comply with the requirements in
paragraph (b)(1)(vi) of this section
beginning January 1, 2022 with regard to
data:
(1) With a date of service on or after
January 1, 2016; and
(2) That are maintained by the MCO,
PIHP, or PAHP.
(B) [Reserved]
*
*
*
*
*
■ 16. Section 438.242 is amended by
adding paragraphs (b)(5) and (6) to read
as follows:
§ 438.242
Health information systems.
*
*
*
*
*
(b) * * *
(5) Implement an Application
Programming Interface (API) as
specified in § 431.60 of this chapter as
if such requirements applied directly to
the MCO, PIHP, or PAHP and include—
(i) All encounter data, including
encounter data from any network
providers the MCO, PIHP, or PAHP is
compensating on the basis of capitation
payments and adjudicated claims and
encounter data from any subcontractors.
(ii) [Reserved]
(6) Implement, by January 1, 2021,
and maintain a publicly accessible
standards-based API described in
§ 431.70, which must include all
information specified in § 438.10(h)(1)
and (2) of this chapter.
*
*
*
*
*
PART 457—ALLOTMENTS AND
GRANTS TO STATES
17. The authority citation for part 457
is revised to read as follows:
■
Authority: 42 U.S.C. 1302.
18. Section 457.700 is amended by—
a. Redesignating paragraphs (a)(1) and
(2) as paragraphs (a)(2) and (3),
respectively;
■ b. Adding paragraph (a)(1); and
■ c. Revising paragraph (c).
The addition and revision reads as
follows:
■
■
E:\FR\FM\01MYR2.SGM
01MYR2
25636
§ 457.700
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Basis, scope, and applicability.
(a) * * *
(1) Section 2101(a) of the Act, which
sets forth that the purpose of title XXI
is to provide funds to States to provide
child health assistance to uninsured,
low-income children in an effective and
efficient manner that is coordinated
with other sources of health benefits
coverage;
*
*
*
*
*
(c) Applicability. The requirements of
this subpart apply to separate child
health programs and Medicaid
expansion programs, except that
§ 457.730 does not apply to Medicaid
expansion programs. Separate child
health programs that provide benefits
exclusively through managed care
organizations may meet the
requirements of § 457.730 by requiring
the managed care organizations to meet
the requirements of § 457.1233(d)(2).
■ 19. Section 457.730 is added to read
as follows:
§ 457.730 Beneficiary access to and
exchange of data.
(a) Application Programming
Interface to support CHIP beneficiaries.
A State must implement and maintain a
standards-based Application
Programming Interface (API) that
permits third-party applications to
retrieve, with the approval and at the
direction of the current individual
beneficiary or the beneficiary’s personal
representative, data specified in
paragraph (b) of this section through the
use of common technologies and
without special effort from the
beneficiary.
(b) Accessible content. A State must
make the following information
accessible to its current beneficiaries or
the beneficiary’s personal representative
through the API described in paragraph
(a) of this section:
(1) Data concerning adjudicated
claims, including claims data for
payment decisions that may be
appealed, were appealed, or are in the
process of appeal, and provider
remittances and beneficiary cost-sharing
pertaining to such claims, no later than
one (1) business day after a claim is
processed;
(2) Encounter data no later than 1
business day after receiving the data
from providers, other than MCOs,
PIHPs, or PAHPs, compensated on the
basis of capitation payments;
(3) Clinical data, including laboratory
results, if a State maintains any such
data, no later than one (1) business day
after the data is received by the State;
and
(4) Information, about covered
outpatient drugs and updates to such
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
information, including, where
applicable, preferred drug list
information, no later than one (1)
business day after the effective date of
the information or updates to such
information.
(c) Technical requirements. A State
implementing an API under paragraph
(a) of this section:
(1) Must implement, maintain, and
use API technology conformant with 45
CFR 170.215;
(2) Must conduct routine testing and
monitoring, and update as appropriate,
to ensure the API functions properly,
including assessments to verify that the
API technology is fully and successfully
implementing privacy and security
features such as, but not limited to,
those required to comply with HIPAA
privacy and security requirements in 45
CFR parts 160 and 164, 42 CFR parts 2
and 3, and other applicable law
protecting the privacy and security of
individually identifiable data;
(3) Must comply with the content and
vocabulary standard requirements in
paragraphs (c)(3)(i) and (ii) of this
section, as applicable to the data type or
data element, unless alternate standards
are required by other applicable law:
(i) Content and vocabulary standards
at 45 CFR 170.213 where such standards
are applicable to the data type or
element, as appropriate; and
(ii) Content and vocabulary standards
at 45 CFR part 162 and § 423.160 of this
chapter where required by law, or where
such standards are applicable to the
data type or element, as appropriate.
(4) May use an updated version of any
standard or all standards required under
paragraphs (c)(1) or (3) of this section,
where:
(i) Use of the updated version of the
standard is required by other applicable
law, or
(ii) Use of the updated version of the
standard is not prohibited under other
applicable law, provided that:
(A) For content and vocabulary
standards other than those at 45 CFR
170.213, the Secretary has not
prohibited use of the updated version of
a standard for purposes of this section
or 45 CFR part 170;
(B) For standards at 45 CFR 170.213
and 170.215, the National Coordinator
has approved the updated version for
use in the ONC Health IT Certification
Program; and
(C) Use of the updated version of a
standard does not disrupt an end user’s
ability to access the data described in
paragraph (b) of this section through the
API described in paragraph (a) of this
section.
(d) Documentation requirements for
APIs. For each API implemented in
PO 00000
Frm 00128
Fmt 4701
Sfmt 4700
accordance with paragraph (a) of this
section, a State must make publicly
accessible, by posting directly on its
website or via publicly accessible
hyperlink(s), complete accompanying
documentation that contains, at a
minimum the information listed in this
paragraph. For the purposes of this
section, ‘‘publicly accessible’’ means
that any person using commonly
available technology to browse the
internet could access the information
without any preconditions or additional
steps, such as a fee for access to the
documentation; a requirement to receive
a copy of the material via email; a
requirement to register or create an
account to receive the documentation;
or a requirement to read promotional
material or agree to receive future
communications from the organization
making the documentation available;
(1) API syntax, function names,
required and optional parameters
supported and their data types, return
variables and their types/structures,
exceptions and exception handling
methods and their returns;
(2) The software components and
configurations that an application must
use in order to successfully interact
with the API and process its response(s);
and
(3) All applicable technical
requirements and attributes necessary
for an application to be registered with
any authorization server(s) deployed in
conjunction with the API.
(e) Denial or discontinuation of access
to the API. A State may deny or
discontinue any third-party
application’s connection to the API
required under paragraph (a) of this
section if the State:
(1) Reasonably determines, consistent
with its security risk analysis under 45
CFR part 164 subpart C, that allowing an
application to connect or remain
connected to the API would present an
unacceptable level of risk to the security
of protected health information on the
State’s systems; and
(2) Makes this determination using
objective, verifiable criteria that are
applied fairly and consistently across all
applications and developers through
which beneficiaries seek to access their
electronic health information as defined
at 45 CFR 171.102, including but not
limited to criteria that may rely on
automated monitoring and risk
mitigation tools.
(f) Beneficiary resources regarding
privacy and security. A State must
provide in an easily accessible location
on its public website and through other
appropriate mechanisms through which
it ordinarily communicates with current
and former beneficiaries seeking to
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
access their health information held by
the State CHIP agency, educational
resources in non-technical, simple and
easy-to-understand language explaining
at a minimum:
(1) General information on steps the
individual may consider taking to help
protect the privacy and security of their
health information, including factors to
consider in selecting an application
including secondary uses of data, and
the importance of understanding the
security and privacy practices of any
application to which they will entrust
their health information; and
(2) An overview of which types of
organizations or individuals are and are
not likely to be HIPAA covered entities,
the oversight responsibilities of OCR
and FTC, and how to submit a
complaint to:
(i) The HHS Office for Civil Rights
(OCR); and
(ii) The Federal Trade Commission
(FTC).
(g) Data availability. (1) The State
must comply with the requirements in
paragraphs (a) through (f) of this section
beginning January 1, 2021 with regard to
data:
(i) With a date of service on or after
January 1, 2016; and
(ii) That are maintained by the State.
(2) [Reserved]
■ 20. Section 457.760 is added to
subpart G to read as follows:
Jkt 250001
*
*
*
*
*
(d) Health information systems. (1)
The State must ensure, through its
contracts, that each MCO, PIHP, and
PAHP complies with the health
information systems requirements as
provided in § 438.242(a), (b)(1) through
(4), (c), (d), and (e) of this chapter.
(2) Each MCO, PIHP, and PAHP must
implement an Application Programming
Interface (API) as specified in § 457.730
as if such requirements applied directly
to the MCO, PIHP, or PAHP, and
include—
(i) All encounter data, including
encounter data from any network
providers the MCO, PIHP, or PAHP is
compensating on the basis of capitation
payments and adjudicated claims and
encounter data from any subcontractors.
(ii) [Reserved]
(3) Implement, by January 1, 2021,
and maintain a publicly accessible
standards-based API described in
§ 457.760, which must include all
information specified in § 438.10(h)(1)
and (2) of this chapter.
*
*
*
*
*
PART 482—CONDITIONS OF
PARTICIPATION: HOSPITALS
22. The authority citation for part 482
is revised to read as follows:
(a) The State must implement and
maintain a publicly accessible,
standards-based Application
Programming Interface (API) that is
conformant with the technical
requirements at § 457.730(c), excluding
the security protocols related to user
authentication and authorization and
any other protocols that restrict the
availability of this information to
particular persons or organizations, the
documentation requirements at
§ 457.730(d), and is accessible via a
public-facing digital endpoint on the
State’s website.
(b) The API must provide a complete
and accurate directory of—
(1) The State’s provider directory
information including provider names,
addresses, phone numbers, and
specialties, updated no later than 30
calendar days after the State receives
provider directory information or
updates to provider directory
information.
(2) [Reserved]
(c) This section is applicable
beginning January 1, 2021.
08:09 May 01, 2020
§ 457.1233 Structure and operations
standards.
■
§ 457.760 Access to published provider
directory information.
VerDate Sep<11>2014
21. Section 457.1233 is amended by
revising paragraph (d) to read as
follows:
■
Authority: 42 U.S.C. 1302, 1395hh, and
1395rr, unless otherwise noted.
23. Section 482.24 is amended by
adding paragraph (d) to read as follows:
■
§ 482.24 Conditions of participation:
Medical record services.
*
*
*
*
*
(d) Standard: Electronic notifications.
If the hospital utilizes an electronic
medical records system or other
electronic administrative system, which
is conformant with the content
exchange standard at 45 CFR
170.205(d)(2), then the hospital must
demonstrate that—
(1) The system’s notification capacity
is fully operational and the hospital
uses it in accordance with all State and
Federal statutes and regulations
applicable to the hospital’s exchange of
patient health information.
(2) The system sends notifications
that must include at least patient name,
treating practitioner name, and sending
institution name.
(3) To the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
PO 00000
Frm 00129
Fmt 4701
Sfmt 4700
25637
the patient’s expressed privacy
preferences, the system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, at the time of:
(i) The patient’s registration in the
hospital’s emergency department (if
applicable).
(ii) The patient’s admission to the
hospital’s inpatient services (if
applicable).
(4) To the extent permissible under
applicable federal and state law and
regulations and not inconsistent with
the patient’s expressed privacy
preferences, the system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, either immediately
prior to, or at the time of:
(i) The patient’s discharge or transfer
from the hospital’s emergency
department (if applicable).
(ii) The patient’s discharge or transfer
from the hospital’s inpatient services (if
applicable).
(5) The hospital has made a
reasonable effort to ensure that the
system sends the notifications to all
applicable post-acute care services
providers and suppliers, as well as to
any of the following practitioners and
entities, which need to receive
notification of the patient’s status for
treatment, care coordination, or quality
improvement purposes:
(i) The patient’s established primary
care practitioner;
(ii) The patient’s established primary
care practice group or entity; or
(iii) Other practitioner, or other
practice group or entity, identified by
the patient as the practitioner, or
practice group or entity, primarily
responsible for his or her care.
■ 24. Section 482.61 is amended by
adding paragraph (f) to read as follows:
§ 482.61 Condition of participation:
Special medical record requirements for
psychiatric hospitals.
*
*
*
*
*
(f) Standard: Electronic notifications.
If the hospital utilizes an electronic
medical records system or other
electronic administrative system, which
is conformant with the content
exchange standard at 45 CFR
170.205(d)(2), then the hospital must
demonstrate that—
(1) The system’s notification capacity
is fully operational and the hospital
uses it in accordance with all State and
Federal statutes and regulations
applicable to the hospital’s exchange of
patient health information.
(2) The system sends notifications
that must include at least patient name,
treating practitioner name, and sending
institution name.
E:\FR\FM\01MYR2.SGM
01MYR2
25638
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
(3) To the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
the patient’s expressed privacy
preferences, the system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, at the time of:
(i) The patient’s registration in the
hospital’s emergency department (if
applicable).
(ii) The patient’s admission to the
hospital’s inpatient services (if
applicable).
(4) To the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
the patient’s expressed privacy
preferences, the system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, either immediately
prior to, or at the time of:
(i) The patient’s discharge or transfer
from the hospital’s emergency
department (if applicable).
(ii) The patient’s discharge or transfer
from the hospital’s inpatient services (if
applicable).
(5) The hospital has made a
reasonable effort to ensure that the
system sends the notifications to all
applicable post-acute care services
providers and suppliers, as well as to
any of the following practitioners and
entities, which need to receive
notification of the patient’s status for
treatment, care coordination, or quality
improvement purposes:
(i) The patient’s established primary
care practitioner;
(ii) The patient’s established primary
care practice group or entity; or
(iii) Other practitioner, or other
practice group or entity, identified by
the patient as the practitioner, or
practice group or entity, primarily
responsible for his or her care.
PART 485—CONDITIONS OF
PARTICIPATION: SPECIALIZED
PROVIDERS
25. The authority citation for part 485
is revised to read as follows:
■
Authority: 42 U.S.C. 1302 and 1395hh.
26. Section 485.638 is amended by
adding paragraph (d) to read as follows:
■
§ 485.638 Conditions of participation:
Clinical records.
*
*
*
*
*
(d) Standard: Electronic notifications.
If the CAH utilizes an electronic
medical records system or other
electronic administrative system, which
is conformant with the content
exchange standard at 45 CFR
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
170.205(d)(2), then the CAH must
demonstrate that—
(1) The system’s notification capacity
is fully operational and the CAH uses it
in accordance with all State and Federal
statutes and regulations applicable to
the CAH’s exchange of patient health
information.
(2) The system sends notifications
that must include at least patient name,
treating practitioner name, and sending
institution name.
(3) To the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
the patient’s expressed privacy
preferences, the system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, at the time of:
(i) The patient’s registration in the
CAH’s emergency department (if
applicable).
(ii) The patient’s admission to the
CAH’s inpatient services (if applicable).
(4) To the extent permissible under
applicable federal and state law and
regulations, and not inconsistent with
the patient’s expressed privacy
preferences, the system sends
notifications directly, or through an
intermediary that facilitates exchange of
health information, either immediately
prior to, or at the time of:
(i) The patient’s discharge or transfer
from the CAH’s emergency department
(if applicable).
(ii) The patient’s discharge or transfer
from the CAH’s inpatient services (if
applicable).
(5) The CAH has made a reasonable
effort to ensure that the system sends
the notifications to all applicable postacute care services providers and
suppliers, as well as to any of the
following practitioners and entities,
which need to receive notification of the
patient’s status for treatment, care
coordination, or quality improvement
purposes:
(i) The patient’s established primary
care practitioner;
(ii) The patient’s established primary
care practice group or entity; or
(iii) Other practitioner, or other
practice group or entity, identified by
the patient as the practitioner, or
practice group or entity, primarily
responsible for his or her care.
PO 00000
Frm 00130
Fmt 4701
Sfmt 4700
TITLE 45—PUBLIC WELFARE
SUBTITLE A—DEPARTMENT OF
HEALTH AND HUMAN SERVICES
PART 156—HEALTH INSURANCE
ISSUER STANDARDS UNDER THE
AFFORDABLE CARE ACT, INCLUDING
STANDARDS RELATED TO
EXCHANGES
27. The authority citation for part 156
continues to read as follows:
■
Authority: 42 U.S.C. 18021–18024, 18031–
18032, 18041–18042, 18044, 18054, 18061,
18063, 18071, 18082, 26 U.S.C. 36B, and 31
U.S.C. 9701.
28. Section 156.221 is added to read
as follows:
■
§ 156.221 Access to and exchange of
health data and plan information.
(a) Application Programming
Interface to support enrollees. Subject to
paragraph (h) of this section, a QHP
issuer on a Federally-Facilitated
Exchange must implement and maintain
a standards-based Application
Programming Interface (API) that
permits third-party applications to
retrieve, with the approval and at the
direction of a current individual
enrollee or the enrollee’s personal
representative, data specified in
paragraph (b) of this section through the
use of common technologies and
without special effort from the enrollee.
(b) Accessible content. (1) A QHP
issuer on a Federally-facilitate Exchange
must make the following information
accessible to its current enrollees or the
enrollee’s personal representative
through the API described in paragraph
(a) of this section:
(i) Data concerning adjudicated
claims, including claims data for
payment decisions that may be
appealed, were appealed, or are in the
process of appeal, and provider
remittances and enrollee cost-sharing
pertaining to such claims, no later than
one (1) business day after a claim is
processed;
(ii) Encounter data from capitated
providers, no later than one (1) business
day after data concerning the encounter
is received by the QHP issuer; and
(iii) Clinical data, including
laboratory results, if the QHP issuer
maintains any such data, no later than
one (1) business day after data is
received by the issuer.
(2) [Reserved]
(c) Technical requirements. A QHP
issuer on a Federally-facilitated
Exchange implementing an API under
paragraph (a) of this section:
(1) Must implement, maintain, and
use API technology conformant with 45
CFR 170.215;
E:\FR\FM\01MYR2.SGM
01MYR2
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
(2) Must conduct routine testing and
monitoring, and update as appropriate,
to ensure the API functions properly,
including assessments to verify the API
is fully and successfully implementing
privacy and security features such as,
but not limited to, those required to
comply with HIPAA privacy and
security requirements in parts 160 and
164, 42 CFR parts 2 and 3, and other
applicable law protecting privacy and
security of individually identifiable
data;
(3) Must comply with the content and
vocabulary standard requirements in
paragraphs (c)(3)(i) and (ii) of this
section, as applicable, to the data type
or data element, unless alternate
standards are required by other
applicable law:
(i) Content and vocabulary standards
at 45 CFR 170.213 where such are
applicable to the data type or element,
as appropriate; and
(ii) Content and vocabulary standards
at part 162 of this subchapter and 42
CFR 423.160 where required by law, or
where such standards are applicable to
the data type or element, as appropriate.
(4) May use an updated version of any
standard or all standards required under
paragraphs (c)(1) or (3) of this section,
where:
(i) Use of the updated version of the
standard is required by other applicable
law, or
(ii) Use of the updated version of the
standard is not prohibited under other
applicable law, provided that:
(A) For content and vocabulary
standards other than those at 45 CFR
170.213, the Secretary has not
prohibited use of the updated version of
a standard for purposes of this section
or part 170 of this subchapter;
(B) For standards at 45 CFR 170.213
and 45 CFR 170.215, the National
Coordinator has approved the updated
version for use in the ONC Health IT
Certification Program; and
(C) Use of the updated version of a
standard does not disrupt an end user’s
ability to access the data described in
paragraph (b) of this section through the
API described in paragraph (a) of this
section.
(d) Documentation requirements for
APIs. For each API implemented in
accordance with paragraph (a) of this
section, a QHP issuer on a FederallyFacilitated Exchange must make
publicly accessible, by posting directly
on its website and/or via publicly
accessible hyperlink(s), complete
accompanying documentation that
contains, at a minimum the information
listed in this paragraph. For the
purposes of this section, ‘‘publicly
accessible’’ means that any person using
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
commonly available technology to
browse the internet could access the
information without any preconditions
or additional steps, such as a fee for
access to the documentation; a
requirement to receive a copy of the
material via email; a requirement to
register or create an account to receive
the documentation; or a requirement to
read promotional material or agree to
receive future communications from the
organization making the documentation
available;
(1) API syntax, function names,
required and optional parameters
supported and their data types, return
variables and their types/structures,
exceptions and exception handling
methods and their returns;
(2) The software components and
configurations an application must use
in order to successfully interact with the
API and process its response(s); and
(3) All applicable technical
requirements and attributes necessary
for an application to be registered with
any authorization server(s) deployed in
conjunction with the API.
(e) Denial or discontinuation of access
to the API. A QHP issuer on a FederallyFacilitated Exchange may deny or
discontinue any third party
application’s connection to the API
required under paragraph (a) of this
section if the QHP issuer:
(1) Reasonably determines, consistent
with its security risk analysis under 45
CFR part 164 subpart C, that allowing an
application to connect or remain
connected to the API would present an
unacceptable level of risk to the security
of personally identifiable information,
including protected health information,
on the QHP issuer’s systems; and
(2) Makes this determination using
objective, verifiable criteria that are
applied fairly and consistently across all
applications and developers through
which enrollees seek to access their
electronic health information as defined
at § 171.102 of this subchapter,
including but not limited to criteria that
may rely on automated monitoring and
risk mitigation tools.
(f) Coordination among payers. (1) A
QHP issuer on a Federally-facilitated
Exchange must maintain a process for
the electronic exchange of, at a
minimum, the data classes and elements
included in the content standard
adopted at 45 CFR 170.213. Such
information received by a QHP issuer on
a Federally-facilitated Exchange must be
incorporated into the QHP issuer’s
records about the current enrollee. With
the approval and at the direction of a
current or former enrollee or the
enrollee’s personal representative, a
PO 00000
Frm 00131
Fmt 4701
Sfmt 4700
25639
QHP issuer on a Federally-facilitated
Exchange must:
(i) Receive all such data for a current
enrollee from any other payer that has
provided coverage to the enrollee within
the preceding 5 years;
(ii) At any time the enrollee is
currently enrolled in the plan and up to
5 years after disenrollment, send all
such data to any other payer that
currently covers the enrollee or a payer
the enrollee or the enrollee’s personal
representative specifically requests
receive the data; and
(iii) Send data received from another
payer under this paragraph (f) in the
electronic form and format it was
received.
(2) [Reserved]
(g) Enrollee resources regarding
privacy and security. A QHP issuer on
a Federally-facilitated Exchange must
provide in an easily accessible location
on its public website and through other
appropriate mechanisms through which
it ordinarily communicates with current
and former enrollees seeking to access
their health information held by the
QHP issuer, educational resources in
non-technical, simple and easy-tounderstand language explaining at a
minimum:
(1) General information on steps the
individual may consider taking to help
protect the privacy and security of their
health information, including factors to
consider in selecting an application
including secondary uses of data, and
the importance of understanding the
security and privacy practices of any
application to which they will entrust
their health information; and
(2) An overview of which types of
organizations or individuals are and are
not likely to be HIPAA covered entities,
the oversight responsibilities of the
Office for Civil Rights (OCR) and the
Federal Trade Commission (FTC), and
how to submit a complaint to:
(i) The HHS Office for Civil Rights
(OCR); and
(ii) The Federal Trade Commission
(FTC).
(h) Exception. (1) If a plan applying
for QHP certification to be offered
through a Federally-facilitated Exchange
believes it cannot satisfy the
requirements in paragraphs (a) through
(g) of this section, the issuer must
include as part of its QHP application a
narrative justification describing the
reasons why the plan cannot reasonably
satisfy the requirements for the
applicable plan year, the impact of noncompliance upon enrollees, the current
or proposed means of providing health
information to enrollees, and solutions
and a timeline to achieve compliance
with the requirements of this section.
E:\FR\FM\01MYR2.SGM
01MYR2
25640
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
(2) The Federally-facilitated Exchange
may grant an exception to the
requirements in paragraphs (a) through
(g) of this section if the Exchange
determines that making such health
plan available through such Exchange is
in the interests of qualified individuals
in the State or States in which such
Exchange operates.
(i) Applicability. A QHP issuer on an
individual market Federally-facilitated
Exchange, not including QHP issuers
VerDate Sep<11>2014
08:09 May 01, 2020
Jkt 250001
offering only stand-alone dental plans,
must comply with the requirements in
paragraphs (a) through (e) and (g) of this
section beginning with plan years
beginning on or after January 1, 2021,
and with the requirements in paragraph
(f) of this section beginning with plan
years beginning on or after January 1,
2022 with regard to data:
(1) With a date of service on or after
January 1, 2016; and
(2) That are maintained by the QHP
issuer for enrollees in QHPs.
PO 00000
Frm 00132
Fmt 4701
Sfmt 9990
Dated: January 21, 2020.
Seema Verma,
Administrator, Centers for Medicare &
Medicaid Services.
Dated: March 5, 2020.
Alex M. Azar II,
Secretary, Department of Health and Human
Services.
[FR Doc. 2020–05050 Filed 4–21–20; 4:15 pm]
BILLING CODE P
E:\FR\FM\01MYR2.SGM
01MYR2
Agencies
[Federal Register Volume 85, Number 85 (Friday, May 1, 2020)]
[Rules and Regulations]
[Pages 25510-25640]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-05050]
[[Page 25509]]
Vol. 85
Friday,
No. 85
May 1, 2020
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
Centers for Medicare & Medicaid Services
-----------------------------------------------------------------------
42 CFR Parts 406, 407, 422, Et al.
45 CFR Part 156
Medicare and Medicaid Programs; Patient Protection and Affordable Care
Act; Interoperability and Patient Access for Medicare Advantage
Organization and Medicaid Managed Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, and Health Care
Providers; Final Rule
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and
Regulations
[[Page 25510]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 406, 407, 422, 423, 431, 438, 457, 482, and 485
Office of the Secretary
45 CFR Part 156
[CMS-9115-F]
RIN 0938-AT79
Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Interoperability and Patient Access for Medicare Advantage
Organization and Medicaid Managed Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, and Health Care
Providers
AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule is intended to move the health care ecosystem
in the direction of interoperability, and to signal our commitment to
the vision set out in the 21st Century Cures Act and Executive Order
13813 to improve the quality and accessibility of information that
Americans need to make informed health care decisions, including data
about health care prices and outcomes, while minimizing reporting
burdens on affected health care providers and payers.
DATES: These regulations are effective on June 30, 2020.
FOR FURTHER INFORMATION CONTACT:
Alexandra Mugge, (410) 786-4457, for issues related to
interoperability, CMS health IT strategy, and technical standards.
Denise St. Clair, (410) 786-4599, for issues related API policies
and related standards.
Natalie Albright, (410) 786-1671, for issues related to Medicare
Advantage.
Laura Snyder, (410) 786-3198, for issues related to Medicaid.
Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified
Health Plans.
Meg Barry, (410) 786-1536, for issues related to CHIP.
Thomas Novak, (202) 322-7235, for issues related to trust exchange
networks and payer to payer coordination.
Sharon Donovan, (410) 786-9187, for issues related to federal-state
data exchange.
Daniel Riner, (410) 786-0237, for issues related to Physician
Compare.
Ashley Hain, (410) 786-7603, for issues related to hospital public
reporting.
Melissa Singer, (410) 786-0365, for issues related to provider
directories.
CAPT Scott Cooper, USPHS, (410) 786-9465, for issues related to
hospital and critical access hospital conditions of participation.
Russell Hendel, (410) 786-0329, for issues related to the
Collection of Information or the Regulation Impact Analysis sections.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Background and Summary of Provisions
A. Purpose
B. Overview
C. Executive Order and MyHealthEData
D. Past Efforts
E. Challenges and Barriers to Interoperability
F. Summary of Major Provisions
II. Technical Standards Related to Interoperability Provisions, and
Analysis of and Responses to Public Comments
A. Technical Approach and Standards
B. Content and Vocabulary Standards
C. Application Programming Interface (API) Standard
D. Updates to Standards
III. Provisions of Patient Access Through APIs, and Analysis of and
Responses to Public Comments
A. Background on Medicare Blue Button
B. Expanding the Availability of Health Information
C. Standards-based API Proposal for MA, Medicaid, CHIP, and QHP
Issuers on the FFEs
IV. API Access to Published Provider Directory Data Provisions, and
Analysis of and Responses to Public Comments
A. Interoperability Background and Use Cases
B. Broad API Access to Provider Directory Data
V. The Health Information Exchange and Care Coordination Across
Payers: Establishing a Coordination of Care Transaction To
Communicate Between Plans Provisions, and Analysis of and Responses
to Public Comments
VI. Care Coordination Through Trusted Exchange Networks: Trust
Exchange Network Requirements for MA Plans, Medicaid Managed Care
Plans, CHIP Managed Care Entities, and QHPs on the FFEs Provisions,
and Analysis of and Responses to Public Comments
VII. Improving the Medicare-Medicaid Dually Eligible Experience by
Increasing the Frequency of Federal-State Data Exchanges Provisions,
and Analysis of and Responses to Public Comments
A. Increasing the Frequency of Federal-State Data Exchanges for
Dually Eligible Individuals
B. Request for Stakeholder Input
VIII. Information Blocking Background and Public Reporting
Provisions, and Analysis of and Responses to Public Comments
A. Information Blocking Background
B. Public Reporting and Prevention of Information Blocking on
Physician Compare
C. Public Reporting and Prevention of Information Blocking for
Eligible Hospitals and Critical Access Hospitals (CAHs)
IX. Provider Digital Contact Information Provisions, and Analysis of
and Responses to Public Comments
A. Background
B. Public Reporting of Missing Digital Contact Information
X. Conditions of Participation for Hospitals and Critical Access
Hospitals (CAHs) Provisions, and Analysis of and Responses to Public
Comments
A. Background
B. Provisions for Hospitals (42 CFR 482.24(d))
C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))
D. Provisions for CAHs (42 CFR 485.638(d))
XI. Provisions of the Final Regulations
XII. Collection of Information Requirements
A. Background
B. Wage Estimates
C. Information Collection Requirements (ICRs)
XIII. Regulatory Impact Analysis
A. Statement of Need
B. Overall Impact
C. Anticipated Effects
D. Alternatives Considered
E. Accounting Statement and Table
F. Regulatory Reform Analysis Under E.O. 13771
G. Conclusion
Regulation Text
I. Background and Summary of Provisions
In the March 4, 2019 Federal Register, we published the ``Medicare
and Medicaid Programs; Patient Protection and Affordable Care Act;
Interoperability and Patient Access for Medicare Advantage Organization
and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies
and CHIP Managed Care Entities, Issuers of Qualified Health Plans on
the Federally-facilitated Exchanges and Health Care Providers''
proposed rule (84 FR 7610) (hereinafter referred to as the ``CMS
Interoperability and Patient Access proposed rule''). The proposed rule
outlined our proposed policies that were intended to move the health
care ecosystem in the direction of interoperability, and to signal our
commitment to the vision set out in the 21st Century Cures Act and
Executive Order 13813 to improve quality and accessibility of
information that Americans need to make informed
[[Page 25511]]
health care decisions, including data about health care prices and
outcomes, while minimizing reporting burdens on affected health care
providers and payers. We solicited public comments on the CMS
Interoperability and Patient Access proposed rule. In this final rule,
we address those public comments and outline our final policies in the
respective sections of this rule.
A. Purpose
This final rule is the first phase of policies centrally focused on
advancing interoperability and patient access to health information
using the authority available to the Centers for Medicare & Medicaid
Services (CMS). We believe this is an important step in advancing
interoperability, putting patients at the center of their health care,
and ensuring they have access to their health information. We are
committed to working with stakeholders to solve the issue of
interoperability and getting patients access to information about their
health care, and we are taking an active approach to move participants
in the health care market toward interoperability and the secure and
timely exchange of health information by adopting policies for the
Medicare and Medicaid programs, the Children's Health Insurance Program
(CHIP), and qualified health plan (QHP) issuers on the individual
market Federally-facilitated Exchanges (FFEs). For purposes of this
rule, references to QHP issuers on the FFEs excludes issuers offering
only stand-alone dental plans (SADPs), unless otherwise noted for a
specific proposed or finalized policy. Likewise, we are also excluding
QHP issuers only offering QHPs in the Federally-facilitated Small
Business Health Options Program Exchanges (FF-SHOPs) from the
provisions of this rule and so, for purposes of this rule references to
QHP issuers on the FFEs excludes issuers offering QHPs only on the FF-
SHOPs. We note that, in this final 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 consumers in these
states enroll in coverage through HealthCare.gov, and QHP issuers in
SBE-FPs are not subject to the requirements in this rule.
B. Overview
We are dedicated to enhancing and protecting the health and well-
being of all Americans. One critical issue in the U.S. health care
system is that people cannot easily access their health information in
interoperable forms. Patients and the health care providers caring for
them are often presented with an incomplete picture of their health and
care as pieces of their information are stored in various, unconnected
systems and do not accompany the patient to every care setting.
Although more than 95 percent of hospitals \1\ and 75 percent of
office-based clinicians \2\ are utilizing certified health IT,
challenges remain in creating a comprehensive, longitudinal view of a
patient's health history.3 4 5 This siloed nature of health
care data prevents physicians, pharmaceutical companies, manufacturers,
and payers from accessing and interpreting important data sets,
instead, encouraging each group to make decisions based upon a part of
the information rather than the whole. Without an enforced standard of
interoperability, data exchanges are often complicated and time-
consuming.
---------------------------------------------------------------------------
\1\ Office of the National Coordinator. (2019). Hospitals' Use
of Electronic Health Records Data, 2015-2017. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-04/AHAEHRUseDataBrief.pdf.
\2\ Office of the National Coordinator. (2019, December 18).
Health IT Playbook, Section 1: Electronic Health Records. Retrieved
from https://www.healthit.gov/playbook/electronic-health-records/.
\3\ Powell, K. R. & Alexander, G. L. (2019). Mitigating Barriers
to Interoperability in Health Care. Online Journal of Nursing
Informatics, 23(2). Retrieved from https://www.himss.org/library/mitigating-barriers-interoperability-health-care.
\4\ Hochman, M., Garber, J., & Robinson, E. J. (2019, August
14). Health Information Exchange After 10 Years: Time For A More
Assertive, National Approach. Retrieved from https://www.healthaffairs.org/do/10.1377/hblog20190807.475758/full/.
\5\ Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, C.,
Natarajan, S., Yong, C., & Zhao, L. (2019). Status of health
information exchange: A comparison of six countries. Journal of
Global Health, 9(2). doi: 10.7189/jogh.09.020427.
---------------------------------------------------------------------------
We believe patients should have the ability to move from payer to
payer, provider to provider, and have both their clinical and
administrative information travel with them throughout their journey.
When a patient receives care from a new provider, a record of their
health information should be readily available to that care provider,
regardless of where or by whom care was previously provided. When a
patient is discharged from a hospital to a post-acute care (PAC)
setting there should be no question as to how, when, or where their
data will be exchanged. Likewise, when an enrollee changes payers or
ages into Medicare, the enrollee should be able to have their claims
history and encounter data follow so that information is not lost. As
discussed in more detail in section III. of this final rule, claims and
encounter data can offer a more holistic understanding of a patient's
health, providing insights into everything from the frequency and types
of care provided and for what reason, medication history and adherence,
and the evolution and adherence to a care plan. This information can
empower patients to make better decisions and inform providers to
support better health outcomes.
For providers in clinical and community settings, health
information technology (health IT) should be a resource, enabling
providers to deliver high quality care, creating efficiencies and
allowing them to access all payer and provider data for their patients.
Therefore, health IT should not detract from the clinician-patient
relationship, from the patient's experience of care, or from the
quality of work life for physicians, nurses, other health care
professionals, and social service providers. Through standards-based
interoperability and information exchange, health IT has the potential
to facilitate efficient, safe, high-quality care for individuals and
populations.
All payers should have the ability to exchange data seamlessly with
other payers for timely benefits coordination or transitions, and with
health care and social service providers to facilitate more coordinated
and efficient care. Payers are in a unique position to provide
enrollees with a comprehensive picture of their claims and encounter
data, allowing patients to piece together their own information that
might otherwise be lost in disparate systems. This information can
contribute to better informed decision making, helping to inform the
patient's choice of coverage options and care providers to more
effectively manage their own health, care, and costs.
We are committed to working with stakeholders to solve the issue of
interoperability and patient access in the U.S. health care system
while reducing administrative burdens on providers and are taking an
active approach using all available policy levers and authorities to
move participants in the health care market toward interoperability and
the secure and timely exchange of health care information.
C. Executive Order and MyHealthEData
On October 12, 2017, President Trump issued Executive Order 13813
to Promote Healthcare Choice and Competition Across the United States.
Section 1(c)(iii) of Executive Order 13813 states that the
Administration will improve access to, and the quality of, information
that Americans need to make informed health care decisions, including
information about health care
[[Page 25512]]
prices and outcomes, while minimizing reporting burdens on impacted
providers, and payers, meaning providers and payers subject to this
rule.
In support of Executive Order 13813, the Administration launched
the MyHealthEData initiative. This government-wide initiative aims to
empower patients by ensuring that they have access to their own health
information and the ability to decide how their data will be used,
while keeping that information safe and secure. MyHealthEData aims to
break down the barriers that prevent patients from gaining electronic
access to their health information from the device or application of
their choice, empowering patients and taking a critical step toward
interoperability and patient data exchange.
In March 2018, the White House Office of American Innovation and
the CMS Administrator announced the launch of MyHealthEData, and CMS's
direct, hands-on role in improving patient access and advancing
interoperability. As part of the MyHealthEData initiative, we are
taking a patient-centered approach to health information access and
moving to a system in which patients have immediate access to their
computable health information such that they can be assured that their
health information will follow them as they move throughout the health
care system from provider to provider, payer to payer. To accomplish
this, we have launched several initiatives related to data sharing and
interoperability to empower patients and encourage payer and provider
competition. We continue to advance the policies and goals of the
MyHealthEData initiative through various provisions included in this
final rule.
As finalized in this rule, our policies are wide-reaching and will
have an impact on all facets of the health care system. Several key
touch points of the policies in this rule include:
Patients: Enabling patients to access their health
information electronically without special effort by requiring the
payers subject to this final rule to make data available through an
application programming interface (API) to which third-party software
applications connect to make data available to patients for their
personal use. This encourages patients to take charge of and better
manage their health care, and thus these initiatives are imperative to
improving a patient's long-term health outcomes.
Clinicians and Hospitals: Ensuring that health care
providers have ready access to health information about their patients,
regardless of where the patient may have previously received care. We
are also implementing policies to prevent health care providers from
inappropriately restricting the flow of information to other health
care providers and payers. Finally, we are working to ensure that
better interoperability reduces the burden on health care providers.
Payers: Implementing requirements to ensure that payers
(that is, entities and organizations that pay for health care), such as
payers in Medicare Advantage, Medicaid, and CHIP, make enrollee
electronic health information held by the payer available through an
API such that, with use of software expected to be developed by payers
and third parties, the information becomes easily accessible to the
enrollee and data flow seamlessly with the enrollee as such enrollees
change health care and social service providers and payers.
Additionally, our policies ensure that payers make it easy for current
and prospective enrollees to identify which providers are within a
given plan's network in a way that is simple and easy for enrollees to
access and understand, and thus find the providers that are right for
them.
As a result of our efforts to standardize data and technical
approaches to advance interoperability, we believe health care
providers and their patients, as well as other key participants within
the health care ecosystem such as payers, will have appropriate access
to the information necessary to coordinate individual care; analyze
population health trends, outcomes, and costs; and manage benefits and
the health of populations, while tracking progress through quality
improvement initiatives. We are working with other federal partners
including the Office of the National Coordinator for Health Information
Technology (ONC) on this effort with the clear objectives of improving
patient access and care, alleviating provider burden, and reducing
overall health care costs, all while taking steps to protect the
privacy and security of patients' personal health information. As
evidence of this partnership, ONC is releasing the ONC 21st Century
Cures Act final rule (published elsewhere in this issue of the Federal
Register) in tandem with this final rule. It is this coordinated
federal effort, in conjunction with strong support and innovation from
our stakeholders, that will help us move ever closer to true
interoperability.
D. Past Efforts
The Department of Health and Human Services (HHS) has been working
to advance the interoperability of electronic health information for
over 15 years. For a detailed explanation of past efforts, see the CMS
Interoperability and Patient Access proposed rule (84 FR 7612 through
7614).
E. Challenges and Barriers to Interoperability
Through significant stakeholder feedback, we understand that there
are many barriers to interoperability, which have obstructed progress
over the years. We have conducted stakeholder meetings and roundtables;
solicited comments via RFIs; and received additional feedback through
letters and rulemaking. All of this input together contributed to the
policies in our Interoperability and Patient Access proposed rule, and
when combined with the comments we received on the proposed rule, the
content of this final rule. Some of the main barriers shared with us,
specifically patient identification, lack of standardization,
information blocking, the lack of adoption and use of certified health
IT among post-acute care (PAC) providers, privacy concerns, and
uncertainty about the requirements of the Health Insurance Portability
and
Accountability Act of 1996 (HIPAA) Privacy, Security, and Breach
Notification Rules, were discussed in the proposed rule (84 FR 7614
through 7617). While we have made efforts to address some of these
barriers in this final rule and through prior rules and actions, we
believe there is still considerable work to be done to overcome some of
these challenges toward achieving interoperability, and we will
continue this work as we move forward with our interoperability
efforts.
F. Summary of Major Provisions
This final rule empowers patients in MA organizations, Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, by finalizing several
initiatives that will break down those barriers currently keeping
patients from easily accessing their electronic health care
information. Additionally, the rule creates and implements new
mechanisms to enable patients to access their own health care
information through third-party software applications, thereby
providing them with the ability to decide how, when, and with whom to
share their information.
[[Page 25513]]
We are finalizing with modifications our proposal to require MA
organizations, Medicaid and 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. This
Patient Access API must meet the technical standards finalized by HHS
in the ONC 21st Century Cures Act final rule (published elsewhere in
this issue of the Federal Register) at 45 CFR 170.215 (currently
including Health Level 7[supreg] (HL7) Fast Healthcare Interoperability
Resources[supreg] (FHIR) Release 4.0.1) and the content and vocabulary
standards finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register) at 45 CFR
170.213, as well as content and vocabulary standards at 45 CFR part 162
and the content and vocabulary standards at 42 CFR 423.160. We are
finalizing that through the Patient Access API, payers must permit
third-party applications to retrieve, with the approval and at the
direction of a current enrollee, data specified at 42 CFR 422.119,
431.60, 457.730, and 45 CFR 156.221. Specifically, we are requiring
that the Patient Access API must, at a minimum, make available
adjudicated claims (including provider remittances and enrollee cost-
sharing); encounters with capitated providers; and clinical data,
including laboratory results (when maintained by the impacted payer).
Data must be made available no later than one (1) business day after a
claim is adjudicated or encounter data are received. We are requiring
that beginning January 1, 2021, impacted payers make available through
the Patient Access API the specified data they maintain with a date of
service on or after January 1, 2016. This is consistent with the
requirements for the payer-to-payer data exchange detailed in section
V. of this final rule. Together these policies facilitate the creation
and maintenance of a patient's cumulative health record with their
current payer.
We are finalizing regulations to require that MA organizations,
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities make standardized information about their
provider networks available through a Provider Directory API that is
conformant with the technical standards finalized by HHS in the ONC
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register) at 45 CFR 170.215, excluding the security
protocols related to user authentication and authorization and any
other protocols that restrict availability of this information to
particular persons or organizations. Authentication and authorization
protocols are not necessary when making publicly available data
accessible via an API. We are finalizing that the Provider Directory
API must be accessible via a public-facing digital endpoint on the
payer's website to ensure public discovery and access. At a minimum,
these payers must make available via the Provider Directory API
provider names, addresses, phone numbers, and specialties. For MA
organizations that offer MA-PD plans, they must also make available, at
a minimum, pharmacy directory data, including the pharmacy name,
address, phone number, number of pharmacies in the network, and mix
(specifically the type of pharmacy, such as ``retail pharmacy''). All
directory information must be made available to current and prospective
enrollees and the public through the Provider Directory API within 30
calendar days of a payer receiving provider directory information or an
update to the provider directory information. The Provider Directory
API is being finalized at 42 CFR 422.120 for MA organizations, at 42
CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for
Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies,
and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. Here we
are finalizing that access to the published Provider Directory API must
be fully implemented by January 1, 2021. We do strongly encourage
payers to make their Provider Directory API public as soon as possible
to make and show progress toward meeting all the API requirements being
finalized in this rule.
We are finalizing our proposal, with certain modifications as
detailed in section V. of this final rule, to require MA organizations,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to coordinate care between payers by exchanging, at
a minimum, the data elements specified in the current content and
vocabulary standard finalized by HHS in the ONC 21st Century Cures Act
final rule (published elsewhere in this issue of the Federal Register)
at 45 CFR 170.213 (currently the ``United States Core Data for
Interoperability'' (USCDI) version 1 \6\). This payer-to-payer data
exchange requires these payers, as finalized at 42 CFR 422.119(f) for
MA organizations, at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care
plans (and by extension under Sec. 457.1216 CHIP managed care
entities), and at 45 CFR 156.221(f) for QHP issuers on the FFEs, to
send, at a current or former enrollee's request, specific information
they maintain with a date of service on or after January 1, 2016 to any
other payer identified by the current enrollee or former enrollee. This
is consistent with the Patient Access API detailed in section III. of
this final rule. We are also finalizing a provision that a payer is
only obligated to share data received from another payer under this
regulation in the electronic form and format it was received. This is
intended to reduce burden on payers. We are finalizing that this payer-
to-payer data exchange must be fully implemented by January 1, 2022.
---------------------------------------------------------------------------
\6\ Office of the National Coordinator. (n.d.). U.S. Core Data
for Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/us-core-data-interoperability-uscdi.
---------------------------------------------------------------------------
In response to comments discussed more fully below, we are not
finalizing our proposal to require MA organizations, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to
participate in a trusted exchange network given the concerns commenters
raised regarding the need for a mature Trusted Exchange Framework and
Common Agreement (TEFCA) to be in place first, and appreciating that
work on TEFCA is ongoing at this time.
We are finalizing the requirements that all states participate in
daily exchange of buy-in data, which includes both sending data to CMS
and receiving responses from CMS daily, and that all states submit the
MMA file data to CMS daily by April 1, 2022 in accordance with 42 CFR
406.26, 407.40, and 423.910, respectively, as proposed. These
requirements will improve the experience of dually eligible individuals
by improving the ability of providers and payers to coordinate
eligibility, enrollment, benefits, and/or care for this population.
We are finalizing our proposal to include an indicator on Physician
Compare for the eligible clinicians and groups that submit a ``no''
response to any of the three prevention of information blocking
statements for MIPS. In the event that these statements are left blank,
the attestations will be considered incomplete, and we will not include
an indicator on Physician Compare. The indicator will be posted on
Physician Compare, either on the profile pages or in the downloadable
database, starting with the 2019 performance period data available for
public reporting starting in late 2020.
[[Page 25514]]
We are finalizing our proposal to include information on a publicly
available CMS website indicating that an eligible hospital or critical
access hospital (CAH) attesting under the Medicare FFS Promoting
Interoperability Program had submitted a ``no'' response to any of the
three attestation statements related to the prevention of information
blocking. In the event that an eligible hospital or CAH leaves a
``blank'' response, the attestations will be considered incomplete, and
no information will be posted related to these attestation statements.
We will post this information starting with the attestations for the
EHR reporting period in 2019 and expect this information will be posted
in late 2020.
Additionally, as detailed in section IX. of this final rule, we are
finalizing our proposal to publicly report the names and NPIs of those
providers who do not have digital contact information included in the
National Plan and Provider Enumeration System (NPPES) system beginning
in the second half of 2020 as proposed. Additionally, we will continue
to ensure providers are aware of the benefits of including digital
contact information in NPPES, and when and where their names and NPIs
will be posted if they do not include this information. We do strongly
encourage providers to include FHIR endpoint information in NPPES if
and when they have the information, as well.
To further advance electronic exchange of information that supports
effective transitions of care we are finalizing the requirement for a
hospital, psychiatric hospital, and CAH, which utilizes an electronic
medical records system or other electronic administrative system that
is conformant with the content exchange standard at 45 CFR
170.205(d)(2) to demonstrate that: (1) Its system's notification
capacity is fully operational and that it operates in accordance with
all state and federal statutes and regulations regarding the exchange
of patient health information; (2) its system sends notifications that
must include the minimum patient health information specified in
section X. of this final rule; and (3) its system sends notifications
directly, or through an intermediary that facilitates exchange of
health information, and at the time of a patient's registration in the
emergency department or admission to inpatient services, and also prior
to, or at the time of, a patient's discharge and/or transfer from the
emergency department or inpatient services, to all applicable post-
acute care services providers and suppliers, primary care practitioners
and groups, and other practitioners and groups identified by the
patient as primarily responsible for his or her care, and who or which
need to receive notification of the patient's status for treatment,
care coordination, or quality improvement purposes. We are establishing
that this policy will be applicable 12 months after publication of this
rule for hospitals, including psychiatric hospitals, and CAHs to allow
for adequate and additional time for these institutions, especially
small and/or rural hospitals as well as CAHs, to come into compliance
with the new requirements.
Finally, we note that we included two RFIs in the proposed rule:
one related to interoperability and health IT adoption in PAC settings
and one related to the role of patient matching in interoperability and
improved patient care. We thank commenters for the insights shared on
these two topics. We are reviewing these comments and will take them
into consideration for potential future rulemaking.
Throughout this final rule, we refer to terms such as ``patient,''
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' We
note that every reader of this final rule is a patient and has or will
receive medical care at some point in their life. In this final rule,
we use the term ``patient'' as an inclusive term, but because we have
historically referred to patients using the other terms noted above in
our regulations, we use specific terms as applicable in sections of
this final rule to refer to individuals covered under the health care
programs that CMS administers and regulates. We also note that when we
discuss patients, we acknowledge a patient's personal representative.
Per the HIPAA privacy regulations at 45 CFR 164.502(g), a personal
representative is someone authorized under state or other applicable
law to act on behalf of the individual in making health care related
decisions (such as a parent, guardian, or person with a medical power
of attorney).\7\ Policies in this final rule that require a patient's
action could be addressed by a patient's personal representative.
---------------------------------------------------------------------------
\7\ See OCR guidance regarding personal representatives at
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/.
---------------------------------------------------------------------------
We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in
this final rule. Certain portions of this final rule are applicable to
the Medicare Fee-for-Service (FFS) Program, the Medicaid FFS Program,
the CHIP FFS program, Medicare Advantage (MA) organizations, Medicaid
Managed Care plans (managed care organizations (MCOs), prepaid
inpatient health plans (PIHPs), and prepaid ambulatory health plans
(PAHPs)), CHIP Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP
issuers on the FFEs. We use the term ``payer'' in the preamble of this
final rule as an inclusive term for all these programs (and plan types
in the case of plans), but we also use specific terms as applicable in
sections of this final rule. Finally, we use the term ``provider,''
too, as an inclusive term comprising individuals, organizations, and
institutions that provide health services, such as clinicians,
hospitals, skilled nursing facilities, home health agencies, hospice
settings, laboratories, suppliers of durable medical equipment,
community based organizations, etc., as appropriate in the context
used.
II. Technical Standards Related to Interoperability Provisions, and
Analysis of and Responses to Public Comments
A. Technical Approach and Standards
1. Use of Health Level 7[supreg] (HL7) Fast Healthcare Interoperability
Resources[supreg] (FHIR) for APIs
Section 106(b)(1)(B)(ii) of the Medicare Access and CHIP
Reauthorization Act of 2015 (MACRA) defines health IT
``interoperability'' as the ability of two or more health information
systems or components to exchange clinical and other information and to
use the information that has been exchanged using common standards to
provide access to longitudinal information for health care providers in
order to facilitate coordinated care and improved patient outcomes.
Interoperability is also defined in section 3000 of the Public Health
Service Act (PHSA) (42 U.S.C. 300jj), as amended by section 4003 of the
21st Century Cures Act. Under that definition, ``interoperability,''
with respect to health IT, means such health IT that enables the secure
exchange of electronic health information with, and use of electronic
health information from, other health IT without special effort on the
part of the user; allows for complete access, exchange, and use of all
electronically accessible health information for authorized use under
applicable state or federal law; and does not constitute information
blocking as defined in section 3022(a) of the PHSA, which was added by
section 4004 of the Cures Act. We believe the PHSA definition is
consistent with the MACRA definition of ``interoperability''.
Consistent with the CMS Interoperability and Patient Access
[[Page 25515]]
proposed rule (84 FR 7619), we will use the PHSA definition of
``interoperability'' for the purposes of this final rule.
We believe the PHSA definition of ``interoperability'' is useful as
a foundational reference for our approach to advancing the
interoperability and exchange of electronic health information for
individuals throughout the United States, and across the entire
spectrum of provider types and care settings with which health
insurance issuers and administrators need to efficiently exchange
multiple types of relevant data. We noted the PHSA definition of
``interoperability'' is not limited to a specific program or
initiative, but rather can be applied to all activities under the title
of the PHSA that establishes ONC's responsibilities to support and
shape the health information ecosystem, including the exchange
infrastructure for the U.S. health care system as a whole. The PHSA
definition is also consistent with HHS's vision and strategy for
achieving a health information ecosystem within which all individuals,
their personal representatives, their health care providers, and their
payers are able to send, receive, find, and use electronic health
information in a manner that is appropriate, secure, timely, and
reliable to support the health and wellness of individuals through
informed, shared decision-making,\8\ as well as to support consumer
choice of payers and providers.
---------------------------------------------------------------------------
\8\ See, for example, Office of the National Coordinator.
(2015). Connecting Health and Care for the Nation: A Shared
Nationwide Interoperability Roadmap, Final Version 1.0. Retrieved
from https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf.
---------------------------------------------------------------------------
We summarize the public comment we received on use of the PHSA
definition of ``interoperability'' and provide our response.
Comment: One commenter specifically supported the use of the PHSA
definition of ``interoperability''.
Response: We appreciate the commenter's support.
A core policy principle we aim to support across all policies in
this rule is that every American should be able, without special effort
or advanced technical skills, to see, obtain, and use all
electronically available information that is relevant to their health,
care, and choices--of plans, providers, and specific treatment options.
In the proposed rule, we explained this included two types of
information: personal health information that health care providers and
health plans, or payers, must make available to an individual, such as
their current and past medical conditions and care received; and
information that is of general interest and should be widely available,
such as plan provider networks, the plan's formulary, and coverage
policies (84 FR 7619).
We also discussed that while many consumers today can often access
their own electronic health information through patient or enrollee
portals and proprietary applications made available by various
providers and health plans, they must typically go through separate
processes to obtain access to each system, and often need to manually
aggregate information that is delivered in various, often non-
standardized, formats. The complex tasks of accessing and piecing
together this information can be burdensome and frustrating to
consumers.
An API can be thought of as a set of commands, functions,
protocols, or tools published by one software developer (``A'') that
enable 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, all while maintaining consumer
privacy data standards.\9\ This is how API technology enables the
seamless user experiences associated with applications familiar from
other aspects of many consumers' daily lives, such as travel and
personal finance. Standardized, transparent, and pro-competitive API
technology can enable similar benefits to consumers of health care
services.\10\
---------------------------------------------------------------------------
\9\ See https://www.hl7.org/fhir/security.html for information
on how FHIR servers and resources integrate privacy and security
protocols into the data exchange via an API.
\10\ ONC has made available a succinct, non-technical overview
of APIs in context of consumers' access to their own medical
information across multiple providers' EHR systems, which is
available at the HealthIT.gov website at https://www.healthit.gov/api-education-module/story_html5.html.
---------------------------------------------------------------------------
While acknowledging the limits of our authority to require use of
APIs to address our goals for interoperability and data access, we
proposed to use our programmatic authority to require that a variety of
data be made accessible by requiring that MA organizations, Medicaid
state agencies, Medicaid managed care plans, CHIP agencies, CHIP
managed care entities, and QHP issuers on the FFEs, adopt and implement
``openly published,'' or secure, standards-based APIs. In the CMS
Interoperability and Patient Access proposed rule, we used the short
form terminology, ``open API''. We appreciate that this term can be
misunderstood to mean ``open'' as in ``not secure''. In actuality, an
``open API'' is a secure, standards-based API that has certain
technical information openly published to facilitate uniform use and
data sharing in a secure, standardized way. To avoid this
misinterpretation, we will use the term ``standards-based API'' in this
final rule where we used ``open API'' in the proposed rule. This is
also in better alignment with the terminology used in the ONC 21st
Century Cures Act proposed rule (84 FR 7453) and final rule (published
elsewhere in this issue of the Federal Register). We noted that having
certain data available through standards-based APIs would allow
impacted enrollees to use the application of their choice to access and
use their own electronic health information and other related
information to manage their health. See section III.C.2.a. of the CMS
Interoperability and Patient Access proposed rule for further
discussion (84 FR 7629).
Much like our efforts under Medicare Blue Button 2.0, also part of
the MyHealthEData initiative, which made Parts A, B, and D claims and
encounter data available via an API to Medicare beneficiaries, the
policies in this rule extend these benefits to even more patients. As
of January 2020, over 53,000 Medicare beneficiaries have taken
advantage of Blue Button. Currently, there are 55 production
applications and over 2,500 developers working in the Blue Button
sandbox. For more information on Blue Button 2.0 see section III. of
this final rule. As we noted in the CMS Interoperability and Patient
Access proposed rule, we believe that our Patient Access API, in
particular, will result in claims and encounter information becoming
easily accessible for the vast majority of patients enrolled with
payers regulated by CMS. As finalized, these policies will apply to all
MA organizations, all Medicaid and CHIP FFS programs, all types of
Medicaid managed care plans (MCOs, PIHPs, and PAHPs), as well as CHIP
managed care entities, and QHP issuers on the FFEs. We hope that states
operating Exchanges might consider adopting similar requirements for
QHPs on the State-Based Exchanges (SBEs), and that other payers in the
private sector might consider voluntarily offering data accessibility
of the type included in the policies being finalized here so that even
more patients across the American health care system can easily have
and use such information to advance their choice and participation in
their health care. In this way, we hope that the example being set by
CMS will raise consumers' expectations and
[[Page 25516]]
encourage other payers in the market to take similar steps to advance
patient access and empowerment outside the scope of the requirements
being finalized in this rule.
We explained in the CMS Interoperability and Patient Access
proposed rule (84 FR 7620) that those seeking further information
regarding what a standards-based API is are encouraged to review the
discussion of the standardized API criterion and associated policy
principles and technical standards included in ONC's 21st Century Cures
Act proposed rule (84 FR 7424) and final rule (published elsewhere in
this issue of the Federal Register). These rules provide more detailed
information on API functionality and interoperability standards
relevant to electronic health information. We noted that while that
discussion was specific to health IT, including Electronic Health
Records (EHR) systems, certified under ONC's Health IT Certification
Program rather than the information systems generally used by payers
and plan issuers for claims, encounters, or other administrative or
plan operational data, it included information applicable to
interoperability standards, as well as considerations relevant to
establishing reasonable and non-discriminatory terms of service for
applications seeking to connect to the standards-based API discussed in
this rule. While we reiterate that we did not propose to require payers
to use Health IT Modules certified under ONC's program to make
administrative data such as claims history or provider directory
information available to enrollees, we believe that the discussion of
APIs and related standards in the ONC 21st Century Cures Act rules will
be of use to those seeking to better understand the role of APIs in
health care information exchange.
We also discussed in our proposed rule how other industries have
advanced the sort of standards-based API-driven interoperability and
innovation that we seek in the health system (84 FR 7620). We have
sought to collaborate and align with ONC's proposed and final policies
specifically related to APIs under the Cures Act as we developed and
finalized these policies. In general, as we noted in our proposed rule,
we believe the following three attributes of standards-based APIs are
particularly important to achieving the goal of offering individuals
convenient access, through applications they choose, to available and
relevant electronic health and health-related information:
The API technologies themselves, not just the data
accessible through them, are standardized;
The APIs are technically transparent; and
The APIs are implemented in a pro-competitive manner.
In that section of the CMS Interoperability and Patient Access
proposed rule, we discussed these concepts generally and how they were
applicable in the health care context for all payers, and explained how
these were relevant to our specific proposals, which are discussed in
detail in section III. of this final rule. To revisit this full
discussion, see the proposed rule (84 FR 7620 through 7621). We did not
receive comments on this general discussion. Any comments on specific
proposals that refer to these three attributes are discussed in this
final rule in the context of the specific proposals.
2. Privacy and Security Concerns in the Context of APIs
As we noted in the CMS Interoperability and Patient Access proposed
rule, HHS has received a wide range of stakeholder feedback on privacy
and security issues in response to prior proposals \11\ about policies
related to APIs that would allow consumers to use an app of their
choosing to access protected health information (PHI) held by or on
behalf of a HIPAA covered entity. Such feedback included concerns about
potential security risks to PHI created by an API connecting to third-
party applications and the implications of an individual's data being
shared with these third-party apps at the direction of the individual.
---------------------------------------------------------------------------
\11\ For instance, see discussion of stakeholder comments in the
2015 Edition final rule at 80 FR 62676.
---------------------------------------------------------------------------
As we discussed in our Interoperability and Patient Access proposed
rule (84 FR 7621), deploying API technology would offer consumers the
opportunity to access their electronic health information held by
covered entities (including, but not limited to MA organizations, the
Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers
on the FFEs, and other health insurance issuers in the private
markets), and would not lessen any such covered entity's duties under
HIPAA and other laws to protect the privacy and security of information
it creates, receives, maintains, or transmits, including but not
limited to PHI. A covered entity implementing an API to enable
individuals to access their health information must take reasonable
steps to ensure an individual's information is only disclosed as
permitted or required by applicable law. The entity must take greater
care in configuring and maintaining the security functionalities of the
API and the covered entities' electronic information systems to which
it connects than would be needed if it was implementing an API simply
to allow easier access to widely available public information. In
accordance with the HIPAA Privacy and Security Rules, the covered
entity is required to implement reasonable safeguards to protect PHI
while in transit. If an individual requests their PHI in an EHR be sent
to the third party by unencrypted email or in another unsecure manner,
which the individual has a right to request, reasonable safeguards
could include, for example, carefully checking the individual's email
address for accuracy and warning the individual of risks associated
with the unsecure transmission. We note that the standards-based APIs
discussed in this final rule are secure methods of data exchange.
HIPAA covered entities and their business associates continue to be
responsible for compliance with the HIPAA Rules, the Federal Trade
Commission Act (FTC Act), and all other laws applicable to their
business activities including but not limited to their handling of
enrollees' PHI and other data. As we stated in the CMS Interoperability
and Patient Access proposed rule (84 FR 7610), nothing proposed in that
rule was intended to alter or should be construed as altering existing
responsibilities to protect PHI under the HIPAA Rules or any other laws
that are currently applicable.
However, we acknowledged that a number of industry stakeholders may
mistakenly believe that they are responsible for determining whether an
application to which an individual directs their PHI employs
appropriat